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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 07 July 2017 21:48 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 606B41316AE for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:48:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 qVL5KE-AAvEK for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 14:48:42 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5149612EB9B for <tls@ietf.org>; Fri, 7 Jul 2017 14:48:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76EE2BE39; Fri, 7 Jul 2017 22:48:40 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpSGsHVpb7_9; Fri, 7 Jul 2017 22:48:39 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0CA4EBE2C; Fri, 7 Jul 2017 22:48:39 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499464119; bh=dObdltMJ/+wlJjY28XWcItLFYPv6vwMszM12EQrBmrA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=t2yGpeLMtfWJGF0nsGH9GyXNTJrA/xRxGkU9pFhDPnlppLBa69rxzko+EMqhsUIDA 4zicOjbpLUUm0zI9JHK2LSLxf7MUhOE1sN37r67/vFUvsmvyrVuySzij3BRqkQD7Nc OSZEdKQk1gHdmTPEXNDI+U4XmkdnzxkmugptR/XQ=
To: Russ Housley <housley@vigilsec.com>
Cc: IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <d16833ed-3b6b-3685-e109-1673f69c67a5@cs.tcd.ie>
Date: Fri, 7 Jul 2017 22:48:38 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <E639C60A-D90C-46C2-9A18-5D02D6EBD9E4@vigilsec.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="B8K6igiqppAGrenAl6sCCu2pTIKrvmfsq"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7C4j3ml12rZNWR4Ju391_UBg8fg>
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:48:44 -0000


On 07/07/17 22:38, Russ Housley wrote:
> 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.

S

PS: You might say that purely static DH can be detected by
the TLS client, but once we give in on this it'll be inevitable
that variants are derived that aren't detectable by the TLS
client.


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