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

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

Hi Ben, thanks for the review.

[ + [e-mail] ]

On 12/3/10 2:24 PM, "Ben Campbell" <[e-mail]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-saintandre-tls-server-id-check-11
> Reviewer: Ben Campbell
> Review Date: 2010-12-03
> IETF LC End Date: 2010-12-16
> 
> Summary: This draft is almost ready for publication as a BCP. I have a few
> questions and comments that I think should be considered first, as well as a
> few editorial comments.
> 
> *** Major issues:
> 
> -- [ 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? Do I put both a
> URI-ID and an SRV-ID in my reference set and/or certificate?  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 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. If so, it might be
> worth mentioning that, and maybe discuss what things the designer of a new
> scheme should keep in mind.

I agree that we need to say more about URI-IDs. I also agree that the
recommendations are probably more technology-specific than for other
identifier types. Jeff and I will work on some text and reply further.

BTW, are you aware of any technologies other than SIP that use URI-IDs?
That's the only one I'm aware of.

> *** Minor issues:
> 
> -- 1.2, last paragraph:
> 
> Nothing normative here? Do we think that protocol designers SHOULD reference
> document instead of rolling their own? For example, would you expect
> additional IESG or SECDIR scrutiny for a new spec that rolls its own rather
> than referenda this? As stated, this paragraph makes it sound like this is
> something designers could use, rather than something designers should use. It
> seems like a BCP might take a stronger position.

If two poor suckers go to the trouble of working up a BCP, I'd hope that
folks would reference it when developing future protocols. But I don't think
putting a few MUSTs and SHOULDs in Section 1.2 is the way to make that
happen.

> -- 1.4.2, 2nd bullet item: "We also do not address identifiers derived from
> Naming Authority Pointer (NAPTR) DNS resource records [NAPTR] and related
> technologies such as [S-NAPTR], since such identifiers cannot be validated in
> a trusted manner in the absence of [DNSSEC]."
> 
> Does that mean validation of a source domain that will be used to construct a
> NAPTR request is out of scope, or just validation against the result of a
> NAPTR query? (I note SIP may require the first).

Another good question. Jeff and I need to research this a bit more before
replying definitively.

> -- 2.3, paragraph 1:
> 
> A DN example might be helpful.

Never enough examples. :) We'll see about adding one here.

> -- 2.3, paragraph 3: "application service is identified by a name or names
> carried in the subject field and/or in one of the following identifier types"
> 
> May be identified, right? Since, as you mentioned earlier, it is common to
> identify a service with a name plus service designator, and only the SRV-ID
> and URI-ID intrinsically do this.

Fixed.

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

Given that a user agent would not connect to sip:example.com or
http://example.com/ via SSL/TLS, it seems appropriate for the certificate to
include only the TLS-aware scheme (sips:, https:, etc.).

> -- 3.1, rule 5: "... unless a profile of this specification... "
> 
> This pattern recurs throughout the document. Can you elaborate on what you
> mean by "profile"? Normally I think of a "profile" as defining a subset of
> choices for some particular application. But if a profile relaxes a
> requirement (i.e. encouraging something that is a SHOULD NOT here), that's not
> really a subset.  Are you referring to an application protocol spec that
> refers to this document? Updates to this document? (I'm not sure if this
> should count as a minor issue or an editorial comment. It depends on whether
> its just a confusion around the word choice, or whether you have something
> specific in mind that I did not grok).

I think it's a terminological issue. By "profile" we mean "a specification
that re-uses this one" -- as, say, draft-ietf-xmpp-3920bis re-uses this I-D.
The relationship is not one of defining a subset, but of being a downstream
customer. Is there a good, single word for that? If not, I think we can say
"Specifications that re-use this one" (ugly, but descriptive).

> -- 3.1, rule 6:
> 
> Can you motivate why this is not a MUST NOT?

Jeff has better numbers on this than I do, but a non-trivial number of
existing certificates contain multiple CN-IDs. In addition, as long as
control over the domain names has been certified then folks on the CertID
list and other reviewers did not see harm in allowing CAs to include those
domain names in CN-ID form, although it's not encouraged to do that.

> -- section 3.2:
> 
> I'd like to see a (non-trivial) URL-ID example.

Yes, we'll work to add that.

> -- 3.2, first example:
> 
> Since we say you SHOULD NOT put the FQDN in a CN-ID, why include it in
> examples? The example does seem to make sense, but it makes me wonder if the
> SHOULD NOT would be better placed on the client verification process not the
> cert generation process.

I think it's better to delete that instance from the first example.

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

This is a matter of extracting the source domain from the input. Naturally
the input itself might be compromised, but "garbage in, garbage out". I
doubt this spec will prevent users from falling for phishing attacks. :)

> -- 4.2.2:
> 
> Can we have a URI-ID example? (and maybe an explanation why the HTTP example
> doesn't use one?)

Yes, we'll add that, following RFC 5922 (although that doesn't have enough
examples to borrow from).

> -- 4.3, 4th bullet item:
> 
> An example would be helpful here.

Yes, this goes along with the other URI-ID examples.

