Subject: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-grease-03: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 15 Aug 2019 08:57:43 -0700

Mirja Kühlewind 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:
----------------------------------------------------------------------

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 15 Aug 2019 22:39:31 -0500

> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/

I added a note to the shepherd writeup's "intended document status" entry:

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.

-Ben

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 16 Aug 2019 09:35:09 +0200

Hi Ben,

Thanks for the explanation.

I would think this is actually a PS given it extents a protocol based on the extension point this protocol provides. Maybe it is not really adding a new function but it also kind of is: I would call probing for non-compliant implementations a protocol function. I mean if we would specify greasing for a new protocol, I think it would simply be part of the main spec.

Mirja

> On 16. Aug 2019, at 05:39, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Aug 2019 18:07:07 -0500

> I would think this is actually a PS given it extents a protocol based on the extension point this protocol provides. Maybe it is not really adding a new function but it also kind of is: I would cal…

Re "part of the main spec", perhaps, but presumably not a
mandatory-to-implement one?
To look at it a different way, what kind of interoperability requirements
does GREASE mandate?  Isn't it just the same interoperability requirements
of the main protocol, i.e., an incremental addition of zero?

-Ben

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 18 Aug 2019 02:43:52 +0200

I do not think this needs to be a PS specification. The code points here do
not require a standards track RFC.

Note that advancing this at PS would require a new IETF LC.

-Ekr

On Sun, Aug 18, 2019 at 1:07 AM Benjamin Kaduk <[email-masked]> wrote:

> > I would think this is actually a PS given it extents a protocol based on
> the extension point this protocol provides. Maybe it is not really adding a
> new function but it also kind of is: I would call probing for non-compliant
> implementations a protocol function. I mean if we would specify greasing
> for a new protocol, I think it would simply be part of the main spec.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>