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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 10 July 2017 14:16 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 3A0F1131455 for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 07:16:28 -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 QqlWRtOkS0kt for <tls@ietfa.amsl.com>; Mon, 10 Jul 2017 07:16:25 -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 42A9E13179A for <tls@ietf.org>; Mon, 10 Jul 2017 07:16:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 52BD7BE5C; Mon, 10 Jul 2017 15:16:22 +0100 (IST)
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 zbkxlpzON_eh; Mon, 10 Jul 2017 15:16:22 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1AB5FBE50; Mon, 10 Jul 2017 15:16:22 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1499696182; bh=W3gz9wTtheTsEQqbWoeALf2VqdiGXml+2VbQL8tCyaI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=UosdVN2yjQeMZRbjJonNLxKS+Gi/ilpQVpSf2X/jEK3zfI8KYC1NtIymWoRD6uo9K fHm24368xqO4GhVtQPOGJ8z5VWNDLs9nmvHJifHe5UVKgfTkY0xio/mgo8bvC7pRMr XdTw4DtcswYMBFW/S/dmM6XibyVG9tUxalzKMM2w=
To: "Polk, Tim (Fed)" <william.polk@nist.gov>, "tls@ietf.org" <tls@ietf.org>
References: <E9640B43-B3AD-48D7-910D-F284030B5466@nist.gov>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <1ddda2f4-147e-27a6-eb71-f945cbbee0d6@cs.tcd.ie>
Date: Mon, 10 Jul 2017 15:16:20 +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: <E9640B43-B3AD-48D7-910D-F284030B5466@nist.gov>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RUiENUpOUhpbK1NAa66JVWApip0HF5Kr1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7F1dq5Mf1S-ErWpjZBj6USt6eNg>
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 14:16:28 -0000

Hiya,

While we're waiting on Sean/Joe... :-)

On 10/07/17 14:54, Polk, Tim (Fed) wrote:
> First, I do not see this as a “wiretapping discussion” based on my
> reading of 2804, although others may disagree.

s/may/do/

Figure 3 in the draft is absolutely clearly describing
an architecture for wiretapping TLS connections. And I
see no way in which this scheme can avoid that problem
as there is no way in which the "TLS decrypter" can be
assured to be in any particular place in any network.
(If one did try fix that, then you end up in the mctls
muck.)

> 
> Second, I believe that this discussion should go forward based on
> several points:
> 
> 1.  this proposal does not involve any changes to the bits on the
> wire specified in the TLS 1.3 document 

I would assert that it substantially changes the semantics of
the bits emitted by standards-track TLS implementations. With
this, a client cannot know if it's application PDUs are being
decrypted from the middle of the network when talking to any
standards-compliant server. That basically breaks one of the
most important security properties of TLS.

> 2.  this proposal offers
> significantly better security properties than current practice
> (central distribution of static RSA keys) 

I fail to see any relevant difference in security properties
between those two, never mind a significant improvement.

> 3.  alternative solutions
> with significantly worse security properties are also feasible under
> TLS 1.3, and I would like to avoid them!

Yes. But that is not a justification to weaken security for
standards-track implementations of TLS1.3. We should not
standardise ways of doing crappy crypto would be my take.

> We should be in the business of developing pragmatic, interoperable
> solutions with appropriate security properties.  

Absolutely. This proposal, being inappropriate for the standards
track, should go visit /dev/null.

> Balancing
> cryptographic security with other security requirements to achieve
> such solutions should be an acceptable path, and pursuing this work
> in the TLS working group gives the IETF the best opportunity to
> influence these solutions.

See the raven mailing list I guess. That was specifically
discussed then.

S.


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