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

David Benjamin <davidben@google.com> Wed, 21 August 2019 21:34 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 03508120099 for <tls@ietfa.amsl.com>; Wed, 21 Aug 2019 14:34:31 -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=unavailable 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 9-BEtY0bWY90 for <tls@ietfa.amsl.com>; Wed, 21 Aug 2019 14:34:28 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 ACEE1120089 for <tls@ietf.org>; Wed, 21 Aug 2019 14:34:28 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id w16so2302679pfn.7 for <tls@ietf.org>; Wed, 21 Aug 2019 14:34:28 -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=MRJiHsWXjhstB5ngxHaEh4TCrtXjmn2vcMbatuOabzM=; b=jXZweP24PKml+bbYzV59R0KQK618YJjyWsUmztGMZ/piMkZncLVEuhhhbozElbfVA9 8IpqqWHv6c46uIIYmcsx5J3Nef6rc7TuFdoDKRb0LJynwGEaRDS1yxSg9G2er6C0J9H4 9ftJ3WZ6y0B570O3tp9zG2i7rjP6RSbwNCOdi6jgOTBSU5oyNNeqfQ7l1OeLZ+UlZvqY aP0Q6Z+ixF5bgon3391BVGK8dxdFkZaJN2xyj9co3SMdo34sOe2KgI8fC4D1LWeB0h/y trJ1EIJ3UiJC51S325mZBu34DVARuhnRsinqZR2HY+a4FIHzEoAu7okQ+vQLWx6gY3am qcVg==
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=MRJiHsWXjhstB5ngxHaEh4TCrtXjmn2vcMbatuOabzM=; b=jwRPLga0sheD/aMmuA4aO56+s9VVUr4mnqX94EVeAlb1V7GKXOeJ6hlAMo8GrCthfE ysDp/MJdiba9CSJ71ZLdncY5ATmnSwA0fKF6WPm/97GAJbOrNghYBLpL+0zILIzC+DDY diHxuTxZrOJnateSNXVp5XCaj+Wxcp7fdWIfDYzBb0bVRcEkCKMOZs7ZaxEN/hg2Nmnt TDveSpMLt9ZpQ1BF2DjZc6TjnyaKIPJkojVbmt0lQtlZYKzOjn0Gdpue6I0Hqm3US2b6 gJaJ4cZYVXE+Xmo9qHAkjtbys4SmWQhzm1oGDw1dcfYRFwj1KdmrEi2TLIzWcFXvW/o8 461g==
X-Gm-Message-State: APjAAAWjbTV4JC0ThF2/ETB6lzXlwM8nIefU9aNKxhM9OXl9Up/ORH8f JHIEobv4sWn95zoP4ArWsBEfIopIyjbu0oyFDWeP
X-Google-Smtp-Source: APXvYqywbI2rVZ4kkuPf/17rxCqv+Him9ixqcAvvlOBeshvz4/hOLDn8CMf1iOqZRBOPRjwcl7NZzHEVyMTspaecgCI=
X-Received: by 2002:aa7:8144:: with SMTP id d4mr39130801pfn.6.1566423267930; Wed, 21 Aug 2019 14:34:27 -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>
In-Reply-To: <FE02C127-99E9-4C43-BC9C-1C94A56870F1@kuehlewind.net>
From: David Benjamin <davidben@google.com>
Date: Wed, 21 Aug 2019 17:34:11 -0400
Message-ID: <CAF8qwaD95ROS2KetzpGGHBRL4L1mgTcs1pw4D5qwR49O-+pjhw@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: David Benjamin <davidben=40google.com@dmarc.ietf.org>, 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-Type: multipart/alternative; boundary="000000000000745e300590a75634"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EkHs6JsdKwJeU1WcZckfhP-HSRA>
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: Wed, 21 Aug 2019 21:34:31 -0000

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.