On 9/13/10 6:03 PM, Stefan Santesson wrote:
> Peter,
> Comments in line;
Ditto.
> On 10-09-13 9:16 PM, "Peter Saint-Andre" <stpeter@xxxxxxxxxx> wrote:
>
>> On 9/13/10 12:39 PM, Stefan Santesson wrote:
>>> Peter,
>>>
>>> On 10-09-13 6:08 PM, "Peter Saint-Andre" <stpeter@xxxxxxxxxx> 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)
Or which might be apphost37.example.net or whatever...
> By service I mean the service under a given domain, which for the same host
> might be _xmpp.example.com (SRVName)
OK.
But what does dNSName=host1.example.com + SRVName=_xmpp.example.com
actually mean? I see three possibilities:
1. "Connect to example.com's XMPP service only if it's hosted on
host1.example.com"
2. "Don't connect to host1.example.com if you are looking for something
other than example.com's XMPP service" (i.e., if you want the IMAP
service or anything else at example.com, terminate the connection)
3. "The connection is fine if you're looking for (a) any service at
host1.example.com, *or* (b) example.com's XMPP service"
In my experience running the XMPP ICA for a few years, I found that our
root CA would issue dNSName=example.com + SRVName=_xmpp.example.com but
not dNSName=host1.example.com + SRVName=_xmpp.example.com (i.e., the
name in both dNSName and SRVName was the same). Yes, that is anecdotal,
but I think it makes some sense, because IMHO a CA is not going to "get
involved" with the particular machine that hosts a service (i.e., to
differentiate between the DNS domain name of the application service and
the DNS domain name of the hosting machine / provider).
> 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.
Are there any application clients today that would check only the SRVName?
> 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).
In what sense does the application client "intend" to contact
host1.example.com? The user controlling a client (a browser or an email
client or an IM client or whatever) intends to contact example.com, not
host1.example.com or apphost37.example.net or whatever.
> - 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).
Correct. If that is a problem in your user community or operating
environment, then you need to find a better client.
IMHO it is almost a best practice for the DNS domain names in the
various presented identifiers of the certificate (dNSName, SRVName,
uniformResourceIdentifier, etc.) to be the same. I think we in the
Internet community don't yet have enough experience to say that with
high confidence, which is why I'm not ready to push on the point in this
I-D. However, let us consider the example of a delegated domain, such as
dNSName=apphost37.example.net + SRVName=_xmpp.example.com, which might mean:
1. "Connect to example.com's XMPP service only if it's hosted on
apphost37.example.com"
2. "Don't connect to apphost37.example.com if you are looking for
something other than example.com's XMPP service" (i.e., if you want the
IMAP service or anything else at example.com, terminate the connection)
3. "The connection is fine if you're looking for (a) any service at
apphost37.example.com, *or* (b) example.com's XMPP service"
In this case, I think #3 is clearly wrong because the user doesn't know
anything about apphost37.example.net and doesn't intend to connect to
that host.
#1 and #2 are close to equivalent, because they attempt to establish a
firm association between a host name (apphost37.example.net) and an
application service (example.com's XMPP service). Is that association
desirable? I'm not convinced (mainly because, to reiterate, I think that
end users don't know or care about the hosting provider or machine).
However, for such an association to be helpful, we'd need (i) clients
that consistently check both identifier types and (ii) CAs that certify
both the application service and the hosting provider. Further, I think
we'd also need (iii) a well-defined semantic that says dNSName is used
to represent the DNS domain name of the hosting provider or machine --
and as far as I can see dNSName does not have that meaning. Given that
we don't have (i), (ii), or (iii), I question the need for this line of
thinking.
>> 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.
See above. You and I seem to continually run aground on a disagreement
over whether it makes any sense for an application client (or the user
thereof) to know of, care about, or verify the DNS domain name of the
hosting machine / service / provider. That's the basis for our previous
discussion about RFC 4985 and it's the basis for our current discussion
about dNSName vs. SRVName. I simply don't understand why a normal human
user of an application client would ever want or need to be aware of the
hosting provider for a given application service, why a CA would want to
certify an association between a hosting provider and a given
application service, or why we would ever assume that the dNSName is
meant to identify the hosting provider whereas the SRVName is meant to
identify the application service. Cementing such an association in those
three ways is outside the scope of this I-D, even if one accepts the
premise that such an association is a good idea (which I don't). Can we
agree to disagree here and, rather than add a note about the security
features of such an association, instead add a note to Section 1.3.2
("Out of Scope") explaining why any possible association between the
application service and the hosting machine / service / provider is out
of scope for this I-D? Perhaps in the future we will have advanced far
enough to define best practices for such associations, but right now it
seems to me that we lack a firm basis for doing so.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf