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

Kathleen Moriarty <> Thu, 13 July 2017 15:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24F8512741D for <>; Thu, 13 Jul 2017 08:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, 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 BmECLx08Ax80 for <>; Thu, 13 Jul 2017 08:09:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7685812ECB0 for <>; Thu, 13 Jul 2017 08:09:02 -0700 (PDT)
Received: by with SMTP id c73so30896378pfk.2 for <>; Thu, 13 Jul 2017 08:09:02 -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=J5qsgwhy8/OctqKRV9xyiO7255aN5HHgNLCqvKv+Abg=; b=rkfstBhtobcNMxexi99emj8hp7WTkKAl5IsFIFCwwyeIXunNtJ9ECnbRAYuiPozUWT AfqHRkhfwYjOTV6Jg8I5tfRjinZSKYd9HGYYEmIX9oA15e6+C13Gip7TdkmrKlCdB3Th hpksHPJdXInw66DR4jKHVfrsDC59unNrvJKhZkEibBH75ucMVGDWOIMGWUrACplM9AqW DfAmELeEpRQfaG5ETZKGIVj95zUT1atS+Sf8JEm5zdtgGsDOSaMYctwQZUhIkEb7/jA+ 5O+tbje971lBaixVWyxAZS2Ow095anUV8tkdxngUkZNDidfckwoCl/fjKBbUlO72qNJk Yc+w==
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=J5qsgwhy8/OctqKRV9xyiO7255aN5HHgNLCqvKv+Abg=; b=G1aeJxysUbQknT1pALprGRJne3PC9Rv2jUhYXAwav2/Gjtspb/Kx+0In8OOgnKEc0+ osmBB9OOweNGKayQU561TeOIvd17VaFmA/svTjl6BOAhjHG8RPg01V5svwga/ogbWzIG HCKyGIcjLB6+iy4O5adf9xcMkTGSoThyDnXcmmbGbYN/LiB4twQG14F70GyIQAf/AifK Ezb4rO/0bCufquEBQhFRwIBzMnWCe6YIiQ3sV3U79yXUSMUSCiRhuSQxosQd8yB/BHCr kPmz1Pxh1+Q4sHclMzTOI4IvEvx5w8vdUZPjWAEEwHAPPI1YO32VqeSZBCoaOdsPO3cd opGw==
X-Gm-Message-State: AIVw112bVFb2cHKi8CiQEKBpzIaWJaSqVRMlBY0L5bkJk2opOy1Dq4W1 VLGHzrsiQaX4dkPJJnQvjA68ktImdg==
X-Received: by with SMTP id 73mr92684pfh.110.1499958541937; Thu, 13 Jul 2017 08:09:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 13 Jul 2017 08:08:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Kathleen Moriarty <>
Date: Thu, 13 Jul 2017 11:08:21 -0400
Message-ID: <>
To: Martin Thomson <>
Cc: Steve Fenter <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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: Thu, 13 Jul 2017 15:09:04 -0000

Hi Steve,

Thanks for taking the time to detail out your concerns and current use
cases.  This is helpful.

On Tue, Jul 11, 2017 at 9:39 PM, Martin Thomson
<>; wrote:
> On 12 July 2017 at 09:59, Steve Fenter <>; wrote:
>>> And if you had one an estimate for how much malware does it's own
>>> obfuscation or home-grown crypto in addition or instead of using TLS.
>>> The reason to ask is that as soon as malware does that then you
>>> are back to analysis based on ciphertext only. From descriptions
>>> of advanced attack schemes, they do seem to do both when calling
>>> home or exfiltrating data. In which case I think your argument
>>> falls.
>> I don't have any numbers for home-grown crypto.  I would think the odds are better for the enterprise if they can decrypt and inspect whatever portion is TLS.
> Wouldn't malware avoid connecting to servers that offer the wrong
> credentials?  Implementing elementary key pinning or overriding trust
> anchors is pretty trivial - it's a feature that enterprises frequently
> rely on after all.

It sounds like for malware, we could do something to better document
your security options as well as monitoring.  While the documentation
is there for key pinning and trust anchors, this might not be obvious
to network managers - what RFC to look at and how they fit together.

The points Stephen, Ted, Martin have made are good.  A TLS overview
document with an appendix of use cases might be a good start to help
fill this gap for operators.  Even if it isn't published, we could
figure out wiki space or something like wikipedia to make sure it's
available to operators. If the start of this documentation looks like
it will generate new work developing alternate ways to accomplish the
goals while maintaining the integrity of TLS, a new WG could even be
an option.

For malware, the proposed solution (Matt Green draft) isn't a great
fit as the server side won't be managed within your enterprise to
allow for the decryption described in the proposal.

For the other parts of your original message that were snipped from
this thread, I have a few questions/comments to see how we might be
able to narrow the scope and clarify a few things.

For the Troubleshooting description, could redefining the end point of
the server work as terminating at a load balancer to help with at
least some of your use cases?

For the threat detection and security analytics, I know a number of
current products rely on the ability to TLS.  The primary concern here
would be the remote server not managed by the enterprise.  TLS 1.3
prevents this from being possible and the proposed draft doesn't help,
so I think it would be best to figure out a way forward for this use
case either with the help of MILE (incident responders) or others.
Currently products use proprietary methods to accomplish this task (at
least some do).  For DDoS, the experts say they can work with
fingerprints of encrypted streams, so it's other attack types that may
require some thinking through of options.  I'm happy to chat about
that as I've done a lot of work in incident response and know of
others that may be able to assist as well.

I'm still reading through messages and drafts on this topic, so this
message should not be read as a position on either side, but more to
narrow the scope if possible and think through what is being requested
and why - so it is clarified.

> _______________________________________________
> TLS mailing list


Best regards,