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

[Benjamin Kaduk <[e-mail]>]

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:[e-mail]] On Behalf Of Christian Huitema
> > Sent: Wednesday, September 18, 2019 10:14 PM
> > To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > 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.
>