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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 16:35:39 -0600

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" <[email-masked]> 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 [email-masked] 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/

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 01:39:30 +0200

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" <[email-masked]> wrote:

<stuff deleted>

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

> 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

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Sep 2010 11:57:07 -0600

> Thank for the clarifying example. I see now what problem you are addressing.

I'm short on time right now so will reply briefly at the end.

> will have to rely on local configuration in order to accept it.

I'm happy that we're all on the same page and that we only have a spec
error in RFC 4985.

> but nobody caught this error.

Submitting an erratum is a good first step, I think.

Peter

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 9 Sep 2010 14:38:29 -0400

> As it is now, the RFC is ambiguous.

Earlier in RFC 4985, it says:

   The SRVName, if present, MUST contain a service name and a domain
   name in the following form:

      _Service.Name

   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

I think this was actually clear enough. The subsequent statement that
Name is "The DNS domain name of the domain where the specified service
is located." (which could mean any of a number of things) confused the 
issue, and probably should not have been in the document.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 21:36:54 +0200

> issue, and probably should not have been in the document.

Agreed, but since it will be an errata, the text must be corrected.

Do you agree with my proposal?

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 10:18:00 -0600

>      is authorized to provide the identified service."

Authorized by whom? I *think* that here the DNS domain name is one that
the certified subject has itself authorized (perhaps even "established"
is better) to provide the desired service. Therefore I suggest an
alternative wording:

     "A DNS domain name which the certified subject has
      authorized to provide the identified service."

Peter

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

---

From: Shumon Huque <[email-masked]>
Date: Mon, 13 Sep 2010 13:03:39 -0400

>       authorized to provide the identified service."

I don't think the term "authorized" makes the situation any
clearer.

Let's take a concrete example: an IMAP client attempting to
connect to and use the IMAP service at "example.com". 

It needs to lookup the "_imap._tcp.example.com." DNS SRV record 
to figure out which servers and ports to connect to.

And in the presented certificate, it needs to expect to find an 
SRVName identifier with "_imap.example.com" as its contents, 
where the _Service and Name components were the same ones it used 
in the SRV query.

There is no need to figure out who authorized what.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 13 Sep 2010 13:01:13 -0400

>      authorized to provide the identified service."

I don't think that's right either, since it's the *issuer* of the cert  
that's making the assertion.  Maybe something like the following:
"
A DNS domain name for which the issuer authorizes the subject to  
provide the indicated service.
"

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 13 Sep 2010 19:59:03 +0200

> There is no need to figure out who authorized what.

I agree here. Both to this and to former speakers stating that the assertion
is made by the CA and no the subject.

I'm struggling with the most easy to understand text, but I think this says
at least the correct thing:

      "A DNS domain name, representing a domain for which the certificate
       issuer has asserted that the certified subject is a legitimate
       provider of the identified service."

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 12:49:59 -0600

>        provider of the identified service."

+1

---

From: Dave Cridland <[email-masked]>
Date: Mon, 13 Sep 2010 20:12:47 +0100

> is made by the CA and no the subject.
Well, I'd say the assertion is the presence of the SAN in the cert. I  
mean, an assertion is a positive statement made *without* evidence.  
The evidence is then the signature of the issuer, who certifies the  
assertion - it doesn't matter who makes that assertion. But anyway,  
that's somewhat moot, and as Shumon points out, we needn't care about  
who authorized what unto whom.

>        provider of the identified service."

"The requested DNS domain name for the specified service. That is,  
the domain name which would be found in the URI for the service, and  
other protocol identifiers of a similar nature. Where the service is  
directly requested by hostname, this domain name would be the  
requested hostname."

I think that covers all the cases I'd expect by example, without  
worrying about who's asserting and certifying. No doubt someone will  
reword with a sprinkling of 2119.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Shumon Huque <[email-masked]>
Date: Tue, 14 Sep 2010 11:45:12 -0400

> who authorized what unto whom.

Yeah, that's what I meant. Thanks for articulating that more clearly
than I did Dave!

RFC 4985 specifies the SRVName othername form. The act of authorizing
a particular identity to be in a certificate is more related to who
issued and signed the certificate, and the act of verifying that
authorization is related to the client authenticating the signature
of the certificate and building a chain of trust from the issuer back
to a trust anchor that it has configured. 4985 doesn't need to say
any more on that subject since it's already covered by base PKIX specs.

> reword with a sprinkling of 2119.

This particular sub thread is about errata to 4985, right? If so,
I don't think it should mention "URI" or "identifiers of a similar
nature". Or are you proposing more general text for inclusion in
draft-saintandre-tls-server-id-check?

For 4985, I think your first sentence is sufficient by itself.

   "The requested DNS domain name for the specified service."

Or, if we want to elaborate more, I'd suggest:

   "The requested DNS domain name for the specified service. This
    is the "Name" component of the corresponding DNS SRV record."

Actually, what would be really useful is if the document provided an
actual example of an SRV record and and SRVName, right after the
definitions in Section 2. Lack of clear examples is a very common
problem with many IETF specifications.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 14 Sep 2010 19:44:16 +0100

> draft-saintandre-tls-server-id-check?
For 4985. The reason I mention URIs and suchlike is that if someone  
is attempting to verify a certificate for, say,  
xmpp://[email-masked]/, the Name is the domain in the URI, and  
not any intermediate form.

> problem with many IETF specifications.

An example speaks a thousand normative statements, as they say.

Dave.