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

=JeffH <Jeff.Hodges@KingsMountain.com> Tue, 18 January 2011 19:51 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373113A6E5D for <certid@core3.amsl.com>; Tue, 18 Jan 2011 11:51:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.081
X-Spam-Level:
X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmMgtzcTDEhQ for <certid@core3.amsl.com>; Tue, 18 Jan 2011 11:51:46 -0800 (PST)
Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id CE5753A6EE1 for <certid@ietf.org>; Tue, 18 Jan 2011 11:51:41 -0800 (PST)
Received: (qmail 31324 invoked by uid 0); 18 Jan 2011 19:54:19 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 18 Jan 2011 19:54:19 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=8CKlpv7g6GuGazzmqL6EFRa2xG5FVeVnTE9bp+WHLcsXtBK/IpMy42XvJkhDYZ9Loz+9KS1J9sQ4m49XSHLpPSyA3wMR0dl9xOCo8SVpEL2wvVlwB3WF2uV/aV1WgcUN;
Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.134]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1PfHdD-0004xI-4f for certid@ietf.org; Tue, 18 Jan 2011 12:54:19 -0700
Message-ID: <4D35EFE7.4060209@KingsMountain.com>
Date: Tue, 18 Jan 2011 11:54:15 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: IETF cert-based identity <certid@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [certid] What security does SRV-ID add when DNS-ID will always match?
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jan 2011 19:51:47 -0000

 > On Mon, 2011-01-17 at 11:57 -0800, =JeffH wrote:
 > [...]
 >
 >>  > - The examples of server certificates that include a SRV-ID (section
 >>  > 4.2) also include a DNS-ID
 >>  > - The server ID check succeeds if any reference identifier matches any
 >>  > presented identifier (section 6.3)
 >>  >
 >>  > it would appear that the DNS-IDs will always match, making the service
 >>  > types in the SRV-IDs irrelevant.  Am I right?
 >>
 >> thx for the headsup, but I don't think so, see section 6.5...
 >>
 >> ###
 >>
 >> 6.5. Matching the Application Type Portion
 >>
 >>
 >>     If a client supports checking of identifiers of type SRV-ID and
 >>     URI-ID, it MUST also check the service type of the application
 >>     service with which it communicates (in addition to checking the
 >>     domain name as described above).
 > [...]
 >> ###
 >
 > Maybe I am misunderstanding how that section applies.  Let's consider an
 > example.
 >
 > Reference identifiers:
 > 1. SRV-ID _imaps.example.net
 > 2. DNS-ID example.net

However, according to 3d bullet of S6.3, the client would effectively do this 
with #1..

  1.  _imaps.example.net =>  DNS domain name portion: "example.net"
                             service type portion:    "imaps"

..before proceeding with seeking a match.


 > Presented identifiers:
 > 3. SRV-ID _xmpp-server.example.net

Also, the spec implies that the client would effectively do this with #3..

  3. SRV-ID _xmpp-server.example.net => DNS domain name portion:
                                                         "example.net"
                                        service type portion:
                                                         "xmpp-server"

(the spec could probably be more clear about this)


 > 4. DNS-ID example.net
 >
 > The client checks each reference identifier against each presented
 > identifier (section 6.3).
 >
 > #1 and #3: The service types differ, so no match.
 > #1 and #4: One identifier specifies a service type and the other
 > doesn't.  The behavior in this case is not spelled out, but I would
 > assume there is no match.
 > #2 and #3: Ditto.
 > #2 and #4: Neither identifier specifies service type, and the DNS names
 > are the same.  Is this a match?  If so, we get the problem I originally
 > described.

The matching details in this example isn't exactly what is intended by the spec 
(but is perhaps not presented as clearly as it should be). I've added details 
here..

#1 and #3: first, the DNS domain name portions "example.net" match. However, 
the service type portions of "imaps" and "xmpp-server" don't match (we note in 
the spec that one ought to ignore the "_" char in SRV-ID service type 
portions). So #1 & #3 don't match.

#1 and #4: first, the DNS domain name portion "example.net" match, but #4 
doesn't have a service type portion so no match.

#2 and #3: same as #1 and #4.

#2 and #4: the DNS domain name portions "example.net" match.

   However, the "MUST" clause in S6.5 quoted above holds and thus this
   match between #2 and #4 is insufficient on its own to declare a match.


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


so yes, good catch, thanks,

=JeffH