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

[Peter Saint-Andre <[e-mail]>]

On 9/8/10 7:40 AM, Stefan Santesson wrote:
> Being the author of RFC 4985 I agree with most of you say here.
> 
> Comments in line;
> 
> On 10-09-06 8:48 PM, "Bernard Aboba" <[e-mail]> wrote:
> 
>> That was in fact my original question.
>>
>> Section 5.1 states that the source domain and service type MUST be
>> provided by a human user, and can't be derived.  Yet in an SRV or
>> DDDS lookup, it is not the source domain that is derived, it is the
>> target domain.  Given that, it's not clear to me what types of DNS
>> resolutions are to be discouraged.
>>
> 
> This puzzled me as well. The domain of interest is the domain where the
> requested service is located = target domain.
> 
>> As noted elsewhere, RFC 4985 appears to require matching of the
>> source domain/service type to the SRV-ID in the certificate.
> 
> 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

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.

>>  Such
>> a process would be consistent with a match between user inputs
>> (the source domain and service type) and the presented identifier
>> (the SRV-ID).  
>>
> 
> Since this is not the definition of SRVName, this type of matching does not
> apply.

Again: is the definition of SRVName in RFC 4985 consistent with RFC 2782
(i.e., 4985 "Name" is 2782 "Name") or is it inconsistent with RFC 2782
(i.e., 4985 "Name" actually is 2782 "Target")?

>>> Yet, Section 5.1 states:
>>>
>>> When the connecting application is an interactive client, the source
>>>    domain name and service type MUST be provided by a human user (e.g.
>>>    when specifying the server portion of the user's account name on the
>>>    server or when explicitly configuring the client to connect to a
>>>    particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
>>>    the user inputs in an automated fashion (e.g., a host name or domain
>>>    name discovered through DNS resolution of the source domain).  This
>>>    rule is important because only a match between the user inputs (in
>>>    the form of a reference identifier) and a presented identifier
>>>    enables the client to be sure that the certificate can legitimately
>>>    be used to secure the connection.
>>>
>>>    However, an interactive client MAY provide a configuration setting
>>>    that enables a human user to explicitly specify a particular host
>>>    name or domain name (called a "target domain") to be checked for
>>>    connection purposes.
>>>
>>> [TP] what I thought was about to be raised here was a contradiction that
>>> RFC4985
>>> is all about information gotten from a DNS retrieval whereas the wording of
>>> s5.1
>>> in this I-D
>>>
>>> "the source
>>>    domain name and service type  ...  MUST NOT be derived from
>>>    the user inputs in an automated fashion (e.g., ... discovered through DNS
>>> resolution ... "
>>>
>>> would appear to exclude DNS resolution.  If DNS resolution is off limits,
>>> then
>>> RFC4985 would appear not to apply.

See my previous note. This text needs to be clarified as I suggested, so
that it talks about whether the reference identifier is based on the
source domain or the target domain. This I-D is attempting to forbid or
at least strongly discourage basing the reference identifier on the
target (derived) domain. If RFC 4985 allows the presented identifier to
be the target domain as a matter of course then I think we have a problem.

> RFC 4985 provides the client with a way to authenticate a host that it
> believes is authorized to provide a specific service in the target domain.

Believes on what basis?

> It does not matter from where the client has obtained that authorization
> information or whether that information is trustworthy.

That's a strange statement to make in the context of security.

> A client may very well do an insecure DNS lookup to discover what host is
> providing the requested service. The client would then contact that host and
> obtained it's certificate. If the certificate is trusted and it's SRVName
> matches the information provided from the DNS server, then everything is
> fine.

For some definition of "fine", yes.

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

Peter

-- 
Peter Saint-Andre
https://stpeter.im/