Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility
draft-ietf-tls-grease-04

[Ballot comment]
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).

[Ballot 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?

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

[Ballot comment]
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.

[Ballot comment]
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.

Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

The GREASE (Generate Random Extensions And Sustain
Extensibility) mechanism is intended to prevent extensibility
failures in the TLS ecosystem.  This document reserves some
currently unused values for TLS implementations to advertise
at random.  Correctly implemented peers will ignore these
values and interoperate.  Peers that do not tolerate unknown
values will fail to interoperate, revealing the mistake before it
is widespread.

The intended status is Informational, which is sufficient to
assign the code points in the TLS registries.  Technically, after
the publication of RFC 8447 this draft does not need to be
published as an RFC to perform these code point assignments
but because GREASE was successfully used to uncover
extensibility failures in the TLS ecosystems, other protocols
could benefit from the same mechanism, and we hear it is
easy to publish RFCs we figured we exercise the process
to get this draft published.
AD NOTE: Note that this has been successfully deployed for
over a year; it's not really an "experiment" anymore but rather
a useful thing that people do, both in TLS and elsewhere.  This
is informational in the sense that "here is a thing you can do,
and some information about why you might want to do it".  There's
no real protocol -- you send some codepoints and expect the other
endpoint to not change behavior as a result -- so it doesn't make sense
as a proposed standard.  I suppose one could argue that it is a BCP
since it is for the health of the ecosystem, but that does not really
feel like a good match.  So to me, Informational is the right status.

Review and Consensus

David presented the draft multiple times to the WG.  He has
also presented the concept elsewhere; this happen to be my
favorite: https://www.youtube.com/watch?v=_mE_JmwFi1Y
The concept is well understood and was reviewed and adopted
by the WG.  But, there's not much to the draft so there was no
controversy (thankfully).

The draft's timeline is quite long but that is primarily because of
the WG chairs as well as the slow progress of RFC 8447, which allowed
an informational draft to do the assigments.


Intellectual Property

The DS confirmed with the author that any IPR related to
this document has already been disclosed, in conformance
with BCPs 78 and 79.


Other Considerations

There are DOWNREFS in this draft.

This entire document is one beig IANA consideration.
The DS did consult IANA about GREASE and their
suggestion was to check with the Registry DEs.  The DS
consulted with the DEs and they gave the thumbs up!

GREASE is implemented by Chrome.

[Ballot comment]
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...

[Ballot comment]
Sorry one more comment/question I forgot earlier: Why is this document informational? Should 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...

[Ballot 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...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-tls-grease-03. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are four actions which we must complete.

First, in the TLS Cipher Suites registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

sixteen new registrations are to be made as follows:

+---------------+-------------+---------+-------------+-------------+
| Value | Description | DTLS-OK | Recommended | Reference |
+---------------+-------------+---------+-------------+-------------+
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x0A,0x0A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x1A,0x1A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x2A,0x2A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x3A,0x3A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x4A,0x4A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x5A,0x5A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x6A,0x6A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x7A,0x7A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x8A,0x8A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0x9A,0x9A} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0xAA,0xAA} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0xBA,0xBA} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0xCA,0xCA} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0xDA,0xDA} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0xEA,0xEA} | | | | |
| {TBD} | Reserved | Y | N |[ RFC-to-be ]|
| {0xFA,0xFA} | | | | |
+---------------+-------------+---------+-------------+-------------+

IANA understands that the TLS Cipher Suite numbers, below the { TBD } are suggested values based on earlier interoperability testing. IANA will attempt to use these values.

As this requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS Cipher Suite have asked that you send a review request to the mailing list tls-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the TLS Supported Groups registry also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

sixteen new registrations are to be made as follows:

+------------+-------------+---------+-------------+----------------+
| Value | Description | DTLS-OK | Recommended | Reference |
+------------+-------------+---------+-------------+----------------+
| {TBD} 2570 | Reserved | Y | N | [RFC-to-be] |
| | | | | |
| {TBD} 6682 | Reserved | Y | N | [RFC-to-be] |
| | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 10794 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 14906 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 19018 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 23130 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 27242 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 31354 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 35466 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 39578 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 43690 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 47802 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 51914 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 56026 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 60138 | | | | |
| {TBD} | Reserved | Y | N | [RFC-to-be] |
| 64250 | | | | |
+------------+-------------+---------+-------------+----------------+

IANA understands that the TLS Supported Group numbers, below the { TBD } are suggested values based on earlier interoperability testing. IANA will attempt to use these values.

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS Supported Group registry have asked that you send a review request to the mailing list tls-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the TLS ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

sixteen, new ExtensionType values will be registered as follows:

+----------+--------------+-----------+-------------+---------------+
| Value | Extension | TLS 1.3 | Recommended | Reference |
| | name | | | |
+----------+--------------+-----------+-------------+---------------+
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 2570 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 6682 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 10794 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 14906 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 19018 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 23130 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 27242 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 31354 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 35466 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 39578 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 43690 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 47802 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 51914 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 56026 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 60138 | | NST | | |
| {TBD} | Reserved | CH, CR, | N | [RFC-to-be] |
| 64250 | | NST | | |
+----------+--------------+-----------+-------------+---------------+

IANA understands that the TLS ExtensionType values, below the { TBD } are suggested values based on earlier interoperability testing. IANA will attempt to use these values.

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS ExtensionType registry have asked that you send a review request to the mailing list tls-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry also on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

sixteen, new Protocol IDs will be registered as follows:

+----------+-------------------------+-----------------+
| Protocol | Identification Sequence | Reference |
+----------+-------------------------+-----------------+
| Reserved | {TBD} 0x0A 0x0A | [RFC-to-be] |
| Reserved | {TBD} 0x1A 0x1A | [RFC-to-be] |
| Reserved | {TBD} 0x2A 0x2A | [RFC-to-be] |
| Reserved | {TBD} 0x3A 0x3A | [RFC-to-be] |
| Reserved | {TBD} 0x4A 0x4A | [RFC-to-be] |
| Reserved | {TBD} 0x5A 0x5A | [RFC-to-be] |
| Reserved | {TBD} 0x6A 0x6A | [RFC-to-be] |
| Reserved | {TBD} 0x7A 0x7A | [RFC-to-be] |
| Reserved | {TBD} 0x8A 0x8A | [RFC-to-be] |
| Reserved | {TBD} 0x9A 0x9A | [RFC-to-be] |
| Reserved | {TBD} 0xAA 0xAA | [RFC-to-be] |
| Reserved | {TBD} 0xBA 0xBA | [RFC-to-be] |
| Reserved | {TBD} 0xCA 0xCA | [RFC-to-be] |
| Reserved | {TBD} 0xDA 0xDA | [RFC-to-be] |
| Reserved | {TBD} 0xEA 0xEA | [RFC-to-be] |
| Reserved | {TBD} 0xFA 0xFA | [RFC-to-be] |
+----------+-------------------------+-----------------+

IANA understands that the Protocol IDs, next to the { TBD } are suggested values based on earlier interoperability testing. IANA will attempt to use these values.

As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry have asked that you send a review request to the mailing list tls-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-12):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-grease@ietf.org, tls-chairs@ietf.org, Sean Turner , tls@ietf.org, sean@sn3rd.com, kaduk@mit.edu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Applying GREASE to TLS Extensibility) to Informational RFC


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Applying GREASE to TLS Extensibility'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-08-12. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes GREASE (Generate Random Extensions And
  Sustain Extensibility), a mechanism to prevent extensibility failures
  in the TLS ecosystem.  It reserves a set of TLS protocol values that
  may be advertised to ensure peers correctly handle unknown values.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-grease/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-grease/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

The GREASE (Generate Random Extensions And Sustain
Extensibility) mechanism is intended to prevent extensibility
failures in the TLS ecosystem.  This document reserves some
currently unused values for TLS implementations to advertise
at random.  Correctly implemented peers will ignore these
values and interoperate.  Peers that do not tolerate unknown
values will fail to interoperate, revealing the mistake before it
is widespread.

The intended status is Informational, which is sufficient to
assign the code points in the TLS registries.  Technically, after
the publication of RFC 8447 this draft does not need to be
published as an RFC to perform these code point assignments
but because GREASE was successfully used to uncover
extensibility failures in the TLS ecosystems, other protocols
could benefit from the same mechanism, and we hear it is
easy to publish RFCs we figured we exercise the process
to get this draft published.

Review and Consensus

David presented the draft multiple times to the WG.  He has
also presented the concept elsewhere; this happen to be my
favorite: https://www.youtube.com/watch?v=_mE_JmwFi1Y
The concept is well understood and was reviewed and adopted
by the WG.  But, there's not much to the draft so there was no
controversy (thankfully).

The draft's timeline is quite long but that is primarily because of
the WG chairs as well as the slow progress of RFC 8447, which allowed
an informational draft to do the assigments.


Intellectual Property

The DS confirmed with the author that any IPR related to
this document has already been disclosed, in conformance
with BCPs 78 and 79.


Other Considerations

There are DOWNREFS in this draft.

This entire document is one beig IANA consideration.
The DS did consult IANA about GREASE and their
suggestion was to check with the Registry DEs.  The DS
consulted with the DEs and they gave the thumbs up!

GREASE is implemented by Chrome.

Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

The GREASE (Generate Random Extensions And Sustain
Extensibility) mechanism is intended to prevent extensibility
failures in the TLS ecosystem.  This document reserves some
currently unused values for TLS implementations to advertise
at random.  Correctly implemented peers will ignore these
values and interoperate.  Peers that do not tolerate unknown
values will fail to interoperate, revealing the mistake before it
is widespread.

The intended status is Informational, which is sufficient to
assign the code points in the TLS registries.  Technically, after
the publication of RFC 8447 this draft does not need to be
published as an RFC to perform these code point assignments
but because GREASE was successfully used to uncover
extensibility failures in the TLS ecosystems, other protocols
could benefit from the same mechanism, and we hear it is
easy to publish RFCs we figured we exercise the process
to get this draft published.

Review and Consensus

David presented the draft multiple times to the WG.  He has
also presented the concept elsewhere; this happen to be my
favorite: https://www.youtube.com/watch?v=_mE_JmwFi1Y
The concept is well understood and was reviewed and adopted
by the WG.  But, there's not much to the draft so there was no
controversy (thankfully).

The draft's timeline is quite long but that is primarily because of
the WG chairs as well as the slow progress of RFC 8447, which allowed
an informational draft to do the assigments.


Intellectual Property

The DS confirmed with the author that any IPR related to
this document has already been disclosed, in conformance
with BCPs 78 and 79.


Other Considerations

There are DOWNREFS in this draft.

This entire document is one beig IANA consideration.
The DS did consult IANA about GREASE and their
suggestion was to check with the Registry DEs.  The DS
consulted with the DEs and they gave the thumbs up!

GREASE is implemented by Chrome.

Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

The GREASE (Generate Random Extensions And Sustain
Extensibility) mechanism is intended to prevent extensibility
failures in the TLS ecosystem.  This document reserves some
currently unused values for TLS implementations to advertise
at random.  Correctly implemented peers will ignore these
values and interoperate.  Peers that do not tolerate unknown
values will fail to interoperate, revealing the mistake before it
is widespread.

The intended status is Informational, which is sufficient to
assign the code points in the TLS registries.  Technically, after
the publication of RFC 8447 this draft does not need to be
published as an RFC to perform these code point assignments
but because GREASE was successfully used to uncover
extensibility failures in the TLS ecosystems, other protocols
could benefit from the same mechanism, and we hear it is
easy to publish RFCs we figured we exercise the process
to get this draft published.

Review and Consensus

David presented the draft multiple times to the WG.  He has
also presented the concept elsewhere; this happen to be my
favorite: https://www.youtube.com/watch?v=_mE_JmwFi1Y
The concept is well understood and was reviewed and adopted
by the WG.  But, there's no much to the draft so there was no
controversy (thankfully).

The draft's timeline is quite long but that is primarily because of
the WG chairs as well as the slow progress of RFC 8447, which allowed
an informational draft to do the assigments.


Intellectual Property

The DS confirmed with the author that any IPR related to
this document has already been disclosed, in conformance
with BCPs 78 and 79.


Other Considerations

There are DOWNREFS in this draft.

This entire document is one beig IANA consideration.
The DS did consult IANA about GREASE and their
suggestion was to check with the Registry DEs.  The DS
consulted with the DEs and they gave the thumbs up!

GREASE is implemented by Chrome.

Summary

Sean Turner is the DS.
Ben Kaduk is the responsible AD.

The GREASE (Generate Random Extensions And Sustain
Extensibility) mechanism is intended to prevent extensibility
failures in the TLS ecosystem.  This document reserves some
currently unused values for TLS implementations to advertise
at random.  Correctly implemented peers will ignore these
values and interoperate.  Peers that do not tolerate unknown
values will fail to interoperate, revealing the mistake before it
is widespread.

The intended status is Informational, which is sufficient to
assign the code points in the TLS registries.  Technically, after
the publication of RFC 8447 this draft does not need to be
published as an RFC to perform these code point assignments
but because GREASE was successfully used to uncover
extensibility failures in the TLS ecosystems, other protocols
could benefit from the same mechanism, and we hear it is
easy to publish RFCs we figured we exercise the process
to get this draft published.

Review and Consensus

David presented the draft multiple times to the WG.  He has
also presented the concept elsewhere; this happen to be my
favorite: https://www.youtube.com/watch?v=_mE_JmwFi1Y
The concept is well understood and was reviewed and adopted
by the WG.  But, there's no much to the draft so there was no
controversy (thankfully).

The draft's timeline is quite long but that is primarily because of
the WG chairs as well as the slow progress of RFC 8447, which allowed
an informational draft to do the assigments.


Intellectual Property

To be confirmed:

The DS confirmed with the author that any IPR related to
this document has already been disclosed, in conformance
with BCPs 78 and 79.


Other Considerations

There are DOWNREFS in this draft.

This entire document is one beig IANA consideration.
The DS did consult IANA about GREASE and their
suggestion was to check with the Registry DEs.  The DS
consulted with the DEs and they gave the thumbs up!

GREASE is implemented by Chrome.