Re: [TLS] TLS Charter Revision

[Brian Smith <[e-mail]>]

On Thu, Dec 12, 2013 at 7:22 AM, Salz, Rich <[e-mail]> wrote:

> I am concerned about the 'political' emphasis on reducing round trips. One
> of the arguments heard I hear against 'https everywhere' is that the extra
> round-trips' cause too much latency and impact customer's web experience.
> If we can work to reduce RTT without sacrificing security, then that's
> great and I would like to see "while maintaining security features" or some
> such added.
>

Rich,

I think you make a very good point. I'd like to clarify, though, that at
least the 1-RTT full handshake proposals are actually not just about
increasing performance, but also about increasing security. A 1-RTT full
handshake improves performance over the case where the client does not use
the TLS False Start mechanism. A new 1-RTT full handshake will improve
security over the case when a client *does* use False Start. (It turns out
that there are more practical security considerations with False Start than
seemed to be the case at first.) Also, a new 1-RTT handshake has the
potential to improve privacy/confidentiality of information in the
handshake. Finally, the 1-RTT handshake would make it esaier to deploy TLS
because it reduces the need for distributed session caches or distributed
session ticket keys--if you're happy to pay the CPU cost of full
handshakes, but not the latency cost of 2-RTTs, then per-host sessions may
work just fine for you.

Consequently, I see the 1-RTT handshake as improving security, privacy,
performance, and ease of deployment at the very small cost of some reduced
flexibility. (But, you get that flexibility back by falling back to the
2-RTT full handshake.)

The 0-RTT handshake ideas I've seen are a little different. There, we may
have to make a security/performance tradeoff, because there are more ways
where an operational failure can make things go bad. I suspect that server
admins will have to decide whether to make this tradeoff or not, after
we've done all we can do to minimize the associated security risks in the
protocol definition. In other words, I think that we should consider
features that have reasonable security tradeoffs, but we should make those
features optional.


> I would like to add a bullet that says backward compatibility with
> previous versions is not a requirement. Given all that downgrade fallback
> issues that continually arise here, we should strongly consider if the
> right thing to do is just break the chain.
>

If there is a way to avoid requiring backward compatibility, that doesn't
add latency when the server only speaks current versions of TLS, then it is
something to consider. But, at least browsers need to work with existing
SSL 3.0-TLS 1.2 servers, without performance regressions, for many years to
come. That leads me to think that the ClientHello message must be backward
compatible with older versions of TLS, at least.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)