On Tuesday 12 July 2016 15:31:21 Benjamin Kaduk wrote:
> >> ### Encrypted Extensions
> >>
> >> 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. All server-sent extensions other than those explicitly listed
> >> in {{server-hello}} or designated in the IANA registry MUST only
> >> appear in EncryptedExtensions. 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.
>
> > This seems inconsistent. In implementation, I would write explicit disjoint
> > whitelists of extensions for both (and non-whitelisted one is a fatal
> > error). Explicit whitelisting is safe even on client side, since the
> > extensions are bounded by client-supported ones.
>
> You would have an explicit whitelist of all (including encrypted)
> extensions for the server, so that it chokes when a client starts
> sending a new one? Or just that it would not be considered for further
> processing [and potential inclusion in ServerHello]?
> I'd rather not see a mechanism that will introduce TLS extension intolerance in compliant implementations. IMNSHO this is the uncommon situation where a blacklist is the correct solution -- 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
