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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Sat, 15 July 2017 16:19 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 616C0131562 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 09:19:17 -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 o5UI9WhGeVgn for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 09:19:15 -0700 (PDT)
Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 907E91293E1 for <tls@ietf.org>; Sat, 15 Jul 2017 09:19:15 -0700 (PDT)
Received: by mail-pg0-x231.google.com with SMTP id v190so1289462pgv.2 for <tls@ietf.org>; Sat, 15 Jul 2017 09:19:15 -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=cV7S4UKGJT2fPt/FVJ9Z4sILGZReRGgJp2cqOqpj3MY=; b=JRdNT1iO4i9l4qm1lFCN6ra89W0mgkWbKXvqPI1zL/+duW0SnA9FIZ2YlwXQFu9Ss4 GB8ZLwYmUCPTdvA8WS3rmgBf23sdRHzRzo3doF9TY0CW4bQxoQK3N5n1Tz6l0Eg34EJb EGORSAfxNWkDOP13Ge5qBj+X389+FwfxAlxra47XqXwxznzGqEG3/RaluZmyUit3qqwQ sTwp8lCvDrF8OKKvHu5JtvU+ffoXrKZgYmtdD3BPfYJEytdRav18LRuhWRlT3H2on/Qf VGJeHjUe9EczWK51SZiOfkzK3b437HYBSYkJRLwiZje5fR7QOq1YZCFA6DRbqTUJI1pL 4rdA==
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=cV7S4UKGJT2fPt/FVJ9Z4sILGZReRGgJp2cqOqpj3MY=; b=GfZTkDDB9cORrQ8a+LUP6RQvpskf1H3O9ahxpII/amVctfvqOZUHWO2/ak9sTnNijH eJLZQDnUkKXMw7IDaOY0IxJsK2qKANo77qLlaYFzYlPhmab1vnUBjNDSxSvhIonlZ68C qcsTRFBnVubVDn/gCSE2OfnQ8DKrcLMxDQ9Z93I2tuI4UduPE7cuYgbAo75kdcb6i9Ga cd4BBnrn5xcAoW2+GrShaCATjFT9P+A3UkNJgCnebo+YimGEkt1e6Ry4B+mL/J09tS7v WZUix4vMagP3+3JvmLOtLtZ9Ns++letEbHU3Tp6Sy3NyHbVkW8LikfEM0ZPXzYEcgAQe pKJQ==
X-Gm-Message-State: AIVw1103VKUqetl/o7TYHbOK/mY6zGFvW1LtbkbqhiYhM5TxXvE0p3m8 CB+NYJL5YGXHIneGR8V7C214c30JQw==
X-Received: by 10.84.215.135 with SMTP id l7mr21898024pli.194.1500135555143; Sat, 15 Jul 2017 09:19:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.180.193 with HTTP; Sat, 15 Jul 2017 09:18:34 -0700 (PDT)
In-Reply-To: <31358CD2-0913-4CA5-88A2-89AB8C4FBF88@arbor.net>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie> <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com> <87k23arzac.fsf@fifthhorseman.net> <C4968C13-3229-43C2-B29B-EC9C01D76D06@arbor.net> <20170715085544.y3hozzzpqzrfacd7@LK-Perkele-VII> <87379yrlqp.fsf@fifthhorseman.net> <31358CD2-0913-4CA5-88A2-89AB8C4FBF88@arbor.net>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Sat, 15 Jul 2017 12:18:34 -0400
Message-ID: <CAHbuEH6LOp6ywFyEKciVemzYje6xXhbYDVq-YvMWFc3DP+1+pw@mail.gmail.com>
To: Roland Dobbins <rdobbins@arbor.net>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, IETF TLS <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/a8zIErKa1fTaQPd5P6-eWP5cICM>
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: Sat, 15 Jul 2017 16:19:17 -0000

On Sat, Jul 15, 2017 at 7:56 AM, Roland Dobbins <rdobbins@arbor.net> wrote:
> On 15 Jul 2017, at 18:19, Daniel Kahn Gillmor wrote:
>
>> I'd like to hear from the people who are doing full-take network capture
>> within their datacenters about how they protect the security of the
>> internal decryption systems.
>
>
> Firstly, they generally aren't storing everything, forever.  Most of the
> time, they feed into collection/analysis systems, and most if not all of the
> actual packets are discarded.
>
> In many cases, they're only enabled on a situational basis - say, a security
> incident or a troubleshooting session.  Most if not all of the packets are
> discarded afterwards, in most cases.
>
> In most cases, they're running on completely out-of-band management
> networks, using transparent taps or SPAN ports or equivalent.  In some
> cases, they can be used to intervene in the cryptostream - but even in that
> in-band case, all the management functions are still isolated on out-of-band
> management networks which are not interconnected with the production
> network, and are further isolated as necessary by implementing
> situationally-appropriate network access policies.

When I have done this in the past in environments I've managed, I
always used a one way cable (receive only), set up the interface for
receive only, and then use the same protection mechanism offered by
the switch.


>
>> It certainly sounds like a tempting target for any adversary interested in
>> datacenter operations.
>
>
> I guarantee you that your bank, your hospital, your insurance provider, your
> credit card processor, your retailer, and/or your government welfare agency
> are doing this, and have been doing it for a long time.
>
> It's quite common in the national security space, as well as other
> governmental bureaux.
>
> I'm not saying everyone has implemented this perfectly, or optimally - but
> it is a common practice which has been going on for many years, and the loss
> of the ability to perform these functions would result in a net security
> loss for these organizations and for their customers and constituents -
> i.e., proles like you and me.
>
> It isn't new, it isn't unique, it isn't a case of a small group engaging in
> special pleading.  What's amazing is that very few engaged in this
> discussion seems to understand all this.
>
> -----------------------------------
> Roland Dobbins <rdobbins@arbor.net>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 

Best regards,
Kathleen