Subject: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt

From: Bodo Moeller <[email-masked]>
Date: Thu, 7 May 2015 17:24:31 +0200

As discussed with Sean, draft-ieft-tls-falsestart-00 intentionally is
essentially a copy of draft-bmoeller-tls-falsestart-01 (with only metadata
updated), not because we don't want to make changes but because we want to
start doing these between -00 to -01 for ease of tracking.

I intend to change the following (and then expect new comments on the
updated I-D resulting in a -02 revision):

- The intended status should probably be "Informational".

- Be clear that the document does not apply to TLS 1.3 and beyond, because
these protocols come with new protocol flows designed to reduce the number
of round-trip times.

- Remove server-side False Start entirely, as the document (now) is mainly
about describing existing deployments. (Server-side False Start isn't
entirely pointless, but I don't think anyone ever saw a sufficiently
compelling case for it to actually deploy it.)

- State explicitly that for client implementations with a maximum version
of TLS 1.2, normally the protocol version whitelist should be TLS 1.2 only
(but clients that don't support TLS 1.2 may be using False Start with
earlier protocol versions, and clients that support TLS 1.3 might disable
False Start entirely -- that's what the TLS_FALLBACK_SCSV language is
really about).

- Recommend against use of False Start with (EC)DHE on any kind of explicit
groups, and on named groups of insufficient size. (I don't think we should
try to predict whether the ffdhe groups from
draft-ietf-tls-negotiated-ff-dhe-08 will catch on with TLS 1.2, so False
Start with traditional DHE shouldn't be entirely left out.)

Then Brian had a comment about False Start with client certificates. I'm
not yet sure what to make out of that. The main point of mentioning client
certificate types in the I-D was to make sure that False Start isn't used
with rsa_fixed_dh and the like (since client implementations might allow
mixing client-side static DH with server-side ephemeral DH, assuming they
support DH certs at all). Sending client certs in the clear may not be a
good idea, but that issue seems entirely orthogonal to what False Start is
all about. Do you see an actual problem about sending a client's signing
cert specifically in a False Start handshake?

Bodo

---------- Forwarded message ----------
From: <[email-masked]>
Date: 2015-05-06 12:12 GMT+02:00
Subject: New Version Notification for draft-ieft-tls-falsestart-00.txt
To: Adam Langley <[email-masked]>, Bodo Moeller <[email-masked]>,
Nagendra Modadugu <[email-masked]>, Nagendra Modadugu <
[email-masked]>

A new version of I-D, draft-ieft-tls-falsestart-00.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Name:           draft-ieft-tls-falsestart
Revision:       00
Title:          Transport Layer Security (TLS) False Start
Document date:  2015-05-06
Group:          Individual Submission
Pages:          11
URL:
https://www.ietf.org/internet-drafts/draft-ieft-tls-falsestart-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ieft-tls-falsestart/
Htmlized:       https://tools.ietf.org/html/draft-ieft-tls-falsestart-00

Abstract:
   This document specifies an optional behavior of TLS implementations,
   dubbed False Start.  It affects only protocol timing, not on-the-wire
   protocol data, and can be implemented unilaterally.  The TLS False
   Start feature leads to a latency reduction of one round trip for
   certain handshakes.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 7 May 2015 18:04:57 +0200

Gah, it turns out I published the I-D as an IEFT document, not an IETF
document. (I just learnt that the submission tool does not check the file
name against the metadata in the file.) Expect
https://www.ietf.org/internet-drafts/draft-ietf-tls-falsestart-00.txt to
show up soon.

Bodo

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 May 2015 16:25:22 -0500

On 7 May 2015 at 10:24, Bodo Moeller <[email-masked]> wrote:
> Sending client certs in the clear may not be a good idea, but that issue
> seems entirely orthogonal to what False Start is all about. Do you see an
> actual problem about sending a client's signing cert specifically in a False
> Start handshake?

If a client is willing to send their certificate in the clear, I see
no reason to prevent them from sending this during False Start.  The
main risk with False Start is that the server has an increased risk of
being impersonated.  But the certificate is in the clear, so it's
unclear what a client could lose by this.

It's different if they were holding out for TLS 1.3 in the hopes that
they might have confidentiality for the certificate.  But that's a
stack problem more than anything else.  A stack might be configured
for client certificate confidentiality and use TLS 1.3, or TLS <= 1.2
and renegotiation to accomplish that end depending on the ServerHello
that it sees.

If the client certificate is to be enciphered in an immediate
renegotiation handshake, and both initial and renegotiation use False
Start, the client should probably check the Finished message on the
first before completing the renegotiation. Unless there are issues
delaying the Finished delivery, the client should have that prior to
when it needs to send the certificate.

---

From: Brian Smith <[email-masked]>
Date: Tue, 12 May 2015 15:56:59 -1000

> - The intended status should probably be "Informational".

I think it is worthwhile for it to be a standards-track document.
"Informational" status would likely result in it not getting sufficient
review.

> - Recommend against use of False Start with (EC)DHE on any kind of
> explicit groups, and on named groups of insufficient size. (I don't think
> we should try to predict whether the ffdhe groups from

To clarify my previous suggestion: I suggest removing the mentions of DHE
and recommending to not do DHE with False Start at all unless/until we have
agreed on the text for criteria for allowing DHE. I think it will be a
while before the text for DHE criteria are agreed to, and having text
suggesting that DHE as commonly implemented is OK to do with False Start is
harmful. Also note that Google Chrome dropped support for False Start with
DHE cipher suites the day I suggested that they do so on this mailing list
a few weeks ago, so neither Firefox nor Chrome (will) support it. (If there
are any more clients that still support False Start with DHE cipher suites,
they probably should stop doing so soon.)

> cert specifically in a False Start handshake?

Assume that the client is an agent of some real person who is using a
certificate that binds their identity to the certificate's keypair. For
example, this might be a government-issued smartcard that is used for
e-voting or taxpaying. The certificate contains personally-identifying
information including the user's name and/or location of residence.

Obviously, it's terrible to send that information in the clear. It is true
that TLS already encourages it to be sent in the clear, without False
Start. Encouraging this malpractice by giving it the False Start
performance boost effectively discourages us from fixing the privacy issue.

But, let's say we don't care about improving privacy. Then, would it be OK
to False Start when client certificates are used? It isn't clear to me that
it is OK. By signing the CertificateVerify with the his private key, the
client end-user is offering a level of non-repudiation for any content that
he/she sends on the connection. Potentially that non-repudiation could have
serious (e.g. legal) consequences for the end-user, so it seems better to
err on the side of caution and wait for the handshake to be fully
authenticated before sending any application data.

Also, there are some regulations regarding how TLS is to be done in certain
environments (e.g. US Government DoD), and it seems likely that False Start
is inappropriate according to those regulations. Client certificates are
often used in such environments, and so by not supporting False Start with
Client Certificates, we end up doing the right thing there. In other words,
requesting a client certificate is a strong indicator that the server
probably doesn't want us to do False Start.

Also, frankly, use of client certificates is rare in the types of stuff I
normally work on, and there was (is) no motivation to optimize that case.
So, it literally wasn't (isn't) a good use of time to analyze whether False
Start should be used with client certificates.

ChannelID is quite a lot like client certificates and I understand why one
would hope that ChannelID and False Start work well together. It seems
likely that considerations that apply to client certificates also apply to
ChannelID, but I don't think we should use an analysis of False Start with
client certificates as a proxy for an analysis of False Start with
ChannelID. Especially since ChannelID got reformulated into an
application-layer thing en route to being standardized, it seems better to
analyze it separately.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Tue, 12 May 2015 16:08:12 -1000

> when it needs to send the certificate.

We should just say that False Start should only be done during the initial
handshake, and MUST NOT be done during renegotiation. Do any
implementations False Start during renegotiation?

Note that you can create a session during the initial TLS handshake and
then resume that session during the renegotiation, so there was already a
way to nearly guarantee a 1-RTT renegotiation handshake with vanilla TLS,
as long as both sides support session resumption. And, if either
implementation is too conservative to implement session resumption, that's
a good hint that they'd rather not do False Start either.

Cheers,
Brian