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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 22 September 2010 18:11 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 933A53A6A46; Wed, 22 Sep 2010 11:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz4ZXrdbYQEv; Wed, 22 Sep 2010 11:11:17 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7EDF53A6A30; Wed, 22 Sep 2010 11:11:17 -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 577D540074; Wed, 22 Sep 2010 12:16:38 -0600 (MDT)
Message-ID: <4C9A46DD.7010502@stpeter.im>
Date: Wed, 22 Sep 2010 12:11:41 -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: Barry Leiba <barryleiba.mailing.lists@gmail.com>
References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com>
In-Reply-To: <AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@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: 7bit
X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700
Cc: IETF discussion list <ietf@ietf.org>, IETF cert-based identity <certid@ietf.org>, 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 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 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.
> 
> 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
> "google.com", not "gmail.com", 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

-- 
Peter Saint-Andre
https://stpeter.im/