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

Colm MacCárthaigh <> Sun, 16 July 2017 08:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C7DAE1317CC for <>; Sun, 16 Jul 2017 01:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h_eZPZmtYqjM for <>; Sun, 16 Jul 2017 01:37:32 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECF3712EC57 for <>; Sun, 16 Jul 2017 01:37:31 -0700 (PDT)
Received: by with SMTP id k7so719141ybj.3 for <>; Sun, 16 Jul 2017 01:37:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pcuuO1bETmJBonIjZveXfKUqZ12cIHweQJavUG8Gevs=; b=SCkutVS3y/szXWlL7Y185NVrR8kPmvTLcWF0BQvKBXflByQdXStGrJ8/2vngDeLj+0 0VHdKeIxwrgyXctBkEPObqJGqqzFXD5Sx62dBAKVCqYMxnAQLabkcfrX7b/tLYxsfBhT 0OGOPswDuMf9RvJlNDuH6nNY2HZP+qARfAQOki0ZmKLfSKrfO7OF8zHNm4AojY5rGcCM 57TcoHquqwHAYbWa/BTTHyKgqWLKBzQe0yJCPBVzp0R4ZudlGOCBC6XSx9Bua4iwxBYW Qux6w6oHYPBUF+aMoQm1YXA7XBv0PAk4K6DVp7lz8ZytyzDBS8X3awJWT6iHdDG9CMeu Hr4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pcuuO1bETmJBonIjZveXfKUqZ12cIHweQJavUG8Gevs=; b=SRP9vL7mbmzJbrVvomDSxj8zfZNOo2rLg0OmylaQZ7z/+kD0AhawYCC9JyCiIzQY/T CVqq1x+ZHVeyNsMlkYwEpoJ518ia1kPTh2RxCiRBY8l1Pt8JxTZVhk0cmbeFnz8FEPqS V9jVBeRkflo19Zf0niRF+pcmNn9UVCJbV1PbE+UUaGpKlIS7C2nXjUMSeF4FxCrDBMzG Q1WOt0weeQy01mvn6Esa7RBE6gkut7JnJY4d8bd20zeNeJc82e9Sx8qc6E1K//oFY/q/ 4R6dk2YgwKUyATW6OYi5BSP7hFSrZG8i6xUGquz84TnzI4tw7lZsRjs+iv4l8kNr4JOa DBBg==
X-Gm-Message-State: AIVw110qt+nwnnFVXBLNYpSAUwZfVmOMnN9m2m6JCmzyZSdFjBECNuLC elJn1HU4xfoG3EhtScqPhn1Ba+HeqnuUt1s=
X-Received: by with SMTP id z184mr12946899yba.34.1500194251137; Sun, 16 Jul 2017 01:37:31 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 16 Jul 2017 01:37:30 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Date: Sun, 16 Jul 2017 01:37:30 -0700
Message-ID: <>
To: Stephen Farrell <>
Cc: "Salz, Rich" <>, "" <>, Matthew Green <>
Content-Type: multipart/alternative; boundary="001a113e7df46efbca05546b31ca"
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Jul 2017 08:37:34 -0000

On Sun, Jul 16, 2017 at 12:59 AM, Stephen Farrell <
> wrote:
> (*) 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.

Of course other techniques could work, every system involved from the
network devices to the endpoints is practically Turing complete. For me,
the more interesting question is really whether the providers/users are
likely to take on the costs of doing it differently, or wether they are
more likely to block TLS1.3 and stay on legacy crypto. Given everything
I've read, I think the latter is more likely.

> 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."

Well, they have the keys, and they have the desire, so I expect them to do
it by some means. The question then becomes not about promoting or
encouraging it, but how we may limit the damage and achieve the best
outcome. I don't understand how proxies are a better solution, as I've
outlined; they have drastically worse security properties.

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 can't make sense of this paragraph. A static-DH solution has no need for
proxies, so I'm unclear on why a static-DH proponent would suggest using
them. If proxies aren't the alternative, then what is? are you suggesting
none? That's the brinksmanship approach, which is valid of course, you can
risk TLS1.3 adoption. And the pcap operators may flinch first, or you may.
But is it really wise to ask your opponent for the evidence that they won't
flinch first?

> > 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.

Real world: They have the keys, so they can break FS by using proxies if
they want. If they do that, and they likely would, everyone is much /worse/
off because now there's less FS, more plaintext floating around, and more
exploitable software floating around. Is that really a sensible outcome?

> > 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.)

Imagine you're blindfolded, with your finger on a button that fires a gun.
The gun might be pointed at you, it might be pointed at your opponent. Your
opponent has no blindfold. Your argument is "Tell me if the gun is pointed
at me or I'm going to push the button". Now if the gun is pointed at them,
can you really trust them? And if it's pointed at you, why should they care
to help you out?