ietf
[Top] [All Lists]

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

2010-09-22 13:12:22
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf