[secdir] secdir review of draft-saintandre-tls-server-id-check-09

[Barry Leiba <[e-mail]>]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Please forgive the lateness of this review; I really meant to have it
done sooner.

First, I found the document to be a tough read, and I can't really pin
down why.  I started reviewing it several times, and restarted, before
I finally got through it.  I can't give any advice with this comment,
so just take it as it is.

Second, there's a mixture of "natural person" and "human user" in the
document, and my sense is that you mean the same thing by both.  If
you do, you should switch to one term (I prefer the latter; "natural
person" sounds odd).  If they're meant to be different, you should
make it clear what the difference is.

Third, I'll note the earlier discussion of issues with IDN
comparisons.  I have nothing to add to that discussion, and it may be
that the best thing is to leave things as they are.

Comments are in order of appearance, not significance:

-- Page 16, bullet 6:
       The certificate MAY contain more than one DNS-ID, but SHOULD NOT
       contain more than one CN-ID.

Why "SHOULD NOT", and not "MUST NOT" ?  I'm not challenging this; it's
a question.

-- Page 17, sec 4.2, first graf:
   Before connecting to the server, the client MUST construct a list of
   acceptable reference identifiers.

Why MUST it be done "before"?  Can anyone detect, or does it hurt
interoperability, if it's done, say, in parallel with connection, or
while the client is waiting for the server to return the certificate?

-- Page 18, sec 4.2, last bullet:
   o  The list SHOULD NOT include a CN-ID; however, the CN-ID (if
      included) MUST be constructed only from the source domain and
      never from a target domain.

I find this oddly put.  How about "The list SHOULD NOT include a
CN-ID.  If a CN-ID is used despite this advice, it MUST be..." ?

I'd also like to take the security note from section 4.3 and echo it
here.  So maybe this?:

<< The list SHOULD NOT include a CN-ID.  If a CN-ID is used despite
this advice, it MUST be constructed only from the source domain and
never from a target domain.  Further, it MUST NOT be used unless there
are no other supported identifiers present in the certificate. >>

-- Page 18, sec 4.3, first graf:
   by seeking a match and aborting the search if any presented
   identifier matches one of its reference identifiers.

"Aborting" has the connotation of premature termination, before
completion, and that's not the case here; you're saying that the match
completes the process.  How about, simply, "stopping", or "ending" ?

-- Page 19, sec 4.4.3:
I think implementers might think that you're simply allowing any
leading wildcard character, so we should explicitly dissuade them.

So, in the first graf:
   the wildcard character '*', but only as the left-most label of the
   domain name,
make it "only as the complete value of the left-most label".

And in the second graf:
   in which the wildcard character is contained within a label fragment
   (e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net)
change to:
   baz1.example.net and baz2.example.net; also, *bozz.example.net is
   not allowed and MUST NOT be taken to match frobozz.example.net)

-- Page 19, sec 4.4.3, last graf:
   A specification that references the rules defined in this document
   can specify that the wildcard character is not allowed in
   certificates used by the relevant application protocol or community
   of interest.

How about “...can strengthen this section by ruling out wildcard
matching altogether for the relevant...” ?

-- Page 20, sec 4.4.4, second graf:
   entry types supported by the client), the client MAY as a fallback
   check for a string whose form matches that of a fully-qualified DNS
   domain name in the CN-ID.

Back in section 4.2, you say that the client SHOULD NOT include CN-ID
in the list, and here you're saying that it MAY make such a
comparison.  That seems oddly contradictory to me, though one can
certainly argue that SHOULD NOT implies MAY.  I'd prefer to see this
worded differently.

-- Page 21, sec 4.6.2:
   client MUST verify that the presented certificate matches the cached
   certificate and (if it is an interactive client) MUST notify the user
   if the certificate has changed since the last time a secure
   connection was successfully negotiated (where causes of change
   include but are not limited to changes in the DNS domain name,
   identifiers, issuer, certification path, and expiration date).

I worry about this kind of advice.  It violates my rule that says,
"Don't ask the user a question that he's not qualified to answer."  Of
course, "notify the user" can mean a lot of things, but too many
clients will implement something like this with a popup that will be
meaningless to 99% of the people who use it.

-- Page 21, sec 4.6.3, last graf:
   Instead, the client MUST proceed as follows.

I like a colon there, instead of the full stop.

-- Page 21, sec 4.6.3.1, security note:
      caution, for example by first encouraging the user to terminate
      the connection, forcing the user to view the entire certification
      path, and allowing the user to accept the certificate only on a
      temporary basis (i.e., for this connection attempt and all
      subsequent connection attempts for the life of the application
      session).

Same comment as for 4.6.2.  Most users will not understand certificate
problems, and will have no idea what they should do about them.
Always remember the "Barry's mother problem".  My mother will *never*
want to see an "entire certification path", let alone appreciate being
"forced" to.

-- Page 22, sec 5.1:
   When the connecting application is an interactive client, the source
   domain name and service type MUST be provided by a human user (e.g.
   when specifying the server portion of the user's account name on the
   server or when explicitly configuring the client to connect to a
   particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
   the user inputs in an automated fashion (e.g., a host name or domain
   name discovered through DNS resolution of the source domain).  This
   rule is important because only a match between the user inputs (in
   the form of a reference identifier) and a presented identifier
   enables the client to be sure that the certificate can legitimately
   be used to secure the connection.

Does this mean that a client specifically designed for the "gumbo"
service can't automatically use the service type "gumbo", without the
user's involvement?  Or that a client put out by example.net can't
assume a host name of services.example.net in the absence of user
input that says otherwise?

Further, it's entirely reasonable for a program to have a user enter
something like "gmail", and have the client turn that into something
like "mail.google.com", deriving it from the user's input in an
automated fashion.  Do we really want to forbid that sort of thing?

--
Barry Leiba