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

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 22 May 2016 17:22:12 +0300

Looking at PR #468:
- It isn't at all obvious how to use it for stateless rejection.
- It is even less obvious how to recover (not causing non-retryable
  fault) from bad cookie (e.g. expired) remembered from previous
  connection.

There are some tricks for both, but with latter, the 255-byte
cookie space can become quite cramped...

I think it would be easier if either:
- Cookies could not be remembered across connections.
- HRR and EE cookies had separate slots those go to in CH.

(Of course, neither of those solves the "failed 0-RTT" case...)

Also, some clients do burst connects, where multiple TLS
connections are connected in parallel. Through quite frequently
these would be pure-PSK, keyed off one master GDHE-CERT
connection.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 May 2016 07:49:12 -0700

> cookie space can become quite cramped...

I'll make the space biggeer.

> - Cookies could not be remembered across connections.

Yes, MT and I discussed this last night and came to the same conclusion.
I will make it so.

-Rk

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 22 May 2016 18:59:21 +0300

> I'll make the space biggeer.

Not having to deal with cross-connection cookies makes things
easier, but...

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.

If it is intended for client to be able to preturb 0-RTT, it can
be much smaller. 32 bytes is plenty for random parameter, and
then ClientRandom preturbs 0-RTT as well...

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.

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

Is the ticket allowed to outlive certificate orginally used in
provisioning it (possibly indirectly, with ticket being provisoned
from connection using ticket)?

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.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 May 2016 11:30:10 -0700

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

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

> errors (wrong time) will be small too (can be <10ms). And have fun

Yes. Those people basically won't be able to use 0-RTT.

> from connection using ticket)?

This has never been something TLS has taken a position on.

> negotiated there are any of any interest with 0-RTT. To me the text

I'll take a look at it, but PRs welcome. Right now I have an open issue
marker,

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 22 May 2016 22:33:02 +0300

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

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

> 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?
 
> 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).
 
> I'll take a look at it, but PRs welcome. Right now I have an open issue

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 May 2016 12:50:38 -0700

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

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

> actually fallback properly with real-world implementations?

I hope so. We plan to test it.

> Here is what I think should match (going through all currently known

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

Best,
-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 22 May 2016 23:48:23 +0300

> have a better suggestion, I'd love to have it, thought!

Well, if you didn't have to deal with possibly overly large contexts,
you could just reconstruct the 1st ClientHello and HelloRetryRequest.

(Reconstruction is even easier without having to worry about cross-
handshake cookies). 

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 22 May 2016 14:30:55 -0700

> (Reconstruction is even easier without having to worry about cross-

They're gone!

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 23 May 2016 19:25:26 +0300

> signed_certificate_timestamp does).

Thinking about it some more, including status_request/status_request_v2/
signed_certificate_timestamp is only useful if one wants to tie the
ticket lifetime to parent certificate lifetime.

Also, list of things saved for 0-RTT-capable context would be useful.
I presume:

- The context name
- The PSK key
- The PSK context
- Timestamp
- Expiry time (not needed for 0-RTT)
- On server side: RTT estimate
- Allowed key exchanges
- Negotiated protection
- Negotiated PRF
- Negotiated ALP (negotiated via any means, or absence thereof)
- (Implementation-defined peer identity, not needed for 0-RTT)
- (Implementation-defined self identity, not needed for 0-RTT)
- What to do with server_name???

(On server side, one can save the rest encrypted into context name). 

Also, how is the context in EDI defined? I couldn't find clear
answer, and I preseume it is a replay detector for 0-RTT (Client-
Random already is a preturbator, and could also be used for
replay detection). But such thing could be much shorter than
maximum of 255 bytes...

-Ilari