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