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

[Sean Turner <[e-mail]>]

I'd offered to review this version during the TLS session at IETF 78, 
but I think I'm going to wait for the next version ;)

spt

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").
> 
> 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.
> 
> Section 1.3.2: (*)
>   This section is full of text that is subjective and really isn't
>   needed in the first place.  Nearly every paragraph contains text that
>   may be true today but might not be in the future 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.
> 
>   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."
> 
> 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?
> 
> Section 3, bullet 5:
>   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.
> 
> Section 4.3, security note:
>   I actually think wording these things is tricky when the future is
>   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.  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.
> 
> 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.
> 
> 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.
> 
> 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.  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.
> 
> 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.
>