Re: [TLS] review of draft-saintandre-tls-server-id-check-09

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

Wes, thank you for reviewing this document. Jeff and I provide replies
inline using the editorial "we".

On 9/13/10 9:58 PM, Wes Hardaker wrote:
> 
> I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good
> document and support it's forward progress.  I do have a few comments
> though:
> 
> (*):
>   Applies to many of the comments below: some parts of the document
>   read like a BCP in the way it tries to rationalize things.  A number
>   of these text sections really don't help the document, though, as it
>   adds unneeded ambiguity.  Examples of this are marked below with (*).
> 
> Section 1.1: (*)
>   I don't think you should be spelling out the popularity of TLS vs
>   DTLS.  While it may be true today, this is intended to be a proposed
>   standard and thus doesn't need to specify that one is potentially more
>   popular than the other.  The document should be targeting the use of
>   both regardless of how well DTLS is used at the moment.  Suggested:
> 
>   OLD:
>                                   When a client connects to an
>     application services using Transport Layer Security [TLS] (or, less
>     commonly, Datagram Transport Layer Security [DTLS]), it references
>     some conception of the server's identity while attempting to
>     establish a secure connection (e.g., "the web site at example.com").
> 
>   New:
>                                   When a client connects to an
>     application services using Transport Layer Security [TLS] or
>     Datagram Transport Layer Security [DTLS], it references some
>     conception of the server's identity while attempting to establish a
>     secure connection (e.g., "the web site at example.com").

Fixed in our working copy.

> Section 1.1 and the appendices:
>   You could now, if you wanted, add SNMP over (D)TLS: RFC5953.  If
>   you're going to copy into the appendix as well, the text to copy is
>   from the snmpTlstmAddrTable object in that document.

Thanks for the pointer; we'll incorporate some of the text from RFC 5953
into our "Prior Art" appendix.

> Section 1.3.2: (*)
>   This section is full of text that is subjective and really isn't
>   needed in the first place.  

The authors have lost count of how many times commenters have said "why
doesn't this spec talk about X and Y and Z?" We think it's valuable to
explain why the scope is as limited as it is, in part to motivate others
to work on specs about X and Y and Z.

> Nearly every paragraph contains text that
>   may be true today but might not be in the future 

Clearly we can't write about the future yet. However, we fully expect to
update this document once the Internet community has gained more
experience with the technologies under discussion. That "C" in BCP does
stand for "current". :)

> or is subject to
>   interpretation.  While I agree with most of the conclusions, I don't
>   think it's worth putting the text into the document; especially when
>   the text is simply defining what's out of scope.  I don't think you
>   need to spend effort rationalizing what's out of scope.

We do. See above.

>   Suggestion: keep the bullets, ditch the paragraphs.
> 
>   Phrasing examples (IE, an incomplete list) that are questionable:
> 
>     "service operators have less experience with client certificates"
> 
>     "Most fundamentally, most users find DNS domain names much easier to
>     work with than IP addresses, which is why the domain name system was
>     designed in the first place.
> 
>     "Furthermore, application technologies have less experience with
>     IPsec than with TLS, thus making it more difficult to gather
>     feedback on proposed best practices."

Those statements seem to us like truisms at this point in the evolution
of the Internet.

> Section 1.4, "Target Domain"
>   It took me far too long into reading this document to remember what a
>   "target domain" really meant.  IMHO, a better term that already
>   conveys the proper meaning to most readers would be a "derived
>   domain".  Think about a global search and replace for target->derived?

We borrowed the term "target" from RFC 2782, because in DNS SRV records
the "target" is the result of an automated lookup for what we're calling
a "source domain". However, we tend to agree with you that "derived
domain" probably captures the concept better, so are looking into
changing it (we haven't yet made that change because we want to be sure
it doesn't have implications we haven't had time to consider).

> Section 3, bullet 5:

That is:

   5.  The certificate SHOULD NOT represent the server's fully-qualified
       DNS domain name in a CN-ID, even though many deployed clients
       still check for this legacy identifier configuration within
       certificate subject name.

