On Sun, Mar 13, 2016 at 11:14:13AM +0000, Stephen Farrell wrote: > First, with no hats, if the WG were to have a poll on whether > or not to include 0rtt in TLS1.3, then as a participant in the > work here, I'd be firmly arguing to leave it out entirely. I > really think an over-emphasis on reducing latency for browsers > is going to bite us (and the Internet) in the ass in the same > ways that emphasising interop over security has in the past with > fallbacks to older, worse versions of TLS/SSL, with all their > inherent flaws and bits of e.g. crappy "export" crypto support. > Absent 0rtt, TLS1.3 seems to me to be an excellent step forward > in security. With 0rtt, I think it also becomes a dangerous > implement. So, that's my personal opinion, while not wearing an > AD hat.
I think you're exactly right. Let's look at the vulnerabilities in TLS:
- Renegotiation attack
- Optimization to establish a new TLS session without reestablishing a
TCP/IP connection. Broken repeatedly despite analysis, etc.
- TLSv1.3's answer? Drop renegotiation.
- BEAST
- CBC chained off the last block sent so that an explicit IV need not
be sent on the wire. Another optimization.
- TLSv1.3's answer? Drop CBC.
- CRIME / BREACH
- Compression was supported to speed up connections (less data to
process/transfer). Optimization, again.
- TLSv1.3's answer? Drop compression.
- Lucky Thirteen / Padding timing attacks / POODLE
- Years later, servers are still vulnerable because insecure
algorithms & versions remain enabled, even with the publicity around
POODLE
- TLSv1.3's answer? Drop the bad cipher suites and offering < 1.0.
- RC4
- RC4 is known to be weak, but it continues to be widely used
- SSL/TLS included it because analysis said it was secure as used.
- TLSv1.3's answer? Drop RC4.
- FREAK / Logjam (downgrade attacks)
- This happened because TLS vendors left obsolete export algorithms
implemented, and server admins left them enabled.
- TLSv1.3's answer? Drop the insecure cipher suites.
- DROWN
- Why is this even an issue? Because people STILL haven't turned off
SSLv2 *twenty* *years* after it was known to be insecure!!
- TLSv1.3's answer? Drop compatibility with SSLv2.
So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?
What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?
If almost everyone should turn it off, why are we including it?
Most server admins won't be reading the TLSv1.3 spec. They're going to
see "shiny feature added specifically in this version that makes it
faster!" with *maybe* a warning that there are risks, which they'll
dismiss because "if it was so insecure, they wouldn't have included it
in the protocol in the first place." Unless 0-RTT can be fixed, it
looks like an attractive nuisance.
Let's leave it out.
--
Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
