[TP]inline
----- Original Message -----
From: "Bernard Aboba" <bernard_aboba(_at_)hotmail(_dot_)com>
To: <daedulus(_at_)btconnect(_dot_)com>; <ietf(_at_)ietf(_dot_)org>;
<stpeter(_at_)stpeter(_dot_)im>
Sent: Monday, September 06, 2010 8:48 PM
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.
[TP] Right, I see what you mean.
The DNS resolution I had in mind, if it is a resolution, is that while the
interactive user had specified a DNS name and that name had been fed into a DNS
Query, then the SRV record had been returned as an Additional RR, not as an
Answer, and that the Name from this Additional RR was now being used as the
source domain for the purposes of this I-D. Which section 5.1 might be trying
to preclude.
Tom Petch
============================================
As noted elsewhere, RFC 4985 appears to require matching of the
source domain/service type to the SRV-ID in the certificate. 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).
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.
Does s5.1 of the I-D mean what it appears to say?
Tom Petch
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf