Folks, In the spirit of making a useful checkpoint, I just posted the latest version of the editor's draft as draft-11. Here's the major changes:
- Port the CFRG curves & signatures work from RFC4492bis. - Remove sequence number and version from additional_data, which is now empty. - Reorder values in HkdfLabel. - Add support for version anti-downgrade mechanism. - Update IANA considerations section and relax some of the policies. - Unify authentication modes. Add post-handshake client authentication. - Remove early_handshake content type. Terminate 0-RTT data with an alert. - Reset sequence number upon key change (as proposed by Fournet et al.) The major open issues I am aware of are: - Figuring out whether we want to hash in additional data from the 0-RTT exchange into the 1-RTT handshake (Issue #351, some on-list comments by Ilari, and the discussion over the past few days about DTLS). I believe that the conclusion of these discussions was that there was not a clear security issue here and that there were different views of the aesthetics of inclusion versus exclusion. Arguments/corrections welcome here. - Closing on Encrypted SNI. My sense is that to the extent to which people have enthusiasm for this, it's for the proposal that I posted on 12/5: https://www.ietf.org/mail-archive/web/tls/current/msg18633.html Chairs: can you please help drive this to conclusion? - Details of state pickling for stateless reject. I owe the list a proposal here. - We still need clearer text around data volumes, which might, I suppose, result in concluding that we don't need rekey. I'll send mail about this separately shortly. - Hugo's proposal to explicitly include the random values in the handshake hashes. Chairs, can you please help drive this to conclusion as well? -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
