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

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

On 8/24/10 6:38 PM, Bernard Aboba wrote:
> I reviewed draft-saintandre-tls-server-id-check.

Thanks. To ensure appropriate review, I've copied the discussion lists
of the working groups that were asked to look at this I-D (PKIX and
TLS), as well as the author of draft-daboo-srv-email (which normatively
references this I-D).

> In a number of instances, this document is vague on the verification of
> an SRV-ID, and in one instance, it appears to contradict RFC 4985, even
> though it does not update that document.
> 
> Section 2.1 states:
> 
>    o  An SRV-ID can be either direct (provided by a user) or more
>       typically indirect (resolved by a client) and is restricted (can
>       be used for only a single application).
> 
> 
> This is consistent with RFC 4985 Section 2.1 which states:
> 
>    The SRVName, if present, MUST contain a service name and a domain
>    name in the following form:
> 
>       _Service.Name
> 
> 
> 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.
> 
> [BA]  As I understand RFC 4985, the SRV-ID provided in the target
> certificate is to be
> matched against components (service name and domain name) of the SRV RR
> obtained
> via lookup within the source domain. As a result, I don't believe that
> RFC 4985 is
> consistent with this advice (e.g. the reference identifier is not
> matched against the
> SRV-ID).

I think the issue here is an ambivalence in the assumptions underlying
RFC 4985, because an SRV record can be used for two quite different
purposes:

1. To point from an application service name to a particular host/domain
name in the same administrative domain (e.g., _imap._example.com points
to mailhost.example.com for its IMAP service).

2. To delegate an application service name to a hosting provider outside
in the administrative domain of the application service (e.g.,
example.com delegates its IMAP service to apps.example.net).

(I freely grant that it's not always easy to tell up front which of
these is happening, and that the concept of "administrative domain" is
itself a bit vague -- e.g., what if the same provider runs both
example.com and apps.example.net?)

As I see it, RFC 4985 glosses over the foregoing distinction.

Some folks seem to like the SRV-ID construct because it enables them to
more tightly scope the certificates issued to an administrative domain,
so that they can limit a cert to usage within the context of their email
service or IM service or HTTP service or whatever (the IM cert can't be
used for the email service, etc.). That's the usage Jeff Hodges and I
had in mind for this I-D.

However, the question arises: what is the client supposed to check if an
SRV lookup for _imap._example.com yields apps.example.net? My reading of
RFC 4985 leads me to think that the certificate presented by
apps.example.net is supposed to contain an SRV-ID of _imap.example.com,
which means roughly "this certificate indicates that this provider is
authorized to provide IMAP service for the example.com domain". (How the
certification authority determines that the delegation is indeed
authorized is outside the scope of this I-D.)

That is my reading of RFC 4985 because:

1. RFC 4985 defines "Name" as "The DNS domain name of the domain where
the specified service is located." (In RFC 2782, "Name" is defined as
"The domain this RR refers to.")

2. RFC 4985 states of the name form "_Service.Name" that "The content of
the components of this name form MUST be consistent with the
corresponding definition of these components in an SRV RR according to
RFC 2782."

3. RFC 2782 defines the format of the SRV RR as follows:

   _Service._Proto.Name TTL Class SRV Priority Weight Port Target

Note well that the name form in RFC 4985 is *not* "_Service.Target", it
is "_Service.Name". Using the terminology that Jeff and I defined in
draft-saintandre-tls-server-id-check, this means that the name component
of the SRV-ID is the "source domain", not the "target domain".

Now, perhaps I am horribly mistaken about RFC 4985 and the intent is to
present an SRV-ID of the form "_Service.Target", but if so then I think
that RFC 4985 needs to be revved through a bis draft, because a plain
reading of RFC 4985 would indicate otherwise. Yes, the description of
"Name" in RFC 4985 as "the DNS domain name of the domain where the
specified service is located" might be construed as referring to the
target domain instead of the source domain (although that interpretation
hinges on the meaning of the vague word "located"), but if so then RFC
4985 is changing the definition of "Name" provided in RFC 2782. Given
that (i) RFC 4985 explicitly states that the components of the name form
"_Service.Name" MUST be consistent with the definitions in RFC 2782 and
(ii) RFC 4985 does not update RFC 2782, I think we need to assume that
"Name" in RFC 4985 does not mean "Target" from RFC 2782.

> Section 4.1 is not as clear as it could be on this point, given that it
> talks about both
> matching of the source domain and the target domain:
> 
>    4.  When checking a reference identifier against a presented
>        identifier, the client (a) MUST match the source domain (or, in
>        some cases, target domain) of the identifiers and (b) MAY also
>        match the service type of the identifiers.
> 
>       Implementation Note: Naturally, in addition to checking
>       identifiers, a client might complete further checks to ensure that
>       the server is authorized to provide the requested service.
>       However, such checking is not a matter of verifying the
>       application service identity presented in a certificate, and
>       therefore methods for doing so (e.g., consulting local policy
>       information) are out of scope for this document.

I agree that the text "or, in some cases, target domain" does not
provide enough detail. The concept here is that a user might have
explicitly "authorized" the target domain to provide application
services for the source domain, either through client configuration
(e.g., account setup that specifies an IMAP server of apps.example.net
despite the fact that the DNS domain name portion of the full username
is example.com) or user interaction (overriding an identity mismatch for
the life of the application session or permanently, which is described
as "pinning" in <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>). These
matters are explained in Sections 4.6.3.1 and 5.1 of the I-D, so at the
least I think that the text in Section 4.1 needs to reference those
sections.

Peter

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