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

Benjamin Kaduk <kaduk@mit.edu> Thu, 15 August 2019 15:24 UTC

Return-Path: <kaduk@mit.edu>
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 92E43120090; Thu, 15 Aug 2019 08:24:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 riKRGpHL0DFV; Thu, 15 Aug 2019 08:24:11 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263F01200BA; Thu, 15 Aug 2019 08:24:10 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x7FFO6Fu024027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 11:24:08 -0400
Date: Thu, 15 Aug 2019 10:24:05 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mirja =?iso-8859-1?Q?K=FChlewind?= <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tls-grease@ietf.org, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
Message-ID: <20190815152405.GS88236@kduck.mit.edu>
References: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <156588205271.15865.9243229289426203471.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HXODVG2QwmHjutKQiAiGGuzKxvE>
Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-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 15:24:14 -0000

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.

> 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.

> 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.

-Ben