On 9/8/10 7:40 AM, Stefan Santesson wrote:
Being the author of RFC 4985 I agree with most of you say here.
Comments in line;
On 10-09-06 8:48 PM, "Bernard Aboba" <bernard_aboba(_at_)hotmail(_dot_)com>
wrote:
That was in fact my original question.
Section 5.1 states that the source domain and service type MUST be
provided by a human user, and can't be derived. Yet in an SRV or
DDDS lookup, it is not the source domain that is derived, it is the
target domain. Given that, it's not clear to me what types of DNS
resolutions are to be discouraged.
This puzzled me as well. The domain of interest is the domain where the
requested service is located = target domain.
As noted elsewhere, RFC 4985 appears to require matching of the
source domain/service type to the SRV-ID in the certificate.
It is not. RFC 4985 says the following in section 2:
_Service.Name
<snip>
Name
The DNS domain name of the domain where the specified service
is located.
Perhaps some examples would help.
The good folks at example.com have delegated their IM service to
apps.hosting.net. When the user someone(_at_)example(_dot_)com does an SRV
lookup
for _xmpp-client._tcp im.example.com, its client gets back something
like this:
20 0 5222 apps.hosting.net.
The client resolves apps.hosting.net to an IP address and connects to
that machine.
During TLS negotiation, the application service for example.com (which
is in fact being serviced by apps.hosting.net) presents a certificate
that contains an SRV-ID. Which of the following is it?
1. _xmpp.example.com
or:
2. _xmpp.apps.hosting.net
If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in
RFC 2782.
If #2, then the "Name" in _Service.Name is actually a "Target" as
defined in RFC 2782.
Such
a process would be consistent with a match between user inputs
(the source domain and service type) and the presented identifier
(the SRV-ID).
Since this is not the definition of SRVName, this type of matching does not
apply.
Again: is the definition of SRVName in RFC 4985 consistent with RFC 2782
(i.e., 4985 "Name" is 2782 "Name") or is it inconsistent with RFC 2782
(i.e., 4985 "Name" actually is 2782 "Target")?
Yet, Section 5.1 states:
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.
However, an interactive client MAY provide a configuration setting
that enables a human user to explicitly specify a particular host
name or domain name (called a "target domain") to be checked for
connection purposes.
[TP] what I thought was about to be raised here was a contradiction that
RFC4985
is all about information gotten from a DNS retrieval whereas the wording of
s5.1
in this I-D
"the source
domain name and service type ... MUST NOT be derived from
the user inputs in an automated fashion (e.g., ... discovered through DNS
resolution ... "
would appear to exclude DNS resolution. If DNS resolution is off limits,
then
RFC4985 would appear not to apply.
See my previous note. This text needs to be clarified as I suggested, so
that it talks about whether the reference identifier is based on the
source domain or the target domain. This I-D is attempting to forbid or
at least strongly discourage basing the reference identifier on the
target (derived) domain. If RFC 4985 allows the presented identifier to
be the target domain as a matter of course then I think we have a problem.
RFC 4985 provides the client with a way to authenticate a host that it
believes is authorized to provide a specific service in the target domain.
Believes on what basis?
It does not matter from where the client has obtained that authorization
information or whether that information is trustworthy.
That's a strange statement to make in the context of security.
A client may very well do an insecure DNS lookup to discover what host is
providing the requested service. The client would then contact that host and
obtained it's certificate. If the certificate is trusted and it's SRVName
matches the information provided from the DNS server, then everything is
fine.
For some definition of "fine", yes.
The client now has assurance from the CA that this host is in fact
authorized to provide this service.
To use my example, the CA is providing assurance that apps.hosting.net
is authorized to provide the XMPP service on behalf of example.com. That
seems reasonable if the presented identifier based on the source domain
(example.com). However, if the assurance is checked on the client side
by finding _xmpp.apps.hosting.net as the presented identifier then I
fail to understand something very basic: how does the client tie that
SRV-ID to the source domain (example.com) in a secure fashion? The
presented identifier seems to be a mere assertion without any connection
whatsoever to the source domain. If we just wave our hands and say "the
client can simply let the user believe that it's OK for apps.hosting.net
to assert a right to provide the IM service for example.com and it
doesn't matter if there is no basis for that belief because the
information might not be trustworthy" then I wonder what RFC 4985 really
accomplishes or whether we want to encourage anyone to use the SRVName
extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna).
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf