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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf