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

David Benjamin <davidben@google.com> Thu, 15 August 2019 18:52 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 B914E120233 for <tls@ietfa.amsl.com>; Thu, 15 Aug 2019 11:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 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, 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 teZuwsb7g0lR for <tls@ietfa.amsl.com>; Thu, 15 Aug 2019 11:52:55 -0700 (PDT)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 3021F120241 for <tls@ietf.org>; Thu, 15 Aug 2019 11:52:55 -0700 (PDT)
Received: by mail-pg1-x543.google.com with SMTP id k3so1667684pgb.10 for <tls@ietf.org>; Thu, 15 Aug 2019 11:52:55 -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=5uMlsCBkQos1j0sMhzrzTYVxNrYWXlz5AI2dyb8XuV0=; b=RrmLEwH39icTCWHZWLjJngVcQkV797xR9nrfer8uoflrTD5LEQpiczbmUfuNaz2WO7 mK93WmHpfC1AyI9DGBV/zbR2p0YFLx3/MH4bTZX4i5YPR1M7u2TEP9i+L5wtT+p4+2Gh eiizyEXHhntUXwjT+n14xoNE6+AYjjasmUuFEGCZRrE5AtJx+RQ554VD70Unv736sFD+ izkNR0VjFVLYU9pUJpEqzgzdJctLmRHhTXdZttgn+ELDJgZDX18xO2wS2T5Z6z3QC+VO vkZS6q/v02nXu8SSTxFfddd+PGA1OqN9wlwW2hdd6RXK00XhszE6lFgQC/BdnJkwhYQJ r6TQ==
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=5uMlsCBkQos1j0sMhzrzTYVxNrYWXlz5AI2dyb8XuV0=; b=H4MbC/c6CCM1nUCDsK+bGgulMmifAs0eO5Cgl3jLlbsNxuHnqdPmOXnS+urNfd7Quk BMRISw5Lv0KRcnxi7VKCMdhYoXQmIILPsz+bSh+uqbLIbPX1o9mXklikhZojb54TOhWI 41LaIQqQs0KUb85VQZn6bKdrDDphoanANmwu7xstXUO5Y3e6mtVToXinAlhDgLnCEk0U svbMbIlLzKiA0uoqsWZSjymgXh9038wO8nWwnusICafcUFm6WCM5Fu/zNdAa2F0z7yrE 60Vg7CNkcCRg4JqILV3sIYiCZyQuWPrl55f8+VBbLCmVDn3CqRnLjqhCoLUXqWDpg9IK rrEg==
X-Gm-Message-State: APjAAAWLQfc8ksPFavOhPurmLaKuB887i68CzO5agI0uF6j09z/q2VT4 H/SVAzPSIBn0swS8u/2GbHTSmcEuIK2FGMenrZTl
X-Google-Smtp-Source: APXvYqzk/jO7MiLmQPOXxAJwEYDz6QIHS82mKmfqv9T4UiwCUyFWWopRhClKWlsMfSLkk+CsAK2meD/xSncxr+Zymw0=
X-Received: by 2002:a63:2685:: with SMTP id m127mr4594213pgm.6.1565895174162; Thu, 15 Aug 2019 11:52:54 -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>
In-Reply-To: <44BDC996-0E18-48BE-A700-C49A101330F8@kuehlewind.net>
From: David Benjamin <davidben@google.com>
Date: Thu, 15 Aug 2019 14:52:37 -0400
Message-ID: <CAF8qwaC7CvyrzrS=SWD9OT9Eq6BGirha2cjut5P-Wz5bz6NQAg@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="0000000000009d307705902c612c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CDRkOW6p1I_OLG0XxS4kYMfg2u8>
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, 15 Aug 2019 18:52:59 -0000

On Thu, Aug 15, 2019 at 11:30 AM Mirja Kuehlewind <ietf@kuehlewind.net>;
wrote:

> Hi Ben,
>
> See line.
>
> > On 15. Aug 2019, at 17:24, Benjamin Kaduk <kaduk@mit.edu>; wrote:
> >
> > On Thu, Aug 15, 2019 at 08:14:12AM -0700, Mirja Kühlewind via
> Datatracker wrote:
> >> Mirja Kühlewind has entered the following ballot position for
> >> draft-ietf-tls-grease-03: No Objection
> >>
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut this
> >> introductory paragraph, however.)
> >>
> >>
> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-grease/
> >>
> >>
> >>
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> 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.)


> >
> >> And a note on normative language:
> >>
> >> "Implementations sending multiple
> >>   GREASE extensions in a single block thus must ensure the same value
> >>   is not selected twice."
> >> Should this be a "MUST"?
> >
> > I asked for this to be changed away from a "MUST" -- RFC 8466 already has
> > this prohibition on duplicated values; we're just calling it out again
> here
> > since randomly picking values (with replacement, which is the easy way to
> > code it) can result in collisions, that are forbidden by 8446.
>
> Ah okay, that’s fine. Didn’t check 8446.
> >
> >> Also this is an interesting MUST:
> >> "... MUST correctly ignore unknown values..."
> >> While this is the whole point of the document, I assume this is already
> >> normatively specified in RFC8446 and therefore it could make sense to
> use
> >> non-formative language here...
> >
> > I think you are correct, but I personally do not mind the extra normative
> > force in this case.
>
> I just found this actually particularly weird because of the “correctly”.
> To me it reads like “please, please finally follow normative specification
> we do in RFCs”… anyway… I after all don't really mind if you pick on or the
> other.
>
> Mirja
>
>
>
> >
> > -Ben
> >
> >
>
>