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

[Peter Saint-Andre <[e-mail]>]

Thanks, Ben.

In general, I think this document is describing the tools available to
protocol designers, not telling protocol designers which tools to use.

More comments inline.

On 12/7/10 5:10 PM, Ben Campbell wrote:
> 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? 

Well, this document is about host ("application service") identity, so
user identity is conveniently out of scope.

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

I think not. IMHO the fallback is a good idea.

> (And doesn't this feel
> a lot like using SRV-IDs?)

Yes.

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

Yes, and I think that's what our text is doing. Or trying to.

> If you want to
> identify something more like a resource, then do this other thing (or
> say it''s out of scope).

The latter.

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

Yes, we really care about the combination of DNS domain name and
application type. That can be represented via SRV-IDs or URI-IDs.

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

I think we're saying "here's some ways you can do it, pick one" (either
SRV-ID or URI-ID, with DNS-ID as a fallback).

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

This document says "if you use a SRV-ID (or URI-ID or DNS-ID), here's
how to represent and verify it".

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

I think it should be out of scope.

Let's imagine that the HTTP community decided to use URI-IDs. Even if
the URI-ID in a certificate were http://www.example.com/foobar.html, a
client would need to connect to the IP address resolved for
www.example.com in order to retrieve foodar.html. Here again, it's the
application service that matters.

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

Yes, we were not thinking that this document would provide guidelines
about how protocol designers would choose between identifier types.

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

Well, I do think a using protocol does need to specify which URI scheme
names are acceptable for the application protocol. You wouldn't want a
client to think that fubar://example.com identifies a SIP service. The
tel: URI scheme is an interesting counter-example in some ways.

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

Because [e-mail] is not an application service. :)

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

What do you mean by "the connection was opened based on a URI of
sip:[e-mail]"? Yes, the client might know that it is
configured for an account with that URI, but in order to communicate
with the application service it will need to resolve the DNS domain name
(and application type) to an IP address. So that's the reference
identifier. The presented identifier in the certificate will also be of
the form sip:domain, not sip:user@domain.

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

Yep. :)

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

My first thought it that it adds too much complexity, but I'll consider
it further tomorrow.

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

Feedback is welcome on that text.

Peter

--
Peter Saint-Andre
https://stpeter.im/