[TLS] Fwd: draft-green-tls-static-dh-in-tls13-01
Watson Ladd <watsonbladd@gmail.com> Sat, 15 July 2017 01:40 UTC
Return-Path: <watsonbladd@gmail.com>
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 5320812EC1D for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 18:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b0WhnxnZpUJg for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 18:40:02 -0700 (PDT)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B27126B72 for <tls@ietf.org>; Fri, 14 Jul 2017 18:40:02 -0700 (PDT)
Received: by mail-pf0-x230.google.com with SMTP id q86so52669152pfl.3 for <tls@ietf.org>; Fri, 14 Jul 2017 18:40:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=SZPJDkExKOYCY2IPPHeZK5XqUUNA32t1hp69KRfbxAg=; b=EZ2NZFYkLusHezIENfv4DLBvFbNJghZaR+jzu3gNtmSVMhJ5l2rGMAUddF5hOl40rT MI7I/6RzJefAZR3xcbHT47QQ0v3ML2o1ncHNZd7239SAzkJN0kwDqmODm7b0pqoWa9s3 QpVla5ojj280Yv4Qo3n2xVD1Z4KPsO1Qc2FQLSr98nhLqtrdzeseKkvQ2Px8PqX3i+Vr 7QKvm0CD4JtON1dAPEty3vAWu/K7sQVL9ggefQnpZGzHpuUgoWZKJRNqxleZkeBCMfLa DgCDAAyGAHBIFXGobVTe8UV5RwNR+zubPG5IRxq+UphHMyxN0jmNAQXVyYo7hbM+DFRr xAkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=SZPJDkExKOYCY2IPPHeZK5XqUUNA32t1hp69KRfbxAg=; b=BGCXq5kyz3FB4XKPHlK1LvHk1eMCQaAyCjewMFcL8i64j799p9M1dvMJPfEETuRhgx XkEi0LNFDMU4KB65IKKwlZUlnZOrybj1uOu+H+QtJ0qXuYkTapahXiVyjbfvddF7ngHP QaJp/9b4lL4thgfkvDSTgHMdnQakoh4DPBpI+lIWuH2w9pXytuvGWzMDfsWIBs6TZX9g obhRu7Fum3O5k+wAdzZgUaLH1Y5yChsFmxaUG0d2iUvGNnPm3MDjaxZQHKf2cmDoMyKx 9p3THu63LWNTmITjTQW/0enfZaYOF3fYzZM5Pay5WQd4zfuloQ4VZuSP+hAyPZ3UE1sy KXgw==
X-Gm-Message-State: AIVw111chtIwSwi614VYbsQ/kv0c603AP/LKWfknK3VSUeOGwPKAGRit JyIPAZoirsKUNOaM7+w86m9DD8ySysrz
X-Received: by 10.98.139.11 with SMTP id j11mr8264620pfe.18.1500082801378; Fri, 14 Jul 2017 18:40:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Fri, 14 Jul 2017 18:40:00 -0700 (PDT)
In-Reply-To: <CAN2QdAGRTLyucM1-JPmDU17kQgAv0bPZNASh54v=XoCW+qj48A@mail.gmail.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <72BACCE6-CCB9-4DE9-84E6-0F942E8C7093@gmail.com> <a0a7b2ed-8017-9a54-fec0-6156c31bbbfa@nomountain.net> <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net> <CAN2QdAGRTLyucM1-JPmDU17kQgAv0bPZNASh54v=XoCW+qj48A@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 14 Jul 2017 18:40:00 -0700
Message-ID: <CACsn0cnc0X5++cOvTNsboda8J42qg3VDquZ4Va-X-YDcggnbvA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/cERNuXgjtemLd-mrpuehgcbD5Rw>
Subject: [TLS] Fwd: 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: Sat, 15 Jul 2017 01:40:04 -0000
On Fri, Jul 14, 2017 at 11:41 AM, Roland Dobbins <rdobbins@arbor.net> wrote: > > On 15 Jul 2017, at 1:01, Melinda Shore wrote: > >> It might make sense to kick it over to ops for a discussion with people whose meat and potatoes is monitoring, management, and >> measurement. > > > As someone who is ops-focused, I think this is an excellent suggestion! > > There have been several assertions posted to the list recently regarding various aspects of security and their intersection with encryption. It may be useful to take a moment and clarify a few of them. > > With regards to DDoS mitigation as it relates to encrypted attack traffic, only a subset of attacks in a subset of situations can actually be adequately mitigated without full visibility into (and often the ability to interact with) the traffic within the cryptostream. There are various ways to approach this issue, including full session termination and 'transparent' detection/classification, the latter of which isn't of course feasible in a PFS scenario. Each of these general approaches has its advantages and drawbacks. DDoS mitigation can be done at endpoints, and indeed has to be given that other tools do not know which endpoints need to be rate-limited or are expensive. A lot of distinct things are being crammed together into DDoS, and the fact is endpoints can deal with application layer attacks via rate-limits, CAPTCHAs, and other techniques, while not-application layer attacks don't require visibility to defeat. What can a middlebox do that an endpoint cannot? Globbing a bunch of distinct things together is not helping the debate. > > Very specifically, fingerprints of encrypted streams are not in fact adequate for DDoS defense; again, they're only useful for a subset of attack types in a subset of situations. > > In the case of detecting and classifying hostile activity within a given network - which isn't limited to malware spreading, but includes data extraction, attempts at unauthorized access, attempts at subverting additional devices, et. al. - the same basic caveats apply. It is not in fact possible to adequately detect and classify all, or even a large subset, of hostile network traffic without visibility into the cryptostream. There are some gross behaviors which can be detected/classified whilst standing outside the tunnel, but assertions to the effect that all or most of what's required in this arena is possible without visibility (one way or another) into the relevant encrypted traffic are incorrect. > > It's also important to understand that inserting proxies into multiple points of a network topology is not cost-free, nor an unalloyed good. It is impractical in many circumstances, and has highly unwelcome side-effects in many more, including a negative impact on reliability, performance, and availability, as well as broadening the potential attack surface. Endpoint monitoring does not scale well, is often impossible to implement due to both technical and administrative challenges - and one can't really trust endpoints to self-report, anyways, as they can be subverted. You are conflating different situations. If you want to detect unauthorized access to a resource, having the resource which determines access anyway log that is enough. Exfiltration detection based on looking for sensitive identifiers doesn't work: real attackers will encrypt the data and dribble it out slowly or pretend to be videoconferencing. Did any exfiltration detector stop heartbleed? Endpoint subversion is not an issue for access control: if the endpoint is subverted, access has been gained. It isn't an issue for DDoS protection. Malware detection on the network does have to worry about subversion of endpoints, and yes, being able to recognize anomalous traffic is helpful here. As for attack surface why is "Press here to get plaintex of everything" not a major, major increase in attackability? Any honest assessment of middlebox techniques would acknowledge they can also be attacked and are inherently unsegmented. Just because many large organizations have decided not to adopt the smart-endpoint, dumb-network model of the Internet doesn't mean the Internet needs to be redesigned to accommodate them. I am seeing middlebox vendors and one vertical express need for this. > > > In many scenarios, one form or another of network-based visibility into encrypted traffic streams within the span of administrative control of a single organization is legitimate, vital and necessary. It is not 'wiretapping', any more than tools such as tcpdump or telemetry formats such as IPFIX and PSAMP can be categorized as 'wiretapping'. The fact is, the availability, confidentiality, and integrity of systems, applications, and networks that everyone on this list relies upon is highly dependent upon the ability of organizations to have visibility into encrypted traffic streams within their own networks, for purposes of security as well as testing and troubleshooting. > > > How this can be accomplished is a matter for further discussion. But it's important that everyone focused on this topic understands that it is simply not possible to successfully defend against many forms of DDoS attacks nor to detect and classify hostile network traffic in the context of encrypted communications without visibility into the traffic in question, via some mechanism. The same goes for troubleshooting complex problems. Which DDoS attacks specifically? And if the traffic isn't hitting endpoints, does it matter? > > > Those with operational experience at scale will likely recognize and acknowledge the difficulties and challenges noted above; others may wish to consider these factors and their impact on the operational community and the networks, services, and applications for which they are responsible, and upon which we all depend, every day. I'm currently working at place you notice when we go down. We do not use these techniques on our production network. We use mutual TLS for a large number of internal services, even within the datacenter and the same machine. We debug many complex issues through logs and specialized tools to examine troublesome state, as well as request tracing. 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. The capacity being asked for already exists. > > ----------------------------------- > Roland Dobbins <rdobbins@arbor.net> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau.
- [TLS] draft-green-tls-static-dh-in-tls13-01 Matthew Green
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Richard Barnes
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Richard Barnes
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Andrei Popov
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kyle Rose
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Eric Mill
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Christian Huitema
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Timothy Jackson
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Yoav Nir
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Tony Arcieri
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Jeremy Harris
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Russ Housley
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Richard Barnes
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Nico Williams
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Nick Sullivan
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Jacob Hoffman-Andrews
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dave Garrett
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Shumon Huque
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dave Garrett
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Eric Mill
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Checkoway
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Nico Williams
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Joseph Lorenzo Hall
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Yoav Nir
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Melinda Shore
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kathleen Moriarty
- [TLS] Fwd: draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Jeffrey Walton
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Daniel Kahn Gillmor
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Daniel Kahn Gillmor
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Yoav Nir
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ilari Liusvaara
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Nick Sullivan
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Daniel Kahn Gillmor
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Daniel Kahn Gillmor
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kyle Rose
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kyle Rose
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kyle Rose
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kathleen Moriarty
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kathleen Moriarty
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13… Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ilari Liusvaara
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Zink
- Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13… Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Daniel Kahn Gillmor
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Peter Gutmann
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ilari Liusvaara
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Melinda Shore
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Stephen Farrell
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Kathleen Moriarty
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Wartan Hachaturow
- Re: [TLS] Fwd: draft-green-tls-static-dh-in-tls13… Roland Zink
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ackermann, Michael
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Mark Nottingham
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Daniel Kahn Gillmor
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Melinda Shore
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Tom Ritter
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Yoav Nir
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Yoav Nir
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Salz, Rich
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Yoav Nir
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Benjamin Kaduk
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Benjamin Kaduk
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Colm MacCárthaigh
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Dobbins, Roland
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Ted Lemon
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Watson Ladd
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Simon Friedberger
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Carl Mehner
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Roland Dobbins
- Re: [TLS] draft-green-tls-static-dh-in-tls13-01 Simon Friedberger