Subject: Re: [certid] What security does SRV-ID add when DNS-ID will always match?

From: Matt McCutchen <[email-masked]>
Date: Sat, 19 Mar 2011 17:05:31 -0400

On Tue, 2011-01-18 at 11:54 -0800, =JeffH wrote:
>  > Are you saying that a client that "supports checking of identifiers of
>  > type SRV-ID and URI-ID" MUST NOT compare two DNS-IDs, because they do
>  > not contain the service type information that the client is required to
>  > check?  If so, then in the following example:
>  >
>  > Reference identifiers:
>  > 1. SRV-ID _imaps.example.net
>  > 2. DNS-ID example.net
>  >
>  > Presented identifiers:
>  > 4. DNS-ID example.net
>  >
>  > we would get "no match", when it seems a match would be helpful for
>  > backward compatibility.
> 
> 
> I think we may have intended to allow for the latter with the "SHOULD" clause 
> of the 2nd bullet of S6.2.1..
> 
>     o  If a server for the service type is typically discovered by means
>        of DNS SRV records, then the list SHOULD include an SRV-ID.
> 
> ..i.e. if the client wishes to be more lenient in what presented idents it 
> checks against, it could leave the reference SRV-ID off it's list of reference 
> idents to use to check against the presented idents.
> 
> And so the resultant behavior is ambiguous given the way S6.5's "MUST" clause 
> is crafted where it says "If a client supports checking of identifiers of type 
> SRV-ID..."
> 
> It should probably say something like..
> 
>    If a client supports checking of identifiers of type SRV-ID or
>    URI-ID, and identifiers of those type(s) are included in the
>    reference identifier list, then it MUST also check the service type...

This is an improvement.  You could just say "if at least one identifier
of type SRV-ID or URI-ID is included in the reference identifier list",
because presumably clients that do not support them will not add them to
the list.

However, you are still forcing the client to decide in advance whether
to require a service type.  Alternatively, the requirement could apply
if at least one reference identifier /and/ at least one presented
identifier contain a service type.  This would realize the general
principle of providing the highest level of security supported by both
sides.  This will be a more realistic client behavior for applications
currently transitioning to the use of SRV-IDs, though it means those
clients do not get any additional security connecting to a service until
all other certificates for that DNS name contain SRV-IDs.  (Note that
clients for the other services need not actually use the SRV-IDs.)
Applications that used SRV-IDs from the beginning can continue to
require a presented SRV-ID.

Proposed replacement for the text in Section 6.5 preceding Section
6.5.1:

-----
Identifiers of type SRV-ID and URI-ID contain service type information.
Clients are usually designed to communicate with one type of service,
such as websites, email services, VoIP services, or IM services, and can
use this information to check that they are communicating with the
intended service.

If at least one reference identifier and at least one presented
identifier contain service type information, then the client MUST check
the service type of the application service with which it communicates
(in addition to checking the domain name as described above).  That is,
a reference identifier and a presented identifier cannot match unless
they both contain service type information and the service types match,
as described below.  If at least one reference identifier contains a
service type, but no presented identifier does, the client MAY accept a
match of DNS name only for backward compatibility.
-----

I regret sending this at the eleventh hour.  I identified this concern
as soon as I read your message, but I got busy and let the issue slip.
Assuming others agree with this proposed change, if it is too late to go
in RFC 6125, at least it can be queued for the next update.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Mar 2011 14:35:24 -0700

> Proposed replacement for the text in Section 6.5 preceding Section

This document was approved by the IESG months ago and is now in the RFC Editor's queue. It is probably not a good idea to change a major chunk of text at this point.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 20 Mar 2011 15:30:00 -0600

On 3/19/11 3:35 PM, Paul Hoffman wrote:
> This document was approved by the IESG months ago and is now in the
> RFC Editor's queue. It is probably not a good idea to change a major
> chunk of text at this point.

Agreed.

