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

Colm MacCárthaigh <colm@allcosts.net> Sat, 15 July 2017 22:55 UTC

Return-Path: <colm@allcosts.net>
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 980A1129B5B for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 15:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.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 LIoaQBQ8qyrK for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 15:55:25 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 DEB54129B34 for <tls@ietf.org>; Sat, 15 Jul 2017 15:55:24 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id j80so27701830ybg.2 for <tls@ietf.org>; Sat, 15 Jul 2017 15:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7JCVyxjMZgrZBCcVurR0sJkzyyTz3hZik8GpOgI7bbQ=; b=OnwkyJwjLDT3w+rVb2osu4wNDmHRaa3U8mPUe473Pzq05LjuBOK5BpRMh8YkW63cWm GzfLMj404O8zNOeOxjNguu41KcuF161O3CtOUjPTllR9lLzmOij4cL7LuQwl5KDzYmvZ YDLnGm3HLuPkU8I42O5M4Mf272BW0Q56f61VZ6kl7uaiEiwLnEIIzNqayw5155E8T+Bw 7ALcwo2RJzVpKY8gKqlVm9N9madBqp1QUsvXemsEXKUW2onmD15mxZF+wSBib2FGZFg8 ZFvJOJAStKPyV5BK9xox16UgYjuSM/CTlLOXuZaGxlQ9/zp1sjFLNXFVQCnUHgwxivUC MWPg==
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=7JCVyxjMZgrZBCcVurR0sJkzyyTz3hZik8GpOgI7bbQ=; b=hMumoYdrKTHvRX/jZVDWEih0W2VB1T45YVWdPwtlXhXYyUQJva08FA/Qam8FIbHYQt F4ADOEVFkTVEu3YW+kUyVOnqZGGraICcufAGUm7deZ/zFysoBYmitcVtNjZBxDL5zt1y 2NvU3bWtj3gGBScmJphsWqPa19AjRZD+cCsZQMl2cc+eBAhiSPELoA3xdBM29u86C0Kt 1AMxg7J5K0azi4hC/fTa6WJEzXJILZE0iyajt8FI9Yo5qNuiodH8QCG6X9d7CiVvvv2s rWNzlMfuJH136LtUb0pAsj3LaIm309FvrSKVVVnKp1ufqojZO+GgSSojlILy/UrubYzQ EoUA==
X-Gm-Message-State: AIVw1101Ewn/2jCKidFduCKXPIRz68SBa2EkJGTrcOSVmB1xQ6smcrzo IV1D42/Y9O0vuIz8a44mWKgRIfAJi61E
X-Received: by 10.37.42.4 with SMTP id q4mr2122267ybq.204.1500159323946; Sat, 15 Jul 2017 15:55:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Sat, 15 Jul 2017 15:55:23 -0700 (PDT)
In-Reply-To: <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net> <CAAF6GDc7e4k5ze3JpS3oOWeixDnyg8CK30iBCEZj-GWzZFv_zg@mail.gmail.com> <54cdd1077ba3414bbacd6dc1fcad4327@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Colm MacCárthaigh <colm@allcosts.net>
Date: Sat, 15 Jul 2017 15:55:23 -0700
Message-ID: <CAAF6GDeSv+T1ww5_nr6NPgg9k44j7y04tJWC=KeaJF7Gtt+TVQ@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Joseph Lorenzo Hall <joe@cdt.org>, Matthew Green <matthewdgreen@gmail.com>, Nick Sullivan <nicholas.sullivan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a11441e9a9c62120554630fca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/L6_lqRpF8VUFcYa3iTZ_2kMn_Kg>
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 22:55:27 -0000

On Sat, Jul 15, 2017 at 12:12 PM, Salz, Rich <rsalz@akamai.com> wrote:

> > On the public internet, it's increasingly common for traffic to be MITMd
> in the form of a CDN.
>
> A CDN is not a middlebox, it is not a MITM.  It is a site that the origin
> has hired to act as a "front" to it.
>

Don't take it as a criticism; I've built two CDNs, and I think they are an
awesome and important part of the internet. But CDNs certainly are middle
boxes; they sit between the origin and the client. A box, in the middle.

What I'm trying to get it is the inconsistency of logic we are applying. So
far responses on the mailing list have been saying "Don't use pcap, instead
run proxies". For some reason we find proxies less distasteful, even though
they have unbounded capability to destroy forward secrecy, even though they
must be in-line and hence subject to exploit, even though it comes at
massive cost (in my opinion), even though it's much harder to use proxies
to examine plaintext in a forensic and selective way. Not only is this very
unlikely to be an answer that will work for the enterprise network folks,
if they did take our advice, it would actually be /worse/ security than
what they have today. That has to be a bizarre outcome to promote. For
what? moral purity?

With regard to CDNs, that's more illogic: why are we so against a key being
shared to decrypt session keys, but fine with a key being shared to
facilitate total impersonation? I can't make sense of it.

PS: I expect everyone who argues against facilitating PCAP decryption on
the ground of "Forward secrecy is a must have" to make identical demands of
0-RTT, which can do much more damage to FS.

-- 
Colm