RE: decisions affecting eOAM attributes for the initial key exchange

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Hi all,

I was sitting on this email for a while and re-reading all the feedback. Some things still donâ??t add up for me.

For reference, I merged all received responses together and they are shown below (in green). I added my new comments (in blue) inline.

Thanks,

Glen

From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Wednesday, August 23, 2023 5:08 PM
Subject: decisions affecting eOAM attributes for the initial key exchange

Hi all,

As a reminder, at the last meeting, we have decided to go with the â??2 attributes / 4 OAMPDUsâ?? solution.

Now, to develop formal definitions for these attributes, we need to clarify several things. The 10 questions below (in red) are mainly for Steve and Craig, but everyone is welcome to chime in.

Attribute #1: List of supported curves (RO)

IANA defines the name space (registry) for the elliptic curves: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

RFC4492 included 25 curves from the above list. RFC 8422 deprecated most of them and listed only these curves:

secp256r1 (23), secp384r1 (24), secp521r1 (25), x25519 (29), x448 (30)

The first three curves are specified in SEC 2 [SECG-SEC2] and are also recommended in ANSI X9.62 [ANSI.X9-62.2005] and FIPS 186-4 [FIPS.186-4]

But IANA shows secp256r1 (23), secp384r1 (24), x25519 (29), x448 (30) as recommended for use and secp521r1 (25) is listed as â??not recommendedâ??

Q1: Is there a reason to have more than one curve as mandatory?

Q2: Which curve(s) do we list as mandatory to support?

[cp] I think we should just see if any of them have any undue requirements â?? esp x25519 and x448. secp256r1 and secp384r1 are widely supported and should be required IMHO.

[GK] Note that RFC 8422 doesnâ??t say that all of the listed 5 curves are mandatory to implement. I wonder if we are unnecessarily burdening ONUs with the mandatory support for that many curves.

