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

Roland Zink <roland@zinks.de> Sat, 15 July 2017 20:39 UTC

Return-Path: <roland@zinks.de>
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 EA19512EA95 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 13:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de
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 NEN-MWpn0lBa for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 13:39:21 -0700 (PDT)
Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49565129B06 for <tls@ietf.org>; Sat, 15 Jul 2017 13:39:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1500151159; l=684; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=YXipul+7OU3IFVU5E9BUauxdrnsm2cYvMho1EwoCyuM=; b=BBeJd2X4NvNXclLhv9BljYUDi8BUMEgQ+Isep9lY9bCN2JDZcPAuexaQAUO9oNhLot Qb2BH0EjrDXqg574UOMEUIAHb2G8v7Qi2PSUUivg0D35VgJzup8Bg+lvZvJj/RVOLKrk r5z6ic8RAqxlkZk46DWr2G0btsbCRUq9QEvrk=
X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JphITAP
X-RZG-CLASS-ID: mo00
Received: from [10.10.10.91] (p5DCF5B04.dip0.t-ipconnect.de [93.207.91.4]) by smtp.strato.de (RZmta 41.1 DYNA|AUTH) with ESMTPSA id 60273et6FKdGr94 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sat, 15 Jul 2017 22:39:16 +0200 (CEST)
To: "Salz, Rich" <rsalz@akamai.com>, "tls@ietf.org" <tls@ietf.org>
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> <5c725355-18a5-9eb1-4b3e-df18b0767872@zinks.de> <f64eba6d270a439494f6e6ed24da2e9c@usma1ex-dag1mb1.msg.corp.akamai.com>
From: Roland Zink <roland@zinks.de>
Message-ID: <00e841d5-7e47-4e21-f13c-9b9f1d24a9ac@zinks.de>
Date: Sat, 15 Jul 2017 22:39:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <f64eba6d270a439494f6e6ed24da2e9c@usma1ex-dag1mb1.msg.corp.akamai.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/tskNJ05gs5zD8zlrc91Inup8eMM>
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 20:39:23 -0000

I think reverse proxies are middleboxes regardless if they have official 
origin TLS certificates. From the TLS viewpoint they may be the endpoint 
although from the HTTP viewpoint they are not.


Roland



Am 15.07.2017 um 22:23 schrieb Salz, Rich:
>> A cache may be hired by a user, origin or even a network operator to act as a
>> "front" to the origin. Is it not a middlebox because of this? It is a question of
>> definition if a CDN is in the middle or the endpoint :)
> Yes.  And I am saying that the definition doesn't include a CDN as a middlepoint.
>
> Do user-provided reverse proxies have official TLS certificates with a SAN field claiming to be the origin?