> On Feb 14, 2017, at 10:02 AM, Ben Schwartz <bem...@google.com> wrote: > > Hi dnsop, > > I've written a draft proposal to improve the privacy of TLS connections, by > letting servers use the DNS to tell clients what SNI to send. >
Hi Ben, > _443._tcp.subdomain1.example.com. IN SNI subdomain2.example.com As I read this part I was assuming that the RDATA of the SNI record is an RFC 1035 <domain-name> and the lack of a trailing dot made me twitch a little bit. It seems to me that you need to decide what the format of the RDATA will be. Throughout most of the doc it looks like a <domain-name>, but in other places it sounds like an opaque string (particularly the paragraph about extensibility). > When initiating a TLS connection to a domain and port, a client > application SHOULD query the SNI record for the prefixed domain at > the same time as the A or AAAA query, and wait for a response before > initiating TLS. In the Introduction you said "Clients can make use of this record without adding delay to their connection process" but here the instruction is to wait. How long should a client wait for a response to its SNI query? Oh, I see later you wrote: A client application SHOULD NOT delay initiating a TCP connection while waiting for the SNI DNS response. > The application MUST discard or ignore any SNI > record whose RDATA is not a well-formed domain name or an empty > string. This might need more clarification. Here's a place where the RDATA sounds very much like <domain-name>. But then the empty label "." becomes particularly tricky here because, arguably, a <domain-name> can never be an empty string. > If > the selected SNI record is present with an empty RDATA (RLENGTH = 0), > then the client SHOULD omit the Server Name Indication. Again, advice here will depend on what you choose for the RDATA format. If its <domain-name> then you can't really have RDLEN=0. > Client applications MUST NOT allow the contents of the SNI record to > influence their certificate validation behavior. The client's > certificate validation MUST be based on the user's specified > destination, not the RDATA of the SNI DNS record. Given this, it sounds like there is no real reason that the SNI value needs to be a domain name. It could be something else, like an opaque string or an RFC4122 UUID? I think this doc also needs a privacy considerations that talks about ways it could be abused by server operators. For example, I think it could be used as a component of a so-called super cookie. Each client could get a unique SNI from the DNS server, allowing the web site to track individuals. While you may be improving privacy with respect to passive attackers, it can reduce privacy between web clients and servers. DW _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
