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

[Bernard Aboba <[e-mail]>]

Here's a forwarded message from the author of RFC 4985:



-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Wednesday, September 08, 2010 7:21 AM
To: Bernard Aboba; [e-mail]; [e-mail]; [e-mail]
Subject: Re: Review of draft-saintandre-tls-server-id-check



My apology,



I just realized that the document defines "source domain" as what I thought
would be the "target domain"



   source domain:  The fully-qualified DNS domain name that a client

      expects an application service to present in the certificate.



Which makes my comments below a bit wrong.



I think it would be better to discuss this in terms of "reference
identifier" and "presented Identifier".



   presented identifier:  An identifier that is presented by a server to

      a client within the server's PKIX certificate when the client

      attempts to establish a secure connection with the server; the

      certificate can include one or more presented identifiers of

      different types.



   reference identifier:  An identifier that is used by the client for

      matching purposes when checking the presented identifiers; the

      client can attempt to match multiple reference identifiers of

      different types.



I see no problem in obtaining the reference identifier from a DNS lookup an
the comparing it with a presented identifier in the certificate.



Why would you require the reference identity to be provided by a human user?



/Stefan







On 10-09-08 3:40 PM, "Stefan Santesson" <[e-mail]> 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.

>

>

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

>