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

Peter Saint-Andre <> Wed, 22 September 2010 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 933A53A6A46; Wed, 22 Sep 2010 11:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tz4ZXrdbYQEv; Wed, 22 Sep 2010 11:11:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7EDF53A6A30; Wed, 22 Sep 2010 11:11:17 -0700 (PDT)
Received: from ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 577D540074; Wed, 22 Sep 2010 12:16:38 -0600 (MDT)
Message-ID: <>
Date: Wed, 22 Sep 2010 12:11:41 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100914 Thunderbird/3.0.8
MIME-Version: 1.0
To: Barry Leiba <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: url=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700
Cc: IETF discussion list <>, IETF cert-based identity <>,,
Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Sep 2010 18:11:19 -0000

On 9/22/10 10:34 AM, Barry Leiba wrote:
> Hi, Peter.  Thanks for the response, and I'm very happy with nearly
> all the changes you've adopted.  I'll not quote and comment on it all,
> except to make the general statement: Great work!

Thanks! Comments inline.

>>> 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.
> I see your point, and I agree.
> Still, it might be useful at this point to explain WHY the list SHOULD
> NOT include a CN-ID.  I'll leave it there, with no further argument...
> it's certainly explained later, so perhaps that's good enough, and
> there's no reason to spend further time on this here.

You're right, it's not good to baldly state this SHOULD NOT without
justification. We'll work to propose appropriate text.

>> 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.
> I agree with you, Peter: I think the text is fine as you've given it.
>> 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).
> True; I'd missed that point, and I'm happy with the newer, scarier text.

In this context, scary is good. :)

> The only point I still want to push on is this one:
>>>    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 can't
>>> assume a host name of 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 "", 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
>> is a legitimate DNS domain name to connect to when
>> interacting with the 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 when
>> interacting with a service at 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.
> There's a distinction, here, between a protocol and a user interface
> for configuration.  My mother doesn't know whom to trust, except that
> she knows that she (at least kinda-sorta) trusts the mail program
> she's decided to use, and an entity she calls "gmail" (not
> "", not "", but just "gmail").  She's relying to
> the mail program's "easy configuration feature" to sort this out.
> The text I reviewed appeared to be saying normative things about what
> client software MUST and MUST NOT do with regard to this sort of
> configuration situation, which goes well beyond what the client
> software is doing on the wire.  Unless I'm mis-reading it, it's
> explicitly saying that my client software is not allowed to do
> something like this, for example:
> 1. Ask the user, "What email service do you use?"
> 2. Receive the answer "gmail" from the user.
> 3. Auto-configure itself for the known gmail servers based only on
> that user input.
> If I am, indeed, misreading it, please tell me... and perhaps tweak
> the wording to make it less likely that someone else will misread it
> the same way.
> Again, this is my only remaining quibble with the document, and,
> again, it's a very good piece of work.

Aha, thanks for the more detailed description of the scenario you had in
mind. I see your point. We certainly don't mean the recommendations in
this document to make life more difficult for your mother as she
interacts with her auto-configuring email client!

Off the top of my head I don't have a proposed solution, but I have
added this to the list of open issues that Jeff and I need to discuss,
and we'll be back with proposed text just as soon as we're able.


Peter Saint-Andre