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

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

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

On 3/19/11 10:05 PM, Matt McCutchen wrote:
> 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.

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/