Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hi David!

From: iesg [mailto:[e-mail]] On Behalf Of David Benjamin
Sent: Wednesday, August 21, 2019 5:44 PM
To: Roman Danyliw <[e-mail]>
Cc: [e-mail]; <[e-mail]> <[e-mail]>; The IESG <[e-mail]>; Sean Turner <[e-mail]>; tls-chairs <[e-mail]>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Per the following:

Section 3.1 says “Note that this requires no special processing on the client.
Clients are already required to reject unknown values  selected by the server.”

Section 4.1 says “Note that this requires no special processing on the server.
Server are already required to reject unknown values selected by the client..”

These statement don’t seem precisely right.  Per Section 3.1, if a client
understands GREASE enough to put it into a message to the server, and the
server for some reason tries to negotiate this value, isn’t there ‘special
processing' required in the client to the degree that it knows it shouldn’t
accept the value it requested in the negotiation?

I suppose it depends on how one implements it. We implemented it by just making our ClientHello, etc., serializer put add extra junk in there, so the logic for deciding what extensions are acceptable does not see it at all. I suppose, sure, if you implemented it by actually registering a fake curve, that would be a lot more complexity and probably a bad plan.

How's this rephrasing?

     Note that this can be implemented without special processing on the client. The client
     is already required to reject unknown server-selected values, so it
     may leave GREASE values as unknown and reuse the existing logic.

(And analogously for the server section.)

[Roman] This text works for me.  Thank you.

(2) Section 7.  Per “GREASE values may not be negotiated …”, is there a reason
this isn’t “must not be negotiated”?

 That clause was meant to be descriptive of the other bits of the document. "[Such-and-such] may not be [such-and-such]ed, so [some consequence of this]". Using "must not" reads odd to me: "GREASE values must not be negotiated, so they do not directly impact the security of TLS connections."

[Roman] Understood.  Under separate cover, Martin suggested “cannot”.  I’m flexible on the edit (i.e., consider what I said a suggestion) given the clarity of your explanation (and this is only a comment).  Thank you.