On Thu, Aug 22, 2019 at 3:48 AM Mirja Kuehlewind <i...@kuehlewind.net> wrote:
> 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. > Uploaded: https://www.ietf.org/rfcdiff?url1=draft-ietf-tls-grease-03&url2=draft-ietf-tls-grease-04
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
