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

Barry Leiba <> Wed, 22 September 2010 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6651E3A69CA; Wed, 22 Sep 2010 09:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.868
X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v1lQUfhiQqla; Wed, 22 Sep 2010 09:34:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 609F43A6900; Wed, 22 Sep 2010 09:34:23 -0700 (PDT)
Received: by gya1 with SMTP id 1so2089gya.31 for <multiple recipients>; Wed, 22 Sep 2010 09:34:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+COdUx65lKGmMyU4EmpsPQmZQuFbOIB4l81+6dA7Mbg=; b=B4t2onz7GT8Nf5QGYObGs2yY4/h6PJwj88DrvmtGtSD29j5o9hmtlv/b04ZeMzHgUQ g42ZMXgzWG0wQiLqgvkn5eaPLugqu00RW0aL0VMED205uq2YKdjCoBLhXlNOkmC+MIx0 A3mxZ56DonCupjYZ4oWOaxC5S0Xthy20+gDjM=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tmktZyA3BwO/yYq4VxKdvPRM16+pSgfhE2IzaaolAbZBHog/v6AO9U43VyL/IOMnvl LlxD4TRasPoWQKJXDDPGkQPq+M8sRBnUAXjmEFC4Wtvq6RQNq2qLQEowxpN3sLg4BlyV e390dJltidgfcqzDBxZjHFcxYOr5rAquNKUGg=
MIME-Version: 1.0
Received: by with SMTP id p9mr1441203ybg.80.1285173290320; Wed, 22 Sep 2010 09:34:50 -0700 (PDT)
Received: by with HTTP; Wed, 22 Sep 2010 09:34:50 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 22 Sep 2010 12:34:50 -0400
X-Google-Sender-Auth: kupZ6sAWANBwT_q5CpOlf5olsQ4
Message-ID: <>
From: Barry Leiba <>
To: Peter Saint-Andre <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 16:34:26 -0000

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!

>> 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.

> 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.

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.