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

Martin Thomson <martin.thomson@gmail.com> Thu, 07 May 2015 21:27 UTC

Return-Path: <martin.thomson@gmail.com>
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 861531B2C23 for <tls@ietfa.amsl.com>; Thu, 7 May 2015 14:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 NnKbtOLlZyVB for <tls@ietfa.amsl.com>; Thu, 7 May 2015 14:27:16 -0700 (PDT)
Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (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 441551B2B48 for <tls@ietf.org>; Thu, 7 May 2015 14:25:23 -0700 (PDT)
Received: by yhcb70 with SMTP id b70so14626366yhc.0 for <tls@ietf.org>; Thu, 07 May 2015 14:25:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q/BsMuvbfvGHWej4WotTyjoaS1sGmrTLGR44DLjcIB4=; b=IrwKlsb6Bk3N2EYR9maOQ/qj8OkVoM8SKIoSU5fIMhz5JR6TwGY9eSlC7vH8JGRsY5 lGPhVUBcvmfxLlZbe1A06Tf5ebuyrhK/S8If7ZJnTHMCBdxq89wrtf9mzYxmij96i+Ht pGc779q9lAbu/L1U3rwN5uu+Ht8+c6sXvIirTtNINaNlb1ppl0GhlaoAMQK5r7KSZM8h Gi6mtNbd6CkqQYu15whjAwFlu6UZeVfVoBOJDoTMeUA7GKnLDZFrqPZGsPWK5HghaP4M a7PiIIZPgY5cqQ6Xho0KgSqJC0+d73g0uLFsxXaXOauP2edxpd4nihAOJQ6G/NbAcPuM WIGQ==
MIME-Version: 1.0
X-Received: by 10.170.121.214 with SMTP id n205mr571130ykb.98.1431033922605; Thu, 07 May 2015 14:25:22 -0700 (PDT)
Received: by 10.13.247.71 with HTTP; Thu, 7 May 2015 14:25:22 -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: Thu, 7 May 2015 16:25:22 -0500
Message-ID: <CABkgnnWM7718gZoZrjW7d3gTUUGs3LzUKO6c_fCyDTi0pj7KaQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/oeRzUevOc0DR1LBdPw-VmlCt4bs>
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: Thu, 07 May 2015 21:27:17 -0000

On 7 May 2015 at 10:24, Bodo Moeller <bmoeller@acm.org> 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.