On Friday, 2 September 2016 12:23:03 CEST Eric Rescorla wrote: > I agree. FWIW, this is how NSS behaves. A clarifying PR would be welcome > here.
that was an easy one: https://github.com/tlswg/tls13-spec/pull/622 since there's already text prohibiting that situation: The ServerHello MUST only include extensions which are required to establish the cryptographic context. Currently the only such extensions are "key_share", "pre_shared_key", and "early_data". Clients MUST check the ServerHello for the presence of any forbidden extensions and if any are found MUST terminate the handshake with a "illegal_parameter" alert. and Extensions which are designated to appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST terminate the handshake with an "illegal_parameter" alert. > 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 -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
