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

[Mirja Kuehlewind <[e-mail]>]

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.

Mirja



> 
> David