Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 26 September 2019 00:42 UTC

Return-Path: <kaduk@mit.edu>
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 C73D8120251; Wed, 25 Sep 2019 17:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Aq0JiqrX6U54; Wed, 25 Sep 2019 17:42:07 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 3365012001A; Wed, 25 Sep 2019 17:42:06 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8Q0fwuW011966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 20:42:00 -0400
Date: Wed, 25 Sep 2019 17:41:57 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Roman Danyliw <rdd@cert.org>
Cc: Christian Huitema <huitema@huitema.net>, The IESG <iesg@ietf.org>, "draft-ietf-tls-sni-encryption@ietf.org" <draft-ietf-tls-sni-encryption@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20190926004157.GU6424@kduck.mit.edu>
References: <156881761812.4630.11745895149419124830.idtracker@ietfa.amsl.com> <c504a433-cc5b-df00-15c2-fcaf3116798c@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CxDRgI-bD3iv1Bl6e2MLqf4aToI>
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 26 Sep 2019 00:42:10 -0000

On Wed, Sep 25, 2019 at 05:27:53PM +0000, Roman Danyliw wrote:
> Hi Christian!
> 
> Thanks for the detailed responses and the helpful background.  Below are a number of proposed text block replacements to clarify my intent (instead of more questions).
> 
> Roman
> 
> > -----Original Message-----
> > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Christian Huitema
> > Sent: Wednesday, September 18, 2019 10:14 PM
> > To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> > Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org; tls@ietf.org
> > Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
> > encryption-05: (with COMMENT)
> > 
> > Thanks for the feedback, Roman. Comments in line.
> > 
> > On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
> > > ** Section 1.  Per “More and more services are colocated on
> > > multiplexed servers, loosening the relation between IP address and web
> > > service”, completely agree.  IMO, unpacking “multiplexed servers” is
> > > worthwhile to explain the subsequent text because it motivates the
> > > loss of visibility due to encryption with network only monitoring.
> > “Multiplex’ happens at two levels:
> > >
> > > -- co-tenants (e.g., virtual hosting) – multiple services on the same
> > > server (i.e., an IP/port doesn’t uniquely identify the service)
> > >
> > > -- cloud/cdn  – a given platform hosts the services/servers of a lot
> > > of organization (i.e., looking up to what netblock an IP belongs
> > > reveals little)
> > 
> > 
> > OK, will try to incorporate your text.
> 
> Thanks.
> 
> > >
> > > ** Section 2.1.  Per “The SNI was defined to facilitate management of
> > > servers, though the developers of middleboxes soon found out that they
> > > could take advantage of the information.  Many examples of such usage
> > > are reviewed in [RFC8404].”,
> > >
> > > -- Can’t middleboxes also help facilitate the management of servers?
> > > This text seems to take a particular view on middleboxes which doesn't
> > seem appropriate.
> > 
> > It is pretty clear that the load balancer in front of a server farm will need
> > access to the service ID, and must be able to retrieve the decrypted SNI.
> > There may be other examples, such as DoS mitigation boxes. The
> > "unanticipated usage" comes typically from middle-boxes that are not in the
> > same management domain as either the client or the server. Is there an
> > established way to designate those?
> 
> I'm not sure I understand the original of the requirement that the client and server being in the same management domain.
> 
> RFC3546's definition of SNI opens with:
>    [TLS] does not provide a mechanism for a client to tell a server the
>    name of the server it is contacting.  It may be desirable for clients
>    to provide this information to facilitate secure connections to
>    servers that host multiple 'virtual' servers at a single underlying
>    network address.

I think the idea is that you can have a client-side forward proxy or a
server-side reverse proxy, and either of those can be okay, but you don't
want some random unaffiliated thing in the network poking at things.
So, one might have client != server, but (client == middlebox) OR (server
== middlebox), where equality reflects membership in the same
administrative domain.

-Ben

> It seems to me that if we are trying to channel original intent, then only the virtual server use case applies.  I'd propose:
> 
> OLD
> The SNI was defined to facilitate management of servers, though the developers of middleboxes soon found out that they could take advantage of the information.  Many examples of such usage are reviewed in [RFC8404].
> 
> NEW
> The SNI was defined to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address [RFC3546].  However, addition management and security practices emerged making use of this information.  Examples of such usage are reviewed in [RFC8404].
> 
> This language would let you distinguish all of the middle box behaviors done by operators and enterprises from a possible [RFC7258] attacker.
>