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/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf