Barry, thank you for your review. Jeff and I are working through all the
feedback that's been provided so far, and we'll be replying in various
threads and cc'ing all appropriate lists as we (the editorial team)
reach agreement on how to proceed.
On 9/14/10 3:39 PM, Barry Leiba wrote:
> 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.
Thanks for the feedback. The subject-matter is more dense than one might
expect, and we attempted to be as thorough as possible so as to remove
ambiguities. As a way of orienting the reader, we are thinking about
adding a paragraph or two to the introduction briefly outlining our
conclusions, but we don't yet have text to propose.
> 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.
In our working copy we've changed "natural person" to "human user" in
all instances.
> 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.
IDN-related topics are indeed always challenging, but we think that the
current text meets the needs of this specification.
> 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.
In an earlier version of this specification, we had "MUST NOT" instead
of "SHOULD NOT". Discussion on the certid@xxxxxxxx list led us to change
it to "SHOULD NOT", because folks argued that if a certificate contains
multiple DNS-IDs then it might appropriately contain one CN-ID
corresponding to each DNS-ID. Jeff said he needs to review the older
discussion again before the editors agree on how to proceed.
> -- 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?
The current wording is unfortunate, because it is not temporal order
that matters; what matters is that the client constructs its list of
reference identifiers without being influenced by the presented
identifiers provided in the certificate that's being checked.
Therefore Jeff and I propose the following corrected text:
Based on the source domain and the type of service to which
the client is connecting, the client MUST construct a list of
acceptable reference identifiers.
> -- 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..." ?
We have changed it to:
o The list SHOULD NOT include a CN-ID; however, if a CN-ID is
included despite this advice, it MUST be constructed only from
the source domain and never from a target domain.
> 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. >>
The last sentence does not apply in Section 4.2, because that section
concerns construction of the list of reference identifiers and as stated
above the client needs to do so without being influenced by the contents
of the certificate presented by the server.
> -- 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" ?
In our working copy, that paragraph now reads:
Once the client has constructed its list of reference identifiers and
has received the server's presented identifiers in the form of a PKIX
certificate, the client checks its reference identifiers against the
presented identifiers for the purpose of finding a match. The search
fails if the client exhausts its list of reference identifiers
without finding a match. The search succeeds if any presented
identifier matches one of the reference identifiers, at which point
the client SHOULD stop the search.
> -- 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)
We've tightened up that text, as follows:
###
A client employing this specification's rules MAY match the reference
identifier against a presented identifier in which a traditional
domain name or internationalized domain name contains one instance of
the wildcard character '*', but only if that character is the
complete left-most label of the domain name (as "label" is defined in
[DNS]). The following rules apply:
1. The client MUST NOT match a presented identifier in which the
wildcard character is not the only character of the label; e.g.,
baz*.example.net and *baz.example.net and b*z.example.net are not
allowed and MUST NOT be taken to match baz1.example.net and
foobaz.example.net and buzz.example.net.
2. The client MUST NOT match a presented identifier in which the
wildcard character comprises a label other than the left-most
label; e.g., bar.*.example.net is not allowed.
3. The client MUST compare the wildcard character only against the
left-most label; e.g., *.example.com matches foo.example.com but
not bar.foo.example.com or example.com.
###
> -- 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...â ?
Changed in our working copy to:
A specification that references the rules defined in this
document can strengthen the generic recommendations herein
by disallowing wildcard matching altogether for the relevant
application protocol or community of interest.
> -- 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.
Good catch.
Jeff and I do indeed mean to say that CN-ID is NOT RECOMMENDED, not that
it is OPTIONAL (the two are not equivalent, as I recently learned by
re-reading RFC 2119). Therefore we have provisionally modified the text
in Section 4.4.4 to read:
As noted, a client MUST NOT seek a match for a reference identifier
of CN-ID if the presented identifiers include an SRV-ID, URI-ID,
DNS-ID, or any application-specific subjectAltName entry types
supported by the client.
Therefore, if and only if the set of identifiers does not include a
subjectAltName entry of type dNSName, SRVName, or
uniformResourceIdentifier (or any application-specific subjectAltName
entry types supported by the client), as a fallback the client is
allowed to check the CN-ID for a string whose form matches that of a
fully-qualified DNS domain name. Despite the fact that this
behavior is NOT RECOMMENDED, if the client does compare a
reference identifier of type CN-ID against that string obtained from
a CN-ID presented in the certificate, it MUST follow the comparison
rules for the source domain of an identifier of type DNS-ID, SRV-ID,
or URI-ID, as described under Section 4.4.
Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if").
Jeff is a bit uncomfortable with that because CN-ID is such a common
practice, but I'm comfortable with it because of the hypothetical nature
of the recommendation. He will review the earlier discussions on this
topic before we finalize that text.
> -- 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.
Based on feedback from other threads, that section now reads:
###
4.6.2. Case #2: No Match Found, Cached Certificate
If the client finds no presented identifier that matches any of the
reference identifiers but a human user has permanently accepted the
certificate during a previous connection attempt or via configured
preferences, the certificate has already been cached. In this case,
the client MUST verify that the presented certificate matches the
cached certificate; if the presented certificate does not match the
cached certificate then the client MUST proceed as described under
Case #3 below.
###
See also our reply below regarding Section 4.3.6.1.
> -- 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.
I used to like colons in such places, but I've migrated to full stop.
We'll see what the RFC Editor has to say. :)
> -- 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.
The part of the text that you have not quoted does say that this
practice is typically offered only to advanced users (and I don't think
that Barry's mother counts as an advanced user). However, we've
provisionally made the text even more scary, as follows:
Security Note: Some existing interactive user agents give advanced
users the option of proceeding despite an identity mismatch.
Although this behavior can be appropriate in certain specialized
circumstances, in general it needs to be exposed only to advanced
users and even then needs to be handled with extreme caution, for
example by first encouraging even an advanced user to terminate
the connection and, if the advanced user chooses to proceed
anyway, by forcing the user to view the entire certification path
and only then allowing the user to accept the certificate on a
temporary basis (i.e., for this connection attempt and all
subsequent connection attempts for the life of the application
session, but not for connection attempts during future application
sessions).
Jeff still needs to review that text before we finalize it.
> -- 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?
IMHO that is a matter of user configuration, or user acknowledgement of
a service agreement, so it falls under the text in this I-D about
allowing the client to check the certificate against a DNS domain name
that is explicitly associated with the source domain by means of user
configuration.
> 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?
Yes, we do, because although you happen to "just know" that
mail.google.com is a legitimate DNS domain name to connect to when
interacting with the gmail.com service, Barry's mother might not have
that kind of knowledge and as a general rule it's a very bad idea to
assume that it's just fine to connect to some domain at foo.com when
interacting with a service at bar.com. However, service delegation is a
difficult topic and there are ongoing discussions among various IETF
participants about how to do service delegation securely; one thing I
think we can safely say is that it's not the task of this I-D to solve
the problem of secure service delegation.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf