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

Eric Rescorla <ekr@rtfm.com> Sun, 22 May 2016 19:51 UTC

Return-Path: <ekr@rtfm.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 3EFFC12D0F9 for <tls@ietfa.amsl.com>; Sun, 22 May 2016 12:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 PqDnYiXxvPZM for <tls@ietfa.amsl.com>; Sun, 22 May 2016 12:51:19 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1D7712B051 for <tls@ietf.org>; Sun, 22 May 2016 12:51:18 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id c127so36834580ywb.1 for <tls@ietf.org>; Sun, 22 May 2016 12:51:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sOB+Mijjftgr4VelFn8Nw7V1YZJE2UHSr+8+fkPZXr4=; b=MpYZIYlC5Zsf4CMkSlaAOH6KlJ1D53A+lRYfNknH2CDl5vV/HLTB1Wl+84NfJh2LqN UGSNBrtaejydInDj3N5qUpbLlirCPwLtkgUL5aY44mIo1NnrTJbAZ2BizNvnNMgfYss+ jq9ovHtcQ9KrE72SQ3hW21j3FjVojUprngr96gNZFaHIpvQr8o+lhOJz+urnFkv3JFsg moL77+UFblHQsrezpY/YBlqY7eUC9tg7iehbFr3hFu5oZS8BMgz9NBlikgjGiFc8O53p XVVPF/4uXyqWWe7lr1S7kZ65iKNrVV4IYzYcF9xfhg1xUhEr7joTZVFoB5Vp7BagvVC4 eqyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sOB+Mijjftgr4VelFn8Nw7V1YZJE2UHSr+8+fkPZXr4=; b=PGPp4R/mMhAEyFTNDZHdtkQmiUomx2Rwf156oGVV9o5eAB4s8nW6u2RVPGCHFva9Za EodpW3MTbfRHXAagEnzzbDrehw1wROMkz5iKpQGJnj/hPgY5Vx1c5tOKYE1JfXRMwY2F 968iiqK0WUis4ng96ilLJiATXot/tiFlIwLsCWCgaG2i951UdQweI3/xttxqYFD+FktR kuvkVsd8daFb7AhpPW523UlLa9xlOBuwHXqBzE6FF/jOqaaahXzBRMW1awbtZrS3j+9R 36KcdbUyf/m/2VFZlQYnOiW3G4ezt83ayjYMA+kxjJzxlHfb5VteX7GvaCKkr/1YqtFP vOLQ==
X-Gm-Message-State: AOPr4FVm9VxmHgYFwNB794EZKTqmw48/a8ClgcbsUHI+RmseA2YcnC8KALphQ4FIGiEGBA3PCfMp+X3BsE66pA==
X-Received: by 10.13.233.1 with SMTP id s1mr7521887ywe.286.1463946678194; Sun, 22 May 2016 12:51:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 12:50:38 -0700 (PDT)
In-Reply-To: <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> <20160522193302.GB17811@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 22 May 2016 12:50:38 -0700
Message-ID: <CABcZeBNG0dkqTbJ0HNYJOi3Uk7SHGm85AwkWtPTcO3ff6Ag_1A@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="94eb2c07cfb4b9862b053373a5ad"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/jtbInA6Bz9AtLVxRsAudt5B_qo4>
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:51:21 -0000

On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> 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.
>

This is a bit of an irritation, I agree. However, it's only required for
stateless implementations, so not your average TLS stack. If you
have a better suggestion, I'd love to have it, thought!


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).
>

Good point. I just made the editor's copy have 2^16-1 thought it didn't
make it into draft-13.


> > 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?
>

I hope so. We plan to test it.



> > 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):
>

Thanks for this. Ill try to work up a PR from the below.

Best,
-Ekr


>
> - 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
>