ietf
[Top] [All Lists]

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

2010-09-14 11:14:56
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.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf