On Mon, Oct 11, 2021 at 01:12:14PM +0200, Hubert Kario wrote: > On Thursday, 7 October 2021 20:37:22 CEST, Yoav Nir wrote: > > > > OK, so now my response: > > > > I agree with the first and second comments. About the third, what I > > meant was that a supported flag that is supposed to appear only in CH > > appears instead and CR, or more likely, a flag that should appear in EE > > apears in SH instead. > > > > But I think the best way to resolve the issue is to remove the bullet > > point list and the last sentence before them, IOW: remove the examples. > > Clients aborting on unrecognised flags in SH or EE is expected, that's what > already happens for normal extensions, but yes, it's too strong for CH. > Maybe > also NST.
I presume flags should mirror how extensions behave (being essentially compact encoding for zero-length extension), and TLS 1.3 specifies that known unexpected extension in any message, including CH, causes abort with illegal_parameter alert (Reference: RFC 8446, Section 4.2). For unknown extensions, the rule is to ignore any unknown extension in CH, CR and NST, and abort with unsupported_extension on any unknown extension in SH, EE and CT (Reference: RFC 8446, Section 4.2). And there already exists an extension that can trigger the first rule in CH, namely oid_filters. So an implementation that supports that extension is supposed to abort if it receives the extension in CH. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
