On Thu, Sep 09, 2010 at 12:59:29AM +0200, Stefan Santesson wrote: > Peter, > > I don't see the problem with accepting a host names provided by DNS SRV > record as the reference identity. > > Could you elaborate the threat? > > Example: > > I ask the DNS for the host providing smtp services for example.com > I get back that the following hosts are available > > smtp1.example.com, and; > smtp2.example.com > > I contact the first one using a TSL connection and receives a server > certificate with the SRVName _smtp.example.com and the dNSName > smtp1.example.com > > The certificate confirms that the host in fact is smtp1.example.com and that > it is authorized to provide smtp services for the domain example.com. > > That is all you need. The host name from the DNS server was setting you on > the track but is not considered trusted. What you trust is the names in the > certificate. This is a more complicated example than the current draft addresses. In your example, the client is verifying "a combination of identifiers" (SRVName and dNSName) in the certificate. This seems like a reasonable thing to do, but this is not what most clients do today (I'd be happy to be corrected about that). Typically, they consider a match successful once they've found a single acceptable reference identifier. In that case, you can't simply use a reference identifier that contains a DNS mapped identifier unless you've obtained it an authenticated (or statically configured) manner. -- Shumon Huque University of Pennsylvania. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf