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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sun, 16 July 2017 08:00 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 6B416131771 for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 01:00:02 -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 jYwRSmycVUF3 for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 01:00:00 -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 861BD127180 for <tls@ietf.org>; Sun, 16 Jul 2017 01:00:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7D355BE58; Sun, 16 Jul 2017 08:59:58 +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 zR6jg0t1mz43; Sun, 16 Jul 2017 08:59:57 +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 E1DBFBE56; Sun, 16 Jul 2017 08:59:56 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1500191997; bh=FkhrmzYaKsZKSAc90CP9618b6WNl7B+bxM067NQu0/w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KNw69Ps2stKZ/fUFWlff8iJXg5+VGZUGPz446zGW5GlaO6e+G9kX1an5lzF+5tfbe 3VImXHIHCEM/lIRw7b6PNTrnTj58lE25UxNBv9HyuKZ9QCva1LkwxSXkSorP3MDbjP KxLUBrmOXqvX1brDJXA0jTsmAE7cRlvI99Db5C4Y=
To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= <colm@allcosts.net>
Cc: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
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> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com> <CAAF6GDeSv+T1ww5_nr6NPgg9k44j7y04tJWC=KeaJF7Gtt+TVQ@mail.gmail.com> <9bd78bb6-1640-68f6-e501-7377dd92172f@cs.tcd.ie> <CAAF6GDeGKEBnUZZFXX0y0a2J2+sVg8VaHh-4H9bhN0Zzk-x9uA@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <6707e55d-63d3-01e2-4e98-5cc0644e29e0@cs.tcd.ie>
Date: Sun, 16 Jul 2017 08:59:56 +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: <CAAF6GDeGKEBnUZZFXX0y0a2J2+sVg8VaHh-4H9bhN0Zzk-x9uA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wJW6KX956kiq8k94Q7StTt8o0RnhMDnSL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0Tlc7GgJ4tv-eam0R6vb3Y2q9BE>
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:00:02 -0000

Hiya,

On 16/07/17 05:41, Colm MacCárthaigh wrote:
> On Sat, Jul 15, 2017 at 5:39 PM, Stephen Farrell 
> <stephen.farrell@cs.tcd.ie>; wrote:
> 
>> On 15/07/17 23:55, Colm MacCárthaigh wrote:
>>> So far responses on the mailing list have been saying "Don't use
>>>  pcap, instead run proxies".
>> Sorry, but that is incorrect. Some list participants have said "we 
>> need pcap" and others have said that "no, we do not need to use 
>> packet capture." And others, myself included, consider that there 
>> is dearth of evidence.
>> 
> 
> Can you be more clear what is lacking in evidence?

Sure, sorry for the late-night terseness:-)

In this debate, there is a fairly complete lack of evidence
being offered as to:

- the (in)effectiveness of proxies or key-leaking vs. one
  another and vs. not doing either
- the precise scenarios in which pcap+key-leaking is the only
  possible (*) answer, and how commonly those scenarios occur

(*) I am not asking that people tell me that "pcap+key-leaking"
might work, but for them to describe when that works but nothing
else works. And that has to include the details of what it is
they can only find in the recovered cleartext that cannot be
detected without access to cleartext using this particular
method.

> Are you skeptical that existing network operators don't do this kind
> of decryption?

I believe that people do this kind of key-leak+pcap decryption.

People do all sorts of other unwise things too (myself included,
and fairly frequently;-), that is not a reason to encourage more
of "it" for any "it."

> There's support for it in tools like Wireshark. Is that sufficient 
> evidence?

Yes and no. That is sufficient in that yes it says that people
can use this tool. It is nowhere near sufficient evidence that the
IETF should standardise (an API for) such a tool. The existence
of a wireshrark dissector for a protocol is also fairly weak
evidence as to the importance of such a dissector - it seems to
be fairly common for folks to write those for lots of other
reasons, e.g. during protocol development, as student projects
that require no thought from the prof etc:-)

> Are you skeptical that there's no evidence that using proxies
> instead would be a burdensome change?

No. All changes are burdensome, and it's clear that that one
would be. (My own belief is that adding proxies solely to help
with possible network debugging would be dim anyway - I'd
argue there ought to be a functional reason for each proxy
added.)

I would also note that the "use a proxy" argument seems to me
to mostly be offered as a strawman counter-argument by folks
who would like to break TLS via static DH, and doesn't seem to
be a common argument offered by those against breaking TLS.
(Adding proxies is of course another way to break TLS, depending
on how and where it's done.)

> I'm not skeptical of that at all, but would be interested in what
> acceptable evidence would look like.

I'm not sure of the phrase "acceptable evidence" but regardless
of that:

TLS is an important protocol, extremely widely used. For any attempt
to weaken or break TLS, I think the onus is on the proponents of the
break-TLS proposal to produce convincing evidence that their scheme
will at least be a net positive, considering the entire ecosystem
that is dependent on TLS. And even if there is evidence that a scheme
would be a net positive, it may still be a bad idea, if the negative
aspects of the scheme have serious enough impacts in some use-cases
for TLS.

That's a pretty high bar, yes. And so it should be. I'm not at all
clear it can be cleared, ever.

> Though I'll point out again: TLS 1.3 is the new thing that we want
> to gain adoption, so really we should be looking for evidence that
> it's /not/ a burdensome change.

Sure, that is another fine thing to do. It'd be helped along if we
had evidence about the precise scenarios in which the pcap+key-leak
wiretapping is the only possible usable approach. That hasn't been
described on the list. (It has been asserted that such scenarios
exist, and it has been claimed that we should all know and accept
all this already, but those were TBBA non-arguments.)

Cheers,
S.