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:14:12 -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:
----------------------------------------------------------------------

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 10:24:05 -0500

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

I'll let the authors chime in, but I think the sense of the security
considerations is more that we are preventing the fallback from being
needed "in production due to "real" negotiation failures.  Falling back on
GREASE failure is not as bad, provided that you follow-up with the failing
peer out of band to try to get it fixed.
I don't know how much value there would be in caching the grease-intolerate
status; ideally it would almost-never happen.

>    GREASE extensions in a single block thus must ensure the same value

I asked for this to be changed away from a "MUST" -- RFC 8466 already has
this prohibition on duplicated values; we're just calling it out again here
since randomly picking values (with replacement, which is the easy way to
code it) can result in collisions, that are forbidden by 8446.

> non-formative language here...

I think you are correct, but I personally do not mind the extra normative
force in this case.

-Ben

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 15 Aug 2019 17:30:08 +0200

Hi Ben,

See line.

> On 15. Aug 2019, at 17:24, Benjamin Kaduk <[email-masked]> wrote:
> 

Okay, then I think it would be nice to say something more in the document, about fallback at least.

> code it) can result in collisions, that are forbidden by 8446.

Ah okay, that’s fine. Didn’t check 8446.
> I think you are correct, but I personally do not mind the extra normative

I just found this actually particularly weird because of the “correctly”. To me it reads like “please, please finally follow normative specification we do in RFCs”… anyway… I after all don't really mind if you pick on or the other.

Mirja

---

From: David Benjamin <[email-masked]>
Date: Thu, 15 Aug 2019 14:52:37 -0400

On Thu, Aug 15, 2019 at 11:30 AM Mirja Kuehlewind <[email-masked]>
wrote:

> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Ben's description is right. If deploying a new TLS feature results in too
many interop failures with existing buggy servers, that feature becomes
difficult to deploy and there is a lot of pressure to apply some sort of
mitigation like a fallback. That's no good. GREASE's goal is to avoid the
interop failures to begin with. The text was not meant to imply that you
should do any sort of fallback.

What change did you have in mind? The current text says:

> Historically, when interoperability problems arise in deploying new TLS
features, implementations have used a fallback retry on error with the
feature disabled. This allows an active attacker to silently disable the
new feature. By preventing a class of such interoperability problems,
GREASE reduces the need for this kind of fallback.

That reads to me as describing historical fallbacks, rather than
recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are
bad. They break downgrade protection.)

> I just found this actually particularly weird because of the “correctly”.
> To me it reads like “please, please finally follow normative specification
> we do in RFCs”… anyway… I after all don't really mind if you pick on or the
> other.
>
> Mirja
>
>
>
> >
> > -Ben
> >
> >
>
>

---

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

Hi David,

See below.

> On 15. Aug 2019, at 20:52, David Benjamin <[email-masked]> wrote:
> 
> On Thu, Aug 15, 2019 at 11:30 AM Mirja Kuehlewind <[email-masked]> wrote:
> Hi Ben,
> 
> See line.
> 
> Ben's description is right. If deploying a new TLS feature results in too many interop failures with existing buggy servers, that feature becomes difficult to deploy and there is a lot of pressure to apply some sort of mitigation like a fallback. That's no good. GREASE's goal is to avoid the interop failures to begin with. The text was not meant to imply that you should do any sort of fallback.
> 
> > Historically, when interoperability problems arise in deploying new TLS features, implementations have used a fallback retry on error with the feature disabled. This allows an active attacker to silently disable the new feature. By preventing a class of such interoperability problems, GREASE reduces the need for this kind of fallback.
> 
> That reads to me as describing historical fallbacks, rather than recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are bad. They break downgrade protection.)

I was thinking about adding some new text somewhere else in the document that give a recommendation if you should fallback on grease and when.

---

From: David Benjamin <[email-masked]>
Date: Fri, 16 Aug 2019 12:16:50 -0400

On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <[email-masked]>
wrote:

> > Ben's description is right. If deploying a new TLS feature results in
> too many interop failures with existing buggy servers, that feature becomes
> > > Historically, when interoperability problems arise in deploying new
> TLS features, implementations have used a fallback retry on error with the
> I was thinking about adding some new text somewhere else in the document
> that give a recommendation if you should fallback on grease and when.
>

I mean, the answer to that is "don't" and "never", just as is unstatedly
true for any other TLS extension. TLS's downgrade protection doesn't work
if you do fallbacks. While downgrading from GREASE doesn't matter per se,
it defeats the purpose, so the usual rules for TLS apply.

David

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 19 Aug 2019 09:51:04 +0200

Hi David,

> On 16. Aug 2019, at 18:16, David Benjamin <davidben=[email-masked]> wrote:
> 
> On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <[email-masked]> wrote:
> > That reads to me as describing historical fallbacks, rather than recommending new ones. (Indeed you shouldn't do fallbacks. Fallbacks are bad.. They break downgrade protection.)
> 
> I mean, the answer to that is "don't" and "never", just as is unstatedly true for any other TLS extension. TLS's downgrade protection doesn't work if you do fallbacks. While downgrading from GREASE doesn't matter per se, it defeats the purpose, so the usual rules for TLS apply.

For me this wasn’t clear because this is not just a “normal” extension. If you want to be sure that it is clear to everybody, you should write it down in the draft. However, that my view and this was a just a comment to consider, so the authors (and group) need to decide.

Mirja

---

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

On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind <[email-masked]>
wrote:

> bad.. They break downgrade protection.)
> >
> For me this wasn’t clear because this is not just a “normal” extension. If
> you want to be sure that it is clear to everybody, you should write it down
> in the draft. However, that my view and this was a just a comment to
> consider, so the authors (and group) need to decide.
>

Fair enough. I've added the following to that paragraph in my local copy.

     Implementations SHOULD
     NOT retry with GREASE disabled on connection failure. While allowing an
     attacker to disable GREASE is unlikely to have immediate security
     consequences, such a fallback would prevent GREASE from defending
against
     extensibility failures.

I'll upload it as -04 after all the comments come in.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 22 Aug 2019 09:48:37 +0200

Thanks!

> On 21. Aug 2019, at 23:34, David Benjamin <davidben=[email-masked]> wrote:
> 
> On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind <[email-masked]> wrote:
> Hi David,
> 
> 
> > On 16. Aug 2019, at 18:16, David Benjamin <davidben=[email-masked]..org> wrote:
> > 
>      consequences, such a fallback would prevent GREASE from defending against
>      extensibility failures.
>

---

From: David Benjamin <[email-masked]>
Date: Thu, 22 Aug 2019 14:22:59 -0400

On Thu, Aug 22, 2019 at 3:48 AM Mirja Kuehlewind <[email-masked]>
wrote:

> > > On 16. Aug 2019, at 18:16, David Benjamin
> <davidben=[email-masked]..org> wrote:
> > >
> > > > Ben's description is right. If deploying a new TLS feature results
> in too many interop failures with existing buggy servers, that feature
> becomes difficult to deploy and there is a lot of pressure to apply some
> sort of mitigation like a fallback. That's no good. GREASE's goal is to
> avoid the interop failures to begin with. The text was not meant to imply
> that you should do any sort of fallback.
> > > >
> > > > > Historically, when interoperability problems arise in deploying
> new TLS features, implementations have used a fallback retry on error with
> the feature disabled. This allows an active attacker to silently disable
> the new feature. By preventing a class of such interoperability problems,
> > > I was thinking about adding some new text somewhere else in the
> document that give a recommendation if you should fallback on grease and
> when.
> > >
> > > I mean, the answer to that is "don't" and "never", just as is
> unstatedly true for any other TLS extension. TLS's downgrade protection
> doesn't work if you do fallbacks. While downgrading from GREASE doesn't
> matter per se, it defeats the purpose, so the usual rules for TLS apply.
> >
> >
> > For me this wasn’t clear because this is not just a “normal” extension.
> If you want to be sure that it is clear to everybody, you should write it
> down in the draft. However, that my view and this was a just a comment to

Uploaded:
https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-grease-03&url2=draft-ietf-tls-grease-04