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

Ted Lemon <mellon@fugue.com> Sat, 15 July 2017 07:48 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 22049131AAF for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 00:48:19 -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 WanshZoTs-cu for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 00:48:17 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 2282C131761 for <tls@ietf.org>; Sat, 15 Jul 2017 00:48:17 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id c73so55378243pfk.2 for <tls@ietf.org>; Sat, 15 Jul 2017 00:48:17 -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=ga2v0YF7XPCpqxIGWQVvAes8CtBAjdtnhjNo7VV/RoI=; b=B3JvAI9De8rcgUrWv9vXe9rgQOtp/EoZglCJERKHzoVRq/9fWjqmxoZgin86d9ss3U Jwe7kuCfqcjOM6dTgdXgeQ6t3Pr01nHhWcy4y7RfeEuSWOiEPYo4iWVkO32Ls5tj21zs 1qjyJ+WGWZcmln9w4jaLxaqOXdetN1I+/is7UUEN3QHdI5Bsk2SahvKKmbbkhchfn2Oo QGBKu7nRPLt/BA2DmuTHZc8qLkHwh0K6u+9P6O5OfPfUM/5SXFepmDM+011VGN/7Bj1a Quryx9k08OmrYCEPn/P1+ywcVJnQb+Dq3ZvqBNtzN0DjojQcLjTcOQf+biyAQh2VVQLH /q3g==
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=ga2v0YF7XPCpqxIGWQVvAes8CtBAjdtnhjNo7VV/RoI=; b=XxzVrZ87Uwd5WpOyOYUPt0xsAMu35QrpNl7d+UfL/si+lD+Wqk6Fd9S2+5kpahP72F NBNJqTQ+a7Idz5eBQ7gU0gSUGNWzB27QdbyvXjkktdNxGmNw6wADDwoMFXWLnmkTY7WE KHgNcC9Qi1/1GfFEIz5zGFFb1d4oWJileenRwz+m+R3Pd4bYHtAyC9CbIV9qK3cuKBai X0N/FLKOBQ4Q5BelckVJSuXzxKdaW2pgYj06zAmgRXuhofP/tZslJLMAusoiSTYuoyhC 1tKJwsA/dK6Dd4PhYC0A5IOicKmbaGDC/cBa9kFnYBf750pbbwJZiRMAUWXwD5EVNq2q fOZw==
X-Gm-Message-State: AIVw110dferqVPE2XxMrXydZWWnu/Ts1Vzviyk2yAOQy9EEkwFHHcJmd pYVmdFf0sLhVCxQ/t83jgcb39r/YYHRC
X-Received: by 10.98.23.3 with SMTP id 3mr9251899pfx.55.1500104896513; Sat, 15 Jul 2017 00:48:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 00:47:35 -0700 (PDT)
In-Reply-To: <D37DF005-4C6E-4EA8-9D9D-6016A04DF69E@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>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 15 Jul 2017 09:47:35 +0200
Message-ID: <CAPt1N1nVhCQBnHd_MCm79e7c1gO6CY6vZG_rZSNePPvmmU_Bow@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="94eb2c1107d47ba8dc055456635d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pMA8kc8j38lcC5QwQcI2Jph9nIc>
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 07:48:19 -0000

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?   If so, why would it be their responsibility to
obtain the plaintext?   It should be the responsibility of the controller
of one of the endpoints.

If they do control one of the endpoints, then they don't need the key, or
rather, they have it.   So it is not our problem to provide them with a way
to change it less frequently, which is really what this proposal boils down
to.

Can you give an example of a use case for this proposal where what I just
said is not true, and explain why it is not true for that use case?   Sorry
if I am being dense, but I just don't understand why this is an issue.

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

>
>
> > On Jul 15, 2017, at 13:26, Daniel Kahn Gillmor <dkg@fifthhorseman.net>;
> wrote:
> >
> > Could you point to an example of any regulation that requires plaintext
> > from network capture specifically?
>
> It often isn't feasible to obtain the plaintext any other way in a given
> circumstance.
>
> Not to mention the security & troubleshooting applications which require
> insight into the cryptostream on the wire.
>
> -----------------------------------
> Roland Dobbins <rdobbins@arbor.net>;
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>