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

Watson Ladd <watsonbladd@gmail.com> Sat, 15 July 2017 22:07 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 BD85D12EA74 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 15:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 xvxz1R7wndW1 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 15:07:49 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 4388D129B19 for <tls@ietf.org>; Sat, 15 Jul 2017 15:07:49 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id e7so60436736pfk.0 for <tls@ietf.org>; Sat, 15 Jul 2017 15:07:49 -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 :cc; bh=SJg+/PKEkgTKbwTDrktXYgp3BF3In2f9BDi33VQ+TdI=; b=bGJao5SUG1jcPP8akp3tosZmR/VIWj2pM0a72imeuZEQtDD05u9QDjkxTwxhnzJQX6 1mo/WJoxO/J1clQ/m49UMnlS72xul3M9+EnuUW5Viv0hB3NJk7n80Wv7cIaFS5WERmXh QZJgAgmac+NkdnDKeDFoIgCiavTYb72ZEpmLoqNEEiwOvx/Gyh54tBDCDNZp+zeD8MAK IM/9HvDlir1iNJMgkjHzsGKiEIMtSfGhctRCX7CpDgu2DoC0nsLemswmXX31LWSjQG2A uaIzv8XY7AWBKVBKsMY5YrBy7QwUr/XAMt9R/IiEEelG2+HKDzQTUczv4gl6XVGB02OR ylGw==
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:cc; bh=SJg+/PKEkgTKbwTDrktXYgp3BF3In2f9BDi33VQ+TdI=; b=jfcPf+IBBNIlg81ShYqRxDxF7z7u7vEuNqut7S6SE4dhQHi7P6ic9fchwwsDxvhWR3 Zba+YS+e11LAW2IB77sEPL/Ce1bvqfLyfbIskMdfJAdjisMuWVZXOTaUnBcUo9PdJoYE iKnSOskN8ihD3YHPeqr3BEKqIrhh33jsVvT1I4FH2c+t/eXcnqdD0EjYhHoNyXSrRVAH yQeq6WfYRnyMg5I33cKhzH8Hetj0mcXpS9Y3dLBhXurHOamonzo5pgW3/Nh09wBHR2Vd ygWUQwInwUsSBjU/xMfK3fb24QLQOpGDk3skS9Sz8tvUA0RIVpOe9vnOp9iL8OlTPb4y H8yg==
X-Gm-Message-State: AIVw111K1FGNoGH+lnqGoL7BbNZk1THPLvuNHf5YAbI7wZ9LwJf2i8x6 VDBHfVFtx+KWxkwQl/KMe3xDBhOpp5dX
X-Received: by 10.84.229.79 with SMTP id d15mr23242648pln.4.1500156468819; Sat, 15 Jul 2017 15:07:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 15:07:48 -0700 (PDT)
Received: by 10.100.187.77 with HTTP; Sat, 15 Jul 2017 15:07:48 -0700 (PDT)
In-Reply-To: <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de>
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> <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 15 Jul 2017 15:07:48 -0700
Message-ID: <CACsn0cm5mndkPGeRT5i7dvohKbrgK2KOMuaPGjWPghG0gzYBDA@mail.gmail.com>
To: Roland Zink <roland@zinks.de>
Cc: tls@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c19ecb46e7ca10554626598"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LkB4tTylymT4OKtMpKg7JK9-l1g>
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 22:07:52 -0000

On Jul 15, 2017 12:33 PM, "Roland Zink" <roland@zinks.de>; wrote:

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.


How does an endpoint not know the source?


> 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.


I'm not talking DDoS. I'm talking attack traffic. You need to talk about
specifics you cannot solve other ways. DDOS isn't specific enough.



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls