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

Ted Lemon <mellon@fugue.com> Sat, 15 July 2017 08:07 UTC

Return-Path: <mellon@fugue.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 11009131B25 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 01:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=fugue-com.20150623.gappssmtp.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 le-iZEtj3LRe for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 01:07:09 -0700 (PDT)
Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 9B7F0131B06 for <tls@ietf.org>; Sat, 15 Jul 2017 01:07:09 -0700 (PDT)
Received: by mail-pf0-x234.google.com with SMTP id e7so55476087pfk.0 for <tls@ietf.org>; Sat, 15 Jul 2017 01:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=79P21paJ6Wml9+NlIB3uhJOKdkrAFMOLMP8N1Pebou8=; b=sqXtaK1yTvP+fgAuF2cEFfOhlf7zF5zblGWKxPtlzoRj1MRJegh+KrlVbNzmWahnf3 BDH7O1U7pMuiilsfdUhVP2TyvG6MRAKkLCmqF1Q0EN+3jLN5VN4IazWUnLuh/xg7NnPY QVaeNcSjXtW2b0jJQYKaKMrhjUq+dM57RJ9r+dirtlF4hZlHYIvH5/LWbhVPNA7u/biq LdaZ/uF/37ojfSP4AHzJBKkot2zyoL7BU6ouyImmKirG807/BN1MRJf/lzkgvErbtZ2A +jHdwYeWYV8HltsMgl3lnvt8kjLXeqCJevdcE8OX8xtj87L85UjjKp3OR+1gdTPwizDL eN0A==
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=79P21paJ6Wml9+NlIB3uhJOKdkrAFMOLMP8N1Pebou8=; b=aZJrXH7LrpU1U/fra4FyUigF+YPd27P9cjF7srT1Mmk4ibdXxMv2pProK0ui2u3gwy 8tdblLyfvWSYR9sCAc2U76/o34/nDxakr0eslxZmWDUjd7oJHAlsLY3iT/Z95DqRN2Wr 8QCjmGRjVjkt4L8pPP7EpG94W7DhsL0kpNPI3yY9hVSLed+oE5rKvYrwqBaonwz2QPxE 6EmcpHZNjck+RGPHninj1RX+rBeXkGjp0s2osNGogUBSkFlgnO4A2hlrCiv7wm5nLAsU luFrtf42RDDe+TezQ2sZg9hlAo06OsO2RcyJzpzwhTZKn7DI8eRI1qYiVNdNJcB2evZ/ U3Iw==
X-Gm-Message-State: AIVw113QgbGXc8bVd3WQRoSlh5N/C6Fkk4C7cu4MYuR6DHbT/aTh1alz BuFCSIRD/ZttYccGbT5fU0FkgY2KEgpa
X-Received: by 10.98.23.3 with SMTP id 3mr9304736pfx.55.1500106029201; Sat, 15 Jul 2017 01:07:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 01:06:28 -0700 (PDT)
In-Reply-To: <44AB7CB8-13C1-44A0-9EC4-B6824272A247@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> <D37DF005-4C6E-4EA8-9D9D-6016A04DF69E@arbor.net> <CAPt1N1nVhCQBnHd_MCm79e7c1gO6CY6vZG_rZSNePPvmmU_Bow@mail.gmail.com> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 15 Jul 2017 10:06:28 +0200
Message-ID: <CAPt1N1=rvtssKXCnsNmr1vy4ejb6YDUxO2kDcgh-ZMh5WGjfWg@mail.gmail.com>
To: "Dobbins, Roland" <rdobbins@arbor.net>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Matthew Green <matthewdgreen@gmail.com>, IETF TLS <tls@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1107d4ff0bc5055456a628"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jJSxngAjtSzuYPRJLx0wvIon5Kc>
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 08:07:11 -0000

I think that your first and third points are actually non-sequiturs: the
unencrypted stream is available to the entities controlling either
endpoint, not just the log.   There is no *technical *reason that in-flight
capture is required to address those two points.

Regarding your second point, this seems to be the real key that is
motivating you to make the first and third points.   If I may paraphrase,
the problem you are attempting to address is that in some situations two
sub-organizations both of which are in principle responsible to a larger
organization nonetheless are unable to cooperate due essentially to a
failure by one sub-organization to take seriously the responsibilities of
the other sub-organization, and the failure of the organization to which
they are both subordinate to successfully encourage cooperation on the part
of the intransigent sub-organization.   Did I paraphrase that correctly?

On Sat, Jul 15, 2017 at 9:54 AM, Dobbins, Roland <rdobbins@arbor.net>; wrote:

>
>
> > On Jul 15, 2017, at 14:48, Ted Lemon <mellon@fugue.com>; wrote:
> >
> > In the event that it is not feasible for an operator to obtain the
> plaintext of a message without the key, isn't that because they don't
> control either endpoint?
>
> First of all, what goes on the wire is often contextually different  (and
> probatively so) from what's recorded in abstract log files.
>
> Secondly, administrative divisions within a single organization often
> impede cooperation between those tasked with securing & troubleshooting
> communications and those who 'own' the assets in question.
>
> Thirdly, for both security & troubleshooting applications, the hard
> requirement is for real-time visibility & possible intercession, not ex
> post facto analysis.
>
> -----------------------------------
> Roland Dobbins <rdobbins@arbor.net>;