[TLS] #445: Enhanced New Session Ticket

[Ilari Liusvaara <[e-mail]>]

Some comments:

- I presume 0-RTT used in retried ClientHello uses (and for the verify
  mechanism to work, that needs to be allowed!) uses ClientHello1...
  ClientHello2 as its base hash?
- Is that 0-RTT Finished message needed? It is the only 0-RTT handshake
  message...
- Server can send CertificateRequest in GDHE-PSK or PSK mode???
- What are 'etc' for parameters for 0-RTT data? Use the present
  extension list here and have any future extensions that matter here
  explicitly define their interaction.
- The requirement for server to validate its extensions... Hopefully
  there is no security reason for that... I really don't see it being
  implemented correctly (and the description looks completely screwy[1]).
- 1 RTT server context presumably ends in CertificateRequest, not
  CertificateVerify (the Certificate and CertificateVerify are
  impiled).
- You might want flag for if server promises replay protection or
  not in NST.
- You might want to specify that allow_dhe_resumption doesn't
  change key exchange, only authentication (so DHE_CERT becomes
  DHE_PSK and ECDHE_CERT becomes ECDHE_PSK).


[1] There are many extensions that are not relevant because those
control server authentication (e.g. status_request, status_request_v2,
signed_certificate_timestamp, server_certificate_type). And some that
are low-level connection control (e.g. max_fragment_length).

ALPN is special here tho: It needs to match the impiled 0-RTT ALPN
(does one want that extension in 0-RTT case anyway?).


-Ilari