Re: [TLS] Remove EncryptedExtensions from 0-RTT

David Benjamin <> Thu, 23 June 2016 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8051612D193 for <>; Thu, 23 Jun 2016 08:06:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VyLei5otpCHg for <>; Thu, 23 Jun 2016 08:06:05 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3782D12D18E for <>; Thu, 23 Jun 2016 08:06:05 -0700 (PDT)
Received: by with SMTP id t74so74100673ioi.0 for <>; Thu, 23 Jun 2016 08:06:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HLjzO68frZJ8SZUAPr7HceSsBzt36sXRSr+G4JtsQEc=; b=IHHeTWrEzesLaFjuMpE6un/fBlCkAX1hHcA+sRr6UAZcYcmCghmiYmKNnA7qF1c3Ql Kzs9C7K6DvAZLryefDRrBQeYyGfEPbu3DkJwlfcvnTf4hAwoF4HYRypx2lxgp7kv6z9N vhbMEtfjviyqxojfVmZtWxJ78IWgBsmsOK80Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HLjzO68frZJ8SZUAPr7HceSsBzt36sXRSr+G4JtsQEc=; b=cY6zKij0arQpzPhev0mV9C6qp5OOanJLCMeLNgDYB5Zc1FEKWUqqDaDEc0gJRXL+mW ex6MY7eHr43/dSTsW4dWHy08mIT+q3JoCAFS15GpoTlNd0zjgjVnsi//rAyDPOErKENQ T34OdPk8NEeiFMO2gEOffbOkgNO7HZ8wA/Q0pKTbBOmK9+LtxU9h3JI3lUAcAjVnbsgi SFIdGhuCDmLJSbHKybfbRBKUHXudcO/zGTNg52nmtGySK6A21FloKgpt0ifa0MF4JNVu H0zBSmjcXOxPk1+igZdn5xXKWdP5DyF1iuSOfyWR5cwrK5Zr64Nlmvl2AtIeP2pyfzb0 S+Ww==
X-Gm-Message-State: ALyK8tLK5kYjUaArbzvmRccwnkkrhyEk8NG+QFgH1oxEa0wRJo6K61b2V9LHXZfnGG56VUoofm1kokXfInn7oUER
X-Received: by with SMTP id d77mr1412138iod.97.1466694364355; Thu, 23 Jun 2016 08:06:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Thu, 23 Jun 2016 15:05:54 +0000
Message-ID: <>
To: Ilari Liusvaara <>, Martin Thomson <>
Content-Type: multipart/alternative; boundary="001a11408bf2952fa50535f3645d"
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: Thu, 23 Jun 2016 15:06:07 -0000

On Thu, Jun 23, 2016 at 6:35 AM David Benjamin <>

> On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara <>
> wrote:
>> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote:
>> > When implementing 0-RTT, an in particular the ticket_age extension, we
>> > discovered that this greatly increases the complexity of the server
>> > state machine.
>> >
>> > David Benjamin rather flippantly described a solution to this problem:
>> > XOR the ticket age value with something that is either derived from
>> > the old session keys or was included in the NewSessionTicket message.
>> >
>> > I propose we take David's solution.  After all, simple is better:
>> >
>> >
>> I don't see a warning that reusing a ticket with that scheme causes
>> the "masking" to break (the classic "multiple time pad" broken scheme).
> Probably worth expanding on in the text, but the assumption here is that
> EncryptedExtensions' only purpose in life was to defeat correlation. That
> is, if we didn't care about that, we'd put it in the clear like other
> ClientHello fields. (Which means integrity is provided by handshake
> transcript, as with other ClientHello fields.)
> To that end, if you were reusing a ticket, you've already leaked a more
> fun correlator (the ticket) and must not have cared about leaking the
> ticket_age either.

I suppose there is a slight difference from ticket reuse in that ticket
reuse correlates the resumption connections together but not the connection
which minted the ticket. The ticket age helps you correlate that initial
connection too.

I don't think this matters. Just don't reuse tickets. But, if we cared, per
the "dumbest possible thing that might work" school of thought, we can
replace XOR with addition modulo 2^32. Now ticket reuse leaks the delta
between two ClientHellos, which, precision aside, was already public
information from the receive time (with ticket as correlator). The
timestamp of the ticket-minting connection is as secret as before.

> If something more heavyweight is wanted, probably better to derive some
> extra key off the session key material + stuff (ought to include
> client_random if worried about ticket reuse) and toss it into the cipher's
> AEAD or something. It didn't seem we needed any of it, so I "flippantly"
> proposed the dumbest possible thing that might work. :-)
> David