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

[Matt McCutchen <[e-mail]>]

On Wed, 2011-03-30 at 15:49 +0200, Peter Saint-Andre wrote:
> 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.
> 
> ###

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