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

Kyle Rose <krose@krose.org> Sat, 15 July 2017 13:08 UTC

Return-Path: <krose@krose.org>
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 D8F4312ECCB for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 06:08:45 -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, 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 (1024-bit key) header.d=krose.org
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 XAyjsw8RSQuk for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 06:08:37 -0700 (PDT)
Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 176BC129B4B for <tls@ietf.org>; Sat, 15 Jul 2017 06:08:37 -0700 (PDT)
Received: by mail-qt0-x242.google.com with SMTP id c20so13121646qte.0 for <tls@ietf.org>; Sat, 15 Jul 2017 06:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8wkspLMMkkm3F+VMC2W38EG3lnRRTQW+CfKxkkMYIE=; b=GyRQA4x//iZDSh7sIfPQjgGpkH/XdxpGERWzvJnGa07o5GKMGNUEkfdKiq55wycF8B mML30IZjzd39tRafU2heI/7SRCImEeYYalIulA52mpay/g1DLyfGffVR1e52kycS4ejK ZNgv7pEnV5ueEs7F0E059ZtqHWZ9WHBLTNibY=
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=G8wkspLMMkkm3F+VMC2W38EG3lnRRTQW+CfKxkkMYIE=; b=pktpszRnHYHxS3N8s0KcVMH0BczoIkhgI8y3waZJSxCscI1XP12LxPbabXTMDWwh3C A5VnKEw3F0giO1k5xqvp0zxH91UWQXo0zKtzkEV/snOJF6MnmnJosRcunnyf0s6LgwYz YyBFiS+UzkWPXcF3Z926sHnXb3f/r+Gt2IEVB0soX8oK+znDqMPbj2j+FeOoQEGa9bBt Gm6E5Ba/QFw3gExT2GEI1ULaRx33nO0DEe27HOGp2VNOt64IEXBSqLPzrCLu9HfcCSEH 87+x5RvxtRZhPZpRu0dlB1EBMpsBcr/u9rqxLnj0bUyFu3p/CjcgTPOtrNYSZUKjDJ1F SCSg==
X-Gm-Message-State: AIVw111xQ8KXvS0xDxCRcgj/2ZbAts5huPacx8kJzGUZ88WuJ6uhdPbX 4m2BYDCCbZ3aZq6Y9gTJI2g2WrVbQ+xn
X-Received: by 10.200.51.235 with SMTP id d40mr17210672qtb.151.1500124116027; Sat, 15 Jul 2017 06:08:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.128.194 with HTTP; Sat, 15 Jul 2017 06:08:34 -0700 (PDT)
X-Originating-IP: [31.133.128.218]
In-Reply-To: <CAJU8_nVkax+7oCxxnFZz_vbKi=rNJ_v27Yjuc-1i7j2QyVzFXQ@mail.gmail.com>
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> <871spirljc.fsf@fifthhorseman.net> <14403761-47B4-4F6C-BF89-2553D180E776@arbor.net> <CAJU8_nVkax+7oCxxnFZz_vbKi=rNJ_v27Yjuc-1i7j2QyVzFXQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Sat, 15 Jul 2017 09:08:34 -0400
Message-ID: <CAJU8_nUm2wa+2U+BYrbOgJUXY_xEWjcxq7=OE72-31-4L=hAWw@mail.gmail.com>
To: Roland Dobbins <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="001a114547be0e1f3105545addb0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/HJaD_waxaAAuV1rHLb3hAREjJlU>
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 13:08:46 -0000

I've rebased from the kernel master HEAD (4.12.0+), tested, and
force-pushed the repository.

Conveniently, it looks like, since the last time I searched for one,
someone added an ECDH implementation to the kernel. That makes this a lot
easier.

Kyle

On Sat, Jul 15, 2017 at 8:18 AM, Kyle Rose <krose@krose.org>; wrote:

> On Sat, Jul 15, 2017 at 7:59 AM, Roland Dobbins <rdobbins@arbor.net>;
> wrote:
>
>> On 15 Jul 2017, at 18:23, Daniel Kahn Gillmor wrote:
>>
>> Whether it justifies a loss of security is a separate question.
>>>
>>
>> It isn't a loss of security - it's actually a net gain for security.
>
>
> Security isn't a scalar quantity, so there's no way you can credibly
> assert this. OTOH, it's easy to point to the individual security properties
> lost by expanding the attack surface for a particular session key or by
> mandating key-reuse.
>
> Analyzing the impact of any particular mechanism for middlebox inspection
> is a question of tradeoffs: what are you giving up, what are you gaining,
> and is the trade worth it? The first two are questions of fact (though I'm
> under no illusion that there would even be broad agreement on those). The
> last is not: it's inherently subjective and among other things it depends
> on the threats, the alternative mechanisms available, and the value placed
> on the properties TLS provides to end users in its unadulterated form.
>
> Every one of your emails seems to boil down to an argument of the form
> "Organizations have infrastructure and operations set up to do inspection
> this way, so we need some way to apply that to TLS 1.3." I am unpersuaded
> by such arguments as a reason for standardizing a weakening of TLS. Given
> that, I would like to understand the origins of this approach to
> monitoring, as that may shed light on the hidden or unspecified constraints
> other than those imposed by TLS. (For example, if this approach is deemed
> to be less costly than doing endpoint monitoring, or if there are
> insufficient access controls for entry to the privileged network, or if the
> privileged network has systems that are too difficult to secure.)
>
> Kyle
>
>