Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

[Hubert Kario <[e-mail]>]

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