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

Watson Ladd <> Mon, 17 July 2017 19:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97DC2129A92 for <>; Mon, 17 Jul 2017 12:11:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] 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 QbBMecblecz1 for <>; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EF5E127B57 for <>; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
Received: by with SMTP id q86so80802259pfl.3 for <>; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YQvPdPrn66mDXzqaR41Hw6m5IYmOegActqy95+FnayA=; b=n+EeXeE8GKu/lOmWszHFJEWbWKwnAJg6J4lfefHbQ0M6sEmG8VFaNApe38HlF1iTyP H8Qhh8L1NWOLOOh8XAIJ4H619CkfihkquQabDxDbnX8YHjK/OM54CQBJ1coai+5kXbT9 IIGsAIujku2CkaaziUdcyPVNkcpyJDS1G1H5jmrEdZBYkb7Thx9K0M+98EGe13jLO0dA IcJct2hGBBG1db9Tio7aLLqNvb/Y6oNg00tVblRF5kOmAv3iNWG2KZvBXbyolWtCeGGe 72Apa8fcGDD7Hfn7CVjrgD9wmYknyb043OQdcnkTBaQJdZbRuENygeCjwVArPYLz4Iq3 LIxQ==
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=YQvPdPrn66mDXzqaR41Hw6m5IYmOegActqy95+FnayA=; b=uOVYAlcrPoblgQeNOxtpVbbiAA6FEgUTA9qSFYe8MdA1wSr+VhLukDMituvR37MDFq Bk8eSFa9gjqQhfRr9GjvBgBTwSkVGEtnKkDSadTLG+NHk9saYAhqIeBI1SSsuEuIAHHS nf6Cv6xQTFiehXGWpiIcsExUEkQ6pCMRcFt0xVZ8nNfe5UfMs3Uony02AXVS+L2IAKNY NPJwrzAU9c1++v/pUd/ZcQ/Ih/CYsaTtSbTbscusGKh8dCxGhR48wWbZylJLg7fvRdlc qmMpSX4/0rEO0k/vBZju2EO/qVNui5BwaWwSIyXCwDsCWIT9CFdxTANgHFC6aHFEdRj8 +kzQ==
X-Gm-Message-State: AIVw110WnlW5yo/bXgBKWv0bzCm4ehFuKoyNXUH0sA9MmEwueqaZAmhX 5yScmo/CJc0uW3nZ2RrW625fM2//FQ==
X-Received: by with SMTP id p16mr403656pli.276.1500318674262; Mon, 17 Jul 2017 12:11:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 17 Jul 2017 12:11:13 -0700 (PDT)
Received: by with HTTP; Mon, 17 Jul 2017 12:11:13 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Watson Ladd <>
Date: Mon, 17 Jul 2017 12:11:13 -0700
Message-ID: <>
To: Roland Dobbins <>
Content-Type: multipart/alternative; boundary="94eb2c0029c6a11f71055488291e"
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: Mon, 17 Jul 2017 19:11:17 -0000

On Jul 17, 2017 3:42 AM, "Roland Dobbins" <> wrote:

On 15 Jul 2017, at 3:40, Watson Ladd wrote:

DDoS mitigation can be done at endpoints

Not at scale.  That's why it isn't done that way.

I'm all in favor of things like mod_security.  But they can't do the heavy
lifting on boxes which are already burdened by handling legitimate traffic.

If you want to detect unauthorized access to a resource, having the
> resource which
determines access anyway log that is enough.

This is incorrect.

How do you detect unauthorized access separate from knowing what
authorization is?

Exfiltration detection based on looking for sensitive identifiers doesn't
> work:

Yes, it does.  I know, because I've done it.

real attackers will encrypt the data and dribble it out slowly or pretend
> to be videoconferencing.

Believe me, real attackers do all kinds of things - and the most common
exfiltration mechanism is to try and get lost in the http/s crowd.

Yes, but you'll rot13 or rot 128 the file first. Why wouldn't you?

As for attack surface why is "Press here to get plaintex of everything" not
> a major, major increase in attackability?

Because these are intranet-only systems on isolated management networks
with strong access controls.

And the endpoints taking logs won't be?

Which DDoS attacks specifically?

Among others, application-layer DDoS attacks within the cryptostream.

Applications can rate-limited their own endpoints. You're telling me a
dedicated out of stream box can handle this but a beefy server cannot?

And if the traffic isn't hitting endpoints, does it matter?

Of course it matters.

I've not personally had the pleasure of doing this, but I
know it is possible because it is done every day.

Finally, most software can export the secrets from TLS connections to a
> file.

Logs are context-free and in no wise have the same value as being able to
see the interactive traffic on the network in real-time.

The capacity being asked for already exists.

Yes - and now folks are talking about arbitrarily taking this capability
away without understanding its criticality to network operations,
troubleshooting, and security.

No one is taking away the ability to log the PMS to a file. That's the
capacity which exists now.

The fact that we're even having this discussion at this point in time is
because of an astounding lack of due diligence on the part of those who are
pushing to remove the capability to monitor standards-based encrypted
traffic on intranets.

Alternatively it's because you've decided to run your networks in ways very
different from the public internet and used this as a way to avoid
organizational battles over giving operations the tools they need to work.

Roland Dobbins <>