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

[Matt McCutchen <[e-mail]>]

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