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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 16 July 2017 08:20 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 65607131787 for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 01:20:46 -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 i7a5aty-pJDO for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 01:20:44 -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 122D712EC57 for <tls@ietf.org>; Sun, 16 Jul 2017 01:20:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 455C7BE58; Sun, 16 Jul 2017 09:20:42 +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 FJ8z-Gu0ysK4; Sun, 16 Jul 2017 09:20:40 +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 92D09BE56; Sun, 16 Jul 2017 09:20:40 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500193240; bh=FkJPlqAlpa8bK5xcVPOavF9Py5z2TIEuKqltA9QH/og=; h=Subject:To:References:From:Date:In-Reply-To:From; b=EQVvJYcXx5OWxT9ZLAo5EvtOiONcVOTyoeNbwHwxKQSmHJmSOFokSYbZNLBtm73qy /KkoJdXcGwLcNEb7PCr0tSLur4Q/Zurc+LdtR0M4U5AhRnXX/m2wcZ9PhfDqXLv/cM /Cb9ayWWXvVUn/88SQuRNVGDwKtIxS8qNmEQeP8Q=
To: Roland Zink <roland@zinks.de>, tls@ietf.org
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <CAAF6GDc7e4k5ze3JpS3oOWeixDnyg8CK30iBCEZj-GWzZFv_zg@mail.gmail.com> <c1fcf8e4-f8c4-5d46-a8eb-9ec47e3a572d@zinks.de>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <f2e633bc-54e4-7f9b-6e09-dad212970300@cs.tcd.ie>
Date: Sun, 16 Jul 2017 09:20:39 +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: <c1fcf8e4-f8c4-5d46-a8eb-9ec47e3a572d@zinks.de>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="GoBuCxPteAlrwjfrdfM8bjEO7W7DMqX3L"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EXwsX4zUAU9GY7ZIoQLSD_WA2Ho>
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: Sun, 16 Jul 2017 08:20:46 -0000

Hiya,

On 15/07/17 20:49, Roland Zink wrote:
> TLS is a two endpoint protocol. It looks like many of the use cases
> describe problems with more than two endpoints but are using TLS because
> it is commonly available. So should TLS be extended to be an n-party
> protocol (or is this always considered wiretapping?) or should be there
> another protocol or something else?

Yes, if one wants different semantics than TLS and needs an
entirely different interface for applications, (which all N>2
party protocols do need) then one needs to define a different
protocol that is not TLS.

Of course, that's impractical, so people will continue to
ignore the fact that they're doing bad engineering and will
come along now and then and try convince us to break TLS.

Cheers,
S.


> 
> 
> Regards,
> 
> Roland
> 
> 
> 
> Am 15.07.2017 um 19:34 schrieb Colm MacCárthaigh:
>>
>>
>> On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor
>> <dkg@fifthhorseman.net <mailto:dkg@fifthhorseman.net>> wrote:
>>
>>      * This proposed TLS variant is *never* acceptable for use on the
>>     public
>>        Internet.  At most it's acceptable only between two endpoints
>>     within
>>        a datacenter under a single zone of administrative control.
>>
>>
>>      * Forward secrecy is in general a valuable property for encrypted
>>        communications in transit.
>>
>>
>>     If there's anyone on the list who disagrees with the above two
>>     statements, please speak up!
>>
>>
>> I agree with the second statement, but I don't really follow the logic
>> of the first. On the public internet, it's increasingly common for
>> traffic to be MITMd in the form of a CDN. Many commenters here have
>> also responded "Just use proxies". I don't get how that's better.
>>
>> A proxy sees all of the plaintext, not just selected amounts. All of
>> the same coercion and compromise risks apply to a proxy too, but since
>> it undetectably sees everything,  that would seem objectively worse
>> from a security/privacy risk POV.
>> Or put another way: if these organizations need to occasionally
>> inspect plaintext, would I prefer that it's the kind of system where
>> they have to go pull a key from a store, and decrypt specific
>> ciphertexts on demand offline, or do I want them recording plaintext
>> *all* of the time inline? It seems utterly bizarre that we would
>> collectively favor the latter. We end up recommending the kinds of
>> systems that are an attacker's dream.
>>
>> Here's what I'd prefer:
>>
>>  * Don't allow static DH. In fact, forbid it, and recommend that
>> clients check for changing DH params.
>>  * For the pcap-folks, define an extension that exports the session
>> key or PMS, encrypted under another key. Make this part of the
>> post-handshake transcript.
>>  * pcap-folks can do what they want, but clients will know and can
>> issue security warnings if they desire. Forbiding static DH enforces
>> this mechanism, and we can collectively land in a better place than we
>> are today.
>>
>> -- 
>> Colm
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>