I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome here.
On Fri, Sep 2, 2016 at 12:21 PM, David Benjamin <david...@chromium.org> wrote: > Huh. I agree that text is weird. We should probably remove it. I think we > actually get something akin to what you suggest basically implicitly: > > Servers aren't allowed to send unsolicited extensions, so your SH and EE > parsers should be rejecting any unknown extensions. If you combine that > with not accepting known extensions in the wrong context (unencrypted ALPN > or encrypted key_share) since extensions already specify which messages > they may live in, this all works out. > > So even if we explicitly say this rule, I don't think reflecting it in > code is the cleanest implementation strategy. (It requires one keep a list > of SH extensions and compare against it.) It might be better to say that > extensions in unexpected contexts should be rejected like any other > unexpected extension. > > David > > > On Fri, Sep 2, 2016 at 1:31 PM Hubert Kario <hka...@redhat.com> wrote: > >> So, the draft has following text: >> >> The same extension types MUST NOT appear in both the ServerHello and >> EncryptedExtensions. If the same extension appears in both locations, >> the client MUST rely only on the value in the EncryptedExtensions >> block. >> >> if the extension "MUST NOT" be in both ServerHello and >> EncryptedExtensions, >> why the client should continue with the handshake if a server makes such a >> major mistake? Why aborting the connection in such situation isn't safer? >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech >> Republic_______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