However, I think that we will probably work on a "bis" version at some
point, so it is good to capture these suggestions.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Mar 2011 15:49:15 +0200

Hi Matt, thanks again for your feedback. Comments at end.

> in RFC 6125, at least it can be queued for the next update.

You're right. Jeff and I looked at this issue in detail and worked with
our sponsoring AD (Alexey Melnikov) to address it during AUTH48. This
was a bit challenging because we wanted to keep the changeset as small
as possible. Although we considered more significant modifications, we
ended up doing two things in Section 6.2.1 (which defines the rules for
constructing a list of reference identifiers)...

1. Changed MUST to SHOULD for DNS-ID:

###

  Using the combination of fully qualified DNS domain name(s) and
  application service type, the client constructs a list of reference
  identifiers in accordance with the following rules:

  o  The list SHOULD include a DNS-ID.  A reference identifier of type
     DNS-ID can be directly constructed from a fully qualified DNS
     domain name that is (a) contained in or securely derived from the
     inputs (i.e., the source domain), or (b) explicitly associated
     with the source domain by means of user configuration (i.e., a
     derived domain).

###

2. Added a paragraph clarifying the need for the change from MUST to SHOULD:

###

     Which identifier types a client includes in its list of reference
     identifiers is a matter of local policy.  For example, in certain
     deployment environments, a client that is built to connect only to
     a particular kind of service (e.g., only IM services) might be
     configured to accept as valid only certificates that include an
     SRV-ID for that application service type; in this case, the client
     would include only SRV-IDs matching the application service type
     in its list of reference identifiers (not, for example, DNS-IDs).
     By contrast, a more lenient client (even one built to connect only
     to a particular kind of service) might include both SRV-IDs and
     DNS-IDs in its list of reference identifiers.

###

These changes will be reflected in RFC 6125.

[And yes, we realize that this issue, among others, might need to be
revisited in 6125bis when we work on that someday...]

Peter

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

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 Mar 2011 16:17:14 -0400

>      DNS-IDs in its list of reference identifiers.

Unfortunately, this change does not solve the problem.  Consider the
following three client behaviors with respect to presented identifiers:

1. Accept only an SRV-ID.
2. Accept an SRV-ID or a DNS-ID.
3. Accept a SRV-ID, or accept a DNS-ID if there are no SRV-IDs.

Both the old and new versions of the spec allow #1 and #2, but there is
no way consistent with the spec to achieve #3 because the first sentence
of section 6.2.1 requires that the reference identifier list be
independent the presented identifier list.  And #3 is what is required
for existing applications that use DNS-IDs to transition smoothly to
SRV-IDs and achieve the highest level of security supported by both
sides.  Here is why:

- If a new server is to work with old clients, its certificate must
include a DNS-ID as well as a SRV-ID.
- If a new client is to work with old servers, it must accept a
certificate that contains a correct DNS-ID and no SRV-IDs.
- When a new client connects to a new server, it should achieve the
highest level of security supported by both sides, which in this case
means verification of the service type.  I.e., if a MITM attacker
diverts the connection to a server that has the desired DNS name but
does not provide the desired service type, the connection should fail.
In this case, the client will see a certificate that contains a correct
DNS-ID and one or more SRV-IDs, none of which have the correct service
type, and it should reject the certificate.

(You can replace "SRV-ID" with "identifier that contains service type
information" throughout the above if you like.)

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Mar 2011 23:00:09 +0200

On 3/30/11 10:17 PM, Matt McCutchen wrote:
> sides.

I think that this is a matter of local policy -- a client could prefer
SRV-IDs yet still accept DNS-IDs, and as far as I can see that behavior
is not expressly forbidden by the spec.

However, in order to explicitly specify that the client's behavior would
be modified based on what the server presents, we would have needed to
change the entire processing model from what I call the inclusion
approach (if there is an identifier type that you might want to check
then you simply include it in the list of reference identifiers) to what
I call the conditional approach (the client's processing is conditioned
on the presented identifiers that it finds in the server's certificate).
Although Jeff and I considered making that change, the spec has always
been based on the inclusion approach, so modifying it to use the
conditional approach would have necessitated a very significant rewrite
at this late stage in the lifecycle. Jeff and I, and our responsible AD,
were simply not comfortable with performing such major surgery during
AUTH48.

Peter

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

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 Mar 2011 17:45:07 -0400

> is not expressly forbidden by the spec.

"Prefer" is vague.  Specifically, I would like the client to accept a
DNS-ID if and only if the certificate contains no SRV-IDs.  How is this
accommodated within the framework of the spec?  Clearly the reference
identifier must contain a DNS-ID.  Somehow, this DNS-ID must be
considered to match the presented DNS-ID if and only if the certificate
contains no SRV-IDs.

Section 6.1 says:

   4.  When checking a reference identifier against a presented
       identifier, the client matches the source domain of the
       identifiers and, optionally, their application service type.

Is it within the meaning of "optionally" for the client to elect to
match the service type (thereby preventing two DNS-IDs from matching) if
and only if the certificate contains at least one SRV-ID?  Section 6.5
only describes service type matching in the context of identifiers that
contain service type information.  Is it legitimate to "match the
service type" solely as a means of preventing identifiers that do not
contain service type information from being used?

> at this late stage in the lifecycle.

Right.

> Jeff and I, and our responsible AD,

Sure.  But the alternative is to release the spec with the issue
unresolved and potentially have to later deal with a mess of SRV-ID
clients that achieve suboptimal interoperability and/or security.  Do
you judge that the first evil is lesser?

Obviously I've put you in an awkward situation, which I regret.  That
said, I don't think I'm wrong to frame the decision this way.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 Mar 2011 17:49:58 -0400

> you judge that the first evil is lesser?

Sorry, s/first/second/.

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 30 Mar 2011 23:51:17 +0200

On 3/30/11 11:45 PM, Matt McCutchen wrote:
> identifier must contain a DNS-ID. 

Ah, I see the confusion. MUST has been changed to SHOULD in order to be
consistent with what I have called the inclusion approach. If we were to
change over to the conditional approach, we could have left DNS-ID as
MUST, but as I said in my previous message that would have required very
significant changes to the spec during AUTH48.

If you'd like I can post the full list of changes, but it is midnight
here in Prague and I have a lot of preparation to do for tomorrow's
working group sessions, so I simply don't have time right now.

Peter

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

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 Mar 2011 18:00:12 -0400

On Wed, 2011-03-30 at 23:51 +0200, Peter Saint-Andre wrote:
> consistent with what I have called the inclusion approach.

I'm not referring to the change in the document.  I meant that the goal
of accepting a DNS-ID in the case that the certificate contains no
SRV-IDs is impossible to achieve unless the (fixed) list of reference
identifiers contains a DNS-ID.  With that clarification, consider my
message.

-- 
Matt

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 31 Mar 2011 00:36:04 +0200

On 3/31/11 12:00 AM, Matt McCutchen wrote:
> identifiers contains a DNS-ID.

You are right that, on the inclusion approach, including a DNS-ID in the
list of reference identifiers is the only way to achieve the behavior
you desire. However, in order for the client to vary its behavior based
on the identifiers presented by the server, we would have needed to
modify the spec to use the conditional approach. I'm sure you can
understand that it was simply way too late to perform such major
surgery, two months after IESG approval.

Peter

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

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 Mar 2011 20:07:39 -0400

On Thu, 2011-03-31 at 00:36 +0200, Peter Saint-Andre wrote:
> you desire.

My claim was that including a DNS-ID in the list of reference
identifiers is a necessary condition.  My question of whether the
behavior is actually consistent with the spec stands.

> However, in order for the client to vary its behavior based

I have nothing more to say on this point except that I will trust your
judgment.  Congratulations on the publication of the RFC.  I look
forward to helping to resolve the issue in a future update, if that is
desired.

-- 
Matt