Re: [Gen-art] [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11
Peter Saint-Andre <stpeter@stpeter.im> Tue, 07 December 2010 22:13 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: gen-art@core3.amsl.com
Delivered-To: gen-art@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1143328C0F3; Tue, 7 Dec 2010 14:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.497
X-Spam-Level:
X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 3WeIvIPHecQs; Tue, 7 Dec 2010 14:13:06 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1254C28C0F6; Tue, 7 Dec 2010 14:13:06 -0800 (PST)
Received: from dhcp-64-101-72-234.cisco.com (dhcp-64-101-72-234.cisco.com [64.101.72.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E2BE4009B; Tue, 7 Dec 2010 15:26:19 -0700 (MST)
Message-ID: <4CFEB1C5.4010103@stpeter.im>
Date: Tue, 07 Dec 2010 15:14:29 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>
References: <p06240832c922cb7e04d9@[10.20.30.151]>
In-Reply-To: <p06240832c922cb7e04d9@[10.20.30.151]>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030000020508040804050403"
Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, certid@ietf.org
Subject: Re: [Gen-art] [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 22:13:08 -0000
Hi Ben, I've looked again at the URI-ID issue, with special reference to SIP domain certs (RFC 5922) because SIP seems to be the main technology that uses URI-IDs. Some of what follows is me thinking out loud. I'll need to check any tentative conclusions with my co-author. Also, please note that in this I-D Jeff and I have been working to generalize from current practices. That's a bit difficult in the case of URI-IDs because we seem to have only one instance (RFC 5922). I'll ask the PKIX WG if folks are aware of any other "customers" for the uniformResourceIdentifier SAN. On 12/6/10 10:19 AM, Ben Campbell wrote: > -- [ Not so much a "major issue" as a "slightly less minor" one] I'd > like to see more discussion around URI-IDs. These seem to me to be > the most complex ID type to get right, but there are no examples and > limited discussion. Picking on SIP, purely as an example for which I > have a passing familiarity: Would a SIP reference identity match a > SIPS URI-ID in a certificate? RFC 5630 states: SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) refer to the same resource. This requirement is implicit in [RFC3261], Section 19.1, which states that "any resource described by a SIP URI can be 'upgraded' to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely". So the two are interchangeable: a SIPS reference identity can be compared against a SIP URI-ID and vice-versa. However, that equivalence is stipulated by the SIP specs and it is not something we could generalize to all uses of URI-IDs (say, http and https). And RFC 5922 says that the scheme of the presented identifier MUST be sip, not sips, so that's a further SIP-specific wrinkle. > Do I put both a URI-ID and an SRV-ID in > my reference set and/or certificate? That depends. :) A using protocol needs to specify what identifier types are required and recommended for that application type. For example, in draft-ietf-xmpp-3920bis we've specified some guidelines for XMPP server certificates, but the guidelines used in the SIP or HTTP or IMAP community would be different (if those communities ever become "customers" of the server-id-check specification). > How do I handle the fact that I > sometimes need to do a NAPTR query, before the SRV query depending on > whether I know the transport protocol? (I realize SIP already defines > cert ID matching, but what would I do for a new application protocol > URI with similar properties?) I think you would take the input to the NAPTR lookup as the source domain, just as you would for an SRV lookup or an A or AAAA lookup. Potentially there are more complexities in a NAPTR lookup (all that regex fun). Furthermore, the NAPTR result might lead the user agent to then perform an SRV lookup and then an A/AAAA lookup on the result of the SRV lookup (which is why I call it "the NAPTR three-step"). But I think that from the perspective of identity checking it doesn't make a difference how many steps are contained in the resolution process. See previous message. > I wonder if the answer is that such things are scheme specific, and > that its hard to say much about the generic handling of URI-IDs. I think we can say that the client needs to separate the application type aspect of the URI-ID from the the DNS domain name aspect, and we do say that in Section 4.3: ### Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application type portion, as follows: [...] o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "authority" component and the application type portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator); note that this document specifies that a URI-ID always contains an "authority" component whose "host" subcomponent contains a "reg- name" (matching only the "reg-name" rule from [URI] limits verification to DNS domain names, differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain an "authority" component), and that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]). ### The client then follows the rules for matching the DNS domain name portion as specified in server-id-check document. So I think that the URI-ID type is not all that different from the others. (There are complexities caused by URI normalization. I think it's best to point to RFC 3986 regarding such issues, rather than trying to describe them all in this spec.) > If > so, it might be worth mentioning that, and maybe discuss what things > the designer of a new scheme should keep in mind. The designer of a new scheme, or the author of a specification that re-uses the recommendations in the server-id-check document? If the former, I think that's a job for other documents (4395bis?). If the latter, I don't particularly see that we can say much -- this is something that each technology community will need to consider, but really the only choices are: 1. Which of CN-ID, DNS-ID, SRV-ID, and URI-ID do we recommend? 2. Do we allow wildcards? If so, exactly where? > -- 3.1, rule 3: > > What happens when you have multiple schemes that are defined to refer > to the same resource. For example, SIP and SIPS? Does a SIP URI-ID > match an otherwise identical SIPS URI-ID? (Maybe this should be left > to the URI definitions themselves, but it might be worth mentioning > the complication somewhere.) Right, so that is a third choice facing authors of specifications that re-use this one. I propose modifying the relevant paragraph in Section 3.1 as follows: 3. If the service using the certificate deploys a technology in which a server is typically associated with a URI (e.g., this is true of [SIP]), then the certificate SHOULD include a URI-ID; the scheme SHALL be that of the protocol associated with the service type and the "authority" component SHALL be the fully-qualified DNS domain name of the service. A specification that re-uses this one MUST specify whether particular URI schemes are to be considered equivalent (e.g., http and https, or sip and sips as described in [RFC5630]). (But see below, where I propose further modifications to that paragraph to address another issue you've raised.) > -- section 3.2: > > I'd like to see a (non-trivial) URL-ID example. How's this? Consider a SIP-accessible voice-over-IP (VoIP) server at "voice.example.edu" servicing SIP addresses of the form "user@voice.example.edu" and located at a URI of <sip:voice.example.edu>. A certificate for this service would include a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). Is that example "trivial", compared to the other examples in the spec? > --4.2.1, paragraph 3: > > It's probably out of scope, but it might be useful to offer some > guidance on how ensuring the extraction is "not subject to > subversion" is not always trivial. For example, if you got your input > URI by clicking on a link in a phishing email, that can be almost > isomorphic to using a delegation from a non-trusted source. I suggest modifying the relevant paragraph as follows (see the last sentence): The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the "authority" component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking). These considerations apply only to extraction of the source domain from the inputs; naturally, if the inputs themselves are invalid or corrupt (e.g., a user has clicked a link provided by a malicious entity in a phishing attack), then the client might end up communicating with an unexpected application service. > -- 4.2.2: > > Can we have a URI-ID example? How's this? A voice-over-IP (VoIP) user agent that is connecting via SIP to the voice service at "voice.example.edu" might have only one reference identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). > (and maybe an explanation why the HTTP > example doesn't use one?) Well, we happen to know that no one does it that way. :) However, we might need to tighten up the wording here: 3. If the service using the certificate deploys a technology in which a server is typically associated with a URI (e.g., this is true of [SIP]), then the certificate SHOULD include a URI-ID.... Specifically, we might need to say "programatically associated with a URI for security purposes" or somesuch. This I-D is decidedly *not* attempting to modify how existing technologies use PKIX certificates, so it would be improper for us to have a URI-ID example for HTTP. I suggest the following tweaks: 3. If the service using the certificate deploys a technology in which a server is programatically associated with a URI for security purposes (e.g., this is true of [SIP] as specified by [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not describe usage of a URI-ID for HTTP services), then the certificate SHOULD include a URI-ID; the scheme SHALL be that of the protocol associated with the service type and the "authority" component SHALL be the fully-qualified DNS domain name of the service. A specification that re-uses this one MUST specify whether particular URI schemes are to be considered equivalent (e.g., http and https, or sip and sips as described in [SIP-SIPS]). > -- 4.3, 4th bullet item: > > An example would be helpful here. Yep, I propose that we add examples to all of those bullet points: ### Before applying the comparison rules provided in the following sections, the client might need to split the reference identifier into its DNS domain name portion and its application type portion, as follows: o A reference identifier of type DNS-ID does not include an application type portion and thus can be used directly as the DNS domain name for comparison purposes. As an example, a DNS-ID of "www.example.com" would result in a DNS domain name portion of "www.example.com". o A reference identifier of type CN-ID also does not include an application type portion and thus can be used directly as the DNS domain name for comparison purposes. As previously mentioned, this document specifies that a CN-ID always contains a string whose form matches that of a DNS domain name (thus differentiating a CN-ID from a Common Name containing a human-friendly name). o For a reference identifier of type SRV-ID, the DNS domain name portion is the Name and the application type portion is the Service. As an example, an SRV-ID of "_imaps.mail.example.net" would be split into a DNS domain name portion of "mail.example.net" and an application type portion of "imaps" (mapping to an application protocol of IMAP as explained in [EMAIL-SRV]). o For a reference identifier of type URI-ID, the DNS domain name portion is the "reg-name" part of the "authority" component and the application type portion is the scheme name matching the [ABNF] "scheme" rule from [URI] (not including the ':' separator). As previously mentioned, this document specifies that a URI-ID always contains an "authority" component whose "host" subcomponent contains a "reg-name". (Matching only the "reg-name" rule from [URI] limits verification to DNS domain names, thereby differentiating a URI-ID from a uniformResourceIdentifier entry that contains an IP address or a mere host name, or that does not contain an "authority" component at all.). Furthermore, note that extraction of the "reg-name" might necessitate normalization of the URI (as explained in [URI]. As an example, a URI-ID of "sip: voice.example.edu" would be split into a DNS domain name portion of "voice.example.edu" and an application type of "sip" (mapping to an application protocol of SIP as explained in [SIP-CERTS]). ### Again, those are all proposals. Ben, let us know if those address your questions. Jeff, let me know if you disagree with your co-author. :) Peter -- Peter Saint-Andre https://stpeter.im/
- [Gen-art] Gen-ART LC Review of draft-saintandre-t… Ben Campbell
- Re: [Gen-art] Gen-ART LC Review of draft-saintand… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Paul Hoffman
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Ben Campbell
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… Peter Saint-Andre
- Re: [Gen-art] [certid] Gen-ART LC Review of draft… =JeffH