So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite large chunks of it. The draft is currently defined for TLS 1.2, but it probably makes sense to order it after TLS 1.3.
TLS 1.3 also adds a many new extension points, and we can expect new TLS 1.3 implementations popping up in the near future, so having the ecosystem primed against intolerance bugs would be great. (As a happy anecdote, Chrome is currently GREASEing bits of its draft TLS 1.3 implementation. This worked beautifully. There was a draft TLS 1.3 server implementation that broke on unknown versions in supported_versions and unknown groups in key_shares. Interop testing against a normal client did not notice. When they tried interop testing against Chrome, the bugs were caught and fixed.) I was thinking of making the following changes: - Cite TLS 1.3 instead of TLS 1.2. - Add some text to use the same code point pattern for TLS 1.3 signature_algorithms. - Add some text to suggest advertising GREASE values in key_shares if advertised in supported_groups. [This already caught a bug.] - Add some text to use the same code point pattern for supported_versions. [This already caught a bug.] - Generalize the extensions text to allow for CertificateRequest and NewSessionTicket extensions sent by the server. [This might have caught a bug had it not been caught by other means first.] Do people agree with this plan? I've left out psk_key_exchange_modes. It would be nice to GREASE that too, but it uses u8 rather than u16 values. The natural generalization is to reserve 0x?a instead of 0x?a?a. But then we lose 16 out of 256 code points, rather than 16 out of 65536 code points. Do people feel this is an acceptable tradeoff? Perhaps a smaller pattern? Or is this not worth bothering with? David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
