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

[Barry Leiba <[e-mail]>]

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

Barry