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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
