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

Russ Housley <housley@vigilsec.com> Fri, 07 July 2017 21:38 UTC

Return-Path: <housley@vigilsec.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 9B30813163D for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:38:40 -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] 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 Nysx5icId2je for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:38:39 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AA412EB8E for <tls@ietf.org>; Fri, 7 Jul 2017 14:38:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5F4F0300563 for <tls@ietf.org>; Fri, 7 Jul 2017 17:38:38 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Es_-gKaia8dd for <tls@ietf.org>; Fri, 7 Jul 2017 17:38:37 -0400 (EDT)
Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D8DC2300250; Fri, 7 Jul 2017 17:38:36 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie>
Date: Fri, 07 Jul 2017 17:38:36 -0400
Cc: IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E639C60A-D90C-46C2-9A18-5D02D6EBD9E4@vigilsec.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie> <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com> <658a6b50-54a7-600a-2f6a-480daf2321dc@cs.tcd.ie> <F830F0DA-F3F1-4A61-8B42-100D31E6F831@vigilsec.com> <1ebb85c3-842e-36f6-ccd5-da7074342118@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/w0un9J1G3j860n7V-7a-X1NDuu8>
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: Fri, 07 Jul 2017 21:38:40 -0000

Stephen:

>>> You didn't refer to 2804 and the standards track. As an author do
>>> you really think this can be on the standards track and yet not
>>> obsolete 2804?
>> 
>> Yes. 
> 
> We disagree.
> 
>> Section 3 of RFC 2804 offers pretty clear definition of
>> wiretapping, and that is not what is going on here.  In this
>> situation, all of the parties are part of the same organization,
>> under common key management.  
> 
> That is one possible deployment. There is nothing in this
> proposal that limits it's use to that.
> 
>> The server must explicitly accept and
>> use the centrally managed (EC)DH key, so that party is completely
>> aware and, in fact, enabling the other parties to decrypt the
>> traffic.
> 
> Yes, and the server could equally be compelled to do that,
> in which case this technology would clearly be a standard
> form of wiretapping.
> 
> Claiming that is not the case would be incredible so I have
> no idea how you maintain that this isn't in conflict with
> 2804.

That does not follow the definition in Section 3 of RFC 2804.  If one of the parties is "compelled" to install the centrally managed (EC)DH key, then the server is aware.  If you consider the server to be the sending party, then this situation does not meet number 1 in the definition.  If you consider the server to be the receiving party, then this situation does not meet number 2 in the definition.

To save everyone from looking it up, RFC 2804 says:

   Wiretapping is what occurs when information passed across the
   Internet from one party to one or more other parties is delivered to
   a third party:

   1. Without the sending party knowing about the third party

   2. Without any of the recipient parties knowing about the delivery to
      the third party

   3. When the normal expectation of the sender is that the transmitted
      information will only be seen by the recipient parties or parties
      obliged to keep the information in confidence

   4. When the third party acts deliberately to target the transmission
      of the first party, either because he is of interest, or because
      the second party's reception is of interest.

   The term "party", as used here, can refer to one person, a group of
   persons, or equipment acting on behalf of persons; the term "party"
   is used for brevity.

   Of course, many wiretaps will be bidirectional, monitoring traffic
   sent by two or more parties to each other.

   Thus, for instance, monitoring public newsgroups is not wiretapping
   (condition 3 violated), random monitoring of a large population is
   not wiretapping (condition 4 violated), a recipient passing on
   private email is not wiretapping (condition 2 violated).

Russ