Re: [1904.4 TF] decisions affecting eOAM attributes for the initial key

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

Thanks for picking that up Glen. I’m on the list now (I think).

Thanks for the feedback Marek. Reply in-line below.

I’ll post my own thoughts on the question separately. Sorry for the duplication.

From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Date: Thursday, August 24, 2023 at 4:11 PM
To: mxhajduczenia@xxxxxxxxx <mxhajduczenia@xxxxxxxxx>, STDS-1904-4-TF@xxxxxxxxxxxxxxxxx <STDS-1904-4-TF@xxxxxxxxxxxxxxxxx>
Cc: Craig Pratt <c.pratt@xxxxxxxxxxxxx>
Subject: RE: [1904.4 TF] decisions affecting eOAM attributes for the initial key exchange

Marek, thank you. Feedback is noted.

+ Craig,

Craig, I noticed you are not on the TF4 reflector. Please, subscribe at https://www.ieee1904.org/4/tf4_reflector.shtml

Also, see below.

From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Wednesday, August 23, 2023 6:56 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] decisions affecting eOAM attributes for the initial key exchange

Hi Glen,

I have some feedback as follows:

Q4 / Q7: 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] Agreed that we should use IANA symbol names and number assignments. But I think we should be explicit about what curves are supported in our spec (or maybe what curves are not supported?)

Q6: 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] Exactly. The fact that RFC8422 eliminated everything but the uncompressed format supports this conclusion. I mean, if the extra bits isn’t an issue for the 20 TLS connections that are opened for a web page, I can’t see why it would be an issue for a PON link.

Q10: 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.

[cp] I don’t really see the harm in the ONU expressing its preferences – so long as the OLT is the final decider. The OLT definitely should call all the shots. And this is consistent with TLS as well. The TLS, the server is presumed to have the more challenging resource management problem, so it gets to pick the curve (and the encryption).

Regards

Marek

From: stds-1904-4-tf@xxxxxxxxxxxxxxxxx <stds-1904-4-tf@xxxxxxxxxxxxxxxxx> On Behalf Of Glen Kramer
Sent: Wednesday, August 23, 2023 6:08 PM
To: 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?

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?

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?

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)

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?

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?

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?

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