Thanks for putting together this list Glen.
Not sure if it’s with convention, but I put my thoughts in-line below.
cp
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Wednesday, August 23, 2023 5:08 PM
To: 'STDS-1904-4-TF@xxxxxxxxxxxxxxxxx' <STDS-1904-4-TF@xxxxxxxxxxxxxxxxx>
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.
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?
[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.
- 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.
- 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)
[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.
- 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.
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.
- 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?
[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.
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