Re: Second Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) to BCP
SM <sm@resistor.net> Tue, 07 December 2010 21:35 UTC
Return-Path: <sm@resistor.net>
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 0C8893A689E for <ietf@core3.amsl.com>; Tue, 7 Dec 2010 13:35:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.45
X-Spam-Level:
X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 2t7xK6nRaYe1 for <ietf@core3.amsl.com>; Tue, 7 Dec 2010 13:35:42 -0800 (PST)
Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 0A4763A6893 for <ietf@ietf.org>; Tue, 7 Dec 2010 13:35:42 -0800 (PST)
Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id oB7LatvV006977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Dec 2010 13:37:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1291757826; x=1291844226; bh=rYj5JZJaLM4r9tuRIsGgZeI+3ePySBwa5U4YbSNpBMo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=EzYLscXe8l9utBVsKn4IG5sGKDLQDto7DJp6e4arw0SJi/Oddlm3znFuFjIUyiJ7S 412Dg0eHcui52jOnd4vicach9hT7sfDJspI6NYCiotq0uB9KzqxEG6/W3K2owFjUJp sbMHI8FD0gyWMWQom0LOLh3nXEUSnGONcXufkhBs=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1291757826; x=1291844226; bh=rYj5JZJaLM4r9tuRIsGgZeI+3ePySBwa5U4YbSNpBMo=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=x0iryRmm6uQgTZf4L8vIVL7Fh6CE5L1UbYV6y4EHa403KWF2OwlXZQcCrhZOzCSEp C3IEZ7n/WOggriHL8qqYYv5F1WCYsRCeHzvyB64GFjLarVbfmMJ9EUsncrJqmwSWGq 3JKQ/jM/6IVZezQBiY7wbaMx7l/2RQs6pghXa/Ec=
DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=iWp7dR5aroEsAaNp3UkgwEI5ibH2jLzykROhZmX3PFGRLy0S2shiwljZyw81DH7ck jMUaX/IBQNNDgAAueaiYA4q5/oS4xg81q/cd8yqqG55oRVnW7AVEnwQ4sXffTQ45zsU jjlIMt/3QfHKNUvu7f9hAx6C2AZWiJfLfNAEjNc=
Message-Id: <6.2.5.6.2.20101207102917.0a8a8bd8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 07 Dec 2010 13:36:43 -0800
To: ietf@ietf.org
From: SM <sm@resistor.net>
Subject: Re: Second Last Call: draft-saintandre-tls-server-id-check (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)) to BCP
In-Reply-To: <20101118123651.8314.60809.idtracker@localhost>
References: <20101118123651.8314.60809.idtracker@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: Peter Saint-Andre <psaintan@cisco.com>, Jeff Hodges <Jeff.Hodges@PayPal.com>
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: Tue, 07 Dec 2010 21:35:48 -0000
At 04:36 18-11-10, The IESG wrote: >The IESG has received a request from an individual submitter to consider >the following document: > >- 'Representation and Verification of Domain-Based Application Service > Identity within Internet Public Key Infrastructure Using X.509 (PKIX) > Certificates in the Context of Transport Layer Security (TLS) ' > <draft-saintandre-tls-server-id-check-11.txt> as a BCP > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the In Section 2.2: 'A "traditional domain name", i.e., a fully-qualified domain name or "FQDN" (see [DNS-CONCEPTS]) all of whose labels are "LDH labels" as defined in [IDNA-DEFS].' It would be better to reference RFC 1123 for LDH labels instead of RFC 5890 unless the authors would like to adopt a terminology that is specific to IDNA. In Section 3.1: "Unless a profile of this specification allows continued support for the wildcard character '*', the fully-qualified DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the definition of "label" from [DNS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or foo*.example.com)." If the presented identifier is a fully-qualified DNS domain name (I assume that means FQDN), the left-most label cannot be a wildcard character according to LDH rules. I suggest rewriting that as: Unless a profile of this specification allows continued support for the wildcard character '*', the domain name portion of a presented identifier SHOULD NOT contain the wildcard character (e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or foo*.example.com). In Section 4.2.1: "The client might need to extract the source domain and service type from the input(s) it has received. The extracted data MUST include only information that can be securely parsed out of the inputs (e.g., extracting the fully-qualified DNS domain name from the authority component of a URI or extracting the service type from the scheme of a URI) or information for which the extraction is performed in a manner that is not subject to subversion by network attackers (e.g., pulling the data from a delegated domain that is explicitly established via client or system configuration, resolving the data via [DNSSEC], or obtaining the data from a third-party domain mapping service in which a human user has explicitly placed trust and with which the client communicates over a connection that provides both mutual authentication and integrity checking)." I read part of the above as meaning that data can only be extracted from DNS if the data has been resolved via DNSSEC. Is that the intent? Section 4.3 discusses about how to seek a match against the list of reference identifiers. I found the thread at http://www.ietf.org/mail-archive/web/certid/current/msg00318.html informative. In Section 4.4.3: "A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*' as part or all of a label (following the definition of "label" from [DNS])" According to the definition of label in RFC 1035, the wildcard character cannot be part of a label. I suggest removing the last part of that sentence. FWIW, RFC 4592 updates the wildcard definition in RFC 1034 and uses the term "asterisk label". Was the comment about the security note ( http://www.ietf.org/mail-archive/web/certid/current/msg00427.html ) in Section 4.6.4 addressed? Regards, -sm