Re: [TLS] chairs - please shutdown wiretapping discussion...

Russ Housley <housley@vigilsec.com> Mon, 10 July 2017 22:32 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 356E51317CF for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 15:32:29 -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 wBRb8VtmX00E for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 15:32:27 -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 00769131937 for <tls@ietf.org>; Mon, 10 Jul 2017 15:32:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 599F7300258 for <tls@ietf.org>; Mon, 10 Jul 2017 18:32:24 -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 zAqY-nzLi6V2 for <tls@ietf.org>; Mon, 10 Jul 2017 18:32:23 -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 EC547300466; Mon, 10 Jul 2017 18:32:22 -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: <e7e39c1c-4ab9-d4cf-a673-6df9c3bc1217@cs.tcd.ie>
Date: Mon, 10 Jul 2017 18:32:22 -0400
Cc: "Polk, Tim (Fed)" <william.polk@nist.gov>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <78DF6C63-8DF1-473A-9150-63EEB9E18B20@vigilsec.com>
References: <E9640B43-B3AD-48D7-910D-F284030B5466@nist.gov> <CY4PR14MB13688370E0544C9B84BB52A3D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <9693fc25-6444-e066-94aa-47094700f188@cs.tcd.ie> <CY4PR14MB1368BA01881DD9495FE86DF0D7A90@CY4PR14MB1368.namprd14.prod.outlook.com> <d806a69c-af30-c963-a361-91075332a61b@cs.tcd.ie> <F87D7646-DC53-4EF8-A2D8-D0939A0FB351@vigilsec.com> <b9001044-83d7-805c-2a49-c2780401bbf8@cs.tcd.ie> <7EB4B7BD-EA31-4D97-98F5-7BF5E47A9A20@vigilsec.com> <e7e39c1c-4ab9-d4cf-a673-6df9c3bc1217@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/b6fsQwQxW5OVH8YYgAxjKoWXKVU>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
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: Mon, 10 Jul 2017 22:32:29 -0000

Stephen:

>>>> 
>>>>> And to avoid a repeat of Russ' failed justification, many protocols
>>>>> use and depend on TLS where the entity controlling the TLS server
>>>>> private key materials is not the higher layer sender or receiver,
>>>>> so all four points in the definition in 2804 are fully met by your
>>>>> wiretapping scheme.
>>>> 
>>>> It is clear that you do not agree with the reasoning that I posted on
>>>> Friday.  Some people do, and clearly, others do not.
>>>> 
>>>> So, I failed to convince you.  However, you have also failed to
>>>> convince me that the proposal is wiretapping under the definition in
>>>> RFC 2804, Section 3.
>>> 
>>> Consider SMTP/TLS. Where one MTA on the path supports this.
>>> Say it's one operated by an anti-spam company for example.
>>> That is clearly not the sender nor recipient.
>>> 
>>> That meets all 4 points in 2804, right?
>> 
>> You are pointing to email.  Some MTAs will use SMTP over TLS, but many others do not.  It would be great if they all do, especially for the authentication.  In your response you are talking about an email system that has been using plaintext for ages, and you are trying to apply hop-by-hop a mechanism to the delivery.  Then, you are saying that the sender and receiver have confidentiality expectations that are being violated.  I do not buy it.
> 
> See [1].
> 
> Those show nearly 90% of mails being encrypted with
> TLS now.
> 
> In many mail deployments there will be an added hop e.g.
> for anti-spam (we do that here in tcd) to an outside
> party.
> 
> While not 100% of mail is encrypted with TLS on all
> hops, much is. (And the UTA WG are developing MTA-STS
> to try improve that.)
> 
> If one of those external parties implements your
> scheme then mail senders and receivers will not know and
> that real TLS application meets the 2804 definition for
> lots and lots and lots of emails.
> 
> Hence, 2804 applies here and the standards-track label
> ought be removed.
> 
> S.
> 
> [1] https://www.google.com/transparencyreport/saferemail/

I'm glad that TLS is being used to protect email delivery.

I do not see how this changes the expectation discussed in RFC 2804, Section 3, Item number 3.

Russ