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

[David Benjamin <[e-mail]>]

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

> Thanks!
>
> > On 21. Aug 2019, at 23:34, David Benjamin <davidben=
> [e-mail]> wrote:
> >
> > 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]..org> 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.
>

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