Re: Review of draft-saintandre-tls-server-id-check

[Stefan Santesson <[e-mail]>]

Peter,

Thank for the clarifying example. I see now what problem you are addressing.

Comments in line;

On 10-09-09 12:35 AM, "Peter Saint-Andre" <[e-mail]> wrote:

<stuff deleted>

>> It is not. RFC 4985 says the following in section 2:
>> 
>>       _Service.Name
>> 
>> <snip>
>> 
>>       Name
>>          The DNS domain name of the domain where the specified service
>>          is located.
> 
> Perhaps some examples would help.
> 
> The good folks at example.com have delegated their IM service to
> apps.hosting.net. When the user [e-mail] does an SRV lookup
> for _xmpp-client._tcp im.example.com, its client gets back something
> like this:
> 
> 20 0 5222 apps.hosting.net.
> 
> The client resolves apps.hosting.net to an IP address and connects to
> that machine.
> 
> During TLS negotiation, the application service for example.com (which
> is in fact being serviced by apps.hosting.net) presents a certificate
> that contains an SRV-ID. Which of the following is it?
> 
> 1. _xmpp.example.com
> 
> or:
> 
> 2. _xmpp.apps.hosting.net
> 

According to the actual intent of RFC 4985 the right answer is 1, however
reading the definition of the name form it suggests 2, since this is where
the service is located. However I think this is an error in RFC 4985. See
below.

In case of 2, If the DNS fooled you, then you may end up at an authorized
service for hosting.net that has no business serving example.com, and you
have no way to tell.


> If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in
> RFC 2782.
> 
> If #2, then the "Name" in _Service.Name is actually a "Target" as
> defined in RFC 2782.
> 


>> The client now has assurance from the CA that this host is in fact
>> authorized to provide this service.
> 
> To use my example, the CA is providing assurance that apps.hosting.net
> is authorized to provide the XMPP service on behalf of example.com. That
> seems reasonable if the presented identifier based on the source domain
> (example.com). However, if the assurance is checked on the client side
> by finding _xmpp.apps.hosting.net as the presented identifier then I
> fail to understand something very basic: how does the client tie that
> SRV-ID to the source domain (example.com) in a secure fashion? The
> presented identifier seems to be a mere assertion without any connection
> whatsoever to the source domain.

I actually think we made an error in 4985 and that the domain name should be
the domain that the service is authorized to represent.

RFC 4985 is ambiguous here: the definition of the name form says:

   "The DNS domain name of the domain where the specified service
    is located."

This corresponds to #2 in your example
While the description underneath the definition states:

   "The purpose of the SRVName is limited to authorization of service
    provision within a domain."

Which corresponds to #1.

I think there should be an errata correcting the definition to be:

   "The DNS domain name of a domain for which the certified subject
    is authorized to provide the identified service."

As it is now, the RFC is ambiguous.

> If we just wave our hands and say "the
> client can simply let the user believe that it's OK for apps.hosting.net
> to assert a right to provide the IM service for example.com and it
> doesn't matter if there is no basis for that belief because the
> information might not be trustworthy" then I wonder what RFC 4985 really
> accomplishes or whether we want to encourage anyone to use the SRVName
> extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna).
> 

I agree. But if we can correct the definition (or specify a new OID for a
corrected name form) according to my proposal above, and clarify the use in
your document, would that help in any way?

I agree that if the SRVName in the cert provides a domain name that is
different from the domain name you asked for (and it's not DNSSEC), then you
will have to rely on local configuration in order to accept it.

I'm not sure how we should fix this. We had quite large review of this RFC
but nobody caught this error.

/Stefan