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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
