Re: [TLS] tls-flags: abort on malformed extension

[Ilari Liusvaara <[e-mail]>]

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