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

Brian Smith <brian@briansmith.org> Wed, 13 May 2015 01:57 UTC

Return-Path: <brian@briansmith.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E827F1A8AE8 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 18:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gx1vz--2xH42 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 18:57:00 -0700 (PDT)
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A9E1A871E for <tls@ietf.org>; Tue, 12 May 2015 18:57:00 -0700 (PDT)
Received: by oiko83 with SMTP id o83so20432815oik.1 for <tls@ietf.org>; Tue, 12 May 2015 18:56:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=slquH3Ph58JBoAU7GqtKtUVhER9ubixgPNbAdNoQhjU=; b=AE1pkK7k3piJR/Deae6LMS/H/VdY/EWJqBgu1j8sCTrQHDpHmgHxleOHYcIYD/uDRu r+g4DxuKrm8JcwkwLr/OKCbY+xhzPxMoU2iiqJ0Pa12+deqoQYv8TClb3PsOPgD+X10A Nd4DVL9JFO7FeI5+lPHza6S1CdobJEYLZni0eaFJpgE61CI+WTe/GEt8FkWALHZrdn/g M2awSJmcqOFsc9HGcCsY7nTlP+/ofYxuPc7UmH98cnRwkM3YXFQeNQfpV/vvNwsR8N7e Bf5blKGnPy6JOR57ybvsIE0z/4XAADgF9MY8lBG0iCzOJYc2GK5sWpAAOR+aL/yTXpvP hFzw==
X-Gm-Message-State: ALoCoQmKNjtBY0NdCtdK0x1Wbz/uBr34MbszxoiPHiIOwGCJ0gi0Iiu19V7LkKHqLtY5YIvIPQ6G
MIME-Version: 1.0
X-Received: by 10.182.246.3 with SMTP id xs3mr14013210obc.17.1431482219782; Tue, 12 May 2015 18:56:59 -0700 (PDT)
Received: by 10.76.90.97 with HTTP; Tue, 12 May 2015 18:56:59 -0700 (PDT)
In-Reply-To: <CADMpkcLzW-ci5ZVocQ-Tz9vS6-ngM5vb_0E1P0SZS-obdAZDRw@mail.gmail.com>
References: <20150506101230.32573.26774.idtracker@ietfa.amsl.com> <CADMpkcLzW-ci5ZVocQ-Tz9vS6-ngM5vb_0E1P0SZS-obdAZDRw@mail.gmail.com>
Date: Tue, 12 May 2015 15:56:59 -1000
Message-ID: <CAFewVt5i2gqSJv7vkN-mvcaVRUoUu6iVK8g7DMyx_BQVqrzBSA@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: multipart/alternative; boundary="001a11c2f59e3679a90515ecedcb"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/_Ixv1jq4OHIfCOT2QeXSYma2VeA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fwd: New Version Notification for draft-ieft-tls-falsestart-00.txt
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2015 01:57:04 -0000

On Thu, May 7, 2015 at 5:24 AM, Bodo Moeller <bmoeller@acm.org> wrote:

> - 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
> 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.)
>

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.)


> 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?
>

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