Last Call Review of draft-ietf-tls-grease-03
review-ietf-tls-grease-03-genart-lc-dupont-2019-08-29-00

Request Review of draft-ietf-tls-grease
Requested rev. 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
Draft 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
Review review-ietf-tls-grease-03-genart-lc-dupont-2019-08-29
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/kOwLN91_ri8wWIaxSPwhdhF5qpk
Reviewed rev. 03 (document currently at 04)
Review result Ready
Review completed: 2019-08-29

Review
review-ietf-tls-grease-03-genart-lc-dupont-2019-08-29

On Wed, Aug 14, 2019 at 4:09 AM Francis Dupont <Francis.Dupont@fdupont.fr>
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
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> 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 <kaduk@mit.edu>, 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. :-/