> -- 4.4, rule 1:
> 
> Why not MUST NOT?

Do you mean "why not MUST" (instead of SHOULD) for checking of the service
type?

> -- 5.1:
> 
> Should this doc mention anything about the ability to unpin?

It's probably worth adding a sentence aobut that to the security note in
Section 4.6.4.

> *** Nits/editorial comments:
> 
> -- 1.1, paragraph 1: "...visible face of the Internet consists of services
> that employ a client-server architecture..."
> 
> This seems a little overstated. Client-server applications are certainly
> common, but they don't represent all common uses of the Internet. (Or do I
> misinterpret what you mean by "visible face"?)

You're right, "largely consists" is more accurate.

> "references some conception... of... identity"
> 
> I'm not sure what that means. Can you state this more plainly? Maybe "concept
> of identity" or "idea of identity"? (I realize "conception" can mean
> "concept", but it sounds strained to my mental ear.)

How about "notion"?

> -- 1.2, Paragraph 1: "document does not supersede the rules for certificate
> issuance or validation provided in [PKIX]"
> 
> If this document does not supercede PKIX, then that also means that PKIX is
> authoritative on any point for which is draft may be in conflict with it,
> right?

Yes indeed.

> "Specifically, in order to ensure proper authentication, application clients
> need to verify the entire certification path, because this document addresses
> only name forms in the leaf server certificate, not any name forms in the
> chain of certificates used to validate the server certificate."
> 
> Sentence hard to parse. Can it be broken up or simplified?

I think this is better:

   This document does not supersede the rules for certificate issuance
   or validation provided in [PKIX].  Therefore, [PKIX] is authoritative
   on any point that might also be discussed in this document.
   Furthermore, [PKIX] also governs any certificate-related topic on
   which this document is silent, such as certificate syntax,
   certificate extensions such as name constraints and extended key
   usage, and handling of certification paths.

   This document addresses only name forms in the leaf server
   certificate, not any name forms in the chain of certificates used to
   validate the server certificate.  Therefore, in order to ensure
   proper authentication, application clients need to verify the entire
   certification path.

> -- 1.2, Paragraph 2: "existing application protocols"
> 
> Probably worth tying that to a point in time, as in "application protocols
> that were specified prior to the publication of this BCP"

Fixed.

> -- 1.5, first paragraph: "each entry is preceded by a dollar sign ($) and a
> space."
> 
> I don't see any $'s

Yes, that was an artifact of the editing process. Removed.

> -- 1.5, definition of "delegated domain":  "connecting to the source domain"
> 
> Is connecting to really the term you want here? Maybe "associated with"? In
> the context of this draft, I'm afraid people will think of connection in terms
> of tcp connections, etc.

Changed to "communicating with"

> -- 1.5, definition of "subject name"
> 
> Is there a definition or reference for "composite name"?

Hmm, I don't see anything in RFC 5280, but I'll have to check the X.5**
specs.

> -- 1.6:
> 
> I don't know if it matters, but I usually see contributors and acknowledgments
> sections near the end. It seems sort of abrupt to find them imbedded between
> technical content sections.

This document was not the product of a WG so we probably wanted to show that
it has received wide-ranging reviews. I'm fine with moving that to the end.

> -- 3.1, 1st paragraph:
> 
> It's probably worth emphasizing that the rules are often cumulative.  I think
> someone thinking about these for the first time might not grasp that until
> they see examples later in the doc.

I've added the second sentence to this paragraph:

   When a certification authority issues a certificate based on the
   fully-qualified DNS domain name at which the application service
   provider will provide the relevant application, the following rules
   apply to the representation of application service identities.  The
   reader needs to be aware that some of these rules are cumulative and
   can interact in important ways that are illustrated later in this
   document.

> -- 4.3, implementation note: "although such behavior is not forbidden by this
> document"
> 
> The "SHOULD stop the search" language in previous paragraph implies that you
> SHOULD NOT do this, doesn't it? So while it's not strictly forbidden, it's
> strongly discouraged. The implementation note makes it sound more like it is
> merely out of scope.

It's difference between:

1. Search for X and stop once you've found it.

and

2. Search for X and stop once you've found it. Then search for Y.

> -- 4.3, 4th bullet item
> 
> does the ABNF or URI reference define "reg-name" as well as "scheme"?

Yes. In the URI spec, "reg-name" is an FQDN, not an IP address or mere host
name.

> That 
> seems ambiguous. If not, then it might be helpful to have an expansion,
> definition, or reference for "reg-name".

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

> -- 4.4:  "Furthermore, if the client supports presented identifiers that
> contain the wildcard character ¹*¹, we define a supplemental rule for
> so-called "wildcard certificates".
> 
> I think the definition will stay there regardless of the intent of the client
> :-)  Perhaps something to the effect of "... We define a supplemental
> rule...which may be used by clients that support wildcards."

Heh. Corrected to:

   Furthermore, to meet the needs of clients that support
   presented identifiers containing the wildcard character '*', we
   define a supplemental rule for so-called "wildcard certificates".

Thanks again for your review. Jeff and I will confer regarding open issues
and then reply further.

Peter