Re: [TLS] Remove EncryptedExtensions from 0-RTT

Eric Rescorla <> Mon, 04 July 2016 01:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8A9B612D1AD for <>; Sun, 3 Jul 2016 18:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8LZMbyeuY4Av for <>; Sun, 3 Jul 2016 18:01:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CCD112B02B for <>; Sun, 3 Jul 2016 18:01:05 -0700 (PDT)
Received: by with SMTP id b72so29255252ywa.3 for <>; Sun, 03 Jul 2016 18:01:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FI25pf4Pk0ar93+3I6aIz9UFs2pMOGYjSTQSiIygPU8=; b=mI1SUtWxA/XFCKRY6Sd4k251AUD6RObBN+PsM7DOMTZ5xESx6Scoyg3VtdXKdJyIyr JgC5wvKN6mGlUutFKi1vwCTH7zlp3MgoV6EPaG9alINDMGkuwE0JQHAOx3AcTrwUmPyU c25maLzs8JwqgGP1AMRhaKgrkcApjczkIcLKnbO5pPck6o5hzavgOtRrwn9eDeghIwSe D8qVn5Fe05YDymMi/2zT/rAorhhF4yMS943EapLRVhCdpEkhpUM75j5XfPLy5/cskscR cbn/uoF2a6Ns0hesccf6GvQUehuimA+doUCmHkfWy1fIQYq3XUBNG0nM9Ja0tdZkeose Qazw==
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; bh=FI25pf4Pk0ar93+3I6aIz9UFs2pMOGYjSTQSiIygPU8=; b=bdLkFhB0tjRvo6SL+gcTgOui6i9GKZcvhmFkNdwF/46BUDfKp3tM+upl5Rfw9NQBTk oInAg29xnFrvH6KP+8HtllBqIr6V+y8chcCbjONIfFEBYP5GD0T/GvsDreQUug2Etcc7 RRT0DtmWS/pOs8HQzVcduMWEEprJehCGRtS4TcuvXFdoF7DnOvswSori8GmeFiOBjGgX t3Z8KEwaH67OjibXfYFPMVWfPy4CW/DWsDen46Rlkkq7uuLMZwpJW7IoIFjO+0zOmDs3 jpo7rZhfwP+SqRwAS9oZ99CyJkidKTNp+9TWu6OX0mfDlYlTga8SQvZui2PhYol0ypmx hpoA==
X-Gm-Message-State: ALyK8tI441dmN7kLvGc2do4Ae8eKfMM759Cn09hNcll/Ft0rya4SbdktK8YApChIKCcGf9RFRqDlEB4i0CMHkg==
X-Received: by with SMTP id b81mr6247900ywa.8.1467594064935; Sun, 03 Jul 2016 18:01:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 3 Jul 2016 18:00:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Sun, 03 Jul 2016 18:00:25 -0700
Message-ID: <>
To: Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a11406f0aea430e0536c4ded2"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Remove EncryptedExtensions from 0-RTT
X-Mailman-Version: 2.1.17
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: Mon, 04 Jul 2016 01:01:07 -0000

I believe that this is the right design.

The primary proposed use for EncryptedExtensions in the 0-RTT flight is for
EncryptedSNI. However, I don't believe that they are actually that useful in
this case because the design constraints for EncryptedSNI are intended to
allow the client to encrypt the SNI to a gateway but encrypt the traffic to
the hidden server, which means that you want the SNI to be protected with
gateway keys, not the terminal traffic keys.

This design still allows two fairly elegant EncryptedSNI designs:

- Stuff a self-encrypted value of the SNI into the ticket label (due to
- Establish a ticket to the gateway server and then encrypt the ClientHello
  that is destined for the hidden server in the 0-RTT early data flight to
  gateway, which deciphers it and passes it to the hidden server, which
  responds with the ServerHello (due to Martin Thomson)

Both of these are more flexible than SNI in EE.

Absent strong objections, I intend to merge this PR on Wednesday.

On Sun, Jun 26, 2016 at 6:33 PM, Martin Thomson <>

> On 27 June 2016 at 02:34, Ilari Liusvaara <>
> wrote:
> > That's the reason it is XOR'd currently, but the XOR probably will
> > be changed to ADD32 to break correlation-to-parent (which is really
> > nasty privacy-wise) in case of ticket reuse.
> Let's not make that probably.  I've updated the PR.
> _______________________________________________
> TLS mailing list