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

[Stefan Santesson <[e-mail]>]

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.


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

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

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.

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

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.

The client now has assurance from the CA that this host is in fact
authorized to provide this service.


/Stefan