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

David Benjamin <davidben@google.com> Thu, 22 August 2019 18:23 UTC

Return-Path: <davidben@google.com>
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 8300E12082D for <tls@ietfa.amsl.com>; Thu, 22 Aug 2019 11:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 ce12en9akfVO for <tls@ietfa.amsl.com>; Thu, 22 Aug 2019 11:23:16 -0700 (PDT)
Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 A4577120ABF for <tls@ietf.org>; Thu, 22 Aug 2019 11:23:16 -0700 (PDT)
Received: by mail-pl1-x632.google.com with SMTP id 4so3908339pld.10 for <tls@ietf.org>; Thu, 22 Aug 2019 11:23:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GzI3uX+AtvwmgCTMsImGSbhDaS99jybRKrQAAHLuiU0=; b=eZ5XQsHUJWOg6haHQrTOEjphL2d+ayriEDBp796dhv2AJvQc3xH5YeNZ4CoX2JP7wq 9CFJsZIrStfLPdRgBE3rncb7D4muKjuhaBuQHFvr/7g537CacGPQ1CIsU8hbLccL1yxN y/xttYA0o53Woq6MBwquC/T0jfW6RXGvoKDglFmSXHFVtoGRptt3ClxeXfifNQalsIGp 2UhkUMnBiwhorggfG/nLzM+iBcWU2r+ETExAi6KJish1pMIqK8+Q2SfHmKZn34Hj/fXN XENy7DiSKxWHzFxtDiXcpMNbPkc25JhBi8v/bv9YFEvKIkcKyq48lMO6ZUOPC2Ds+9zh GIIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GzI3uX+AtvwmgCTMsImGSbhDaS99jybRKrQAAHLuiU0=; b=U1GGIQbpJD+BXeDpiUrypuvnAXVBewcHByDr6apJNcghXTHFQNFIxmwQtV7rUfZsLm g80YRSAfPlj5Gxbfuv0SVBMjgswzAXFhyfsMf/zZpMENrHeeeFpWDMxFcw+Zrm8ggl9N uB526Hrua72Czpqti1KYZSYRHfaKgZx7HtVCunlUTu4vjw1MssxWsH/4t5UUzh85GYLW /YvkjUhnehymp6DinsAkDondN0GqsCu2eP+87VjR0u0JQEbvlX0orBnTH0nAmPEor5rb TiTbD5gzsGSy5MhcPOVE3zTfAtrk5Kq3M1jVplqVvmsTzftdaA+IYJD6DMTzXDoRXuCF DYWQ==
X-Gm-Message-State: APjAAAWdMxBs0P9CIvsFbgCfh6zyGd7e+BNptNEC+yTtdmA3SZJpU5l1 xsSWRZagKMuzZarL45Oa9UebJ3VQq3j8jr5ctXKe
X-Google-Smtp-Source: APXvYqy5mCnASGcaQthoMh7w6nvwTCbhZtmmuVhNcN0Ss4hMER77Juunn/I4BTSTnSWcMnyEpJKIfYH16qDmNquNik0=
X-Received: by 2002:a17:902:f64:: with SMTP id 91mr156959ply.334.1566498195837; Thu, 22 Aug 2019 11:23:15 -0700 (PDT)
MIME-Version: 1.0
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> <FE02C127-99E9-4C43-BC9C-1C94A56870F1@kuehlewind.net> <CAF8qwaD95ROS2KetzpGGHBRL4L1mgTcs1pw4D5qwR49O-+pjhw@mail.gmail.com> <98ECFB35-5D77-433F-A902-B96E5EB3F33A@kuehlewind.net>
In-Reply-To: <98ECFB35-5D77-433F-A902-B96E5EB3F33A@kuehlewind.net>
From: David Benjamin <davidben@google.com>
Date: Thu, 22 Aug 2019 14:22:59 -0400
Message-ID: <CAF8qwaAb6DeX_uzYTAniP15gr4o1znw5PVe-KiPGtZ_x=15wgw@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: David Benjamin <davidben=40google.com@dmarc.ietf.org>, draft-ietf-tls-grease@ietf.org, Benjamin Kaduk <kaduk@mit.edu>, tls-chairs <tls-chairs@ietf.org>, The IESG <iesg@ietf.org>, Sean Turner <sean@sn3rd.com>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008180860590b8c8ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qaziUcrIeyQ4e8ZvXgdnkxk4Phc>
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: Thu, 22 Aug 2019 18:23:20 -0000

On Thu, Aug 22, 2019 at 3:48 AM Mirja Kuehlewind <ietf@kuehlewind.net>;
wrote:

> Thanks!
>
> > On 21. Aug 2019, at 23:34, David Benjamin <davidben=
> 40google.com@dmarc.ietf.org>; wrote:
> >
> > On Mon, Aug 19, 2019 at 3:51 AM Mirja Kuehlewind <ietf@kuehlewind.net>;
> wrote:
> > 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.
> >
> > 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