[TP]inline ----- Original Message ----- From: "Bernard Aboba" <bernard_aboba@xxxxxxxxxxx> To: <daedulus@xxxxxxxxxxxxx>; <ietf@xxxxxxxx>; <stpeter@xxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf