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

Russ Housley <housley@vigilsec.com> Fri, 07 July 2017 21:54 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 23F3F129A96 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:54:06 -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 0hOIgw1aMxB2 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:54:05 -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 E0EF7129462 for <tls@ietf.org>; Fri, 7 Jul 2017 14:54:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4339A300563 for <tls@ietf.org>; Fri, 7 Jul 2017 17:54:04 -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 W7hYCTeGureX for <tls@ietf.org>; Fri, 7 Jul 2017 17:54:03 -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 EFE7A300250; Fri, 7 Jul 2017 17:54:02 -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: <d16833ed-3b6b-3685-e109-1673f69c67a5@cs.tcd.ie>
Date: Fri, 07 Jul 2017 17:54:02 -0400
Cc: IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
Content-Transfer-Encoding: 7bit
Message-Id: <5CF364CB-96E1-4103-9C83-81187897F5F3@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> <E639C60A-D90C-46C2-9A18-5D02D6EBD9E4@vigilsec.com> <d16833ed-3b6b-3685-e109-1673f69c67a5@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/WTm5OOs8FT_vhdij_Ch9jOqNGMI>
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:54:06 -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.  
> 
> And also: I'm sorry to have to say it, but I consider that
> attempted weasel wording around the clear intent of 2804. The
> clear and real effect if your wiretapping proposal were standardised
> by the IETF would be that we'd be standardising ways in which
> TLS servers can be compelled into breaking TLS - it'd be a standard
> wiretapping API that'd be insisted upon in many places and would
> mean significantly degrading TLS (only *the* most important
> security protocol we maintain) and the community's perception
> of the IETF. It's all a shockingly bad idea.

I clearly disagree.  Otherwise, I would not have put any work into the draft.

Russ