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

[Ilari Liusvaara <[e-mail]>]

On Sun, May 22, 2016 at 10:33:02PM +0300, Ilari Liusvaara wrote:

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

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