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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 22 September 2010 15:58 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C220428C115; Wed, 22 Sep 2010 08:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.261
X-Spam-Level:
X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQPO1TcLaW+h; Wed, 22 Sep 2010 08:58:48 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AB30228C116; Wed, 22 Sep 2010 08:58:48 -0700 (PDT)
Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1DBCE40074; Wed, 22 Sep 2010 10:04:07 -0600 (MDT)
Message-ID: <4C9A27D0.7030909@stpeter.im>
Date: Wed, 22 Sep 2010 09:59:12 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8
MIME-Version: 1.0
To: barryleiba@computer.org
References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com>
In-Reply-To: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com>
X-Enigmail-Version: 1.0.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700
Cc: IETF cert-based identity <certid@ietf.org>, IETF discussion list <ietf@ietf.org>, Barry Leiba <barryleiba.mailing.lists@gmail.com>, tls@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2010 15:58:50 -0000

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@ietf.org 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/