Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

[Ben Campbell <[e-mail]>]

I'm jumping in a bit late with some review followup. It's not entirely clear to me where in the thread I should re-insert myself, so I apologize if I bring up stuff that would have been resolved or otherwise obvious at other points in the thread--I'll dig back through and respond further as appropriate.

(And I realize I'm doing lots of arm-waving around whats-really-going-on with URI-IDs and SIP. If we need a higher bandwidth communication, I can be available.)

Comments inline:

On Dec 7, 2010, at 4:14 PM, Peter Saint-Andre wrote:

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

Understood. It may be that the answer is that the use of URI-ID is not sufficiently understood to offer general guidance. OTOH, in the case of SIP, the URI-ID appears to be solely for the purpose of binding a domain name to the service. Otherwise, the use as defined in RFC5922 would be substantially identical to using a DNS-ID. More to the point, RFC5922 does not use URI-ID to specify a user identity, only a host identity. Would you recommend designers of a new protocol to follow that pattern? I note that (unless I missed it) the 5922 doesn't seem to allow for falling back to a dNSName. Is that a reasonable choice for a new protocol to make? (And doesn't this feel a lot like using SRV-IDs?)

Now compare that to HTTP using a DNS-ID. The two are trying to accomplish the same thing, in that they are identifying a domain name, not a resource (in the case of HTTP) or a user (in the case of SIP). Can we generalize anything from that? If we were starting over with either, would we recommend HTTP use URI-ID, or perhaps SIP should not?

I almost wonder if the best thing would be a discussion of what you might could do with URI-ID, with very little normative stuff. If you want to identify a host and service only, here's how. If you want to identify something more like a resource, then do this other thing (or say it''s out of scope). 


> 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:[e-mail] and sips:[e-mail]) 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.

Yeah, that's an interesting one. On reflection, I think RFC 5922 is, again, trying to match  _service_ more than a URI scheme. The service is "sip" regardless of whether you started with a SIPS URI.   When you consider the further complication of TEL URIs (e.g. tel:[phone]), you're _still_ looking for a SIP service. This is pretty much what I think you had in mind in the section 4.3 text on URI_IDs, except that the service is implied by the fact that its a SIP application in the first place, rather than simply copied from some specific URI. 

If this is the correct interpretation of 5922, then the SIPS/SIP equivalence is probably a red herring.  I'd certainly be interested to hear the RFC 5922 author's thoughts on that.

For that matter, I think that XMPP and SIP both needed to accomplish the same thing--match a source domain name and a service. Both SRV-IDs and URI-IDs can do that, but they made opposite choices. I suspect the choices were along the lines of "XMPP doesn't _use_ URIs, and SIP does". But it doesn't seem like SIP is really matching against a URI . And you could just as easily synthesize an XMPP scheme and use URI-IDs--but the awkwardness becomes more obvious there.


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

Right. But this document endeavors to recommend what people should put in their specs for future protocols, right? Or does it just discuss things they need to think about in their specs? I meant the SIP questions as examples. They would probably been better stated as "What should the new FUBAR protocol, which uses URIs and DNS in a way functionally identical to SIP, do?"


The bottom line is, should this draft offer guidance on the best way to match a source domain and service? Or is it to say "here's some ways you can do it, pick one (or some)." I'm okay either way, but it would be best to be explicit.


> 
>> 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 agree, that's the way it is supposed to work for SIP. Do you think that it would be obvious to the hypothetical FUBAR designers whether they should do the same? (I'm not saying it's not--I would need to reread the draft with that in mind, and haven't done so yet.)

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

Is it your expectation that no protocol should try to include other, more resourcey parts of a URI for the purposes of cert matching? Or that that sort of thing should be out of scope?

> 
> (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?

The second, keeping in mine that new scheme design often happens as a part of such an effort, even if the documents are split. (Would cert matching be scheme specific, or protocol specific?)

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

 Recommendations about how to choose between DNS-ID, SRV-ID, and URI-ID would be out of scope for this document, then, right? I think that answers my previous question about how much the draft tries to recommend.

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

Given the previous conversation about how SIP seems to be the only protocol with the equivalent scheme issue that actually uses URI-IDs, and that it doesn't seem to need to worry about which scheme its using at the moment, I no longer think this draft needs to worry about it. If it were to say anything at all along those lines, it would probably need to be along the lines of KISS. For example, I don't think you want designers trying to assert security properties by which scheme they include in a cert (i.e. "foo" vs "foos")

> 
> (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
>   "[e-mail]" 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?

No, I think that's a good one based on the discussion so far. (assuming I am correct in my understanding that you don't expect to ever see protocols match on user or resource information inside the URI.) It might be worth mentioning in the example why the "user@" part is not used.

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

WFM

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

Would it make sense to say something to indicate this is true, even though the connection may have been opened based on a URI of "sip:[e-mail]"? (I'm trying to figure out the best way to word that without trying to invoke SIP request-URI vs route set complexities, but my brain is tired. I will think further about it.)

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

Sure, the reason HTTP does not use is because HTTP isn't specified that way :-)  (i.e. for historical reasons.)

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

I think this is pretty close, modulo previous comments above. I wonder if the fact that SIP appears to abstract the scheme rather than use the scheme of any particular URI is relevant here, or just adds too much complexity to the language.

> 
>> -- 4.3, 4th bullet item:
>> 
>> An example would be helpful here.
> 
> Yep, I propose that we add examples to all of those bullet points:

Ah, okay. I was mainly picking on URI-IDs due to the lack of examples elsewhere. But more examples (almost) never hurt.

> 
> ###
> 
>   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/
> 
> 
>