Re: [TLS] #445: Enhanced New Session Ticket
Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 29 April 2016 15:38 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 33A6E12B03A for <tls@ietfa.amsl.com>; Fri, 29 Apr 2016 08:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 AETzAP04J0Vv for <tls@ietfa.amsl.com>; Fri, 29 Apr 2016 08:38:37 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4059B12B02C for <tls@ietf.org>; Fri, 29 Apr 2016 08:38:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D1CE25680; Fri, 29 Apr 2016 18:38:35 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id rInaiSnLEBNd; Fri, 29 Apr 2016 18:38:35 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 644242310; Fri, 29 Apr 2016 18:38:35 +0300 (EEST)
Date: Fri, 29 Apr 2016 18:38:31 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160429153831.GA16797@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160428193252.GA16096@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBO2aFuq7PbxLimUoez66u0MkE3_qQi9fdfMS33dFVh_+Q@mail.gmail.com> <20160428214046.GB16096@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBMFg4iC-EN9DocqTpmjp46EYrTBdfi-G5nNMKN_xiHxVA@mail.gmail.com> <20160429055831.GA16405@LK-Perkele-V2.elisa-laajakaista.fi> <CABkgnnUFn_UrUFro-yLmn9wf7YkTpRf8anm7LK-bKgYBBkUVNg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnUFn_UrUFro-yLmn9wf7YkTpRf8anm7LK-bKgYBBkUVNg@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/h7ynGxXBJKCDWjPUHCfnG3q1jRU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] #445: Enhanced New Session Ticket
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: Fri, 29 Apr 2016 15:38:40 -0000
On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > On 29 April 2016 at 15:58, Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > >> [HRR state] > > > > That enlarges the state that needs to be kept. If one keeps extensions, > > one only needs ~40 bytes. Whereas saving full hash state needs IIRC 114 > > bytes (SHA-256) or 228 bytes (SHA-384). And cookies are max. 255 bytes. > > Cookies are as yet undefined, but I would imagine that these would be > just the same size as the pre-shared-key identity for all the same > reasons. Well, this is about the size one needs for the required state. > > And not many hash implementations support dumping and reloading state. > > What would you prefer? We could specify some very strict rules about > what changes a client can make to their ClientHello so that the server > can simply store things that might change (like the early_data > extension, which will disappear on the second attempt, and whether a > key share was needed, and so forth). That ~40 bytes (IIRC, it was actually 37) was done by exploiting every- thing I could out of the rules in WIP #344 and relied on EDI being preserved. EDI looks like rather sizable structure currently (even after compressing the configuration_id by obvious means). > >> [extension checking on resumption] > > > > So the 'etc' stands for "whatever will be defined by future extensions"? > > One might want to make that clearer. > > > > Also, things get screwy with SNI, and I think it is better not to try to > > use SNI with PSK. > > The primary function of SNI is routing. Remove it and stuff breaks. > Thus, I would say include it, but make sure it doesn't result in a > change in configuration. The simplest thing to do is reject PSK if > the old SNI != the new SNI. That kind of non-obvious stuff really needs to be included. They way it is right now written, I think very few TLS stacks are going to get it right. > > The rest besides ALPN and SNI looks to me those are either meaningless > > or should be taken anew. > > That is probably true for a lot of them. But we can't say that for > certain. For instance, when we defined EMS, which is irrelevant here, > it was important that it be present when resuming or bad things > happened. I'm not suggesting that exact thing will happen again, but > we can't presume that we won't need this. My point is: Future extensions can give their rules, TLS 1.3 spec needs to give rules about present ones. > > I mean for the subsequent handshake. Since 0-RTT ALPN and connection > > ALPN needs to match, either: > > > > 1) Take the 0-RTT ALPN implicitly as connection ALPN. > > 2) Signal the same ALPN again, and have that client MUST check it matches > > and abort otherwise. > > I believe that we have to do the latter. Since we can't be sure that > the server knows the ALPN from before if it has to reject 0-RTT. My > plan for this is: > > 1. store ALPN in the ticket/session > 2. if doing 0-RTT, before accepting 0-RTT data, perform the normal > ALPN negotiation > 3. check the negotiated ALPN with the stored value, and if they don't > match reject the 0-RTT data 4. If 0-RTT is accepted, client checks the ALPN server sent and compares it with value it impiled. If those don't match, the client MUST abort. 1) would be: 1. store ALPN in the ticket/session 2. if doing 0-RTT, before accepting 0-RTT data, check if the 0-RTT ALPN is acceptable. If it isn't, reject 0-RTT. 3. If 0-RTT was rejected, select new ALPN, signal it in Encrypted Extensions. That would make ALPN and EDI mutually exclusive in EncryptedExtensions. > Note that this means that clients will have to deal with having to > change protocols when 0-RTT data is rejected. But I don't see any > other way to do this. Well, the applications obviously have to be able to deal with the protocol possibly changing. > This also assumes that TLS session resumption is not carrying over > application state in addition to TLS state. I believe that is > reasonable, though it's worth stating. Well, any state they can't recover. -Ilari
- [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara
- Re: [TLS] #445: Enhanced New Session Ticket Eric Rescorla
- Re: [TLS] #445: Enhanced New Session Ticket Martin Thomson
- Re: [TLS] #445: Enhanced New Session Ticket Eric Rescorla
- Re: [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara
- Re: [TLS] #445: Enhanced New Session Ticket Eric Rescorla
- Re: [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara
- Re: [TLS] #445: Enhanced New Session Ticket Martin Thomson
- Re: [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara
- Re: [TLS] #445: Enhanced New Session Ticket Eric Rescorla
- Re: [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara
- Re: [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara
- Re: [TLS] #445: Enhanced New Session Ticket Eric Rescorla
- Re: [TLS] #445: Enhanced New Session Ticket Ilari Liusvaara