On Fri, Apr 29, 2016 at 10:46 AM, Ilari Liusvaara <[email protected]> wrote:
> On Fri, Apr 29, 2016 at 09:16:07AM -0700, Eric Rescorla wrote: > > On Fri, Apr 29, 2016 at 8:38 AM, Ilari Liusvaara < > [email protected]> > > wrote: > > > > > On Fri, Apr 29, 2016 at 04:52:08PM +1000, Martin Thomson wrote: > > > > On 29 April 2016 at 15:58, Ilari Liusvaara <[email protected] > > > > > wrote: > > > > > > EDI looks like rather sizable structure currently (even after > compressing > > > the configuration_id by obvious means). > > > > > > > Are you looking at a different document than I am: EDI currently is: > > > > struct { > > select (Role) { > > case client: > > opaque context<0..255>; > > > > case server: > > struct {}; > > } > > } EarlyDataIndication; > > > > And the context is basically a placeholder. > > Ah, I didn't see a PR about it and then looked at Editor's Copy. > Clearly a different document. > Yes, 445 builds on 444. > > > Proposed text would be welcome here. > > Well, the more I think about this, the messier things about interaction > between SNI, "static" PSKs and "dynamic" PSKs seem to be... > > And unlike ALPN, where problems only appear in context of 0-RTT, now you > also get the issues without 0-RTT: > > > > > 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. > > > > > > > This doesn't seem awesome from the client's perspective. I'm trying to > make > > the ordinary PSK-resumption design less of a special case. > > Well, the client needs to keep track of the ALP anyway. If for nothing > else, to check that the server isn't trying to do anything crazy. > I don't see why that's true in the absence of 0-RTt. There's no reason why the server shouldn't be able to select any ALPN offers the client provides regardless of the original offer.. -Ekr > > I think it is easier for the client just to imply the ALP in presence of > accepted 0-RTT. > > > -Ilari >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
