[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] secdir review of draft-saintandre-tls-server-id-check-09
From:       Peter Saint-Andre <stpeter () stpeter ! im>
Date:       2010-09-22 18:11:41
Message-ID: 4C9A46DD.7010502 () stpeter ! im
[Download RAW message or body]

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/



[prev in list] [next in list] [prev in thread] [next in thread]