Re: [TLS] Pull request for 1RTT Handshake

Watson Ladd <> Sat, 05 July 2014 03:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A6A101A0303 for <>; Fri, 4 Jul 2014 20:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tGQn_KjqLn0P for <>; Fri, 4 Jul 2014 20:30:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 758601A01C8 for <>; Fri, 4 Jul 2014 20:30:51 -0700 (PDT)
Received: by with SMTP id m15so1158534wgh.19 for <>; Fri, 04 Jul 2014 20:30:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q5p3FgobTao7aNyOxXUIYEARtocPzlqOC4vrzfc5FqE=; b=tcc3MiD/xuXA8cfRjUfCDKc/opYtfg228XnLotp7RSdCbhpY4Wzk3cIVdRAvGW7Ptq znc1mnXqjbkE2VH5AJ9axkG95SgEe+aksdyATFpvY9tOFjt4ZGxWRbULVH3ckqNZy8n8 LysUIoFF850yHlVEMEejMDG95mCO3d7Ary373xHRi/kSG0Md5/dgrKOZAl840FZJrlR/ ok2MK0+YzEnEtijEWeprXugBwihjjjBnE8M3UzP1JkzbWHs9gES42LBS+fruVs1ExnKl tx5kg2VoR/MlNx17NeY2+8obUbhSVLhr8Wg7IV1oe5AFRJ6vjGOS2l+wzJlWgNUtkItD Y0EQ==
MIME-Version: 1.0
X-Received: by with SMTP id s1mr6707023wiz.36.1404531049928; Fri, 04 Jul 2014 20:30:49 -0700 (PDT)
Received: by with HTTP; Fri, 4 Jul 2014 20:30:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 4 Jul 2014 20:30:49 -0700
Message-ID: <>
From: Watson Ladd <>
To: Eric Rescorla <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] Pull request for 1RTT Handshake
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: Sat, 05 Jul 2014 03:30:53 -0000

On Thu, Jul 3, 2014 at 10:27 PM, Eric Rescorla <> wrote:
> On Thu, Jul 3, 2014 at 9:41 PM, Watson Ladd <> wrote:
>> On Thu, Jul 3, 2014 at 9:00 PM, Eric Rescorla <> wrote:
>> Why send two messages when one will do? In particular the server can
>> send a Server Key Exchange,
>> and a Certificate, CertificateVerify message in response to the Client
>> Hello.
> I assume you intend the ServerHello here as well, since you need that for
> the
> cipher suite, etc.?
>> Once the client receives this, it's ready to send data after its CKE
>> and such messages.
>> Restarting the protocol the way we have now introduces another round trip.
> Ah, I understand what you are suggesting.
> Certainly something like this is possible, but the general sense of the
> discussion at the Interim was that people wanted the "wrong group"
> handshake to look like a missed guess/correction followed by the "right
> group" handshake, in the interest of simplicity. Note also that if we
> have a relatively small number of groups (which seems like a good idea
> in any case) then the vast majority of handshakes can complete in 1-RTT
> because the client guesses right (e.g., they send P256 and 25519 and
> the server supports one or both.)

True: the client can take a guess.
> Another difficulty is that it in the flow you are suggesting, you don't
> protect
> the server's first flight, which includes:
> - The server's extensions response (and request if we add DKG/Ritter's
>    'type B extensions').
> - The server's certificate (relevant if using SNI encryption and for
>    passive protection for P2P applications).

Unless I'm missing something you aren't either: the Change Cipher Spec
would come before the Certificate and Certificate Verification to
protect these two. But yes, this does require guessing of server
parameters, so once we need to do that, might as well guess more.

(It seems a bit weird to me to design the protocol one feature request
at a time: that way lies Perl 6. Also, I don't recall having seen
'type B extensions': what was the rationale? How was the answer going
to come back?)

Watson Ladd

> In some cases, an attacker can elicit these, so protection is just
> passive, and in others he cannot, in which case protection is also
> active.
> Best,
> -Ekr

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin