On Tue, Aug 20, 2019 at 1:39 PM Roman Danyliw via Datatracker <
nore...@ietf.org> 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.)
> (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."
David
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
