Re: Review of draft-saintandre-tls-server-id-check

[Peter Saint-Andre <[e-mail]>]

On 9/8/10 2:09 AM, t.petch wrote:
> [TP]inline
> 
> ----- Original Message -----
> From: "Bernard Aboba" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>
> 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.

Aha, I see the source of confusion. I think the first sentence of
Section 5.1 is better written as follows:

   When the connecting application is an interactive client,
   construction of the reference identifier SHOULD be based on the
   source domain and service type 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 SHOULD NOT be based on a
   target domain 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).

We want to make sure that the reference identifier is based on the
source (user-provided) domain, not the target (automatically-derived)
domain, except perhaps in several well-defined and carefully-limited
scenarios.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/