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

Watson Ladd <watsonbladd@gmail.com> Mon, 10 July 2017 23:39 UTC

Return-Path: <watsonbladd@gmail.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 E069A120726 for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 16:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 kg06d-C59Akp for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 16:39:04 -0700 (PDT)
Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8743F1200ED for <tls@ietf.org>; Mon, 10 Jul 2017 16:39:04 -0700 (PDT)
Received: by mail-pg0-x22e.google.com with SMTP id u62so56867515pgb.3 for <tls@ietf.org>; Mon, 10 Jul 2017 16:39:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rlx7nmKhJ5tCte0QNnLhiK7Qe4qyDurXLYcu9D7HrsI=; b=LbtQn4kQ+au4CS6Tn/wzd47DLKd9S+53yCO0Zx/nKYvOgzOSf73UDSVLYFXrTWA2Hg EjusOC/Q2wA5N1R0CmYjevnARtvdDT0NE8H+kmnvwCbrDwqjJZIQrG5piLpSUfOqJne9 kw7ACAGULA8kkfPAYV3MPCpuCQx9DlZUAS0D0UkrpQSRdaqA7TtQRZC6SUQliXpvpGKi 3c3Td6MpZiMApUWNCY6O4wMmB8vWCnmKLiM+IPHpD296E6D/JuJ2n3U9YbKVM1Vv7Ttf Wk3KB/9jPBk2UC5O/yEP1xcbqzL9zCSmeV8WAG/e0XUpJVla8J0EZ6kXgrKfujbCOZ5P cJ+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rlx7nmKhJ5tCte0QNnLhiK7Qe4qyDurXLYcu9D7HrsI=; b=DwHCVdr50vqaI8kO+Lskk3aw9IHaIOoscL3KH1WoHnfiPB9PDfMbobGtWIQAdeZDWo i5jecGydo8Mku/LuaOnD0rLGcgxX6Xl6RKbGhHwedyvrfVk7k+o6FQXbih6aCAKKmnFR jDErrBkJ8UJsQxkqOCG67x7nV6C7cDSwyixolX+eGgQ+Me9GA/QJkSqNJ4NRpIrT3+dJ 3UZ6aUps+2n+bkNL+CeSckdCX6+Wqdx8DKULf2yLzYvNLtxUdEzXLwyRuaW01i/e8BwX ThAoUb4+X5LZNZK9ZiSRGD4G19HUIPryHpT1qbcR3ww3YsDuSUycwzbsuoxI9DqrIwjJ oeHw==
X-Gm-Message-State: AIVw1132agt3mfd0JMH0ViwEhtTwZ6V0VgWU/4VNHNe3hpOe63APNM/L Hdw+7ey0AVDhWnSpXBSVOCzFOMAu5LMe
X-Received: by 10.101.76.140 with SMTP id m12mr16859595pgt.159.1499729944099; Mon, 10 Jul 2017 16:39:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Mon, 10 Jul 2017 16:39:03 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Mon, 10 Jul 2017 16:39:03 -0700 (PDT)
In-Reply-To: <CANBOYLXjqeLOadK+BY7564cz2pnx1nVmkAJNJ65iU3HND=8usg@mail.gmail.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> <CANBOYLXjqeLOadK+BY7564cz2pnx1nVmkAJNJ65iU3HND=8usg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 10 Jul 2017 16:39:03 -0700
Message-ID: <CACsn0cmzCBOHKGucZ5i9_EZuXtOJC4NgRm=qpoR=6S-Ad7CuNQ@mail.gmail.com>
To: Eric Mill <eric@konklone.com>
Cc: "Polk, Tim (Fed)" <william.polk@nist.gov>, tls@ietf.org, Russ Housley <housley@vigilsec.com>
Content-Type: multipart/alternative; boundary="089e0823838493c17e0553ff1638"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/J4qYafD43SLsWYkWhdx_DVySCiU>
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 23:39:07 -0000

On Jul 10, 2017 4:09 PM, "Eric Mill" <eric@konklone.com>; wrote:

On Mon, Jul 10, 2017 at 6:07 PM, Russ Housley <housley@vigilsec.com>; wrote:
>
> >> 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.
>

It seems like a weak counterargument to say that because there remain areas
where mail servers don't use TLS, that senders and receivers have no
expectation of confidentiality with email at all. Are you really saying
that if an MTA used this static-DH draft version of TLS to maintain keys to
decrypt email traffic, despite it only being "intended" for enterprise use,
that it wouldn't be wiretapping?

What about if/when MTA STS[1] is implemented? Will MTA adoption have to hit
100% before it's suddenly wiretapping for any given MTA to surreptitiously
use the static DH version of TLS that was "intended" only for enterprise
use?


I don't read RFC 2804 as applying to cases where intermediaries authorized
by a party to view information are handing it over. The MTA is authorized
by the recipient to be in the path and to look at the emails for all sorts
of reasons, and if they decide to hand over all your emails to someone else
via FTP, that's not a reason to be against FTP.

If it was to apply anything where a proxy service can be behind another
proxy would run afoul of this: they would proxy through the evesdropper. So
would reply-all, the most blatant cause of accidental evesdropping online.

Historically 2804 came out of (I think) a different situation where
signaling information related to interception was going to be included in
the protocol. Sadly it talks about sender and recipient without considering
cases where the identity is confused by subcontracting, and doesn't
distinguish cases like this which are similar to key escrow except there is
only one entity involved in the escrow.


-- Eric

[1] https://tools.ietf.org/html/draft-ietf-uta-mta-sts-06


> Russ
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls