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

From: "t.petch" <[email-masked]>
Date: Mon, 6 Sep 2010 15:37:39 +0200

I realise that this thread has moved on to a question of what RFC4985 means (and
I agree with the conclusions) but I thought that this post was about to raise a
quite different point, that may still need clarifying.

see inline

Tom Petch

----- Original Message -----
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 25, 2010 2:38 AM

I reviewed draft-saintandre-tls-server-id-check.

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

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

Does s5.1 of the I-D mean what it appears to say?

Tom Petch

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.

--------------------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Sep 2010 11:48:52 -0700

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. 

As noted elsewhere, RFC 4985 appears to require matching of the
source domain/service type to the SRV-ID in the certificate.  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).

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Sep 2010 17:25:37 -0700

Peter said:

If that's the logic, I'd at the least like to see a "4985bis" spec make
> that clear, because IMHO it's not spelled out now.
>

RFC 4985 refers to authentication of service discovery in Sections 1 and 2.
Section 1 states:

"

   This document specifies a name form for inclusion in X.509

   certificates that may be used by a certificate relying party to
   verify that a particular host is authorized to provide a specific
   service within a domain.

   RFC 2782 [N3] defines a DNS RR (Resource Record) for specifying the

   location of services (SRV RR), which allows clients to ask for a
   specific service/protocol for a specific domain and get back the
   names of any available servers.

   Existing name forms in X.509 certificates support authentication of a

   host name.  This is useful when the name of the host is known by the
   client prior to authentication.

   When a server host name is discovered through DNS RR lookup query
   based on service name, the client may need to authenticate the

   server's authorization to provide the requested service in addition
   to the server's host name.

   While DNS servers may have the capacity to provide trusted
   information, there may be many other situations where the binding

   between the name of the host and the provided service needs to be
   supported by additional credentials.

   Current dNSName GeneralName Subject Alternative name form only
   provides for DNS host names to be expressed in "preferred name

   syntax", as specified by RFC 1034 [N4].  This definition is therefore
   not broad enough to allow expression of a service related to that
   domain.

"

Section 2 states:

"

   Even though this name form is based on the service resource record
   (SRV RR) definition in RFC 2782 [N3] and may be used to enhance
   subsequent authentication of DNS-based service discovery, this
   standard does not define any new conditions or requirements regarding

   use of SRV RR for service discovery or where and when such use is
   appropriate.

"

---

From: "t.petch" <[email-masked]>
Date: Wed, 8 Sep 2010 10:09:16 +0200

[TP]inline

----- Original Message -----
From: "Bernard Aboba" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, September 06, 2010 8:48 PM

[TP]  Right, I see what you mean.

The DNS resolution I had in mind, if it is a resolution, is that while the
interactive user had specified a DNS name and that name had been fed into a DNS
Query, then the SRV record had been returned as an Additional RR, not as an
Answer, and that the Name from this Additional RR was now being used as the
source domain for the purposes of this I-D.  Which section 5.1 might be trying
to preclude.

Tom Petch
============================================

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 Sep 2010 16:21:15 +0200

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" <[email-masked]> 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:
> 
> This puzzled me as well. The domain of interest is the domain where the
> requested service is located = target domain.
> 
>> 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
> Since this is not the definition of SRVName, this type of matching does not
> apply.
> 
>> 
>>> Yet, Section 5.1 states:
>>> 
> 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
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 8 Sep 2010 08:44:56 -0700

So the statement that "RFC 4985 appears to require matching of the source
domain/service type to the SRV-ID in the certificate" is correct, right? 

If the "reference identifier" is  _Service.Name then the match is being done
on the *input* to the SRV lookup process, not the output, and prohibition on
DNS lookups would not apply (or even make any sense). 

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

My apology,

/Stefan

On 10-09-08 3:40 PM, "Stefan Santesson" <[email-masked]> wrote:

> This puzzled me as well. The domain of interest is the domain where 
> the requested service is located = target domain.
> 
>> 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:
>>> 
>>> [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
>>>    the user inputs in an automated fashion (e.g., ... discovered 
>>> through DNS resolution ... "
>>> 
> 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
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 Sep 2010 15:40:08 +0200

Comments in line;

      _Service.Name

<snip>

      Name

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.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 Sep 2010 19:28:07 +0200

For clarity, I'll provide two examples where I think it is motivated to
obtain the FQDN reference identifier in an automated fashion and not through
direct user input or configuration (contrary to section 5.1).

1) Obtaining EU Trusted Lists
EU has standardized on XML based lists over national Trust Service Providers
and their certificates. Each country in the EU publish their own list.
The EU commission provides a central list with all the URLs to each national
list.

The first step is for the client to establish a secure connection with the
EU commission and download the EU list. This is done by configuration.

The second step is to automatically obtain reference identifiers for all
national lists from the EU list.

2) Redirects from a trusted service.
If I connect to a trusted service and then get redirected to another host,
it can be reasonable to obtain the reference identifier from the rediricet.
Typical application I can think of is a redirect to a SAML IdP or a SAML
Discovery service.

/Stefan

On 10-09-08 4:21 PM, "Stefan Santesson" <[email-masked]> wrote:

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

---

From: Shumon Huque <[email-masked]>
Date: Wed, 8 Sep 2010 15:53:49 -0400

> domain/service type to the SRV-ID in the certificate" is correct, right? 

I think so. It seems pretty obvious to me from Section 2 that's
what is meant:

	http://tools.ietf.org/html/rfc4985#section-2

ie. take the "Service" and "Name" components of the SRV record
owner name (and ignore the _Proto component), and construct 
"_Service.Name".

> DNS lookups would not apply (or even make any sense). 

Yes.

The output of the SRV record lookup contains a target hostname,
not a service name, so it's not applicable to the SRVName name
form. The target could be used in another name form (dNSName)
as the reference identifier, but then the client needs to convince
itself that the lookup was done securely (DNSSEC or some other
means) otherwise there's a security problem.

-- 
Shumon Huque
University of Pennsylvania.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 08 Sep 2010 23:08:29 +0200

> means) otherwise there's a security problem.

I disagree,

A client can use the output from the DNS lookup also from a normal insecure
DNS server.

The only thing the client need to do is to verify that the domain name
provided in the input to the lookup matches the host names provided in the
output. It can then safely use the host names in the SRV record as reference
identifiers IF the SRV-ID in the server certificate matches the the
reference identifier.

A false host represented by a false identifier from a bad DNS server will
not be able to present a trusted certificate that supports it's claim to be
an authorized provider of the requested service for the domain in question.

/Stefan

---

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

> direct user input or configuration (contrary to section 5.1).

Thanks for the examples.

> Typical application I can think of is a redirect to a SAML IdP or a SAML

It seems to me that in both of these cases, the user has placed trust in
a certain entity (the EU's system of trust service providers, a
particular trusted service) and has configured his or her application
client to allow that entity to transform a source domain into a
target-domain-based reference identifier for the purposes of secure
connection. (One could argue that DNSSEC might result in a similar
arrangement.)

Would the following text address the scenarios you mention?

###

5.1.  Service Delegation

   When the connecting application is an interactive client, the source
   domain name and service type SHOULD 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 SHOULD 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.

   There are several scenarios in which it can be legitimate for an
   interactive client to override the recommendation in the foregoing
   rule.  Examples include:

   1.  A human user has explicitly configured the client to associate a
       particular target domain with a given source domain (e.g., for
       connection and identity checking purposes the user has explicitly
       approved "apps.example.net" as the target domain associated with
       a source domain of "example.com").

   2.  A human user has explicitly agreed to trust a service that
       provides mappings of source domains to target domains, such as a
       dedicated discovery service or an identity service that securely
       redirects requests from the source domain to a target domain
       (however, such an arrangement is not encouraged and if a client
       supports such a service then it needs to disable it by default
       and carefully warn the user about the possible negative
       consequences of trusting such a service).

###

I'm quite leery of these identity mapping services you have mentioned; I
can see that some people might trust them, but I think we need to
encourage clients to clearly and forcefully warn users about them,
because trusting such a service means handing over a great deal of power.

/psa

---

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

> source domain for the purposes of this I-D.  Which section 5.1 might be trying

Aha, I see the source of confusion. I think the first sentence of
Section 5.1 is better written as follows:

   When the connecting application is an interactive client,
   construction of the reference identifier SHOULD be based on the
   source domain and service type 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 SHOULD NOT be based on a
   target domain 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).

We want to make sure that the reference identifier is based on the
source (user-provided) domain, not the target (automatically-derived)
domain, except perhaps in several well-defined and carefully-limited
scenarios.

Peter

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 8 Sep 2010 15:29:31 -0700

Peter said:

"Aha, I see the source of confusion. I think the first sentence of Section 5.1 is better written as follows:

We want to make sure that the reference identifier is based on the source (user-provided) domain, not the target (automatically-derived) domain, except perhaps in several well-defined and carefully-limited scenarios.

Peter"

[BA] IMHO, this text is much clearer.  Thanks!

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

---

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

>          The DNS domain name of the domain where the specified service

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.

> Since this is not the definition of SRVName, this type of matching does not

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")?

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

> believes is authorized to provide a specific service in the target domain.

Believes on what basis?

> information or whether that information is trustworthy.

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

> matches the information provided from the DNS server, then everything is

For some definition of "fine", yes.

> 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: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 16:49:33 -0600

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

Because the user is trying to connect to (say) a source domain of
example.com, not a target domain of apps.hosting.net. Jeff and I have
assumed all along that normal humans don't know anything about such
hosting services or other delegated parties (heck, normal humans know
very little about SSL/TLS or certificates or DNS resolution or any of
the other magic that happens behind the scences, but we assume that
normal humans at least think they want to connect to bigbank.com and not
possiblyshadydelegationservice.info).

Peter

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 00:59:29 +0200

Peter,

I don't see the problem with accepting a host names provided by DNS SRV
record as the reference identity.

Could you elaborate the threat?

Example:

I ask the DNS for the host providing smtp services for example.com
I get back that the following hosts are available

smtp1.example.com, and;
smtp2.example.com

I contact the first one using a TSL connection and receives a server
certificate with the SRVName _smtp.example.com and the dNSName
smtp1.example.com

The certificate confirms that the host in fact is smtp1.example.com and that
it is authorized to provide smtp services for the domain example.com.

That is all you need. The host name from the DNS server was setting you on
the track but is not considered trusted. What you trust is the names in the
certificate.

As to IdP services. This type of redirect is extremely common and widely
deployed in SAML. 

Example: The client connects to a service by choice. That service is
retrieving the metadata for the identity federation from a central database.
Among other things this metadata contains URLs to all approved Identity
provides (IdP) in the federation.

In order to allow the user to select the appropriate IdP service the user
may first be directed to a SAML discovery service (often called WAYF =
"Where Are You From"). The WAYF service redirects the user back to the
original service with information about the selected IdP. The Service
locates the IdP from the metadata and redirects the user to its IdP for
identification. The user is then handed a ticket (SAML assertion) and gets
redirected back to the service with the ticket.

Again, this is very common and designed and has undergone thorough security
reviews in a very large community.

I think it is very bold of the IETF to claim that SAML got it wrong and
should not be allowed.

Unfortunately, for these reasons I still don't think the proposed text is
satisfactory

/Stefan

On 10-09-09 12:01 AM, "Peter Saint-Andre" <[email-masked]> wrote:

>>>>>> is all about information gotten from a DNS retrieval whereas the wording
>>>>>> of
>>>>>> s5.1
>>>>>> in this I-D
>>>>>> 
>>>>>> "the source

---

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: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 01:45:41 +0200

On 10-09-09 12:10 AM, "Peter Saint-Andre" <[email-masked]> wrote:

>    source domain and service type provided by a human user

Could we remove "and service type" from that sentence.
It is the domain name that is the problem and not the service type right?

I mean, the app may very well know that it is supposed to talk to an XMPP
service without asking a human user.

/Stefan

---

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

> service without asking a human user.

Yes, that change makes sense.

Peter

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

---

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:11:37 -0400

> the track but is not considered trusted. What you trust is the names in the

This is a more complicated example than the current draft
addresses.

In your example, the client is verifying "a combination of 
identifiers" (SRVName and dNSName) in the certificate. This
seems like a reasonable thing to do, but this is not what
most clients do today (I'd be happy to be corrected about
that). Typically, they consider a match successful once they've
found a single acceptable reference identifier. In that case,
you can't simply use a reference identifier that contains
a DNS mapped identifier unless you've obtained it an authenticated
(or statically configured) manner.

---

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

> identifiers IF the SRV-ID in the server certificate matches the the

This only works if the certificate matching rules say something 
like "match the SRVName AND also match the DNS resolved target
hostname in dNSName". If a client attempts to match _only_ the DNS 
resolved hostname without DNSSEC, there is a security problem.

The question is: what should the certificate matching rules say
when encountering a certificate with multiple identity types?
Right now the draft approximately says "find a match" (ie. find
ANY match), rather than match some logically AND'ed combination of 
identity types.

  http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4

---

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:

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

---

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

On the issue of checking multiple name forms.

I would put it in another way. Web clients are typically only used to check
the domain name and nothing else because it is the only thing they care
about and know how to match.

PKI enabled clients in general are used to check numerous of name forms and
attributes in order to determine a match.

When you add SRV-ID to the pool you change what is usual in the case of TLS.

I think it is wrong to say as a general rule that a certificate successfully
maps to the appropriate server if either the SRV-Name or the DNS Name
matches. To me this is highly context dependent where different protocols
and applications have different needs.

If the only thing I need to know is that the server is authorized to deliver
the requested service for the requested domain, then SRVName match only is
OK. If you need to know that this host is the host it claims to be, then
it's not.

What needs to be checked is to me a typical case of local policy and one
size does not fit all.

/Stefan

---

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: Shumon Huque <[email-masked]>
Date: Thu, 9 Sep 2010 16:08:33 -0400

> about and know how to match.

Not just Web, but likely the various other applications listed 
in the appendix of draft-saintandre-tls-server-id-check also
(IMAP, POP3, LDAP, ..)

> attributes in order to determine a match.

Can you give us some examples of such applications, and where 
their subject identity matching rules are specified? Appendix
A ("Prior Art") probably should consider them.

> and applications have different needs.

Yeah, I think I agree with that. Ultimately the application protocol
should decide what its (potentially arbitrarily complex) identity
matching rules should be. This is why I'm suspicious that the current
draft can successfully achieve it's supposed goal of defining some
general purpose rules or best practices.

One of the ideas was that application protocol designers often
don't want to be concerned with the complex details of certificate
matching and verification rules and would like to refer to some 
standard document that does.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 09 Sep 2010 22:55:08 +0200

Shumon,

> A ("Prior Art") probably should consider them.

Right now I have none that is applicable to the listed protocols. So I don't
think I have an example that is suitable for this annex.
But in general many government services using PKI are comparing multiple
attributes. Many national PKIs in Europe have banned single identifiers in
their certs, so the applications are forced to do multiple attribute
comparisons.

The thing is that name comparison is often done on an application level
according to local policy and even on the user level and the only thing I
have learned after spending 18 years with PKI is to expect almost anything
:)

In this context, EKUs are often also an important part of certificate
acceptance. A dimension that I miss in the current spec.

I don't think it is particularly useful to specify in generic documents what
constitutes a positive identification of the subject in terms or required
matching name forms.
It becomes useful mostly only when you want to achieve interoperability
within a reasonably narrow context.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Thu, 9 Sep 2010 23:10:35 +0200 (MEST)

> means) otherwise there's a security problem.

I'm feeling very uneasy with the suggestion that a DNSSEC instead
of the DNS lookup might make it less of a security problem.

DNSSEC provides only data integrity protection and data origin
authentication of the records, and NOTHING beyond that.  In particular,
it does _NOT_ provide any trust in the conveyed information.

But in order to avoid the mentioned security problem, trust in the
transformation is an absolute prerequisite for the name transformation
in order to use the result in any kind of endpoint identity verification.

Although I personally think the trustworthiness of the rootCA certs
in web browsers is significantly overrated, there seems to be some
understanding out there that there is a huge difference between
cryptographic protection and trust, so there are browser vendors that
require CAs to apply a certain amount of scrutiny before issuing
certificates and subject themselves to an audit for a non-negligable
amount of cost before the browser vendors are going to include the
CAs self-signed rootCA cert as pre-trusted with their browser.

Are DNS domain admins going to be required to apply as much scrutiny
for each and every DNS record in their zone and have to succeed a
comparable audit of their DNS record maintenance procedures before
their parent domain will sign their zone signing keys?

DNS is an important an vital part of the internet, and it needs to
remain fast, efficient and free in order to remain useful.
Besides, even if DNSSEC signed records are being made available
in increasing numbers, that information is not visible to >90% of
the end users of the internet (like DSL subscribers) and is going to
remain invisible for most of them for many years to come.

-Martin

---

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

>   http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4

Hi Shumon,

As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server identities. Do we have evidence that any existing
certification authorities issue certificates containing both an SRVname
for the source domain (e.g., example.com) and dNSName for the target
domain (e.g., apphosting.example.net)? Do we have evidence that any
existing application clients perform such checks? If not, I would
consider such complications to be out of scope for this I-D.

That said, we need to be aware that if such usage arises in the future,
someone might write a document that updates or obsoletes this I-D; in
fact the present authors very much expect that such documents will
emerge after the Internet community (specifically certification
authorities, application service providers, and application client
developers) have gained more experience with PKIX certificates in the
context of various application technologies.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Sep 2010 09:17:01 -0700

>consider such complications to be out of scope for this I-D.

A big +1 here. It is a Good Thing that people are starting to look at the interaction between SRV and security (it's also happening on the keyassure list), but it definitely seems like "starting to look at". Please do not instantiate anything until this has been discussed more widely.

--Paul Hoffman, Director
--VPN Consortium

---

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 12:52:59 -0400

On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote:
> application server identities.

Yes, but whether they are actually "current" best practices is 
debatable. I certainly would like them to become best practices.
For example I don't believe any existing commercial CAs issue 
certificates with the SRVName or URI SAN name forms.

> Do we have evidence that any existing

I think the question is whether we have examples of applications 
that need to verify "combinations" of subjectaltname name forms in 
certificates. Stefan says there are, but so far no-one has offered
up any public specifications of such apps. So, I think until we 
have them, I agree we can defer considerations of them to future 
documents.

I think it's reasonable for this draft to consider multiple identity
types in certificates (eg. common name, dNSName, SRVName) with the
current matching rules of ANY. This might be needed to gradually
transition an app from validating a host specific identity to an
application specific identity. The current draft allows this.

> context of various application technologies.

Sounds reasonable.

---

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: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 11:03:24 -0600

> certificates with the SRVName or URI SAN name forms.

As far as I know, at least one CA will issue certificates with the
SRVName form (for XMPP certificates). We could ask some folks in the SIP
community if any CAs issue certificates with the URI form (see
draft-ietf-sip-certs).

> have them, I agree we can defer considerations of them to future 

Agreed. I've never seen this I-D as the final word, but instead as the
beginning of a longer-term conversation, both about the limited topic
that's covered in the I-D as well as all the topics we deemed out of scope.

> application specific identity. The current draft allows this.

Correct.

>> context of various application technologies.

I'm looking forward to further work in this area.

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: Dave Cridland <[email-masked]>
Date: Mon, 13 Sep 2010 18:05:11 +0100

> certificates with the SRVName or URI SAN name forms.
They do, I've seen sRVName SANs in some XMPP server certificates.

> application specific identity. The current draft allows this.
Isode M-Link will check xmppAddr and dNSName (and I'll add in sRVName  
soonish, and possibly URI). If no SANs of a supported type exist,  
then it will fall back to a CN match.

It will not check the dNSName against the result of a SRV DNS lookup,  
ever, nor will it check a dNSName if it has already found a matching  
xmppAddr (nor vice-versa). As such it's not checking combinations of  
SANs.

Looking at the draft, it seems to read that I should check dNSName  
first, and then, only if this matches, check xmppAddr or sRVName.  
This seems odd - sRVName and xmppAddr (and URI) all contain a  
superset of the data contained, so why look at dNSName if a more  
specific match exists?

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: 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: Stefan Santesson <[email-masked]>
Date: Mon, 13 Sep 2010 20:39:43 +0200

Peter,

> context of various application technologies.

I would like to turn the question around and ask why this specification need
to have an opinion on whether a relying party feels he have to check both
host name and service?

I'm not against describing the typical case, as long as this specification
does not imply that a relying party that has a reason to check two name
types is doing something wrong.

I have no extremely good examples of practical implementation here but
checking both host name and service seems like both extremely easy and good
practice.

/Stefan

---

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

On 9/13/10 11:05 AM, Dave Cridland wrote:
> soonish, and possibly URI). If no SANs of a supported type exist, then
> it will fall back to a CN match.
> 
> xmppAddr (nor vice-versa). As such it's not checking combinations of SANs.
> 
> first, and then, only if this matches, check xmppAddr or sRVName. This
> seems odd - sRVName and xmppAddr (and URI) all contain a superset of the
> data contained, so why look at dNSName if a more specific match exists?

Earlier versions of this draft had somewhat elaborate rules about
ordering of reference identifiers. Those rules were removed in -09
because folks on the [email-masked] list argued persuasively that they
were not necessary because "first match wins" is good enough. Naturally,
an implementation might have a preference order of reference
identifiers, but such an order is not mandated by this I-D.

Peter

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

---

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 13:16:57 -0600

> to have an opinion on whether a relying party feels he have to check both

Stop right there. :) I sense a possible source of confusion. What do you
mean by "host name" and what do you mean by "service"?

In this I-D, we talk about "DNS domain name" and "service type", which
map quite well to _Service.Name from RFC 4985: the DNS domain name is
the "source domain" provided by the user or configured into the client
(e.g., "example.com") and the "service type" is a given application
protocol that could be serviced by the source domain (e.g., "IMAP").

This I-D is attempting to gently nudge people in the direction of
checking both the DNS domain name and the service type. IMHO this is
consistent with considering the SRVName and uniformResourceIdentifier
subjectAltName entries as more tightly scoped than dNSName or CN, and
therefore as potentially more "secure" in some sense (the subject might
want to limit use of a particular certificate to only the service type
identified in the SRVName or uniformResourceIdentifier).

If by "host name" you mean "target domain" as defined in the I-D (and
mapping to "Target" from RFC 2782) then we have more to discuss.

> types is doing something wrong.

That is not the intent of this I-D, however that would be functionality
over and above what this I-D defines.

> checking both host name and service seems like both extremely easy and good

With respect to revisions to this I-D, the lack of good examples
troubles me because we have been trying to abstract from common usage,
not to define guidelines for use cases that have not yet been defined,
implemented, and deployed.

Given that you would prefer to leave the door open to more advanced
checking rules, I think you would object to this text in Section 4.3:

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  It does so
   by seeking a match and stopping the search if any presented
   identifier matches one of its reference identifiers.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.

You are saying that it is not necessarily appropriate to stop the search
once a single match is found, because the client might be configured to
look for multiple matches (e.g., a match against both the source domain
and the target domain). Would you like to suggest text that covers such
a case? Here is a possible rewrite of Section 4.3 that might address
your concern.

###

4.3.  Seeking a Match

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.  The search succeeds if any presented
   identifier matches one of the reference identifiers, at which point
   the client SHOULD stop the search.

      Implementation Note: A client might be configured to perform
      multiple searches, i.e., to match more than one reference
      identifier; although such behavior is not forbidden by this
      document, rules for matching multiple reference identifiers are a
      matter for implementation or future specification.

      Security Note: A client MUST NOT seek a match for a reference
      identifier of CN-ID if the presented identifiers include an
      SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
      entry types supported by the client.

   Detailed comparison rules for finding a match are provided in the
   following sections.

###

Peter

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

---

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

On Mon Sep 13 19:48:56 2010, Peter Saint-Andre wrote:
> This

Ah, I see my confusion. §4.4 says:

4.4. Verifying a Domain Name

   The client MUST match the source domain of a reference identifier
   according to the following rules

And §4.5 says:

4.5. Verifying an Application Type

   A client SHOULD check not only the domain name but also the service
   type of the service to which it connects.

Now, I misconstrued that to mean "MUST use dNSName, SHOULD use  
sRVName", which is purely me misreading.

Up to you whether you think other people will be as silly as me, and  
what to do about it if so.

Dave.

---

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

On 9/13/10 1:18 PM, Dave Cridland wrote:
> Now, I misconstrued that to mean "MUST use dNSName, SHOULD use sRVName",
> which is purely me misreading.
> 

A forward reference seem appropriate:

   The client MUST match the source domain of a reference identifier
   according to the following rules (and SHOULD also check the service
   type as described under Section 4.5).

Peter

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

---

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

>    type as described under Section 4.5).

Spot on.

Dave.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 02:03:39 +0200

Peter,
Comments in line;

> mean by "host name" and what do you mean by "service"?
Sorry for sloppy use of words.

With host name I mean here the actual DNS name of the host, which might be
host1.example.com (dNSName)

By service I mean the service under a given domain, which for the same host
might be _xmpp.example.com (SRVName)

Under the current rules, using this example I read it that the following
apply:

- If you are just checking the SRVName you will not learn the legitimate
host DNS name. So a certificate issued to host2.example.com will be accepted
even if you intended to contact host1.example.com (even if that information
is in the cert).

- If you just check the dNSName, you will miss the fact that you talk to the
desiganted ldap server and not the xmpp server (even if that information is
in the cert).

>    Detailed comparison rules for finding a match are provided in the

This sounds better to me.

If I'm not totally wrong in my example above I also think it would be good
with a security note stating that an SRVName may not provide the full host
DNS name, and if it is important to verify the host DNS name, you must
verify the dNSName in addition to what else you are checking.

/Stefan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 13 Sep 2010 21:32:42 -0600

> Comments in line;

Ditto.

> host1.example.com (dNSName)

Or which might be apphost37.example.net or whatever...

> might be _xmpp.example.com (SRVName)

OK.

But what does dNSName=host1.example.com + SRVName=_xmpp.example.com
actually mean? I see three possibilities:

1. "Connect to example.com's XMPP service only if it's hosted on
host1.example.com"

2. "Don't connect to host1.example.com if you are looking for something
other than example.com's XMPP service" (i.e., if you want the IMAP
service or anything else at example.com, terminate the connection)

3. "The connection is fine if you're looking for (a) any service at
host1.example.com, *or* (b) example.com's XMPP service"

In my experience running the XMPP ICA for a few years, I found that our
root CA would issue dNSName=example.com + SRVName=_xmpp.example.com but
not dNSName=host1.example.com + SRVName=_xmpp.example.com (i.e., the
name in both dNSName and SRVName was the same). Yes, that is anecdotal,
but I think it makes some sense, because IMHO a CA is not going to "get
involved" with the particular machine that hosts a service (i.e., to
differentiate between the DNS domain name of the application service and
the DNS domain name of the hosting machine / provider).

> host DNS name. 

Are there any application clients today that would check only the SRVName?

> So a certificate issued to host2.example.com will be accepted

In what sense does the application client "intend" to contact
host1.example.com? The user controlling a client (a browser or an email
client or an IM client or whatever) intends to contact example.com, not
host1.example.com or apphost37.example.net or whatever.

> desiganted ldap server and not the xmpp server (even if that information is

Correct. If that is a problem in your user community or operating
environment, then you need to find a better client.

IMHO it is almost a best practice for the DNS domain names in the
various presented identifiers of the certificate (dNSName, SRVName,
uniformResourceIdentifier, etc.) to be the same. I think we in the
Internet community don't yet have enough experience to say that with
high confidence, which is why I'm not ready to push on the point in this
I-D. However, let us consider the example of a delegated domain, such as
dNSName=apphost37.example.net + SRVName=_xmpp.example.com, which might mean:

1. "Connect to example.com's XMPP service only if it's hosted on
apphost37.example.com"

2. "Don't connect to apphost37.example.com if you are looking for
something other than example.com's XMPP service" (i.e., if you want the
IMAP service or anything else at example.com, terminate the connection)

3. "The connection is fine if you're looking for (a) any service at
apphost37.example.com, *or* (b) example.com's XMPP service"

In this case, I think #3 is clearly wrong because the user doesn't know
anything about apphost37.example.net and doesn't intend to connect to
that host.

#1 and #2 are close to equivalent, because they attempt to establish a
firm association between a host name (apphost37.example.net) and an
application service (example.com's XMPP service). Is that association
desirable? I'm not convinced (mainly because, to reiterate, I think that
end users don't know or care about the hosting provider or machine).
However, for such an association to be helpful, we'd need (i) clients
that consistently check both identifier types and (ii) CAs that certify
both the application service and the hosting provider. Further, I think
we'd also need (iii) a well-defined semantic that says dNSName is used
to represent the DNS domain name of the hosting provider or machine --
and as far as I can see dNSName does not have that meaning. Given that
we don't have (i), (ii), or (iii), I question the need for this line of
thinking.

> verify the dNSName in addition to what else you are checking.

See above. You and I seem to continually run aground on a disagreement
over whether it makes any sense for an application client (or the user
thereof) to know of, care about, or verify the DNS domain name of the
hosting machine / service / provider. That's the basis for our previous
discussion about RFC 4985 and it's the basis for our current discussion
about dNSName vs. SRVName. I simply don't understand why a normal human
user of an application client would ever want or need to be aware of the
hosting provider for a given application service, why a CA would want to
certify an association between a hosting provider and a given
application service, or why we would ever assume that the dNSName is
meant to identify the hosting provider whereas the SRVName is meant to
identify the application service. Cementing such an association in those
three ways is outside the scope of this I-D, even if one accepts the
premise that such an association is a good idea (which I don't). Can we
agree to disagree here and, rather than add a note about the security
features of such an association, instead add a note to Section 1.3.2
("Out of Scope") explaining why any possible association between the
application service and the hosting machine / service / provider is out
of scope for this I-D? Perhaps in the future we will have advanced far
enough to define best practices for such associations, but right now it
seems to me that we lack a firm basis for doing so.

Peter

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 08:41:11 +0200

Peter,

I'm not driven by any desire to mandate more complex name comparison than is
called for. I just tend to think that it is better leave name comparison
requirement up to local policy.

However I think your argumentation is reasonable here and you convinced me.
I agree that in the general cases you are not interested in the host DNS
name.

I've decided that I'm perfectly fine with your proposed wording.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 14 Sep 2010 08:51:27 +0200

Peter,

After the past discussions, the remaining things on my review list are:

General:
consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI
systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively
include [PKIX] brackets to clarify that it references RFC 5280.

General: 
I would consider stating that server certificates according to this profile
either MUST or SHOULD have the serverAuth EKU set since it is allways
related to the use of TSL and server authentication. At least it MUST be set
when allowing checks of the CN-ID (see 2.3 below).

1.3.2 and section 3
SRVName is described as an extension in 1.3.2, but is in fact a Subject Alt
Name (otherName form) RFC 4985.
This error is repeated in section 3, bullet 4, on page 16.
 
1.1. 
s/an application services/an application service
 
1.2
I find the following text is hard to understand:
³(this document addresses only the DNS domain name of the application
service itself, not the entire trust chain)²
I¹m not sure what the DNS domain name has to do with checking the entire
trust chain. Further, this document discuss more name forms than the DNS
domain name.
Perhaps this sentence was meant to say:
"(this document only addresses name forms in the leaf server certificate,
not any name forms in the chain of certificate used to validate the server
certificate)"

2.3
It would be good if we could restrict the use of CN-ID for storing a domain
name to the case when the serverAuth EKU is set. Requiring the EKU reduce
the probability that the CN-ID appears to be a domain name by accident or is
a domain name in the wrong context.
 
In many deployments, this also affects the name constraints processing to
perform domain name constraints also on the CN attribute.
 
There should at least be a rule stating that any client that accepts the CN
attribute to carry the domain name MUST also perform name constraints on
this attribute using the domain name logic if name constraints is applied to
the path. Failing this requirement poses a security threat if the claimed
domain name in CN-ID violated the name constraints set for domain names.

4.4.3 checking wildcard labels
The restriction to match against only one subdomain seems to not be
compatible with FRC 4592. RFC 4592 states:
 
   A wildcard domain name can have subdomains.  There is no need to
   inspect the subdomains to see if there is another asterisk label in
   any subdomain.
 
Further, I'm pretty sure that the rule of this draft is incompatible with
many deployments of wildcard matching. I recall in Microsoft we allowed any
number of subdomains when I was involved with the CAPI team.

4.6.2 
States:
 
   In this case, the
   client MUSTverify that the presented certificate matches the cached
   certificate and (if it is an interactive client) MUST notify the
   user if the certificate has changed since the last time a secure
   connection was successfully negotiated
 
How does the client know if the certificate has changed or whether it just
obtained an unauthorized certificate?
 
I guess in some cases it would work but I feel sure there are exception
cases where the client just has a configured certificate but no knowledge of
what it obtained the last time it talked to the server.

/Stefan

---

From: Dave Cridland <[email-masked]>
Date: Tue, 14 Sep 2010 08:58:49 +0100

> even if you intended to contact host1.example.com (even if that  
But I don't care about the legitimate hostname. All I care about is  
that my TLS endpoints are me, and the service I wanted. What hostname  
that service happens to be delivered on is entirely immaterial. If I  
*did* care about that, I'd surely also want to verify the IP address,  
and then I'd want to verify the MAC address, and then the CPUID, and  
then...

Surely if an sRVName (or equivalent) fully matches, this is  
sufficient to verify that the contacted host is authorized to provide  
that service for that domain?

> desiganted ldap server and not the xmpp server (even if that  
Kind of. The rules effectively mean that dNSName is treated as a  
sRVName with a wildcard service type, as I understand it.

> verify the dNSName in addition to what else you are checking.

I don't see any time when it's desirable, from a security  
perspective, to check the host name in addition to the service domain  
name.

Dave.

---

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Sep 2010 16:17:16 -0600

On 9/14/10 1:58 AM, Dave Cridland wrote:
> Kind of. The rules effectively mean that dNSName is treated as a sRVName
> with a wildcard service type, as I understand it.

That's a good way to put it.

Peter

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

---

From: "t.petch" <[email-masked]>
Date: Thu, 16 Sep 2010 16:15:48 +0200

----- Original Message -----
From: "Peter Saint-Andre" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>
Sent: Monday, September 13, 2010 9:16 PM

> identified in the SRVName or uniformResourceIdentifier).

<tp>
Ah, that explains a lot; I knew I smelt a rat, I just did not realise how big it
was:-) It is fine if you want to nudge Certificate Authorities into issuing
certs with SRVName but you should put that up front, in the Abstract eg
"This memo encourages Certificate Authorities to issue certificates with SRVName
names"

Otherwise people are likely to expend effort on this memo which will turn out to
be unproductive; as this thread has established, SRVName do exist, but not in
many places, which makes this memo of rather limited scope.

I wondered why the emphasis on server names had grown and grown, in the I-D and
on this thread, an emphasis which to me seemed a distraction and irrelevance,
and now I see why; nothing wrong, just needs making this explicit.

Tom Petch

</tp>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 10:21:38 -0600

> After the past discussions, the remaining things on my review list are:

Jeff and I would like to thank you for sticking with us as we slowly
work through the feedback we've received. Comments inline.

> include [PKIX] brackets to clarify that it references RFC 5280.

Jeff and I would prefer to define "PKIX" in the terminology section and
then use that definition as the basis for the terms "PKIX-based system"
and "PKIX certificate".

We propose to define "PKIX" as follows:

   PKIX is a short name for RFC 5280 [PKIX], which comprises a
   profile of the X.509v3 certificate specifications and X.509v2
   certificate revocation list (CRL) specifications for use in the
   Internet.

> when allowing checks of the CN-ID (see 2.3 below).

Jeff and I are still discussing this topic and do not yet have editorial
agreement about how to proceed.

> This error is repeated in section 3, bullet 4, on page 16.

Fixed.

> s/an application services/an application service

Fixed.

> not any name forms in the chain of certificate used to validate the server

That's better. Thanks for the text.

> domain name in CN-ID violated the name constraints set for domain names.

See above; Jeff and I are still discussing this topic.

>    inspect the subdomains to see if there is another asterisk label in

Speaking for myself, not for Jeff, I think the entire notion of a
subdomain is suspect and very poorly defined, which is why the XMPP WG
did away with it in rfc3920bis. For example, is foo.co.uk a subdomain of
co.uk? No. And I think we really don't want to pull in a normative
reference to the public suffix list in this specification!

> number of subdomains when I was involved with the CAPI team.

It also seems to me that allowing recursive wildcards (e.g., allowing
*.*.example.com via *.example.com) is a major expansion beyond RFC 2818
or current verification methods.

Jeff would like to check the relevant specifications (all of the specs
in the "Prior Art" appendix) and the previous discussion threads on the
[email-masked] list before coming to a conclusion on this matter.

> obtained an unauthorized certificate?

If the client has lost its cache then it simply needs to proceed as
described under "Case #3: No Match Found, Uncached Certificate".

> what it obtained the last time it talked to the server.

Is your concern about caching the certificate or keeping track of what
the client received the actual "last time" it connected? The mention of
"last time" is meant to ensure continuity of checking, not to force the
client to keep track of particular connection attempts. Therefore in our
working copy we have changed that paragraph to read:

   If the client finds no presented identifier that matches any of the
   reference identifiers but a human user has permanently accepted the
   certificate during a previous connection attempt or via configured
   preferences, the certificate has already been cached.  In this case,
   the client MUST verify that the presented certificate matches the
   cached certificate; if the presented certificate does not match the
   cached certificate then the client MUST proceed as described under
   Case #3 below.

Thanks again for your feedback.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 10:33:03 -0600

> and now I see why; nothing wrong, just needs making this explicit.

Thanks for your feedback. As a way of orienting the reader, Jeff and I
are discussing the possibility of adding a section to the introduction
that provides an informational overview of the recommendations contained
in the document.

Peter

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 09:44:13 -0700

>agreement about how to proceed.

This is not editorial, this is definitely technical. What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating.

> > a domain name in the wrong context.

That makes no sense from an operational standpoint. The inclusion of an EKU has nothing to do with the decision-making for the domain name location.

>> perform domain name constraints also on the CN attribute.

True, and irrelevant.

>> domain name in CN-ID violated the name constraints set for domain names.

Fully disagree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 11:58:49 -0600

On 9/22/10 10:44 AM, Paul Hoffman wrote:
>>> General: I would consider stating that server certificates
>>> according to this profile either MUST or SHOULD have the
>>> serverAuth EKU set since it is allways related to the use of TSL
>>> and server authentication. At least it MUST be set when allowing
>>> checks of the CN-ID (see 2.3 below).
>> 
>> Jeff and I are still discussing this topic and do not yet have
>> editorial agreement about how to proceed.
> 
> This is not editorial, this is definitely technical. 

Sorry, by "editorial agreement" I meant consensus between the document
editors about how we think it's best to address the issue that Stefan
raised. Jeff and I have discussed many of the issues that have been
raised, but haven't yet had a chance to discuss this one.

> What possible
> advantage is there to making certificates that do not have this flag
> set be excluded from the practices you are defining? That is, if a
> TLS client gets a certificate from a TLS server that the TLS server
> says is its authentication certificate, why should the client care
> whether or not that flag is set? That flag is an assertion from the
> CA, not from the server who is authenticating.
> 
>>> 2.3 It would be good if we could restrict the use of CN-ID for
>>> storing a domain name to the case when the serverAuth EKU is set.
>>> Requiring the EKU reduce the probability that the CN-ID appears
>>> to be a domain name by accident or is a domain name in the wrong
>>> context.
> 
> That makes no sense from an operational standpoint. The inclusion of
> an EKU has nothing to do with the decision-making for the domain name
> location.
> 
>>> In many deployments, this also affects the name constraints
>>> processing to perform domain name constraints also on the CN
>>> attribute.
> 
> True, and irrelevant.
> 
>>> There should at least be a rule stating that any client that
>>> accepts the CN attribute to carry the domain name MUST also
>>> perform name constraints on this attribute using the domain name
>>> logic if name constraints is applied to the path. Failing this
>>> requirement poses a security threat if the claimed domain name in
>>> CN-ID violated the name constraints set for domain names.
> 
> Fully disagree.

Thanks for your input. Our little editors team will take your comments
under advisement during our discussion of this open issue. :)

Peter

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

---

From: Martin Rex <[email-masked]>
Date: Thu, 23 Sep 2010 18:13:44 +0200 (MEST)

>>> domain name in CN-ID violated the name constraints set for domain names.

I do agree with Paul that something is very wrong about this paragraph.

What it seems to request is that dNSName SAN name constraints ought
to be performed on CN-ID if server endpoint identification is
performed with CN-ID.

Since there is a requirement to use (issue) DNS-IDs in server certs,
and a requirement to ignore CN-ID when DNS-ID is present, such a
name constraints processing scheme looks awkward to me.

Name Constraints (and its processing) is something that is specified
in PKIX Internet Certificate and CRL profile (rfc-5280 and its
predecessor rfc-3280) plus some ISO-specs (btw. are these publicly
available anywhere), and that is normally implemented entirely within
the certificate path validation of the PKI software.

The BCP for server endpoint identification with TLS is something,
that according to the last sentence of section 1 of all TLS specs
is a matter of the application on top of TLS.

A CA with name constraints for DNSName SANs (required critical according
to rfc5280, mind you) in its own CA certificate that issues TLS server
certificates without dNSName SANs yields "fubar" on my scorecard.

The support of CN-IDs is "legacy" and retained for backwards
compatibility with the installed base.

Those that need the backwards compatibility will _not_ disable
the matching fallback if DNSName SANs are present, and they're
even more unlikely to adopt such a weird name constraints
processing of a fallback they shouldn't be doing in the 
first place and keep doing only to not interfere with
installed base.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 22 Sep 2010 19:36:20 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Hoffman
> Sent: Wednesday, September 22, 2010 9:44 AM
> To: Peter Saint-Andre; Stefan Santesson
> Cc: IETF cert-based identity; [email-masked]; [email-masked]
> Subject: [TLS] Why require EKU for certid?
> 
> >> I would consider stating that server certificates according to this
> >> profile either MUST or SHOULD have the serverAuth EKU set since it is
> >> allways related to the use of TSL and server authentication. At least
> >> it MUST be set when allowing checks of the CN-ID (see 2.3 below).
> >
> This is not editorial, this is definitely technical. What possible
advantage is
> there to making certificates that do not have this flag set be excluded
from the
> practices you are defining? That is, if a TLS client gets a certificate
from a TLS
> server that the TLS server says is its authentication certificate, why
should the
> client care whether or not that flag is set? That flag is an assertion
from the CA,
> not from the server who is authenticating.
> 
> > > 2.3
> > > It would be good if we could restrict the use of CN-ID for storing a
> > > domain name to the case when the serverAuth EKU is set. Requiring
> > > the EKU reduce the probability that the CN-ID appears to be a domain
> > > name by accident or is a domain name in the wrong context.
> 
> That makes no sense from an operational standpoint. The inclusion of an
EKU
> has nothing to do with the decision-making for the domain name location.
> 
> > > processing to
> >> attribute to carry the domain name MUST also perform name constraints
> >> on this attribute using the domain name logic if name constraints is
> >> applied to the path. Failing this requirement poses a security threat
> >> if the claimed domain name in CN-ID violated the name constraints set
for
> domain names.

I also agree that this is not something that I would ever like to see as a
required element.  Applying name constraint logic in places that it should
not be performed is something that is very hard on any certificate
evaluation logic.

I think it would be much more an issue of "asking" CAs not to issue
certificates that have this characteristic.

Jim

> 
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 23 Sep 2010 10:43:50 -0700

On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote:

>> [..snip..]

> What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating.

Does this point need discussion?  Without checking, I suspect that 5280 says you obey the EKU, period.  OTOH I think Paul raises a valid point.

OTOH (again) one could argue that the EKU provides a way to prevent a stolen cert/key issued to the machine for a different function from being repurposed to support a fake server.  (I'm not convinced this is significant, but it's something.)

Absent discussion and consensus, I vote for whatever 5280 says, which I suppose is what the current silence on the topic equates to.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]