Skip to main content

Last Call Review of draft-ietf-tls-grease-03

Request Review of draft-ietf-tls-grease
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-08-12
Requested 2019-07-29
Authors David Benjamin
I-D last updated 2019-08-29
Completed reviews Secdir Last Call review of -03 by Carl Wallace (diff)
Genart Last Call review of -03 by Francis Dupont (diff)
Assignment Reviewer Francis Dupont
State Completed
Request Last Call review on draft-ietf-tls-grease by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 03 (document currently at 04)
Result Ready
Completed 2019-08-29
On Wed, Aug 14, 2019 at 4:09 AM Francis Dupont <>

> 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. :-/