>   Unfortunately, this is the one rule I think will be
>   broken the most often.  Fortunately, checking from the client side
>   says to ignore the CN-ID if it can match on other things as well.
>   Because of this, the only thing this particular rule hurts is the
>   software that isn't going to conform to this document because the code
>   is already too old.  It's basically a "should upgrade" statement.  I
>   think an extra sentence here might be helpful, though I don't have a
>   suggestion at the moment.

Jeff and I are discussing what text to add here.

> Section 4.3, security note:
>   I actually think wording these things is tricky when the future is
>   unknown. 

Is there a time when the future is not unknown? ;-)

> I think it's generally safer to describe the only conditions
>   which are valid for checking a CN-ID instead of trying to list all the
>   "MUST NOT" cases, which is more likely to change with the addition of
>   future specs into the spec tree. 

Sure, which is why we expect to update this document when reality has
changed enough to justify the effort.

> I didn't have time to fully think
>   out replacement text, but I'd start it with "A client MUST only seek a
>   match for a reference identifier of a CN-ID if it is the only
>   available presented identifier."  Or something like that.

How about this?

   A client SHALL seek a match for a reference identifier of CN-ID
   only if the certificate contains no other presented identifiers.

That does seem better -- it's good to future-proof the spec where
possible, I just don't think it's always possible.

I'll ask Jeff to review that text, too, because I came up with it just
now while replying to you.

> Section 5, Security Considerations:
>   The interesting thing about this specification is that we're leaving a
>   fairly broad range of potential "success" matches.  Not only that, but
>   future specifications may lead to future reference identity matches
>   that previously didn't work.  Fortunately, I can't come up with an
>   example that works all that well to describe it but somehow I'm left
>   feeling nervous that a server cert could have a clause the clients
>   don't understand currently but might later after a software upgrade
>   and an admin that expects a failure may suddenly see a success.  You
>   can ignore this paragraph if you fail to grasp what I'm trying to say,
>   as I'm not at all stating it well.

I have a sense of what you're getting at, but I'm not deeply concerned
about it because I think we'll be updating this document in the future.

> Section 5.1, Service Delegation:
>   You discuss interactive clients and how the the source domain name
>   MUST be provided by a human user.  But the odd case that I couldn't
>   figure out what it mapped to was references from an original source.
>   EG, images or javascript elements in a web page aren't "provided by
>   the user", but a web-browser is certainly interactive.  This sort of
>   "snow ball" domain list probably should be discussed at least in
>   brief.

That is an excellent catch. Jeff and I are discussing how to address
this matter and will post again once we have proposed text.

> Section 5.1, Service Delegation:
>   I read the last paragraph (which is one sentence) multiple times and I
>   only barely feel that I understand what it's saying. 

That is:

   There are several scenarios in which it can be legitimate for an
   interactive client to override the recommendation in the foregoing
   rule.  Examples include:

   <snip/>

   2.  A human user has explicitly agreed to trust a service that
       provides mappings of source domains to target domains, such as a
       dedicated discovery service or an identity service that securely
       redirects requests from the source domain to a target domain
       (however, such an arrangement is not encouraged and if a client
       supports such a service then it needs to disable it by default
       and carefully warn the user about the possible negative
       consequences of trusting such a service).

> I'd suggest
>   rewording it for clarity and splitting it into multiple sentences.
>   I'd offer suggestive text, but then I'd prove that I really didn't
>   understand it.

During an earlier review, Stefan Santesson suggested adding some text
about trusted mapping services, and the quoted text is the result.
Although there are cases when trusted mapping services are well-defined
(e.g., some SAML-based services), in general we agree with you that the
concept of a trusted mapping service is vague and difficult to grok.
We'd be open to removing that paragraph entirely, if Stefan would not
object too strongly. :)

> General:
>   Some of the possible combinations and options that may exist could
>   really use an "examples" section or something that had example info
>   from a certificate combined with example list of expected reference
>   indenties.  Though this would be nice, it's not at all critical.

Good suggestion. We will work to add a section of examples. See for
instance Section 13.7.1.2.2 (!) of draft-ietf-xmpp-3920bis-15 for the
kind of thing we'll include.

Thanks again for your feedback.

Peter

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