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

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 22 May 2016 19:33 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 1A88112D577 for <tls@ietfa.amsl.com>; Sun, 22 May 2016 12:33:10 -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 fqE5kuK8gSW9 for <tls@ietfa.amsl.com>; Sun, 22 May 2016 12:33:08 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id B8DD012D575 for <tls@ietf.org>; Sun, 22 May 2016 12:33:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6010FD4AC; Sun, 22 May 2016 22:33:06 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 5AfwsSY8dy3W; Sun, 22 May 2016 22:33:05 +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-smtp1.welho.com (Postfix) with ESMTPSA id D6FAF28F; Sun, 22 May 2016 22:33:05 +0300 (EEST)
Date: Sun, 22 May 2016 22:33:02 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBPEQMJvBkb9kNvE4XeV8PyXoi=MchxrjPmmmYbJ8aXamQ@mail.gmail.com> <20160522155921.GA17811@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBPBtuqm-Qz7+WaQfaCzqKSXdpfER-cRHxCV0reae6vpyg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBPBtuqm-Qz7+WaQfaCzqKSXdpfER-cRHxCV0reae6vpyg@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/86VPDyGxVmNhUYbX7y38uJ5GAdk>
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 19:33:10 -0000

On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote:
> On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > 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.
> >
> 
> I don't understand what you're saying here. Here is my claim:
> 
> 1. The second ClientHello doesn't come with EDI.
> 2. The Cookie (if used for this) needs to contain the entire hash
>     state, which means it includes the ClientHello w/ EDI transitively.
> 3. Therefore you can recover the hash state no matter how much
>     the client changes the ClientHello (though we forbid a lot of
>     changes)
> 
> If I'm wrong here, would definitely like to know. Can you explain?

That would require hash implementation supporting freezing/thawing
(I have seen only one, and that used MD5), which is even more exotic
than forking checkpointable hash implementations.

Also, SHA-384 states are so big (the state at arbitrary point is 208
bytes!) that putting one into cookie leaves space VERY cramped (if
all necressary things fit at all).

 
> > 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.
> >
> 
> "All of the parameters for the 0-RTT data (symmetric cipher suite,
> ALPN, etc.) MUST be those which were negotiated in the connection
> which established the PSK. "
> 
> Would be happy to have clarifications.

I would phrase the thing as what various values are, not what they
must be (there is no way negotiate those, which is good).

> 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. :-)
> 
> 
> Yes. Those people basically won't be able to use 0-RTT.

Even if ticket timestamp mismatch error has fallback in spec, will it
actually fallback properly with real-world implementations?
 
> > Is the ticket allowed to outlive certificate orginally used in
> > provisioning it (possibly indirectly, with ticket being provisoned
> > from connection using ticket)?
> >
> 
> This has never been something TLS has taken a position on.

Ah, it only came up in conjunction with GDHE-PSK-CERT modes, where
tickets can't outlast parent certificate (because it can't change).
 
> 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.
> 
> I'll take a look at it, but PRs welcome. Right now I have an open issue
> marker,

Here is what I think should match (going through all currently known
values and excetions):

- Version
- Ciphersuite Protection+PRF, key exchange in allowed values.
- What to do with server_name???
- Status_request presence (but not contents)???
- Status_request_v2 presence (but not contents)???
- Signed_certificate_timestamp presence (but not contents)???
- ALP can not be negotiated by any means.
- 0-RTT Protection+PRF+ALP can not be negotiated.

(I think status_request and status_request_v2 should mirror whatever
signed_certificate_timestamp does).

Also, that server_name is just its own kind of mess, where what is
the proper thing isn't at all obvious.


And here is the list of extensions that are allowed to be negotiated
with 0-RTT (parenthesis denotes extensions where things depend on exact
handling discussed above).

- (server_name)
- max_framgment_length
- (status_request)
- supported_groups
- use_srtp
- heartbeat
- (status_request_v2)
- (signed_certificate_timestamp)
- token_binding [I-D stage]
- cached_info?
- key_share
- pre_shared_key
- early_data (required for obvious reasons)


(Note: application_layer_protocol_negotiation is not on this list,
very much intentionally, since negotiation of ALP is not possible
in presence of 0-RTT. Don't even try).



-Ilari