Re: [certid] Review of draft-saintandre-tls-server-id-check

[Stefan Santesson <[e-mail]>]

On the issue of checking multiple name forms.

I would put it in another way. Web clients are typically only used to check
the domain name and nothing else because it is the only thing they care
about and know how to match.

PKI enabled clients in general are used to check numerous of name forms and
attributes in order to determine a match.

When you add SRV-ID to the pool you change what is usual in the case of TLS.

I think it is wrong to say as a general rule that a certificate successfully
maps to the appropriate server if either the SRV-Name or the DNS Name
matches. To me this is highly context dependent where different protocols
and applications have different needs.

If the only thing I need to know is that the server is authorized to deliver
the requested service for the requested domain, then SRVName match only is
OK. If you need to know that this host is the host it claims to be, then
it's not.

What needs to be checked is to me a typical case of local policy and one
size does not fit all.

/Stefan




On 10-09-09 8:11 PM, "Shumon Huque" <[e-mail]> wrote:

> 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.