Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Nico Williams <nico@cryptonector.com> Thu, 13 July 2017 20:27 UTC

Return-Path: <nico@cryptonector.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 A2888129562 for <tls@ietfa.amsl.com>; Thu, 13 Jul 2017 13:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 XvlMShKfs02u for <tls@ietfa.amsl.com>; Thu, 13 Jul 2017 13:27:26 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874AC12009C for <tls@ietf.org>; Thu, 13 Jul 2017 13:27:26 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 0CE54C086D10; Thu, 13 Jul 2017 13:27:26 -0700 (PDT)
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id AAEFAC086D0A; Thu, 13 Jul 2017 13:27:25 -0700 (PDT)
Date: Thu, 13 Jul 2017 15:27:22 -0500
From: Nico Williams <nico@cryptonector.com>
To: Stephen Checkoway <s@pahtak.org>
Cc: "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Message-ID: <20170713202721.GA2926@localhost>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <E0D7FC2A-23E6-4317-868E-F68633C58030@pahtak.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E0D7FC2A-23E6-4317-868E-F68633C58030@pahtak.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pt4ruJyombzwZsI-eoIUvQ6m4Bw>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 13 Jul 2017 20:27:28 -0000

On Thu, Jul 13, 2017 at 03:01:04PM -0500, Stephen Checkoway wrote:
> I don't think the WG should adopt this.

+1

> There are essentially two separate proposals in the I-D. Section 5
> proposes a slight change to TLS that results in no changes on the wire
> and, as far as I can tell, is already allowed (but should probably be
> discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to
> do.
> 
> Sections 6 and 7 propose a new protocol for distributing key pairs.
> The use case is TLS, but it isn't specific to TLS and doesn't interact
> with TLS (outside of using TLS for HTTPS). As such, I believe it's
> outside the WG's charter.

Agreed.

Authors should make an ISE submission aiming for Informational, or just
let the I-D expire and never bring it up again -- that would work just
as well for me.  The IESG could always direct the ISE to not publish.

Given the lack of normative language in the proposed I-D, Informational
is the only track that makes sense.

What's to be gained by anyone in having this be a WG item anyways?
A patina of legitimacy is the only thing I can think of.

What's to be gained by anyone in having this be an RFC?  A patina of
legitimacy with which to flog it at implementors is the only thing I can
think of.

Legislatures elsewhere can always just legislate this sort of thing
(think CALEA).  But there's no reason the IETF should preemptively help
such things along.

I wouldn't be too annoyed if this gets published as an RFC because it's
all obvious and could always get published elsewhere anyways.  Refusing
to publish here won't keep this sort of thing from getting specified and
implemented.  But there is no need for the IETF's help in the matter.

Nico
--