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

David Benjamin <davidben@google.com> Fri, 16 August 2019 16:17 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 B240C120865 for <tls@ietfa.amsl.com>; Fri, 16 Aug 2019 09:17:10 -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 pMS8aLrlXh0n for <tls@ietfa.amsl.com>; Fri, 16 Aug 2019 09:17:09 -0700 (PDT)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 2A48712029C for <tls@ietf.org>; Fri, 16 Aug 2019 09:17:09 -0700 (PDT)
Received: by mail-pl1-x634.google.com with SMTP id t14so2620248plr.11 for <tls@ietf.org>; Fri, 16 Aug 2019 09:17:09 -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=6QD5Rxi5Bu3hkJNq+D8RzfnB59ixYqxRlW1C2Td3sxQ=; b=c3KE16LITQz4ko8An2fklj7z4uHfX+Wx6rJ9vk6qrhvEN9CpxkmuNIkEMZdtXb98TU WFfpSLlR2fVb+OAkrLh+aBv4HbBy0+hYAr8Sf61wyR9Sff9kG3oCSyNlNdRqDu91qUeV vmuXrmFRyHKbvIT+e8+e649tfvCZl+gl1Ua9aAUyruzMZ+pG4Vkpv6RCJFCCUSGDbJCl 1Q/nYf1zQINmEZNNbs8R5MPo6N/qiTpl7IYjBnP+UioXm8EliMU3/DdVhoxzwwfoL01m YBLdGzAUN65J/mqeV5o/WAyxlDAo08wTiBakTqK6aFk/jARJyKKW3yqj91QsamhH1Pxq QpKg==
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=6QD5Rxi5Bu3hkJNq+D8RzfnB59ixYqxRlW1C2Td3sxQ=; b=JszuwuyB+sFJ1JAsba5GDxFTnejBvOo/cCrwPGUw9ea9W2b6CArObceux304iQYBCB WgsiRBzS/d8NH9CWEF7niaDDiFk4LmxAVZ7gkJB8FfXmbD0DP2oI84jV84+YMDqYVp30 WNfE+4aqBmu/1cG6H9xJHEs57vL69oOw9IHrHMzFwYgUZypnjrJER0gTfoFwaCwWErbt JRDS8/ZD791/0qe/yGv/fQcmETHBOYE+RxQnwVuXvD5xUOE2BG+HQjTXFnJ7L7YlBIJc pqF3KfASmidItpY3G0qqBHUts5f/dYAisNQ/ddiZ5NcqGeIG8A6YoxY+fwnO4uksiiqQ vWqw==
X-Gm-Message-State: APjAAAVyE9xiD6dLdmdqRV91hL4x91N8IUkJp60WqC9ZODZcG4nQArQh Xmq8o67NiK+OBOuZC8MYXYu2N3B9E4kC6RdrqIlV
X-Google-Smtp-Source: APXvYqw0um55K5F3MF7lYJ5hr/nO5uq3leCppRilZToyLWlVGTx4gT4+mTaPU5Lsw3C+h8eEKpOTobtZKEM8qUCGcA8=
X-Received: by 2002:a17:902:e510:: with SMTP id ck16mr1502738plb.334.1565972228367; Fri, 16 Aug 2019 09:17:08 -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>
In-Reply-To: <6BD4AC5B-BA54-4BED-8B9B-ECA298E8BF0F@kuehlewind.net>
From: David Benjamin <davidben@google.com>
Date: Fri, 16 Aug 2019 12:16:50 -0400
Message-ID: <CAF8qwaBmrgzBPF-FrdO1md8pAAG_M1mR4feW0t3amxfc10oy9A@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-tls-grease@ietf.org, "<tls@ietf.org>" <tls@ietf.org>, The IESG <iesg@ietf.org>, Sean Turner <sean@sn3rd.com>, tls-chairs <tls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000066c86d05903e52e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g8hxEcJi1sWP2LYILRXO2fuCHhg>
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: Fri, 16 Aug 2019 16:17:11 -0000

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.

David