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

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 19 August 2019 07:51 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8240B120072; Mon, 19 Aug 2019 00:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jyvzpkzOAFV; Mon, 19 Aug 2019 00:51:09 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A843120110; Mon, 19 Aug 2019 00:51:09 -0700 (PDT)
Received: from 200116b82c4ebb005df5fa3ef969d67c.dip.versatel-1u1.de ([2001:16b8:2c4e:bb00:5df5:fa3e:f969:d67c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hzcRU-0000iE-RO; Mon, 19 Aug 2019 09:51:04 +0200
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <CAF8qwaBmrgzBPF-FrdO1md8pAAG_M1mR4feW0t3amxfc10oy9A@mail.gmail.com>
Date: Mon, 19 Aug 2019 09:51:04 +0200
Cc: draft-ietf-tls-grease@ietf.org, "<tls@ietf.org>" <tls@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, tls-chairs <tls-chairs@ietf.org>, Sean Turner <sean@sn3rd.com>, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE02C127-99E9-4C43-BC9C-1C94A56870F1@kuehlewind.net>
References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com> <20190815152405.GS88236@kduck.mit.edu> <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net> <CAF8qwaC7CvyrzrS=SWD9OT9Eq6BGirha2cjut5P-Wz5bz6NQAg@mail.gmail.com> <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net> <CAF8qwaBmrgzBPF-FrdO1md8pAAG_M1mR4feW0t3amxfc10oy9A@mail.gmail.com>
To: David Benjamin <davidben=40google.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1566201069;8d5c65e9;
X-HE-SMSGID: 1hzcRU-0000iE-RO
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/89ADCKxw3yFEWRBOQjtV8Oh69Jk>
Subject: Re: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-grease-03=3A_=28with_COMMENT=29?=
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Aug 2019 07:51:12 -0000

Hi David,


> On 16. Aug 2019, at 18:16, David Benjamin <davidben=40google.com@dmarc.ietf.org>; wrote:
> 
> On Fri, Aug 16, 2019 at 3:39 AM Mirja Kuehlewind <ietf@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