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" <stpeter(_at_)stpeter(_dot_)im> 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 someone(_at_)example(_dot_)com 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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf