Skip to main content

Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility
RFC 8701

Yes

Éric Vyncke
(Alissa Cooper)

No Objection

Alvaro Retana
(Barry Leiba)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)

Note: This ballot was opened for revision 03 and is now closed.

Éric Vyncke Yes

Alvaro Retana No Objection

Roman Danyliw No Objection

Comment (2019-08-20 for -03)
(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?

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

Warren Kumari No Objection

Comment (2019-08-21 for -03)
Thank you for a nicely written, and easy to understand document.

(Alexey Melnikov; former steering group member) Yes

Yes (2019-08-17 for -03)
I am looking forward to this being deployed.

TLS 1.2 should be a Normative reference, despite being obsolete, as some of the requirements only apply to TLS 1.2.

(Alissa Cooper; former steering group member) Yes

Yes (for -03)

                            

(Adam Roach; former steering group member) No Objection

No Objection (2019-08-19 for -03)
Thanks for the work done on this -- it seems like it should be quite
useful. I have one comment that applies across four sections of the
document.

---------------------------------------------------------------------------

§3.1:

>  Clients MUST reject GREASE values when negotiated by the server.  In
>  particular, the client MUST fail the connection if a GREASE value
>  appears any in the following:
...
>  Note that this requires no special processing on the client.  Clients
>  are already required to reject unknown values selected by the server.

If the behavior is already defined in other documents, please don't
reiterate it normatively here ("Clients MUST..."). I suggest rephrasing
as "As required by Section x.y of [RFCxxxx], clients will reject GREASE
values when..."

---------------------------------------------------------------------------

§3.2:

>  Note that these requirements are restatements or corollaries of
>  existing server requirements in TLS.

Same comment as above.

---------------------------------------------------------------------------

§4.1:

>  Note that this requires no special processing on the server.  Servers
>  are already required to reject unknown values selected by the client.

Same comment as above.

---------------------------------------------------------------------------

§4.2:

>  Note that these requirements are restatements or corollaries of
>  existing client requirements in TLS.

Same comment as above.

(Barry Leiba; former steering group member) No Objection

No Objection (for -03)

                            

(Benjamin Kaduk; former steering group member) (was Discuss, Yes) No Objection

No Objection (2019-08-25)
A second TLS DE approved the registrations over the weekend, so there shouldn't be a need to
hold this up anymore (though presumably IANA will not notice until they come back to the
office on Monday).

(Deborah Brungard; former steering group member) No Objection

No Objection (for -03)

                            

(Ignas Bagdonas; former steering group member) No Objection

No Objection (for -03)

                            

(Martin Vigoureux; former steering group member) No Objection

No Objection (for -03)

                            

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2019-08-15 for -03)
Sorry one more comment/question I forgot earlier: Why is this document informational? Shouldn't it be at least experimental?

------ previous comment ------

One comment/question: I think I didn't quite understand what a client is supposed to do if the connection fails with use of greasing values...? The security considerations seems to indicate that you should not try to re-connect without use of grease but rather just fail completely...? Also should you cache the information that greasing failed maybe?

And a note on normative language:

"Implementations sending multiple
   GREASE extensions in a single block thus must ensure the same value
   is not selected twice."
Should this be a "MUST"?

Also this is an interesting MUST:
"... MUST correctly ignore unknown values..."
While this is the whole point of the document, I assume this is already normatively specified in RFC8446 and therefore it could make sense to use non-formative language here...

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -03)