Re: [TLS] TLS Charter Revision

Brian Smith <> Fri, 13 December 2013 05:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 143A21AE64F for <>; Thu, 12 Dec 2013 21:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7OlDdenFmMfn for <>; Thu, 12 Dec 2013 21:15:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A04441AE64D for <>; Thu, 12 Dec 2013 21:15:29 -0800 (PST)
Received: by with SMTP id e9so1153235qcy.12 for <>; Thu, 12 Dec 2013 21:15:23 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qKZMO9jHq9EKQm1uk4UqrF4EXkrA5Bp2BYEXoflxo8w=; b=Zfp2Pq6mt96e6WQcG/n8XmVSd5ugRY/IZRNNggtykARJmptA6DGffGrk309NfTSCUl NI7v61Er/OkmLEruFQHAleT8n/uQ+4RVzYgdlUYEB7wduYW3kI2Kdmqx+SoL5d2VN55d oqLKFgguTfcn0tEU10LkVkYkDZxzbRjAtSbwU8gDV/qfkPdlFJo7Qz/j3wg9a3DoiAPs krgHcWSFEZmSHXzm9RHZi2uh9nsnaRfQGexgBu/rUebpmsSzbr4tf1KVMJqbfymEIZmB pra6T5KEo4IaaNfoF7xE5ZEw0V/EBcW2ATU1OyhIYlJo4tOkr9K3/jT0CUbiMzhYkvtc nmAA==
X-Gm-Message-State: ALoCoQm2yNFE8LBvVWaN3qvw80kWkCO+/GAsdFx10bh2Fcj60R7MFuZc+cK0rNFwboqHE/qIuYPw
MIME-Version: 1.0
X-Received: by with SMTP id w19mr1131987qef.9.1386911723240; Thu, 12 Dec 2013 21:15:23 -0800 (PST)
Received: by with HTTP; Thu, 12 Dec 2013 21:15:23 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 12 Dec 2013 21:15:23 -0800
Message-ID: <>
From: Brian Smith <>
To: "Salz, Rich" <>
Content-Type: multipart/alternative; boundary=047d7b67795c99526304ed638cea
Cc: "<>" <>
Subject: Re: [TLS] TLS Charter Revision
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Dec 2013 05:15:32 -0000

On Thu, Dec 12, 2013 at 7:22 AM, Salz, Rich <> 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.


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.

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)