Re: [TLS] ban more old crap

[Hubert Kario <[e-mail]>]

On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote:
> > And I completely agree. FREAK and Logjam wouldn't happen at all if we
> > didn't drag with us stuff that was considered legacy 10 years ago.
> > 
> > But stuff like "server MUST abort handshake if it sees export grade
> > ciphers in Client Hello" (or anything similar) will just get ignored. For
> > a user a bad connection is better than no connection. One works and the
> > other doesn't, the details are voodoo witchcraft.
> 
> To be clear, the wording I have in the PR is not this broad. It only
> requires aborting if export ciphers were offered by a TLS 1.3+ client, not
> just any client.

and how a server can tell that the client is TLS1.3 only and not TLS1.0-up-to-
TLS1.3?

> The point is to ensure that all TLS 1.3 implementations
> cut this out and don't regress due to error or exploit. Applying it to
> everything would, unfortunately, be a mess. In particular, search engine
> spiders actually have a legitimate reason to have export ciphers actually
> still enabled.

and not only them, opportunistic encryption in SMTP is another example

technically it's already in the draft, isn't it? - TLSv1.3 supports only AEAD, 
all export ciphers were either CBC or stream mode - if you intend to accept 
only TLS1.3 reply from server there's no point in including them, moreover 
negotiating them is a clear bug and protocol violation anyway

but if you want a "clients SHOULD NOT advertise support for ciphersuites 
incompatible with TLS1.3 if it will not accept a TLS1.2 or lower protocol 
reply from server" as a reminder/idea for implementers then it certainly won't 
hurt
-- 
Regards,
Hubert Kario
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