Re: [TLS] PR ¤468: Cookie for hrr
Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 22 May 2016 15:59 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB92612D130 for <tls@ietfa.amsl.com>; Sun, 22 May 2016 08:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UnpG7KSk87Z for <tls@ietfa.amsl.com>; Sun, 22 May 2016 08:59:26 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id B435D12B038 for <tls@ietf.org>; Sun, 22 May 2016 08:59:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 295127925; Sun, 22 May 2016 18:59:25 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id yrkQ7uGtPSVW; Sun, 22 May 2016 18:59:24 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (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 <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBPEQMJvBkb9kNvE4XeV8PyXoi=MchxrjPmmmYbJ8aXamQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBPEQMJvBkb9kNvE4XeV8PyXoi=MchxrjPmmmYbJ8aXamQ@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/T6XeWMoW2CZIw-Yhg3x7czHeZSQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR ¤468: Cookie for hrr
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 <ilariliusvaara@welho.com> > 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. -Ilari
- [TLS] PR ¤468: Cookie for hrr Ilari Liusvaara
- Re: [TLS] PR ¤468: Cookie for hrr Eric Rescorla
- Re: [TLS] PR ¤468: Cookie for hrr Ilari Liusvaara
- Re: [TLS] PR ¤468: Cookie for hrr Eric Rescorla
- Re: [TLS] PR ¤468: Cookie for hrr Ilari Liusvaara
- Re: [TLS] PR ¤468: Cookie for hrr Eric Rescorla
- Re: [TLS] PR ¤468: Cookie for hrr Ilari Liusvaara
- Re: [TLS] PR ¤468: Cookie for hrr Eric Rescorla
- Re: [TLS] PR ¤468: Cookie for hrr Ilari Liusvaara