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

Roland Zink <roland@zinks.de> Sun, 16 July 2017 10:10 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 31284120725 for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 03:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=0.01] 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 liQiFIG5hM2k for <tls@ietfa.amsl.com>; Sun, 16 Jul 2017 03:10:40 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 30F641300CE for <tls@ietf.org>; Sun, 16 Jul 2017 03:10:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500199827; l=11559; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:Cc:To: Subject; bh=50vGd/bjuZLsAC5qWf05Rvsc+ybPfzPsiI4CalQ+gis=; b=lHxXvzWTn46w+KFk00O4QIrB2qwM5MsJXuZE62My6oeNcHRjNDKzm1acHmPhcjk+ot TH16f4i/B+wdYbvecLyCwB+PhzKQklXNfQPYmjCliOq6+iA9qk6+xUmqHwL0D6EMGT+o 2DrgbCEL3zN0kpOPOPDkZT6oNHYrhcPpoJALM=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JRiIT76qfE=
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p5DCF48F8.dip0.t-ipconnect.de [93.207.72.248]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id L01bc0t6GAAPqfy (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); Sun, 16 Jul 2017 12:10:25 +0200 (CEST)
To: Watson Ladd <watsonbladd@gmail.com>
Cc: 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> <860cd103-4e40-3f6f-1a3e-be9a6513c86c@zinks.de> <CACsn0cm5mndkPGeRT5i7dvohKbrgK2KOMuaPGjWPghG0gzYBDA@mail.gmail.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <c903c5df-06a8-b87d-1941-278259005d12@zinks.de>
Date: Sun, 16 Jul 2017 12:10:26 +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: <CACsn0cm5mndkPGeRT5i7dvohKbrgK2KOMuaPGjWPghG0gzYBDA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------82184637976CE07E747ECE38"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vRePNQ9S9jbUTpS2VKaXRiixhXs>
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: Sun, 16 Jul 2017 10:10:43 -0000

Am 16.07.2017 um 00:07 schrieb Watson Ladd:
>
>
> On Jul 15, 2017 12:33 PM, "Roland Zink" <roland@zinks.de 
> <mailto: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 <mailto: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?

An endpoint has information about the source IP address. It may not have 
an IP adress before NAT, email adress, postal adress or information 
about building / desk number. A middle box having more exact information 
about the source may notify the source owners which often are victims 
themselves.

>
>
>             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.
I was not talking about how it could be detected or prevented only that 
it matters before it is hitting the endpoint and if there is a way to 
avoid it then it should be avoided.

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