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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Fri, 14 July 2017 21:01 UTC

Return-Path: <kathleen.moriarty.ietf@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 8B42813189C for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 14:01:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 MTr65qtEZb1E for <tls@ietfa.amsl.com>; Fri, 14 Jul 2017 14:01:31 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 3473C12EA74 for <tls@ietf.org>; Fri, 14 Jul 2017 14:01:31 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id 62so30145846wmw.1 for <tls@ietf.org>; Fri, 14 Jul 2017 14:01:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jv0lCpQnZAGNvcAFzfOIt/XKf+lJJkCaxkqP01TxZhs=; b=RbRI6mLNeYyK5vIBJHg/VQJEIAFMfrvB4ke0jNYeP8jHYpHU4+hinJDCAtkhV6WEAl b6+aW1PL6Qz2c08QIby1NNMVsHd7OZU1kjI4c7cULVjlnLfJJGmDWGwS3JwnRbDT/75W 2KD+vZc1ZLzZRi+Pe7sPlNargNdYG+vHNc/nxldzS9clFF4P50oUHADi2vhu/Maa+OV9 J3bRu8HdHh19AqENfWsUDEn6kOwSGQhsfGD7xSdbcoNtHowzxRmYgECgtbUU8hcvIJd8 x7mEPKpDPQliU938okWkeajbgPZHfBsB0KR3pBHjBVn8nMq7ksAFWchk+BTmsxmiAbyC TO5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jv0lCpQnZAGNvcAFzfOIt/XKf+lJJkCaxkqP01TxZhs=; b=NcIvF/TH2TaBbaDPsi1UoYxGJobk35hsZbtcrh991iTJcWR0WiPJuKWqG+sqiYwZCD PD9v5EOORU5U3dVQKkvy12g1BxN62zOwYSrDA/c56VrEzk3EpLWWzAPsJI5IQZJIMNbn 6qhWCkUJoFctSfPb33ifetKyD8CMBkKK5BYZpmaioViF6240nxiccbd8r0wegLdyLCpz eVYRfT64USJznQmyJWWExsPUXraTwSjY+HzN3uFvqetzK0tBuJbRFFBGjSHgaJ7H/Xpi vwE087J7+2dEgtuMkSzyD+fH7OgycN32bqFX18FITkcoZgtQXsKtBtxIhpKUHczOcFPA OdSg==
X-Gm-Message-State: AIVw113zsuKpTzlN4CaM9hJUto0iWjLaJxBSfD6WaW0+u/lfqBauy1DL y0r+gzU3SPX599dJgyI=
X-Received: by 10.28.147.137 with SMTP id v131mr4205074wmd.98.1500066089227; Fri, 14 Jul 2017 14:01:29 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:2dfc:340f:9a86:e0c9? ([2001:67c:1232:144:2dfc:340f:9a86:e0c9]) by smtp.gmail.com with ESMTPSA id z108sm10040459wrb.41.2017.07.14.14.01.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Jul 2017 14:01:27 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (14F89)
In-Reply-To: <6AF150DF-D3C8-4A4A-9D56-617C56539A6E@arbor.net>
Date: Fri, 14 Jul 2017 23:01:26 +0200
Cc: tls@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <31FB06FE-F2A5-4A15-B896-D0FEBECCC6D4@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>
To: Roland Dobbins <rdobbins@arbor.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6g7KMKYiZS98zmTCc_68idnA01c>
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: Fri, 14 Jul 2017 21:01:34 -0000

Hi Roland,

It sounds like you misread my messages and should read them in context of TLS 1.3 and the draft using DH static keys proposed to help with monitoring.

Best regards,
Kathleen 

Sent from my iPhone

> On Jul 14, 2017, at 8:41 PM, 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> -----------------------------------
> Roland Dobbins <rdobbins@arbor.net>;
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls