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

[David Benjamin <[e-mail]>]

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

> Hi David,
>
>
> > On 16. Aug 2019, at 18:16, David Benjamin <davidben=
> [e-mail]> wrote:
> >
> > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <[e-mail]>
> wrote:
> > > >> 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?
> > > >
> > > > 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.
> > >
> > > Okay, then I think it would be nice to say something more in the
> document, about fallback at least.
> > >
> > > 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 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
> 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.