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

Roland Zink <roland@zinks.de> Sat, 15 July 2017 19:33 UTC

Return-Path: <roland@zinks.de>
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 415A3127B73 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 12:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 55JEWRrWcQqr for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 12:33:34 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30EE126D46 for <tls@ietf.org>; Sat, 15 Jul 2017 12:33:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500147211; l=3149; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=r94Upeg+DdwmxLC9CxqXZvjU/IN5FosA0znmjkHHBlY=; b=j67Ow1n/86CqTIwrtUO9+jwvUYwekVi+9aTVE27yXjTBnD8XcGt/JkSSAM707CmzLh ig44fXZK11t6D4qnhGZU9Bx2UhliqHMt9wkS5KLSnKSD4RdViMVi4u6tKEWzqhb0W8cq LWl2nlmpKA3C9Cs2Lqkj0Oa6wKkZ501pTgvDM=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id 6091c1t6FJXVpxJ (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for <tls@ietf.org>; Sat, 15 Jul 2017 21:33:31 +0200 (CEST)
To: tls@ietf.org
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> <CACsn0cnc0X5++cOvTNsboda8J42qg3VDquZ4Va-X-YDcggnbvA@mail.gmail.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de>
Date: Sat, 15 Jul 2017 21:33:31 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CACsn0cnc0X5++cOvTNsboda8J42qg3VDquZ4Va-X-YDcggnbvA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/7K3pZ1HfB7r2AgkbH_R1OhXX8l0>
Subject: Re: [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 19:33:36 -0000

see inline

Roland


Am 15.07.2017 um 03:40 schrieb Watson Ladd:
> 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.
One thing which can be done is identifying the sources and notifying the 
owner of the devices so they can be cleaned.
>
>> 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?
Yes, DDoS cause damage to dumb networks in between as well.