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

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 06 September 2010 18:48 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFBA3A6825 for <ietf@core3.amsl.com>; Mon, 6 Sep 2010 11:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.722
X-Spam-Level:
X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=0.876, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVC1UZYGdq4r for <ietf@core3.amsl.com>; Mon, 6 Sep 2010 11:48:25 -0700 (PDT)
Received: from blu0-omc4-s33.blu0.hotmail.com (blu0-omc4-s33.blu0.hotmail.com [65.55.111.172]) by core3.amsl.com (Postfix) with ESMTP id 45BC13A67E1 for <ietf@ietf.org>; Mon, 6 Sep 2010 11:48:24 -0700 (PDT)
Received: from BLU137-W15 ([65.55.111.137]) by blu0-omc4-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Sep 2010 11:48:53 -0700
Message-ID: <BLU137-W154CAC092887C97B8F0B6493700@phx.gbl>
Content-Type: multipart/alternative; boundary="_726212c6-695c-4760-ab9f-81a89eb51d12_"
X-Originating-IP: [184.78.195.189]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: daedulus@btconnect.com, ietf@ietf.org, stpeter@stpeter.im
Subject: RE: Review of draft-saintandre-tls-server-id-check
Date: Mon, 06 Sep 2010 11:48:52 -0700
Importance: Normal
In-Reply-To: <00c301cb4dcc$f7be44a0$4001a8c0@gateway.2wire.net>
References: <BLU137-W32189ED2D1B0FDFCBF639F93840@phx.gbl>, <00c301cb4dcc$f7be44a0$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 06 Sep 2010 18:48:53.0040 (UTC) FILETIME=[26E9B300:01CB4DF4]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Sep 2010 18:48:28 -0000

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. 

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