> -----Original Message----- > From: Benjamin Kaduk [mailto:[email protected]] > Sent: Wednesday, September 25, 2019 8:42 PM > To: Roman Danyliw <[email protected]> > Cc: Christian Huitema <[email protected]>; The IESG <[email protected]>; > [email protected]; [email protected]; [email protected] > Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni- > encryption-05: (with COMMENT) > > 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:[email protected]] On Behalf Of Christian > > > Huitema > > > Sent: Wednesday, September 18, 2019 10:14 PM > > > To: Roman Danyliw <[email protected]>; The IESG <[email protected]> > > > Cc: [email protected]; [email protected]; > > > [email protected] > > > 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.
Understood, but IMO, this is an interpretation of "anticipated use". Taking a narrow read of RFC3546, I don't see explicit references to proxies, domain boundaries, etc. The line of thinking I read in this draft is that there are certain anticipated and unanticipated uses of SNI. If the practice is categorized as unanticipated, then it should be "thwarted" with encrypted SNI (per Section 2.3). My concern is that with this framing is that we're unnecessarily divining intent from RFC3546 to classify certain practices. This draft is a commentary on concerns of certain existing practices (whether they were intended or not). I'm trying to avoid adjudicating whether proxies are middleboxes and what uses were intended. My proposed text sticks to citable sources by explicitly referencing the purpose of the SNI from RFC3546 and acknowledging that it gets used for other things. Roman > -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 [email protected] https://www.ietf.org/mailman/listinfo/tls
