On Tue, Nov 28, 2023, at 05:03, Watson Ladd wrote: >> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to >> indicate a value; remember, this column indicates the messages in which the >> extension may appear. Currently, it’s “”. “N/A" has been suggested, which >> makes sense to me considering this extension never directly appears in CH, >> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that >> means not used in TLS 1.3. “” is used elsewhere in the registry by only for >> unassigned and reserved values. The following PR change “” to “N/A”: >> https://github.com/tlswg/draft-ietf-tls-esni/pull/59 > > The only alternative I can think of is to introduce CHI, standing for > client hello inner, as a possible value for that field. Then we need > to update all the other values in the registry as well. I understand > why we got to N/A, but the subtlety of N/A vs - vs the empty string > irks me a bit, especially as this is used in TLS 1.3, hence the list > is applicable, it's just empty!
"CH" seems fine to me. That it can only appear in the inner CH is a very important detail, but one that is addressed in the specification. Many other extensions have conditions on when they can be included in a message. This might be a new level of conditionality, but it seems like implementing the specification will clear up any confusion. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
