Re: [TLS] PR ¤468: Cookie for hrr

Ilari Liusvaara <> Sun, 22 May 2016 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB92612D130 for <>; Sun, 22 May 2016 08:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1UnpG7KSk87Z for <>; Sun, 22 May 2016 08:59:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B435D12B038 for <>; Sun, 22 May 2016 08:59:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 295127925; Sun, 22 May 2016 18:59:25 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id yrkQ7uGtPSVW; Sun, 22 May 2016 18:59:24 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BE99027B; Sun, 22 May 2016 18:59:24 +0300 (EEST)
Date: Sun, 22 May 2016 18:59:21 +0300
From: Ilari Liusvaara <>
To: Eric Rescorla <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] PR ¤468: Cookie for hrr
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: Sun, 22 May 2016 15:59:29 -0000

On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote:
> On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara <>
> wrote:
> > Looking at PR #468:
> > - It isn't at all obvious how to use it for stateless rejection.
> > - It is even less obvious how to recover (not causing non-retryable
> >   fault) from bad cookie (e.g. expired) remembered from previous
> >   connection.
> >
> > There are some tricks for both, but with latter, the 255-byte
> > cookie space can become quite cramped...
> >
> I'll make the space biggeer.

Not having to deal with cross-connection cookies makes things
easier, but...

Actually, looking at it, I didn't find how EDI context is
determined. And EDI context needs to be fit into cookies because
it isn't retransmitted on 2nd CH.

If it is intended for client to be able to preturb 0-RTT, it can
be much smaller. 32 bytes is plenty for random parameter, and
then ClientRandom preturbs 0-RTT as well...

Also while looking at 0-RTT:

It occured to me how to determine the ciphersuite used for 0-RTT.
Then it occured to me that the symmetric parts are determined by the
provisioned context and asymmetric parts don't matter. But I think
this is quite non-obvious.

And clock errors being small outside of gross corrections? Clock
first-order errors can be pretty large with unsynchronized clocks
(I have personally seen FO errors on order of 1s per day on some
bit bad piece of kit), and those would absolutely show up as errors
in ticket age. And if you have synchronized clock, the zeroth-order
errors (wrong time) will be small too (can be <10ms). And have fun
with leap seconds. :-)

Is the ticket allowed to outlive certificate orginally used in
provisioning it (possibly indirectly, with ticket being provisoned
from connection using ticket)?

Also, the extension negotiation matching stuff with 0-RTT talking
about padding? Padding just plain can't be negotiated. And "negotiated
in ServerHello"? None of the extensions that can presently be
negotiated there are any of any interest with 0-RTT. To me the text
looks really confused.