Thanks! > On 21. Aug 2019, at 23:34, David Benjamin > <davidben=40google....@dmarc.ietf.org> wrote: > > On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind <i...@kuehlewind.net> wrote: > 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. > > 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
