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
