Hi David,
> On 16. Aug 2019, at 18:16, David Benjamin > <davidben=40google....@dmarc.ietf.org> wrote: > > On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <i...@kuehlewind.net> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
