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-boun...@ietf.org] On Behalf Of Christian Huitema > > Sent: Wednesday, September 18, 2019 10:14 PM > > To: Roman Danyliw <r...@cert.org>; The IESG <i...@ietf.org> > > Cc: draft-ietf-tls-sni-encrypt...@ietf.org; tls-cha...@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. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
