Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 08 December 2010 22:51 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622D928C0CF for <certid@core3.amsl.com>; Wed, 8 Dec 2010 14:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.073
X-Spam-Level:
X-Spam-Status: No, score=-101.073 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, MANGLED_LIST=2.3, 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 fQGYts27mbtL for <certid@core3.amsl.com>; Wed, 8 Dec 2010 14:51:12 -0800 (PST)
Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id E6EAA3A69A9 for <certid@ietf.org>; Wed, 8 Dec 2010 14:51:11 -0800 (PST)
Received: (qmail 22001 invoked by uid 0); 8 Dec 2010 22:52:39 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com.bluehost.com with SMTP; 8 Dec 2010 22:52:39 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=fWjsQrcbvG6cX9jKG7SE3lCTz8Ty0EN5Mi1cXqL+6GGESOvpThL7lB5KMDiQNKD5uQg3wl2gsy0Q5Gl2z69AGc5guF48Z4A0qJLL4Y3XhqD/atNgupWNp98L7+sThz4b;
Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1PQSsJ-0004um-0J; Wed, 08 Dec 2010 15:52:39 -0700
Message-ID: <4D000C34.5070008@KingsMountain.com>
Date: Wed, 08 Dec 2010 14:52:36 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: draft-saintandre-tls-server-id-check.all@tools.ietf.org, General Area Review Team <gen-art@ietf.org>, certid@ietf.org
Subject: Re: [certid] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates <certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>, <mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Dec 2010 22:51:13 -0000

see way below...

PeterSA wrote on Wed, 08 Dec 2010 07:54:52 -0700 (06:54 PST)
 >
 > On 12/8/10 7:37 AM, Ben Campbell wrote:
 >>
 >>
 >> On Dec 8, 2010, at 7:10 AM, Peter Saint-Andre <stpeter@stpeter.im>
 >> wrote:
 >>
 >>> On 12/7/10 10:45 PM, Ben Campbell wrote:
 >>>>
 >>>> On Dec 7, 2010, at 11:12 PM, Peter Saint-Andre wrote:
 >>>>
 >>>>> On 12/7/10 6:35 PM, Ben Campbell wrote:
 >>>>>>
 >>>>>> On Dec 6, 2010, at 7:00 PM, =JeffH wrote:
 >>>>>>
 >>>>>>> Peter Saint-Andre <Peter.SaintAndre@webex.com> replied..
 >>>>>>>>
 >>>>>>>> On 12/3/10 2:24 PM, "Ben Campbell" <ben@nostrum.com>
 >>>>>>>> wrote:
 >>>>>
 >>>>> <snip/>
 >>>>>
 >>>>>>>>> -- 3.1, 1st paragraph:
 >>>>>>>>>
 >>>>>>>>> It's probably worth emphasizing that the rules are
 >>>>>>>>> often cumulative.  I think someone thinking about these
 >>>>>>>>> for the first time might not grasp that until they see
 >>>>>>>>> examples later in the doc.
 >>>>>>>>
 >>>>>>>> I've added the second sentence to this paragraph:
 >>>>>>>>
 >>>>>>>> When a certification authority issues a certificate based
 >>>>>>>> on the fully-qualified DNS domain name at which the
 >>>>>>>> application service provider will provide the relevant
 >>>>>>>> application, the following rules apply to the
 >>>>>>>> representation of application service identities.  The
 >>>>>>>> reader needs to be aware that some of these rules are
 >>>>>>>> cumulative and can interact in important ways that are
 >>>>>>>> illustrated later in this document.
 >>>>>>>
 >>>>>>> LGTM.
 >>>>>>
 >>>>>> WFM
 >>>>>>
 >>>>>> In fact, as I was re-reading RFC 5922, it occurred to me to
 >>>>>> wonder if people need guidance one way or another on the idea
 >>>>>> of "multi-purpose" certs that might have any number of
 >>>>>> subjectAltName entries for different purposes. I'm talking
 >>>>>> about virtual domain hosting, or multi-protocol hosts. I
 >>>>>> assume in the latter case, you would expect a host to use
 >>>>>> different certs for different protocols. In the first case,
 >>>>>> is their any guidance to give. I can't remember, do you
 >>>>>> mention the TLS server_name extension?
 >>>>>>
 >>>>>> (I don't mean to suggest any real action here--just thinking
 >>>>>> out loud about something that would have been much better to
 >>>>>> bring up well before IETF LC. :-)  )
 >>>>>
 >>>>> Those scenarios are important, but IMHO how the server
 >>>>> determines which certificate to present (e.g., based on the SNI
 >>>>> or something else, such as the 'to' address on an XMPP stream
 >>>>> header) is something that an application protocol specification
 >>>>> needs to define.
 >>>>
 >>>> Agreed. Does this draft need to say that, or do we just take it
 >>>> as given?
 >>>
 >>> I think it's appropriate to add a few words about that. I
 >>> suggest...
 >>>
 >>> 1.1
 >>>
 >>> ... When a client connects to an application service using
 >>> Transport Layer Security [TLS] or Datagram Transport Layer Security
 >>> [DTLS], it references some notion of the server's identity while
 >>> attempting to establish a secure connection (e.g., "the website at
 >>> example.com") and typically specifies at least the DNS domain name
 >>> with which it is trying to communicate (e.g., using a Server Name
 >>> Indication during TLS negotiation as described in [TLS-EXT]).
 >>>
 >>> 1.5
 >>>
 >>> presented identifier:  An identifier that is presented by a server
 >>> to a client within a PKIX certificate when the client attempts to
 >>> establish a secure connection with the server; the certificate can
 >>> include one or more presented identifiers of different types, and
 >>> the certificate presented is typically based on a DNS domain name
 >>> specified by the client when initiating communication (e.g., using
 >>> a Server Name Indication during TLS negotiation as described in
 >>> [TLS-EXT]).
 >>>
 >>
 >> Do you think server_name extension use is actually common enough to
 >> call typical? I'm not saying it's not--I don't really know one way or
 >> another. Otherwise, WFM.

I don't think the TLS server_name extension (aka SNI) is in common enough use 
yet to call it "typical". There's a certain still-widely-deployed version of a 
certain desktop OS that doesn't support it, unfortunately.


 > We could say "and if the server hosts more than one domain then the
 > certificate presented is typically based..."

Upon re-reading what we presently have in -11 for [S1.1], I don't think we need 
to introduce in that intro paragraph the notion of disambiguating names in a 
multi-domain situation. I'd leave that para as-is.

in terms of the defn for "presented identifier" in [S1.5], I'd update it like 
so (I don't think mentioning SNI is reasonable in that defn proper)..

  presented identifier:  An identifier that is presented by a server
  to a client within a PKIX certificate when the client attempts to
  establish a secure connection with the server; the certificate can
  include one or more presented identifiers of different types, and
  if the server hosts more than one domain then the certificate might
  present distinct identifiers for each domain.


I'm wondering if we ought to add an "implementation note" at the end of [S3.1] 
where we mention why one might have a cert with multiple presented identifiers 
or a client may employ SNI.


Implementation Note:  A given application service may be addressed by multiple 
domain names for a variety of reasons. In the default [TLS] handshake exchange,
there is no indication by the client as to the domain name the client trying to 
connect to, and the TLS server returns only one certificate for itself. Thus 
absent an extension to [TLS], a typical workaround used to facilitate mapping 
an application service to multiple domain names is to embed the said domain 
names into the returned application service certificate. Another approach, more 
recent and formally specified, is for the client to use the TLS "Server Name 
Indication" extension, when sending the client_hello message, stipulating the 
domain name the client used to connect with the application service. The 
application service can then return the appropriate certificate in its 
Certificate message. This latter certificate could thus contain a single domain 
name.

of course, the FDA notes that the above will require generous wordsmithing 
before use.

=JeffH