Peter,
I'm not driven by any desire to mandate more complex name comparison than is
called for. I just tend to think that it is better leave name comparison
requirement up to local policy.
However I think your argumentation is reasonable here and you convinced me.
I agree that in the general cases you are not interested in the host DNS
name.
I've decided that I'm perfectly fine with your proposed wording.
/Stefan
On 10-09-14 5:32 AM, "Peter Saint-Andre" <stpeter@xxxxxxxxxx> wrote:
> 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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf