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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 20 Aug 2019 10:39:14 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-tls-grease-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-grease/

----------------------------------------------------------------------
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”?

---

From: David Benjamin <[email-masked]>
Date: Wed, 21 Aug 2019 17:44:22 -0400

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.)

> 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

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 22 Aug 2019 10:02:01 +1000

On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote:
>  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."

Perhaps what you are looking for is "cannot": "GREASE values cannot be negotiated, ..."

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 22 Aug 2019 03:18:47 +0000

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Wednesday, August 21, 2019 8:02 PM
> To: David Benjamin <davidben=[email-masked]>; Roman
> Danyliw <[email-masked]>
> Cc: [email-masked]; <[email-masked]> <[email-masked]>; The IESG
> <[email-masked]>; tls-chairs <[email-masked]>
> Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-grease-03:
> (with COMMENT)
> 
> > 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."
> 

A "cannot" would make sense to me.

Roman

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 22 Aug 2019 03:31:27 +0000

Hi David!

From: iesg [mailto:[email-masked]] On Behalf Of David Benjamin
Sent: Wednesday, August 21, 2019 5:44 PM
To: Roman Danyliw <[email-masked]>
Cc: [email-masked]; <[email-masked]> <[email-masked]>; The IESG <[email-masked]>; Sean Turner <[email-masked]>; tls-chairs <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Per the following:

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..”

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.

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

 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.

---

From: David Benjamin <[email-masked]>
Date: Thu, 22 Aug 2019 11:03:50 -0400

> A "cannot" would make sense to me.

"cannot" it is! :-)

David