Re: [TLS] Pull request for 1RTT Handshake

Eric Rescorla <> Fri, 04 July 2014 05:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 66E9A1B2BE1 for <>; Thu, 3 Jul 2014 22:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 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] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tj_NoWRX5iJ5 for <>; Thu, 3 Jul 2014 22:28:34 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E78A11B2BDB for <>; Thu, 3 Jul 2014 22:28:33 -0700 (PDT)
Received: by with SMTP id q59so1145062wes.12 for <>; Thu, 03 Jul 2014 22:28:32 -0700 (PDT)
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:from:date :message-id:subject:to:cc:content-type; bh=Vk41VW5Huy945QcJTnYRVYK/qwsqqC0fLkUIx0zC76c=; b=YwFGWTVxnhJJlxhUkmQi1BgN3ku4gbqDgpqzhx6k2+URE/3Bh/BHl/4r9pn5XS7JNh mTYDh4Q5jNfjJTkc7NFfZiEE/epaHNkMuSO500WJjqYRDV5Ce6M9V3viIMwqyUxpiDqx ofjdBqWWtvMRtJdfu1NaPZEKxYf9z9YM9m7meWqWcdtuUEMrYpleRo3wxwqrO5bciWah PTDAaBbF7dkhE6Kiap79otmwBEjclHp4DAnmHRnsAoLUBdos1nB4woA2+u9rGY8Ha3ga qXOMWCQGle0UF/si8eMPS9YyLuAq6eWxLCUFOlappRsYsjHIzGvNs7GSPqOTnSxNr/pu 8QvQ==
X-Gm-Message-State: ALoCoQmQzB0D7V7fhgNMz9iu+AU/l0GXfdwxjRgtVm/oY5EKzKDcd8Rc6FnNsYl8yKJozRBgs8OI
X-Received: by with SMTP id 4mr9563272wjn.17.1404451712548; Thu, 03 Jul 2014 22:28:32 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 Jul 2014 22:27:52 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Thu, 3 Jul 2014 22:27:52 -0700
Message-ID: <>
To: Watson Ladd <>
Content-Type: multipart/alternative; boundary=047d7b3a81766e6f0c04fd5765ec
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: Fri, 04 Jul 2014 05:28:35 -0000

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

Another difficulty is that it in the flow you are suggesting, you don't
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).

In some cases, an attacker can elicit these, so protection is just
passive, and in others he cannot, in which case protection is also