As of 2018, x25519 was second popular after the secp256r1 (https://malware.news/t/everyone-loves-curves-but-which-elliptic-curve-is-the-most-popular/17657)

[sjg] Always a good idea to support more than one because the one may be determined as unsafe. Iâ??m not sure it matters what external normative source we go with. The benefit of IANA is itâ??s international in contrast to NIST or ANSI. And, the benefit of saying â??Support the curves IANA citesâ?? ensures future compatibility of our standard.

[GK] So, we can say that ONU shall support secp256r1 and x25519 and may support other curves listed in IANA TLS Supported Groups registry.

Q3: If ONU supports any of the curves beyond the 5 listed above, do we even want the ONU to report them?

Q4: Do we list all curve IDs in our standard, so simply point to IANA?

[mh] I would prefer to point to IANA if possible â?? that eliminates the need to keep track of any updates made over time, so that we do not have to update our standard but maintain reference to IANA

[cp] I mean, if we stick to using IANA-numbered curves (I think we should use IANA names and IDs), I canâ??t see any issue with the ONU listing them. It might ease migration to new curves if/when necessary. 1904.4 can just specify which are required.

[GK] I agree with both responses above. But is IANA all we need to point to?

[sjg] Itâ??s always a good idea to leave the operators latitude in choosing how they secure their services without sacrificing interoperability. If they want to use other curves, and their supporting suppliers are willing to do so, why not allow that? Of course, it means some complexity for some suppliers; but it also allows applicability across the globe where a given government or operator might at any time decide they want to do something special.

[GK] The question then is where these â??other curvesâ?? come from? If they are enumerated by IANA, then ONUs can simply report the corresponding curve_IDs, even if IANA adds them after IEEE 1904.4 approval. But if they are not, then we have to devise a different reporting system. Hence my question below (Q8) if we should support private-use curves.

Types of curves

In addition to named curves, IAN shows two additional curve types: explicit_prime and explicit_char2 (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-10)

But RFC 8422 says: â??The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this specification.â??

Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Q5: Should we follow the RFC 8422 lead and stay with only the named curves?

[cp] This is definitely my recommendation. Keep it simple â?? and 8422 takes the same tack.

[sjg] I agree we should stay close to our normative reference.

[GK] Agreed, we are not going to bother with â??unnamed curvesâ??.

Point format

Similarly to curve types, IANA lists three point formats: uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2 (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-9).

RFC8422 deprecated two of them and only kept the uncompressed.

Q6: Do we also keep only the uncompressed point format? (Q5 and Q6 are tied together, I believe)

[mh] uncompressed format will consume more OAM bandwidth but we will not be exchanging these all the time so I am not concerned about it too much. Eliminating compression eliminated extra complexity and potential failure steps IMHO

[cp] This is definitely my recommendation here as well â?? the savings is so small itâ??s not worth using the non-uncompressed format â?? and itâ??s definitely not worth negotiating.

[GK] Agreed and Agreed.

Extensibility of curve list

Previously, it was mentioned in our discussions that we should allow the capability of extending the list of curves in the future. This needs to be clarified.

Q7: Does extensibility assume ONUâ??s ability to report future curves that are not listed in the 1904.4, but that will be listed in in the future in other standards or in IANA?

[cp] Mentioned this above, but I donâ??t see any reason to not allow the ONU to express whatever curves it can support. It could ease migration to new curves if/when they might be necessary. We just need to maintain which ones are required, IMHO, by both ONUs and OLTs.

[GK] Agreed, but if IANA is not the only registry, we need to add a prefix to the curve-IDs as explained below.

The RFC 8422 states that curve-ID values 0xFE00 through 0xFEFF are reserved for private use.

Q8: Should the 1904.4 also allow ONUs to report private-use curves?

Q9: How should the OLT differentiate private-use curves reported by ONUs from different vendors? Should we include OUI to disambiguate the domain of the private-use curve-IDs?

[cp] Well the real question, IMHO, is whether we should use a code to differentiate curves from other key establishment Â methods. I think we should have our own prefix for the key establishment method â?? with e.g. â??1â?? designated to refer to â??TLS EC Curve Typesâ?? and other values (2-255) reserved.

[GK] I think in more general terms, the prefix needs to identify the domain of the IDs of the key establishment methods. â??1â?? would refer to â??IANA TLS Group Registryâ??.Â There could be other documents, listing other curve IDs and/or non-curve IDs. Those documents define the exact key establishment methods for the listed IDs.Â Note that IANA TLS Group Registry lists both Elliptic Curves and Finite Field DH groups, all within the same 16-bit ID space.Â

Q8 above asked if we should also reserve â??255â?? for â??Private-use KEMâ??. These are curves or other methods based on vendor own specifications. If we do that, then the private KEM domain would consist of prefix 255 followed by vendor OUI to distinguish the ID space of one vendor from the ID space of another vendor. Use of OUIs is a typical IEEE method of adding vendor-specific extensions to message formats or TLV formats.

Order of curve-IDs in the list

The RFC8422 states that â??Items in named_curve_list are ordered according to the client's preferences (favorite choice first).â??

Q10: How can ONU decide that one curve is more preferable than another curve? If ONU supports multiple curves, does it care which one will the OLT choose?

[mh] in all other cases, ONU does what OLT tells it to do. I do not see a reason for it to be any different in here, i.e., OLT picks the curve, ONU applies the curve. The end.

[GK] That is certainly more in-line with EPON approach. For example, for the ONU reporting of its supported OAM versions, the standard says â??No particular ordering of OAM versions in the list is assumed.â?? The seelction is done exclusively by the OLT.

[cp] I donâ??t really see any harm in this â?? so long as the OLT is the complete authority about which one is used. If an OLT considers some key establishment methods equivalent (from a security and resource perspective), then it can use the KEM highest in the ONU-specified list. And it really doesnâ??t add any complexity.

[GK] My first point is that this cannot be a requirement, because this is not testable (in other words, any order reported by ONU would pass the test).

The second point is that for the OLT, it is an issue of both complexity and ambiguity:

Ambiguity: does the OLT trust its own order or it follows the ONUâ??s order?

The OLT and/or the NMS know how secure each method is and can choose the best one.Â Based on operatorâ??s configuration, the OLT has to maintain its own order of preference and it should choose the first ID in its list that is supported by the ONU, even if the ONU listed that ID last.

Complexity: In order to make any use of ONUâ??s preferential order, the OLT needs to maintain a more complicated scheme of ordering priorities, where multiple KEMs can reside at the same priority level, so the tie-breaking can be delegated to the ONU. This is an unnecessary complexity. If the OLT has simple sequential priority order (like all KEM IDs stored sequentially in an array in order of their preference), then there will never be a need or an opportunity for tie breaking by the ONU.

[sjg] Will there be a corresponding information and data model to what we specify. If so, this becomes an ordered list and weâ??ll set the priority. If the operator or their suppliers want to overhaul the model and change the order, that is up to them. If there is no model, there should be a configuration setting that allows the operator to specify which curves to support and in which order of preference.

[GK] Yes, that is right, but this order needs to exist only in the OLT. ONUâ??s preference doesnâ??t play a role.

Thank you,

Glen

To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1