On Tue, Nov 21, 2023 at 9:03 PM Sean Turner <s...@sn3rd.com> wrote:
>
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure we 
> have agreement on the two changes to the registrations in s11.1. If you don’t 
> agree with the values proposed below please let the list know by 1 December 
> 2023.
>
> 1. The encrypted_client_hello and ech_outer_extensions registrations need to 
> indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is 
> the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>
> 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!

Sincerely,
Watson

>
> Cheers,
> spt
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Astra mortemque praestare gradatim

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to