ietf
[Top] [All Lists]

Re: Review of draft-saintandre-tls-server-id-check

2010-09-13 19:04:07
Peter,
Comments in line;


On 10-09-13 9:16 PM, "Peter Saint-Andre" <stpeter(_at_)stpeter(_dot_)im> wrote:

On 9/13/10 12:39 PM, Stefan Santesson wrote:
Peter,

On 10-09-13 6:08 PM, "Peter Saint-Andre" <stpeter(_at_)stpeter(_dot_)im> 
wrote:

Hi Shumon,

As I see it, this I-D is attempting to capture best current practices
regarding the issuance and checking of certificates containing
application server identities. Do we have evidence that any existing
certification authorities issue certificates containing both an SRVname
for the source domain (e.g., example.com) and dNSName for the target
domain (e.g., apphosting.example.net)? Do we have evidence that any
existing application clients perform such checks? If not, I would
consider such complications to be out of scope for this I-D.

That said, we need to be aware that if such usage arises in the future,
someone might write a document that updates or obsoletes this I-D; in
fact the present authors very much expect that such documents will
emerge after the Internet community (specifically certification
authorities, application service providers, and application client
developers) have gained more experience with PKIX certificates in the
context of various application technologies.

Peter

I would like to turn the question around and ask why this specification need
to have an opinion on whether a relying party feels he have to check both
host name and service?

Stop right there. :) I sense a possible source of confusion. What do you
mean by "host name" and what do you mean by "service"?

Sorry for sloppy use of words.

With host name I mean here the actual DNS name of the host, which might be
host1.example.com (dNSName)

By service I mean the service under a given domain, which for the same host
might be _xmpp.example.com (SRVName)

Under the current rules, using this example I read it that the following
apply:

- If you are just checking the SRVName you will not learn the legitimate
host DNS name. So a certificate issued to host2.example.com will be accepted
even if you intended to contact host1.example.com (even if that information
is in the cert).

- If you just check the dNSName, you will miss the fact that you talk to the
desiganted ldap server and not the xmpp server (even if that information is
in the cert).


In this I-D, we talk about "DNS domain name" and "service type", which
map quite well to _Service.Name from RFC 4985: the DNS domain name is
the "source domain" provided by the user or configured into the client
(e.g., "example.com") and the "service type" is a given application
protocol that could be serviced by the source domain (e.g., "IMAP").

This I-D is attempting to gently nudge people in the direction of
checking both the DNS domain name and the service type. IMHO this is
consistent with considering the SRVName and uniformResourceIdentifier
subjectAltName entries as more tightly scoped than dNSName or CN, and
therefore as potentially more "secure" in some sense (the subject might
want to limit use of a particular certificate to only the service type
identified in the SRVName or uniformResourceIdentifier).

If by "host name" you mean "target domain" as defined in the I-D (and
mapping to "Target" from RFC 2782) then we have more to discuss.

I'm not against describing the typical case, as long as this specification
does not imply that a relying party that has a reason to check two name
types is doing something wrong.

That is not the intent of this I-D, however that would be functionality
over and above what this I-D defines.

I have no extremely good examples of practical implementation here but
checking both host name and service seems like both extremely easy and good
practice.

With respect to revisions to this I-D, the lack of good examples
troubles me because we have been trying to abstract from common usage,
not to define guidelines for use cases that have not yet been defined,
implemented, and deployed.

Given that you would prefer to leave the door open to more advanced
checking rules, I think you would object to this text in Section 4.3:

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  It does so
   by seeking a match and stopping the search if any presented
   identifier matches one of its reference identifiers.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.

You are saying that it is not necessarily appropriate to stop the search
once a single match is found, because the client might be configured to
look for multiple matches (e.g., a match against both the source domain
and the target domain). Would you like to suggest text that covers such
a case? Here is a possible rewrite of Section 4.3 that might address
your concern.

###

4.3.  Seeking a Match

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.  The search succeeds if any presented
   identifier matches one of the reference identifiers, at which point
   the client SHOULD stop the search.

      Implementation Note: A client might be configured to perform
      multiple searches, i.e., to match more than one reference
      identifier; although such behavior is not forbidden by this
      document, rules for matching multiple reference identifiers are a
      matter for implementation or future specification.

      Security Note: A client MUST NOT seek a match for a reference
      identifier of CN-ID if the presented identifiers include an
      SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
      entry types supported by the client.

   Detailed comparison rules for finding a match are provided in the
   following sections.


This sounds better to me.

If I'm not totally wrong in my example above I also think it would be good
with a security note stating that an SRVName may not provide the full host
DNS name, and if it is important to verify the host DNS name, you must
verify the dNSName in addition to what else you are checking.

/Stefan


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf