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

Melinda Shore <> Sun, 16 July 2017 06:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20B2F126B7F for <>; Sat, 15 Jul 2017 23:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KdaiI7HA5sjQ for <>; Sat, 15 Jul 2017 23:02:54 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4AEE120726 for <>; Sat, 15 Jul 2017 23:02:53 -0700 (PDT)
Received: by with SMTP id v60so16762891wrc.3 for <>; Sat, 15 Jul 2017 23:02:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=DWoSeWEcUp1Oa5NPmqcAo4jgI06ADvm9ZLUIjeJVSvk=; b=NFPJM/c5MNH8bzEgnEiNf8BZp5mM2FxsaFmKmYRKQI9NctVWcUPqSJxKoJZVFJCVkP nOU0lmhM3zpP0j7bojP3PVK694m102f39XpGUERpdKeJ9zlntFWk0IWHALwysSd+00rq P7f+GSB1QHoKtYaREc7qZ82+CQPSZAzjYm8r88aTrTRD7Y0Srwdk48QXSmAot2dHo9Vb PD/IXYpxHR+JEj0GDDKf/wHZ+UaoR71R43ALDLxpPeyjyzt/KyHHfUSKrkvWClEdMKbM JnxrltEEEK/pmIEk3HIfelD53c88K+MyDqh66hUza3CaWAvgHQNVlLS5Zb+wery9Bwiw NvvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=DWoSeWEcUp1Oa5NPmqcAo4jgI06ADvm9ZLUIjeJVSvk=; b=KkmI2phrpopdo9SpwwX87aLXNX1bZwkxJ5JP73O/KsUlc6TNyXtTniX7XbYaIhm/SW tDxbaueYEygQjWIM3h13t0VYTf1Ntt/G6EtgQ5PWT8Bl4EMp2INJLCbXOk6xmX6eElti RHrKMzDFJQmzLXYQUrcekzkCfGm0YkQvZUhFFkKynJSV1vjE0OSZ6wbAZsYfLBXg+lGU s+w69h05L8tcvDDtxrUmIqcc21CSkBosXekLjRRVaEGk7/x7odBB/ga/3BtTCq3du1nG rC1vGeA3UiFZq7XSqsc+KvqtVA2mdai6JzelFyb+Cn/EnVcVCgC/Box/M40aHtwt5/2Y MRXw==
X-Gm-Message-State: AIVw110IhHq2bQ9O1v6NrRlEgwQX+LMycFX4z9nqugk+xe6aqza9rJIB I5CczgN2W5GsxZFXx7l1Og==
X-Received: by with SMTP id 88mr8261455wre.51.1500184971916; Sat, 15 Jul 2017 23:02:51 -0700 (PDT)
Received: from ([2001:67c:1232:144:e80d:3c44:1d6e:df40]) by with ESMTPSA id c131sm8972114wmh.2.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jul 2017 23:02:51 -0700 (PDT)
References: <> <> <> <> <> <> <> <> <>
From: Melinda Shore <>
Message-ID: <>
Date: Sun, 16 Jul 2017 08:02:50 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mW9SL0A2aAAoES66eRIVQ9LFmeSq4rapC"
Archived-At: <>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Jul 2017 06:02:55 -0000

On 7/16/17 7:55 AM, Salz, Rich wrote:
> I am not offended.  I am saying that if it terminates the connection it
> is an endpoint not a middlebox.

Well, maybe.  That's certainly the general understanding of middleboxes
(i.e that they they are not directly addressed [well, NATs, but] and
that they don't terminate traffic) but even way back when we did the
original midcom work and produced 3234 (hard to believe it's been 15
years) there was some mushiness around transparency being a requirement
for being considered a middlebox.  For example, from 3234:

   Note that HTTP proxies do in fact terminate an IP packet flow and
   recreate another one, but they fall under the definition of
   "middlebox" given in Section 1.1 because the actual applications
   sessions traverse them.

However, that's not really a description of the behavior of CDNs -
HTTP sessions really do terminate on cache nodes.

That said, I'm not sure how this helps sort out the question of what
(if anything) needs to be done to satisfy monitoring requirements in
some deployments.