On Wed, Aug 14, 2019 at 4:09 AM Francis Dupont wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-tls-grease-03.txt > Reviewer: Francis Dupont > Review Date: 20190803 > IETF LC End Date: 20190812 > IESG Telechat date: 20190822 > > Summary: Ready > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > - ToC page 2 and 8 page 11: Acknowledgements -> Acknowledgments > Thanks! I've updated this in my local copy, which I'll publish as -04 later this week. > - 5 page 7: I have a concern about your use of the term random. In fact > even it is a security document here random is just plain English > (vs any crypto meaning). Constraints seems to be: > * coverage: the set of used values should not be small > * privacy: fingerprinting should not be easy > I do not propose any solution: just follow recommendations of > the security directorate in the case this point is a problem. > Ack. +Benjamin Kaduk , do you have preferences on this? I don't think the requirements on "random" are particularly strong, so I don't know if we should prescribe cryptographic randomness. At the same time, it is perhaps odd to just say "random". My implementation just draws from the PRNG because it's easy, but if the values are predictable, it doesn't expose user-fingerprinting surface, which is the more important one. (User-fingerprinting would come more from doing something stateful or user-specific.) It does expose implementation-fingerprinting surface, but even sending GREASE does so too. TLS is full of implementation decision and policy points (e.g. the entire ClientHello), nearly every one of which contributes to the implementation fingerprint. :-/