From stpeter@stpeter.im Wed Sep 8 15:00:56 2010 Return-Path: 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 9BD4C3A6965; Wed, 8 Sep 2010 15:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 x4NfQOuofDa7; Wed, 8 Sep 2010 15:00:55 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 456A03A6952; Wed, 8 Sep 2010 15:00:55 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 97A0E40074; Wed, 8 Sep 2010 16:04:59 -0600 (MDT) Message-ID: <4C8807AC.9020808@stpeter.im> Date: Wed, 08 Sep 2010 16:01:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:00:56 -0000 On 9/8/10 11:28 AM, Stefan Santesson wrote: > For clarity, I'll provide two examples where I think it is motivated to > obtain the FQDN reference identifier in an automated fashion and not through > direct user input or configuration (contrary to section 5.1). Thanks for the examples. > 1) Obtaining EU Trusted Lists > EU has standardized on XML based lists over national Trust Service Providers > and their certificates. Each country in the EU publish their own list. > The EU commission provides a central list with all the URLs to each national > list. > > The first step is for the client to establish a secure connection with the > EU commission and download the EU list. This is done by configuration. > > The second step is to automatically obtain reference identifiers for all > national lists from the EU list. > > > 2) Redirects from a trusted service. > If I connect to a trusted service and then get redirected to another host, > it can be reasonable to obtain the reference identifier from the rediricet. > Typical application I can think of is a redirect to a SAML IdP or a SAML > Discovery service. It seems to me that in both of these cases, the user has placed trust in a certain entity (the EU's system of trust service providers, a particular trusted service) and has configured his or her application client to allow that entity to transform a source domain into a target-domain-based reference identifier for the purposes of secure connection. (One could argue that DNSSEC might result in a similar arrangement.) Would the following text address the scenarios you mention? ### 5.1. Service Delegation When the connecting application is an interactive client, the source domain name and service type SHOULD 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 SHOULD 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. There are several scenarios in which it can be legitimate for an interactive client to override the recommendation in the foregoing rule. Examples include: 1. A human user has explicitly configured the client to associate a particular target domain with a given source domain (e.g., for connection and identity checking purposes the user has explicitly approved "apps.example.net" as the target domain associated with a source domain of "example.com"). 2. A human user has explicitly agreed to trust a service that provides mappings of source domains to target domains, such as a dedicated discovery service or an identity service that securely redirects requests from the source domain to a target domain (however, such an arrangement is not encouraged and if a client supports such a service then it needs to disable it by default and carefully warn the user about the possible negative consequences of trusting such a service). ### I'm quite leery of these identity mapping services you have mentioned; I can see that some people might trust them, but I think we need to encourage clients to clearly and forcefully warn users about them, because trusting such a service means handing over a great deal of power. /psa > /Stefan > > > On 10-09-08 4:21 PM, "Stefan Santesson" wrote: > >> My apology, >> >> I just realized that the document defines "source domain" as what I thought >> would be the "target domain" >> >> source domain: The fully-qualified DNS domain name that a client >> expects an application service to present in the certificate. >> >> Which makes my comments below a bit wrong. >> >> I think it would be better to discuss this in terms of "reference identifier" >> and "presented Identifier". >> >> presented identifier: An identifier that is presented by a server to >> a client within the server's 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. >> >> reference identifier: An identifier that is used by the client for >> matching purposes when checking the presented identifiers; the >> client can attempt to match multiple reference identifiers of >> different types. >> >> I see no problem in obtaining the reference identifier from a DNS lookup an >> the comparing it with a presented identifier in the certificate. >> >> Why would you require the reference identity to be provided by a human user? >> >> /Stefan >> >> >> >> On 10-09-08 3:40 PM, "Stefan Santesson" wrote: >> >>> Being the author of RFC 4985 I agree with most of you say here. >>> >>> Comments in line; >>> >>> On 10-09-06 8:48 PM, "Bernard Aboba" wrote: >>> >>>> 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. >>>> >>> >>> This puzzled me as well. The domain of interest is the domain where the >>> requested service is located = target domain. >>> >>>> As noted elsewhere, RFC 4985 appears to require matching of the >>>> source domain/service type to the SRV-ID in the certificate. >>> >>> It is not. RFC 4985 says the following in section 2: >>> >>> _Service.Name >>> >>> >>> >>> Name >>> The DNS domain name of the domain where the specified service >>> is located. >>> >>> >>>> 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). >>>> >>> >>> Since this is not the definition of SRVName, this type of matching does not >>> apply. >>> >>>> >>>>> 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. >>>>> >>> >>> RFC 4985 provides the client with a way to authenticate a host that it >>> believes is authorized to provide a specific service in the target domain. >>> >>> It does not matter from where the client has obtained that authorization >>> information or whether that information is trustworthy. >>> >>> A client may very well do an insecure DNS lookup to discover what host is >>> providing the requested service. The client would then contact that host and >>> obtained it's certificate. If the certificate is trusted and it's SRVName >>> matches the information provided from the DNS server, then everything is >>> fine. >>> >>> The client now has assurance from the CA that this host is in fact authorized >>> to provide this service. >>> >>> >>> /Stefan >>> From stpeter@stpeter.im Wed Sep 8 15:10:04 2010 Return-Path: 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 9ED3A3A69BB; Wed, 8 Sep 2010 15:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 LOv38Zi4wF0g; Wed, 8 Sep 2010 15:10:03 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 32DE73A682E; Wed, 8 Sep 2010 15:10:03 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E609540074; Wed, 8 Sep 2010 16:14:09 -0600 (MDT) Message-ID: <4C8809D4.9010603@stpeter.im> Date: Wed, 08 Sep 2010 16:10:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "t.petch" References: , <00c301cb4dcc$f7be44a0$4001a8c0@gateway.2wire.net> <00b701cb4f2d$a1c29e40$4001a8c0@gateway.2wire.net> In-Reply-To: <00b701cb4f2d$a1c29e40$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:10:04 -0000 On 9/8/10 2:09 AM, t.petch wrote: > [TP]inline > > ----- Original Message ----- > From: "Bernard Aboba" > To: ; ; > 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/ From stpeter@stpeter.im Wed Sep 8 15:35:20 2010 Return-Path: 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 E13F73A6852; Wed, 8 Sep 2010 15:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, 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 3HLAcT2HbCEk; Wed, 8 Sep 2010 15:35:15 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1A8913A6838; Wed, 8 Sep 2010 15:35:15 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5190A40074; Wed, 8 Sep 2010 16:39:21 -0600 (MDT) Message-ID: <4C880FBB.7070309@stpeter.im> Date: Wed, 08 Sep 2010 16:35:39 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:35:20 -0000 On 9/8/10 7:40 AM, Stefan Santesson wrote: > Being the author of RFC 4985 I agree with most of you say here. > > Comments in line; > > On 10-09-06 8:48 PM, "Bernard Aboba" wrote: > >> 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. >> > > This puzzled me as well. The domain of interest is the domain where the > requested service is located = target domain. > >> As noted elsewhere, RFC 4985 appears to require matching of the >> source domain/service type to the SRV-ID in the certificate. > > It is not. RFC 4985 says the following in section 2: > > _Service.Name > > > > Name > The DNS domain name of the domain where the specified service > is located. Perhaps some examples would help. The good folks at example.com have delegated their IM service to apps.hosting.net. When the user someone@example.com does an SRV lookup for _xmpp-client._tcp im.example.com, its client gets back something like this: 20 0 5222 apps.hosting.net. The client resolves apps.hosting.net to an IP address and connects to that machine. During TLS negotiation, the application service for example.com (which is in fact being serviced by apps.hosting.net) presents a certificate that contains an SRV-ID. Which of the following is it? 1. _xmpp.example.com or: 2. _xmpp.apps.hosting.net If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in RFC 2782. If #2, then the "Name" in _Service.Name is actually a "Target" as defined in RFC 2782. >> 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). >> > > Since this is not the definition of SRVName, this type of matching does not > apply. Again: is the definition of SRVName in RFC 4985 consistent with RFC 2782 (i.e., 4985 "Name" is 2782 "Name") or is it inconsistent with RFC 2782 (i.e., 4985 "Name" actually is 2782 "Target")? >>> 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. See my previous note. This text needs to be clarified as I suggested, so that it talks about whether the reference identifier is based on the source domain or the target domain. This I-D is attempting to forbid or at least strongly discourage basing the reference identifier on the target (derived) domain. If RFC 4985 allows the presented identifier to be the target domain as a matter of course then I think we have a problem. > RFC 4985 provides the client with a way to authenticate a host that it > believes is authorized to provide a specific service in the target domain. Believes on what basis? > It does not matter from where the client has obtained that authorization > information or whether that information is trustworthy. That's a strange statement to make in the context of security. > A client may very well do an insecure DNS lookup to discover what host is > providing the requested service. The client would then contact that host and > obtained it's certificate. If the certificate is trusted and it's SRVName > matches the information provided from the DNS server, then everything is > fine. For some definition of "fine", yes. > The client now has assurance from the CA that this host is in fact > authorized to provide this service. To use my example, the CA is providing assurance that apps.hosting.net is authorized to provide the XMPP service on behalf of example.com. That seems reasonable if the presented identifier based on the source domain (example.com). However, if the assurance is checked on the client side by finding _xmpp.apps.hosting.net as the presented identifier then I fail to understand something very basic: how does the client tie that SRV-ID to the source domain (example.com) in a secure fashion? The presented identifier seems to be a mere assertion without any connection whatsoever to the source domain. If we just wave our hands and say "the client can simply let the user believe that it's OK for apps.hosting.net to assert a right to provide the IM service for example.com and it doesn't matter if there is no basis for that belief because the information might not be trustworthy" then I wonder what RFC 4985 really accomplishes or whether we want to encourage anyone to use the SRVName extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 8 15:49:17 2010 Return-Path: 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 721573A6968; Wed, 8 Sep 2010 15:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.752 X-Spam-Level: X-Spam-Status: No, score=-101.752 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, SARE_HTML_URI_LHOST30=1.666, 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 sF8XJo2rDHvk; Wed, 8 Sep 2010 15:49:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AA4B03A682E; Wed, 8 Sep 2010 15:49:15 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0526E40074; Wed, 8 Sep 2010 16:53:14 -0600 (MDT) Message-ID: <4C8812FD.1050409@stpeter.im> Date: Wed, 08 Sep 2010 16:49:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:49:18 -0000 On 9/8/10 8:21 AM, Stefan Santesson wrote: > My apology, > > I just realized that the document defines "source domain" as what I thought > would be the "target domain" > > source domain: The fully-qualified DNS domain name that a client > expects an application service to present in the certificate. > > Which makes my comments below a bit wrong. > > I think it would be better to discuss this in terms of "reference > identifier" and "presented Identifier". > > presented identifier: An identifier that is presented by a server to > a client within the server's 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. > > reference identifier: An identifier that is used by the client for > matching purposes when checking the presented identifiers; the > client can attempt to match multiple reference identifiers of > different types. > > I see no problem in obtaining the reference identifier from a DNS lookup an > the comparing it with a presented identifier in the certificate. > > Why would you require the reference identity to be provided by a human user? Because the user is trying to connect to (say) a source domain of example.com, not a target domain of apps.hosting.net. Jeff and I have assumed all along that normal humans don't know anything about such hosting services or other delegated parties (heck, normal humans know very little about SSL/TLS or certificates or DNS resolution or any of the other magic that happens behind the scences, but we assume that normal humans at least think they want to connect to bigbank.com and not possiblyshadydelegationservice.info). Peter -- Peter Saint-Andre https://stpeter.im/ From bernard_aboba@hotmail.com Wed Sep 8 15:29:07 2010 Return-Path: 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 7052E3A6991; Wed, 8 Sep 2010 15:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.736 X-Spam-Level: X-Spam-Status: No, score=-101.736 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, 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 Yin-jEbLrDqL; Wed, 8 Sep 2010 15:29:05 -0700 (PDT) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by core3.amsl.com (Postfix) with ESMTP id 74FE83A682E; Wed, 8 Sep 2010 15:29:05 -0700 (PDT) Received: from BLU137-DS12 ([65.55.111.73]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Sep 2010 15:29:33 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Peter Saint-Andre'" , "'t.petch'" References: , <00c301cb4dcc$f7be44a0$4001a8c0@gateway.2wire.net> <00b701cb4f2d$a1c29e40$4001a8c0@gateway.2wire.net> <4C8809D4.9010603@stpeter.im> In-Reply-To: <4C8809D4.9010603@stpeter.im> Date: Wed, 8 Sep 2010 15:29:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQENyKL5Lgta0fr6nt5F+jUK6VKoNgLYVKvYAiLGiAcCHKynaQJkDbg/lDfaXrA= Content-Language: en-us X-OriginalArrivalTime: 08 Sep 2010 22:29:33.0376 (UTC) FILETIME=[4F982400:01CB4FA5] X-Mailman-Approved-At: Wed, 08 Sep 2010 18:10:59 -0700 Cc: 'IETF cert-based identity' , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:29:07 -0000 Peter said: "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" [BA] IMHO, this text is much clearer. Thanks! -- Peter Saint-Andre https://stpeter.im/ From stefan@aaa-sec.com Wed Sep 8 16:00:21 2010 Return-Path: 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 37B5A3A698A for ; Wed, 8 Sep 2010 16:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.406 X-Spam-Level: X-Spam-Status: No, score=-102.406 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Tlb3BlllUZl1 for ; Wed, 8 Sep 2010 16:00:19 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 3702B3A6981 for ; Wed, 8 Sep 2010 16:00:19 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D88303BB5F8 for ; Thu, 9 Sep 2010 00:59:40 +0200 (CEST) Received: (qmail 69327 invoked from network); 8 Sep 2010 22:59:43 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Sep 2010 22:59:43 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Sep 2010 00:59:29 +0200 From: Stefan Santesson To: Peter Saint-Andre Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActPqX3eKc3SIeJbTE+KOpnRzFkIvA== In-Reply-To: <4C8807AC.9020808@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 08 Sep 2010 18:11:01 -0700 Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 23:00:21 -0000 Peter, I don't see the problem with accepting a host names provided by DNS SRV record as the reference identity. Could you elaborate the threat? Example: I ask the DNS for the host providing smtp services for example.com I get back that the following hosts are available smtp1.example.com, and; smtp2.example.com I contact the first one using a TSL connection and receives a server certificate with the SRVName _smtp.example.com and the dNSName smtp1.example.com The certificate confirms that the host in fact is smtp1.example.com and that it is authorized to provide smtp services for the domain example.com. That is all you need. The host name from the DNS server was setting you on the track but is not considered trusted. What you trust is the names in the certificate. As to IdP services. This type of redirect is extremely common and widely deployed in SAML. Example: The client connects to a service by choice. That service is retrieving the metadata for the identity federation from a central database. Among other things this metadata contains URLs to all approved Identity provides (IdP) in the federation. In order to allow the user to select the appropriate IdP service the user may first be directed to a SAML discovery service (often called WAYF = "Where Are You From"). The WAYF service redirects the user back to the original service with information about the selected IdP. The Service locates the IdP from the metadata and redirects the user to its IdP for identification. The user is then handed a ticket (SAML assertion) and gets redirected back to the service with the ticket. Again, this is very common and designed and has undergone thorough security reviews in a very large community. I think it is very bold of the IETF to claim that SAML got it wrong and should not be allowed. Unfortunately, for these reasons I still don't think the proposed text is satisfactory /Stefan On 10-09-09 12:01 AM, "Peter Saint-Andre" wrote: > On 9/8/10 11:28 AM, Stefan Santesson wrote: >> For clarity, I'll provide two examples where I think it is motivated to >> obtain the FQDN reference identifier in an automated fashion and not through >> direct user input or configuration (contrary to section 5.1). > > Thanks for the examples. > >> 1) Obtaining EU Trusted Lists >> EU has standardized on XML based lists over national Trust Service Providers >> and their certificates. Each country in the EU publish their own list. >> The EU commission provides a central list with all the URLs to each national >> list. >> >> The first step is for the client to establish a secure connection with the >> EU commission and download the EU list. This is done by configuration. >> >> The second step is to automatically obtain reference identifiers for all >> national lists from the EU list. >> >> >> 2) Redirects from a trusted service. >> If I connect to a trusted service and then get redirected to another host, >> it can be reasonable to obtain the reference identifier from the rediricet. >> Typical application I can think of is a redirect to a SAML IdP or a SAML >> Discovery service. > > It seems to me that in both of these cases, the user has placed trust in > a certain entity (the EU's system of trust service providers, a > particular trusted service) and has configured his or her application > client to allow that entity to transform a source domain into a > target-domain-based reference identifier for the purposes of secure > connection. (One could argue that DNSSEC might result in a similar > arrangement.) > > Would the following text address the scenarios you mention? > > ### > > 5.1. Service Delegation > > When the connecting application is an interactive client, the source > domain name and service type SHOULD 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 SHOULD 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. > > There are several scenarios in which it can be legitimate for an > interactive client to override the recommendation in the foregoing > rule. Examples include: > > 1. A human user has explicitly configured the client to associate a > particular target domain with a given source domain (e.g., for > connection and identity checking purposes the user has explicitly > approved "apps.example.net" as the target domain associated with > a source domain of "example.com"). > > 2. A human user has explicitly agreed to trust a service that > provides mappings of source domains to target domains, such as a > dedicated discovery service or an identity service that securely > redirects requests from the source domain to a target domain > (however, such an arrangement is not encouraged and if a client > supports such a service then it needs to disable it by default > and carefully warn the user about the possible negative > consequences of trusting such a service). > > ### > > I'm quite leery of these identity mapping services you have mentioned; I > can see that some people might trust them, but I think we need to > encourage clients to clearly and forcefully warn users about them, > because trusting such a service means handing over a great deal of power. > > /psa > >> /Stefan >> >> >> On 10-09-08 4:21 PM, "Stefan Santesson" wrote: >> >>> My apology, >>> >>> I just realized that the document defines "source domain" as what I thought >>> would be the "target domain" >>> >>> source domain: The fully-qualified DNS domain name that a client >>> expects an application service to present in the certificate. >>> >>> Which makes my comments below a bit wrong. >>> >>> I think it would be better to discuss this in terms of "reference >>> identifier" >>> and "presented Identifier". >>> >>> presented identifier: An identifier that is presented by a server to >>> a client within the server's 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. >>> >>> reference identifier: An identifier that is used by the client for >>> matching purposes when checking the presented identifiers; the >>> client can attempt to match multiple reference identifiers of >>> different types. >>> >>> I see no problem in obtaining the reference identifier from a DNS lookup an >>> the comparing it with a presented identifier in the certificate. >>> >>> Why would you require the reference identity to be provided by a human user? >>> >>> /Stefan >>> >>> >>> >>> On 10-09-08 3:40 PM, "Stefan Santesson" wrote: >>> >>>> Being the author of RFC 4985 I agree with most of you say here. >>>> >>>> Comments in line; >>>> >>>> On 10-09-06 8:48 PM, "Bernard Aboba" wrote: >>>> >>>>> 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. >>>>> >>>> >>>> This puzzled me as well. The domain of interest is the domain where the >>>> requested service is located = target domain. >>>> >>>>> As noted elsewhere, RFC 4985 appears to require matching of the >>>>> source domain/service type to the SRV-ID in the certificate. >>>> >>>> It is not. RFC 4985 says the following in section 2: >>>> >>>> _Service.Name >>>> >>>> >>>> >>>> Name >>>> The DNS domain name of the domain where the specified service >>>> is located. >>>> >>>> >>>>> 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). >>>>> >>>> >>>> Since this is not the definition of SRVName, this type of matching does not >>>> apply. >>>> >>>>> >>>>>> 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. >>>>>> >>>> >>>> RFC 4985 provides the client with a way to authenticate a host that it >>>> believes is authorized to provide a specific service in the target domain. >>>> >>>> It does not matter from where the client has obtained that authorization >>>> information or whether that information is trustworthy. >>>> >>>> A client may very well do an insecure DNS lookup to discover what host is >>>> providing the requested service. The client would then contact that host >>>> and >>>> obtained it's certificate. If the certificate is trusted and it's SRVName >>>> matches the information provided from the DNS server, then everything is >>>> fine. >>>> >>>> The client now has assurance from the CA that this host is in fact >>>> authorized >>>> to provide this service. >>>> >>>> >>>> /Stefan >>>> From jimsch@nwlink.com Mon Sep 6 22:07:12 2010 Return-Path: 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 DD92A3A6782; Mon, 6 Sep 2010 22:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=1.739, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6] 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 S-ZT3LIQlGjW; Mon, 6 Sep 2010 22:07:05 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 4642A3A6971; Mon, 6 Sep 2010 22:07:05 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTP id 110506EF64; Mon, 6 Sep 2010 22:07:31 -0700 (PDT) From: "James Schaad" To: , , References: In-Reply-To: Date: Mon, 6 Sep 2010 22:14:33 -0700 Message-ID: <000701cb4e4b$8f8f5480$aeadfd80$@nwlink.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01CB4E10.E3390800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQND7Iu6/+NhgYxajluQqz7CT/Ju85AN7QVg Content-Language: en-us X-Mailman-Approved-At: Wed, 08 Sep 2010 18:11:03 -0700 Cc: tls@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 05:07:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01CB4E10.E3390800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1. There are those who say that the DNS system is dead for dealing with identification of items. That the main way that people find items these days is by doing searches. This should perhaps be acknowledged in section 1.3 under the DNS domain names section. I.e. we use DNS names still for some things (such as SMTP servers), but for many things the name that the user knows is obtained in a very indirect manner. (search, URL click, address book entry) In a similar manner today people don't remember telephone numbers as they are all indirectly obtained, but they do write them down to give to other people. 2. Do you consider an HTTP redirect to still be a direct name or is this now an indirect name? The simplest method would be to go from an http: to an https: but other types of redirects are also interesting - not the least is just clicking w/o actually looking at where you are going. 3. You might want to also give a domain-component (dc=) version of the common name for doing identifiers - and then say it is out of scope. i.e. "dc=com, dc=example, dc=www" 4. You might want to add to the implementation note on page 15 that there is not always agreement about the order that the strings should be displayed in. Thus for some the root RDN is displayed first but for others it is displayed last. (Thus the CERT_NAME_STR_REVERSE_FLAG for the CertStrToName function from Microsoft.) 5. In section 3, what about URI-ID and SVN-ID - are multiple of these name forms allowed or not? Since 5 is explicit on CN-ID and DNS-ID I think that the other two name forms should be covered as well. 6. I am not really happy with the choice of wording for 'and aborting the search' - in my mind you abort for bad conditions and not for good conditions. Stop the search, exit the search are all reasonable and don't imply an error state. 7. I got confused and started to say that you needed to do wildcards in section 4.4.1 because that is not referenced in the text of section 4.4. It is not clear how the wildcard label matching should be done dependent on the tradition vs. internationalized domain name difference. The client MUST match the source domain of a reference identifier according to the following rules. The rules used depends on whether the source domain is a "traditional domain name" or an "internationalized domain name" as previously defined, and if wildcard labels are permitted. 8. Does the following statement apply in section 4.4.2? What does it mean for 4.4.1 if a wildcard is present? Each label MUST match in order for the names to be considered to match. I think that it is confusing and should potentially be removed. 9. In section 4.6.2 - I can understand that a certificate "change" by having the certification path change. However if one were to change the DNS domain name, identifiers, issuer or expiration date, I don't understand how one would say that it is the same cached certificate? Do you expect clients to cache the certificate based one something other than the actual bytes of the certificate? i.e. the public key and subject name? Or are you trying to address the case where for the specific reference identifier there exists a cached certificate and the certificate that was presented is a different certificate from the one that was cached? (In which case one should potentially say that one needs to fall into the 4.6.3 logic after informing the user of the fact.) From: Joe Salowey [mailto:jsalowey@cisco.com] Sent: Wednesday, September 01, 2010 8:14 PM To: ekr@rtfm.com; Sean Turner; yngve@opera.com; jimsch@exmsft.com; ietf@hardakers.net; jsalowey@cisco.com Subject: Review of draft-saintandre-tls-server-id-check At IETF-78 you accepted the task of reviewing draft-saintandre-tls-server-id-check. We'd like to get this draft moving and we think it needs wide review. Please let me know when you think you will be able to complete a review of the draft. Thanks, Joe ------=_NextPart_000_0008_01CB4E10.E3390800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Review of = draft-saintandre-tls-server-id-check

1.  There are those who say that the DNS system is dead for = dealing with identification of items.  That the main way that = people find items these days is by doing  searches.  This = should perhaps be acknowledged in section 1.3 under the DNS domain names = section.  I.e. we use DNS names still for some things (such as SMTP = servers), but for many things the name that the user knows is obtained = in a very indirect manner. (search, URL click, address book entry)  = In a similar manner today people don’t remember telephone numbers = as they are all indirectly obtained, but they do write them down to give = to other people.

 

2.  Do you consider an HTTP redirect to still be a direct name = or is this now an indirect name?  The simplest method would be to = go from an http: to an https: but other types of redirects are also = interesting – not the least is just clicking w/o actually looking = at where you are going.

 

3.  You might want to also give a domain-component (dc=3D) = version of the common name for doing identifiers – and then say it = is out of scope.  i.e.  “dc=3Dcom, dc=3Dexample, = dc=3Dwww”

 

4.  You might want to add to the implementation note on page 15 = that there is not always agreement about the order that the strings = should be displayed in.  Thus for some the root RDN is displayed = first but for others it is displayed last.  (Thus the = CERT_NAME_STR_REVERSE_FLAG for the CertStrToName function from = Microsoft.)

 

5.  In section 3, what about URI-ID and SVN-ID – are = multiple of these name forms allowed or not?  Since 5 is explicit = on CN-ID and DNS-ID I think that the other two name forms should be = covered as well.

 

6.  I am not really happy with the choice of wording for = ‘and aborting the search’ – in my mind you abort for = bad conditions and not for good conditions.  Stop the search, exit = the search are all reasonable and don’t imply an error = state.

 

7.  I got confused and started to say that you needed to do = wildcards in section 4.4.1 because that is not referenced in the text of = section 4.4.  It is not clear how the wildcard label matching = should be done dependent on the tradition vs. internationalized domain = name difference.

 

The client MUST match the source =
domain of a reference identifier
according to the =
following rules.  The rules used depends on whether the =
source
domain is a "traditional domain =
name" or an "internationalized =
domain
name" as previously defined, and if =
wildcard labels are =
permitted.
 

8.  Does the following statement apply in section 4.4.2?  = What does it mean for 4.4.1 if a wildcard is present? = 

        =
Each label MUST match in order for the names to be considered to =
match.

           &nbs= p;    I think that it is confusing and should potentially = be removed.

 

9.  In section 4.6.2 – I can understand that a certificate = “change” by having the certification path change.  = However if one were to change the DNS domain name, identifiers, issuer = or expiration date, I don’t understand how one would say that it = is the same cached certificate?  Do you expect clients to cache the = certificate based one something other than the actual bytes of the = certificate?  i.e. the public key and subject name?   Or = are you trying to address the case where for the specific reference = identifier there exists a cached certificate and the certificate that = was presented is a different certificate from the one that was = cached?  (In which case one should potentially say that one needs = to fall into the 4.6.3 logic after informing the user of the = fact.)

 

 

From:= = Joe Salowey [mailto:jsalowey@cisco.com]
Sent: Wednesday, = September 01, 2010 8:14 PM
To: ekr@rtfm.com; Sean Turner; = yngve@opera.com; jimsch@exmsft.com; ietf@hardakers.net; = jsalowey@cisco.com
Subject: Review of = draft-saintandre-tls-server-id-check

 

At = IETF-78 you accepted the task of reviewing = draft-saintandre-tls-server-id-check.   We’d like to get = this draft moving and we think it needs wide review.  Please let me = know when you think you will be able to complete a review of the draft. =

Thanks,

Joe

------=_NextPart_000_0008_01CB4E10.E3390800-- From stefan@aaa-sec.com Wed Sep 8 16:40:26 2010 Return-Path: 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 BA2A73A68EA for ; Wed, 8 Sep 2010 16:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.458 X-Spam-Level: X-Spam-Status: No, score=-102.458 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 4KsYIU66tR+d for ; Wed, 8 Sep 2010 16:40:15 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id D70CE3A699A for ; Wed, 8 Sep 2010 16:40:03 -0700 (PDT) Received: from s128.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 7EDD13B56F3 for ; Thu, 9 Sep 2010 01:39:41 +0200 (CEST) Received: (qmail 16864 invoked from network); 8 Sep 2010 23:39:32 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Sep 2010 23:39:32 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Sep 2010 01:39:30 +0200 From: Stefan Santesson To: Peter Saint-Andre Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActPrxT6XIinfMb2m0W1nAT5bqy3PQ== In-Reply-To: <4C880FBB.7070309@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 08 Sep 2010 18:11:02 -0700 Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 23:40:26 -0000 Peter, Thank for the clarifying example. I see now what problem you are addressing. Comments in line; On 10-09-09 12:35 AM, "Peter Saint-Andre" wrote: >> It is not. RFC 4985 says the following in section 2: >> >> _Service.Name >> >> >> >> Name >> The DNS domain name of the domain where the specified service >> is located. > > Perhaps some examples would help. > > The good folks at example.com have delegated their IM service to > apps.hosting.net. When the user someone@example.com does an SRV lookup > for _xmpp-client._tcp im.example.com, its client gets back something > like this: > > 20 0 5222 apps.hosting.net. > > The client resolves apps.hosting.net to an IP address and connects to > that machine. > > During TLS negotiation, the application service for example.com (which > is in fact being serviced by apps.hosting.net) presents a certificate > that contains an SRV-ID. Which of the following is it? > > 1. _xmpp.example.com > > or: > > 2. _xmpp.apps.hosting.net > According to the actual intent of RFC 4985 the right answer is 1, however reading the definition of the name form it suggests 2, since this is where the service is located. However I think this is an error in RFC 4985. See below. In case of 2, If the DNS fooled you, then you may end up at an authorized service for hosting.net that has no business serving example.com, and you have no way to tell. > If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in > RFC 2782. > > If #2, then the "Name" in _Service.Name is actually a "Target" as > defined in RFC 2782. > >> The client now has assurance from the CA that this host is in fact >> authorized to provide this service. > > To use my example, the CA is providing assurance that apps.hosting.net > is authorized to provide the XMPP service on behalf of example.com. That > seems reasonable if the presented identifier based on the source domain > (example.com). However, if the assurance is checked on the client side > by finding _xmpp.apps.hosting.net as the presented identifier then I > fail to understand something very basic: how does the client tie that > SRV-ID to the source domain (example.com) in a secure fashion? The > presented identifier seems to be a mere assertion without any connection > whatsoever to the source domain. I actually think we made an error in 4985 and that the domain name should be the domain that the service is authorized to represent. RFC 4985 is ambiguous here: the definition of the name form says: "The DNS domain name of the domain where the specified service is located." This corresponds to #2 in your example While the description underneath the definition states: "The purpose of the SRVName is limited to authorization of service provision within a domain." Which corresponds to #1. I think there should be an errata correcting the definition to be: "The DNS domain name of a domain for which the certified subject is authorized to provide the identified service." As it is now, the RFC is ambiguous. > If we just wave our hands and say "the > client can simply let the user believe that it's OK for apps.hosting.net > to assert a right to provide the IM service for example.com and it > doesn't matter if there is no basis for that belief because the > information might not be trustworthy" then I wonder what RFC 4985 really > accomplishes or whether we want to encourage anyone to use the SRVName > extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna). > I agree. But if we can correct the definition (or specify a new OID for a corrected name form) according to my proposal above, and clarify the use in your document, would that help in any way? I agree that if the SRVName in the cert provides a domain name that is different from the domain name you asked for (and it's not DNSSEC), then you will have to rely on local configuration in order to accept it. I'm not sure how we should fix this. We had quite large review of this RFC but nobody caught this error. /Stefan From stefan@aaa-sec.com Wed Sep 8 16:45:55 2010 Return-Path: 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 0A5873A6781 for ; Wed, 8 Sep 2010 16:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 UG8Zthi6oLoG for ; Wed, 8 Sep 2010 16:45:53 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 7BA493A6941 for ; Wed, 8 Sep 2010 16:45:52 -0700 (PDT) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 54B153E8F7B for ; Thu, 9 Sep 2010 01:45:58 +0200 (CEST) Received: (qmail 44728 invoked from network); 8 Sep 2010 23:46:09 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Sep 2010 23:46:09 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Sep 2010 01:45:41 +0200 From: Stefan Santesson To: Peter Saint-Andre , "t.petch" Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActPr/IcxDfkyKbczEWnRH3Oj/7CRQ== In-Reply-To: <4C8809D4.9010603@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 08 Sep 2010 18:11:03 -0700 Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 23:45:55 -0000 On 10-09-09 12:10 AM, "Peter Saint-Andre" wrote: > 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 Could we remove "and service type" from that sentence. It is the domain name that is the problem and not the service type right? I mean, the app may very well know that it is supposed to talk to an XMPP service without asking a human user. /Stefan From stpeter@stpeter.im Thu Sep 9 10:55:28 2010 Return-Path: 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 E6A893A6919; Thu, 9 Sep 2010 10:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 2ovkIkNKQlRu; Thu, 9 Sep 2010 10:55:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C01EF3A6A65; Thu, 9 Sep 2010 10:55:16 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7101540074; Thu, 9 Sep 2010 11:59:27 -0600 (MDT) Message-ID: <4C891F9E.4020608@stpeter.im> Date: Thu, 09 Sep 2010 11:55:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, "t.petch" Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 17:55:29 -0000 On 9/8/10 5:45 PM, Stefan Santesson wrote: > > > > On 10-09-09 12:10 AM, "Peter Saint-Andre" wrote: > >> 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 > > Could we remove "and service type" from that sentence. > It is the domain name that is the problem and not the service type right? > > I mean, the app may very well know that it is supposed to talk to an XMPP > service without asking a human user. Yes, that change makes sense. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Sep 9 10:56:49 2010 Return-Path: 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 C372F3A6831; Thu, 9 Sep 2010 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 RSBp28bopKHQ; Thu, 9 Sep 2010 10:56:41 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9A7833A680C; Thu, 9 Sep 2010 10:56:41 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BCC5040074; Thu, 9 Sep 2010 12:00:52 -0600 (MDT) Message-ID: <4C891FF3.8070607@stpeter.im> Date: Thu, 09 Sep 2010 11:57:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 17:56:49 -0000 On 9/8/10 5:39 PM, Stefan Santesson wrote: > Peter, > > Thank for the clarifying example. I see now what problem you are addressing. > > Comments in line; I'm short on time right now so will reply briefly at the end. > On 10-09-09 12:35 AM, "Peter Saint-Andre" wrote: > > > >>> It is not. RFC 4985 says the following in section 2: >>> >>> _Service.Name >>> >>> >>> >>> Name >>> The DNS domain name of the domain where the specified service >>> is located. >> >> Perhaps some examples would help. >> >> The good folks at example.com have delegated their IM service to >> apps.hosting.net. When the user someone@example.com does an SRV lookup >> for _xmpp-client._tcp im.example.com, its client gets back something >> like this: >> >> 20 0 5222 apps.hosting.net. >> >> The client resolves apps.hosting.net to an IP address and connects to >> that machine. >> >> During TLS negotiation, the application service for example.com (which >> is in fact being serviced by apps.hosting.net) presents a certificate >> that contains an SRV-ID. Which of the following is it? >> >> 1. _xmpp.example.com >> >> or: >> >> 2. _xmpp.apps.hosting.net >> > > According to the actual intent of RFC 4985 the right answer is 1, however > reading the definition of the name form it suggests 2, since this is where > the service is located. However I think this is an error in RFC 4985. See > below. > > In case of 2, If the DNS fooled you, then you may end up at an authorized > service for hosting.net that has no business serving example.com, and you > have no way to tell. > > >> If #1, then the "Name" in _Service.Name is indeed a "Name" as defined in >> RFC 2782. >> >> If #2, then the "Name" in _Service.Name is actually a "Target" as >> defined in RFC 2782. >> > > >>> The client now has assurance from the CA that this host is in fact >>> authorized to provide this service. >> >> To use my example, the CA is providing assurance that apps.hosting.net >> is authorized to provide the XMPP service on behalf of example.com. That >> seems reasonable if the presented identifier based on the source domain >> (example.com). However, if the assurance is checked on the client side >> by finding _xmpp.apps.hosting.net as the presented identifier then I >> fail to understand something very basic: how does the client tie that >> SRV-ID to the source domain (example.com) in a secure fashion? The >> presented identifier seems to be a mere assertion without any connection >> whatsoever to the source domain. > > I actually think we made an error in 4985 and that the domain name should be > the domain that the service is authorized to represent. > > RFC 4985 is ambiguous here: the definition of the name form says: > > "The DNS domain name of the domain where the specified service > is located." > > This corresponds to #2 in your example > While the description underneath the definition states: > > "The purpose of the SRVName is limited to authorization of service > provision within a domain." > > Which corresponds to #1. > > I think there should be an errata correcting the definition to be: > > "The DNS domain name of a domain for which the certified subject > is authorized to provide the identified service." > > As it is now, the RFC is ambiguous. > >> If we just wave our hands and say "the >> client can simply let the user believe that it's OK for apps.hosting.net >> to assert a right to provide the IM service for example.com and it >> doesn't matter if there is no basis for that belief because the >> information might not be trustworthy" then I wonder what RFC 4985 really >> accomplishes or whether we want to encourage anyone to use the SRVName >> extension (at least absent DNSSEC, see for example draft-barnes-xmpp-dna). >> > > I agree. But if we can correct the definition (or specify a new OID for a > corrected name form) according to my proposal above, and clarify the use in > your document, would that help in any way? > > I agree that if the SRVName in the cert provides a domain name that is > different from the domain name you asked for (and it's not DNSSEC), then you > will have to rely on local configuration in order to accept it. I'm happy that we're all on the same page and that we only have a spec error in RFC 4985. > I'm not sure how we should fix this. We had quite large review of this RFC > but nobody caught this error. Submitting an erratum is a good first step, I think. Peter -- Peter Saint-Andre https://stpeter.im/ From shuque@isc.upenn.edu Thu Sep 9 11:11:22 2010 Return-Path: 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 EE61D3A688A; Thu, 9 Sep 2010 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599] 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 H4HfCoM21djp; Thu, 9 Sep 2010 11:11:21 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 7A08A3A67EC; Thu, 9 Sep 2010 11:11:10 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id B8D9626E4; Thu, 9 Sep 2010 14:11:37 -0400 (EDT) Date: Thu, 9 Sep 2010 14:11:37 -0400 From: Shumon Huque To: Stefan Santesson Message-ID: <20100909181137.GA3460@isc.upenn.edu> References: <4C8807AC.9020808@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 18:11:23 -0000 On Thu, Sep 09, 2010 at 12:59:29AM +0200, Stefan Santesson wrote: > Peter, > > I don't see the problem with accepting a host names provided by DNS SRV > record as the reference identity. > > Could you elaborate the threat? > > Example: > > I ask the DNS for the host providing smtp services for example.com > I get back that the following hosts are available > > smtp1.example.com, and; > smtp2.example.com > > I contact the first one using a TSL connection and receives a server > certificate with the SRVName _smtp.example.com and the dNSName > smtp1.example.com > > The certificate confirms that the host in fact is smtp1.example.com and that > it is authorized to provide smtp services for the domain example.com. > > That is all you need. The host name from the DNS server was setting you on > the track but is not considered trusted. What you trust is the names in the > certificate. This is a more complicated example than the current draft addresses. In your example, the client is verifying "a combination of identifiers" (SRVName and dNSName) in the certificate. This seems like a reasonable thing to do, but this is not what most clients do today (I'd be happy to be corrected about that). Typically, they consider a match successful once they've found a single acceptable reference identifier. In that case, you can't simply use a reference identifier that contains a DNS mapped identifier unless you've obtained it an authenticated (or statically configured) manner. -- Shumon Huque University of Pennsylvania. From shuque@isc.upenn.edu Thu Sep 9 11:38:11 2010 Return-Path: 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 5A3763A6855; Thu, 9 Sep 2010 11:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.743 X-Spam-Level: X-Spam-Status: No, score=-3.743 tagged_above=-999 required=5 tests=[AWL=-1.144, BAYES_00=-2.599] 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 lDUsoHQNFQDz; Thu, 9 Sep 2010 11:38:10 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id AE3CE3A6894; Thu, 9 Sep 2010 11:38:02 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 42F0926E4; Thu, 9 Sep 2010 14:38:29 -0400 (EDT) Date: Thu, 9 Sep 2010 14:38:29 -0400 From: Shumon Huque To: Stefan Santesson Message-ID: <20100909183829.GA4332@isc.upenn.edu> References: <4C880FBB.7070309@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 18:38:11 -0000 On Thu, Sep 09, 2010 at 01:39:30AM +0200, Stefan Santesson wrote: > > I actually think we made an error in 4985 and that the domain name should be > the domain that the service is authorized to represent. > > RFC 4985 is ambiguous here: the definition of the name form says: > > "The DNS domain name of the domain where the specified service > is located." > > This corresponds to #2 in your example > While the description underneath the definition states: > > "The purpose of the SRVName is limited to authorization of service > provision within a domain." > > Which corresponds to #1. > > I think there should be an errata correcting the definition to be: > > "The DNS domain name of a domain for which the certified subject > is authorized to provide the identified service." > > As it is now, the RFC is ambiguous. Earlier in RFC 4985, it says: The SRVName, if present, MUST contain a service name and a domain name in the following form: _Service.Name The content of the components of this name form MUST be consistent with the corresponding definition of these components in an SRV RR according to RFC 2782 I think this was actually clear enough. The subsequent statement that Name is "The DNS domain name of the domain where the specified service is located." (which could mean any of a number of things) confused the issue, and probably should not have been in the document. -- Shumon Huque University of Pennsylvania. From stefan@aaa-sec.com Thu Sep 9 12:29:57 2010 Return-Path: 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 9D8E93A6855 for ; Thu, 9 Sep 2010 12:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 EUR40732W2-m for ; Thu, 9 Sep 2010 12:29:56 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 826863A677E for ; Thu, 9 Sep 2010 12:29:56 -0700 (PDT) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 03BDA3859AD for ; Thu, 9 Sep 2010 21:30:03 +0200 (CEST) Received: (qmail 58979 invoked from network); 9 Sep 2010 19:29:55 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Sep 2010 19:29:55 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Sep 2010 21:29:53 +0200 From: Stefan Santesson To: Shumon Huque Message-ID: Thread-Topic: [certid] Review of draft-saintandre-tls-server-id-check Thread-Index: ActQVWBnZiGXzzdlrkmGCvUA3UdZ8w== In-Reply-To: <20100909181137.GA3460@isc.upenn.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 19:29:57 -0000 On the issue of checking multiple name forms. I would put it in another way. Web clients are typically only used to check the domain name and nothing else because it is the only thing they care about and know how to match. PKI enabled clients in general are used to check numerous of name forms and attributes in order to determine a match. When you add SRV-ID to the pool you change what is usual in the case of TLS. I think it is wrong to say as a general rule that a certificate successfully maps to the appropriate server if either the SRV-Name or the DNS Name matches. To me this is highly context dependent where different protocols and applications have different needs. If the only thing I need to know is that the server is authorized to deliver the requested service for the requested domain, then SRVName match only is OK. If you need to know that this host is the host it claims to be, then it's not. What needs to be checked is to me a typical case of local policy and one size does not fit all. /Stefan On 10-09-09 8:11 PM, "Shumon Huque" wrote: > On Thu, Sep 09, 2010 at 12:59:29AM +0200, Stefan Santesson wrote: >> Peter, >> >> I don't see the problem with accepting a host names provided by DNS SRV >> record as the reference identity. >> >> Could you elaborate the threat? >> >> Example: >> >> I ask the DNS for the host providing smtp services for example.com >> I get back that the following hosts are available >> >> smtp1.example.com, and; >> smtp2.example.com >> >> I contact the first one using a TSL connection and receives a server >> certificate with the SRVName _smtp.example.com and the dNSName >> smtp1.example.com >> >> The certificate confirms that the host in fact is smtp1.example.com and that >> it is authorized to provide smtp services for the domain example.com. >> >> That is all you need. The host name from the DNS server was setting you on >> the track but is not considered trusted. What you trust is the names in the >> certificate. > > This is a more complicated example than the current draft > addresses. > > In your example, the client is verifying "a combination of > identifiers" (SRVName and dNSName) in the certificate. This > seems like a reasonable thing to do, but this is not what > most clients do today (I'd be happy to be corrected about > that). Typically, they consider a match successful once they've > found a single acceptable reference identifier. In that case, > you can't simply use a reference identifier that contains > a DNS mapped identifier unless you've obtained it an authenticated > (or statically configured) manner. From stefan@aaa-sec.com Thu Sep 9 12:39:17 2010 Return-Path: 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 8A12C3A68EC for ; Thu, 9 Sep 2010 12:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 bQ0PjbbvWC6N for ; Thu, 9 Sep 2010 12:38:58 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 5AA9C3A68E3 for ; Thu, 9 Sep 2010 12:38:22 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id D15773A6849 for ; Thu, 9 Sep 2010 21:37:03 +0200 (CEST) Received: (qmail 71161 invoked from network); 9 Sep 2010 19:36:55 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Sep 2010 19:36:55 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Sep 2010 21:36:54 +0200 From: Stefan Santesson To: Shumon Huque Message-ID: Thread-Topic: [certid] Review of draft-saintandre-tls-server-id-check Thread-Index: ActQVltWPSULorgnYEC0PcrppggBrg== In-Reply-To: <20100909183829.GA4332@isc.upenn.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 19:39:17 -0000 On 10-09-09 8:38 PM, "Shumon Huque" wrote: > Earlier in RFC 4985, it says: > > The SRVName, if present, MUST contain a service name and a domain > name in the following form: > > _Service.Name > > The content of the components of this name form MUST be consistent > with the corresponding definition of these components in an SRV RR > according to RFC 2782 > > I think this was actually clear enough. The subsequent statement that > Name is "The DNS domain name of the domain where the specified service > is located." (which could mean any of a number of things) confused the > issue, and probably should not have been in the document. Agreed, but since it will be an errata, the text must be corrected. Do you agree with my proposal? "The DNS domain name of a domain for which the certified subject is authorized to provide the identified service." /Stefan From shuque@isc.upenn.edu Thu Sep 9 13:08:07 2010 Return-Path: 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 24BC33A6873; Thu, 9 Sep 2010 13:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.689 X-Spam-Level: X-Spam-Status: No, score=-3.689 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599] 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 RTYe+v35mxNK; Thu, 9 Sep 2010 13:08:06 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 376D63A686B; Thu, 9 Sep 2010 13:08:06 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 3124B26D7; Thu, 9 Sep 2010 16:08:33 -0400 (EDT) Date: Thu, 9 Sep 2010 16:08:33 -0400 From: Shumon Huque To: Stefan Santesson Message-ID: <20100909200833.GA6057@isc.upenn.edu> References: <20100909181137.GA3460@isc.upenn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 20:08:07 -0000 On Thu, Sep 09, 2010 at 09:29:53PM +0200, Stefan Santesson wrote: > On the issue of checking multiple name forms. > > I would put it in another way. Web clients are typically only used to check > the domain name and nothing else because it is the only thing they care > about and know how to match. Not just Web, but likely the various other applications listed in the appendix of draft-saintandre-tls-server-id-check also (IMAP, POP3, LDAP, ..) > PKI enabled clients in general are used to check numerous of name forms and > attributes in order to determine a match. Can you give us some examples of such applications, and where their subject identity matching rules are specified? Appendix A ("Prior Art") probably should consider them. > I think it is wrong to say as a general rule that a certificate successfully > maps to the appropriate server if either the SRV-Name or the DNS Name > matches. To me this is highly context dependent where different protocols > and applications have different needs. Yeah, I think I agree with that. Ultimately the application protocol should decide what its (potentially arbitrarily complex) identity matching rules should be. This is why I'm suspicious that the current draft can successfully achieve it's supposed goal of defining some general purpose rules or best practices. One of the ideas was that application protocol designers often don't want to be concerned with the complex details of certificate matching and verification rules and would like to refer to some standard document that does. > If the only thing I need to know is that the server is authorized to deliver > the requested service for the requested domain, then SRVName match only is > OK. If you need to know that this host is the host it claims to be, then > it's not. > > What needs to be checked is to me a typical case of local policy and one > size does not fit all. > > /Stefan > -- Shumon Huque University of Pennsylvania. From stefan@aaa-sec.com Thu Sep 9 13:56:55 2010 Return-Path: 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 991AE3A68A9 for ; Thu, 9 Sep 2010 13:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 XnX+tdkNGIMi for ; Thu, 9 Sep 2010 13:56:54 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id A171A3A6826 for ; Thu, 9 Sep 2010 13:56:54 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 0F0953CDEA9 for ; Thu, 9 Sep 2010 22:55:29 +0200 (CEST) Received: (qmail 76672 invoked from network); 9 Sep 2010 20:55:20 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Sep 2010 20:55:20 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 09 Sep 2010 22:55:08 +0200 From: Stefan Santesson To: Shumon Huque Message-ID: Thread-Topic: [certid] Review of draft-saintandre-tls-server-id-check Thread-Index: ActQYUkuy4ylGFcGm0ufK5uWZbrXNA== In-Reply-To: <20100909200833.GA6057@isc.upenn.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 20:56:55 -0000 Shumon, On 10-09-09 10:08 PM, "Shumon Huque" wrote: >> PKI enabled clients in general are used to check numerous of name forms and >> attributes in order to determine a match. > > Can you give us some examples of such applications, and where > their subject identity matching rules are specified? Appendix > A ("Prior Art") probably should consider them. Right now I have none that is applicable to the listed protocols. So I don't think I have an example that is suitable for this annex. But in general many government services using PKI are comparing multiple attributes. Many national PKIs in Europe have banned single identifiers in their certs, so the applications are forced to do multiple attribute comparisons. The thing is that name comparison is often done on an application level according to local policy and even on the user level and the only thing I have learned after spending 18 years with PKI is to expect almost anything :) In this context, EKUs are often also an important part of certificate acceptance. A dimension that I miss in the current spec. I don't think it is particularly useful to specify in generic documents what constitutes a positive identification of the subject in terms or required matching name forms. It becomes useful mostly only when you want to achieve interoperability within a reasonably narrow context. /Stefan From stpeter@stpeter.im Mon Sep 13 09:07:48 2010 Return-Path: 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 5E7D13A6872; Mon, 13 Sep 2010 09:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 p9n1YvEsFQa4; Mon, 13 Sep 2010 09:07:47 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1E1F53A69F7; Mon, 13 Sep 2010 09:07:47 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC111400EE; Mon, 13 Sep 2010 10:12:17 -0600 (MDT) Message-ID: <4C8E4C6B.3040803@stpeter.im> Date: Mon, 13 Sep 2010 10:08:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Shumon Huque References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> In-Reply-To: <20100909182253.GB3460@isc.upenn.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 16:07:48 -0000 On 9/9/10 12:22 PM, Shumon Huque wrote: > On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote: >> >> On 10-09-08 9:53 PM, "Shumon Huque" wrote: >>> The output of the SRV record lookup contains a target hostname, >>> not a service name, so it's not applicable to the SRVName name >>> form. The target could be used in another name form (dNSName) >>> as the reference identifier, but then the client needs to convince >>> itself that the lookup was done securely (DNSSEC or some other >>> means) otherwise there's a security problem. >> >> I disagree, >> >> A client can use the output from the DNS lookup also from a normal insecure >> DNS server. >> >> The only thing the client need to do is to verify that the domain name >> provided in the input to the lookup matches the host names provided in the >> output. It can then safely use the host names in the SRV record as reference >> identifiers IF the SRV-ID in the server certificate matches the the >> reference identifier. > > This only works if the certificate matching rules say something > like "match the SRVName AND also match the DNS resolved target > hostname in dNSName". If a client attempts to match _only_ the DNS > resolved hostname without DNSSEC, there is a security problem. > > The question is: what should the certificate matching rules say > when encountering a certificate with multiple identity types? > Right now the draft approximately says "find a match" (ie. find > ANY match), rather than match some logically AND'ed combination of > identity types. > > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4 Hi Shumon, As I see it, this I-D is attempting to capture best current practices regarding the issuance and checking of certificates containing application server identities. Do we have evidence that any existing certification authorities issue certificates containing both an SRVname for the source domain (e.g., example.com) and dNSName for the target domain (e.g., apphosting.example.net)? Do we have evidence that any existing application clients perform such checks? If not, I would consider such complications to be out of scope for this I-D. That said, we need to be aware that if such usage arises in the future, someone might write a document that updates or obsoletes this I-D; in fact the present authors very much expect that such documents will emerge after the Internet community (specifically certification authorities, application service providers, and application client developers) have gained more experience with PKIX certificates in the context of various application technologies. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Mon Sep 13 09:16:39 2010 Return-Path: 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 D51803A69FE for ; Mon, 13 Sep 2010 09:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.464 X-Spam-Level: X-Spam-Status: No, score=-100.464 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, 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 qkPIZ-dQS0Uk for ; Mon, 13 Sep 2010 09:16:38 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BCBF13A69A0 for ; Mon, 13 Sep 2010 09:16:38 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o8DGH2HB007426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Sep 2010 09:17:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C8E4C6B.3040803@stpeter.im> References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> Date: Mon, 13 Sep 2010 09:17:01 -0700 To: Peter Saint-Andre , Shumon Huque From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 16:16:40 -0000 At 10:08 AM -0600 9/13/10, Peter Saint-Andre wrote: >As I see it, this I-D is attempting to capture best current practices >regarding the issuance and checking of certificates containing >application server identities. Do we have evidence that any existing >certification authorities issue certificates containing both an SRVname >for the source domain (e.g., example.com) and dNSName for the target >domain (e.g., apphosting.example.net)? Do we have evidence that any >existing application clients perform such checks? If not, I would >consider such complications to be out of scope for this I-D. A big +1 here. It is a Good Thing that people are starting to look at the interaction between SRV and security (it's also happening on the keyassure list), but it definitely seems like "starting to look at". Please do not instantiate anything until this has been discussed more widely. --Paul Hoffman, Director --VPN Consortium From stpeter@stpeter.im Mon Sep 13 09:17:52 2010 Return-Path: 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 BC85C3A6A1D; Mon, 13 Sep 2010 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 SfQlhZzTvtWo; Mon, 13 Sep 2010 09:17:41 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3239C3A6A11; Mon, 13 Sep 2010 09:17:36 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E7F72400EE; Mon, 13 Sep 2010 10:22:06 -0600 (MDT) Message-ID: <4C8E4EB8.8030905@stpeter.im> Date: Mon, 13 Sep 2010 10:18:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 16:17:52 -0000 On 9/9/10 1:36 PM, Stefan Santesson wrote: > > > > On 10-09-09 8:38 PM, "Shumon Huque" wrote: > >> Earlier in RFC 4985, it says: >> >> The SRVName, if present, MUST contain a service name and a domain >> name in the following form: >> >> _Service.Name >> >> The content of the components of this name form MUST be consistent >> with the corresponding definition of these components in an SRV RR >> according to RFC 2782 >> >> I think this was actually clear enough. The subsequent statement that >> Name is "The DNS domain name of the domain where the specified service >> is located." (which could mean any of a number of things) confused the >> issue, and probably should not have been in the document. > > > Agreed, but since it will be an errata, the text must be corrected. > > Do you agree with my proposal? > > "The DNS domain name of a domain for which the certified subject > is authorized to provide the identified service." Authorized by whom? I *think* that here the DNS domain name is one that the certified subject has itself authorized (perhaps even "established" is better) to provide the desired service. Therefore I suggest an alternative wording: "A DNS domain name which the certified subject has authorized to provide the identified service." Peter -- Peter Saint-Andre https://stpeter.im/ From shuque@isc.upenn.edu Mon Sep 13 09:52:45 2010 Return-Path: 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 ECB6D3A6A11; Mon, 13 Sep 2010 09:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.639 X-Spam-Level: X-Spam-Status: No, score=-3.639 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599] 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 OLIgJf56RoN5; Mon, 13 Sep 2010 09:52:39 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 03E513A6A0C; Mon, 13 Sep 2010 09:52:34 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id DE8112713; Mon, 13 Sep 2010 12:52:59 -0400 (EDT) Date: Mon, 13 Sep 2010 12:52:59 -0400 From: Shumon Huque To: Peter Saint-Andre Message-ID: <20100913165259.GA9709@isc.upenn.edu> References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C8E4C6B.3040803@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 16:52:45 -0000 On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote: > On 9/9/10 12:22 PM, Shumon Huque wrote: > > On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote: > >> The only thing the client need to do is to verify that the domain name > >> provided in the input to the lookup matches the host names provided in the > >> output. It can then safely use the host names in the SRV record as reference > >> identifiers IF the SRV-ID in the server certificate matches the the > >> reference identifier. > > > > This only works if the certificate matching rules say something > > like "match the SRVName AND also match the DNS resolved target > > hostname in dNSName". If a client attempts to match _only_ the DNS > > resolved hostname without DNSSEC, there is a security problem. > > > > The question is: what should the certificate matching rules say > > when encountering a certificate with multiple identity types? > > Right now the draft approximately says "find a match" (ie. find > > ANY match), rather than match some logically AND'ed combination of > > identity types. > > > > http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4 > > Hi Shumon, > > As I see it, this I-D is attempting to capture best current practices > regarding the issuance and checking of certificates containing > application server identities. Yes, but whether they are actually "current" best practices is debatable. I certainly would like them to become best practices. For example I don't believe any existing commercial CAs issue certificates with the SRVName or URI SAN name forms. > Do we have evidence that any existing > certification authorities issue certificates containing both an SRVname > for the source domain (e.g., example.com) and dNSName for the target > domain (e.g., apphosting.example.net)? Do we have evidence that any > existing application clients perform such checks? If not, I would > consider such complications to be out of scope for this I-D. I think the question is whether we have examples of applications that need to verify "combinations" of subjectaltname name forms in certificates. Stefan says there are, but so far no-one has offered up any public specifications of such apps. So, I think until we have them, I agree we can defer considerations of them to future documents. I think it's reasonable for this draft to consider multiple identity types in certificates (eg. common name, dNSName, SRVName) with the current matching rules of ANY. This might be needed to gradually transition an app from validating a host specific identity to an application specific identity. The current draft allows this. > That said, we need to be aware that if such usage arises in the future, > someone might write a document that updates or obsoletes this I-D; in > fact the present authors very much expect that such documents will > emerge after the Internet community (specifically certification > authorities, application service providers, and application client > developers) have gained more experience with PKIX certificates in the > context of various application technologies. Sounds reasonable. > Peter Saint-Andre > https://stpeter.im/ > -- Shumon Huque University of Pennsylvania. From stpeter@stpeter.im Mon Sep 13 10:03:02 2010 Return-Path: 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 432193A6A72; Mon, 13 Sep 2010 10:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, 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 LQgVMQcbDWYY; Mon, 13 Sep 2010 10:03:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D4E823A6A2C; Mon, 13 Sep 2010 10:03:00 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 935B7400EE; Mon, 13 Sep 2010 11:07:31 -0600 (MDT) Message-ID: <4C8E595C.2090409@stpeter.im> Date: Mon, 13 Sep 2010 11:03:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Shumon Huque References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> <20100913165259.GA9709@isc.upenn.edu> In-Reply-To: <20100913165259.GA9709@isc.upenn.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 17:03:02 -0000 On 9/13/10 10:52 AM, Shumon Huque wrote: > On Mon, Sep 13, 2010 at 10:08:11AM -0600, Peter Saint-Andre wrote: >> On 9/9/10 12:22 PM, Shumon Huque wrote: >>> On Wed, Sep 08, 2010 at 11:08:29PM +0200, Stefan Santesson wrote: >>>> The only thing the client need to do is to verify that the domain name >>>> provided in the input to the lookup matches the host names provided in the >>>> output. It can then safely use the host names in the SRV record as reference >>>> identifiers IF the SRV-ID in the server certificate matches the the >>>> reference identifier. >>> >>> This only works if the certificate matching rules say something >>> like "match the SRVName AND also match the DNS resolved target >>> hostname in dNSName". If a client attempts to match _only_ the DNS >>> resolved hostname without DNSSEC, there is a security problem. >>> >>> The question is: what should the certificate matching rules say >>> when encountering a certificate with multiple identity types? >>> Right now the draft approximately says "find a match" (ie. find >>> ANY match), rather than match some logically AND'ed combination of >>> identity types. >>> >>> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4 >> >> Hi Shumon, >> >> As I see it, this I-D is attempting to capture best current practices >> regarding the issuance and checking of certificates containing >> application server identities. > > Yes, but whether they are actually "current" best practices is > debatable. I certainly would like them to become best practices. > For example I don't believe any existing commercial CAs issue > certificates with the SRVName or URI SAN name forms. As far as I know, at least one CA will issue certificates with the SRVName form (for XMPP certificates). We could ask some folks in the SIP community if any CAs issue certificates with the URI form (see draft-ietf-sip-certs). >> Do we have evidence that any existing >> certification authorities issue certificates containing both an SRVname >> for the source domain (e.g., example.com) and dNSName for the target >> domain (e.g., apphosting.example.net)? Do we have evidence that any >> existing application clients perform such checks? If not, I would >> consider such complications to be out of scope for this I-D. > > I think the question is whether we have examples of applications > that need to verify "combinations" of subjectaltname name forms in > certificates. Stefan says there are, but so far no-one has offered > up any public specifications of such apps. So, I think until we > have them, I agree we can defer considerations of them to future > documents. Agreed. I've never seen this I-D as the final word, but instead as the beginning of a longer-term conversation, both about the limited topic that's covered in the I-D as well as all the topics we deemed out of scope. > I think it's reasonable for this draft to consider multiple identity > types in certificates (eg. common name, dNSName, SRVName) with the > current matching rules of ANY. This might be needed to gradually > transition an app from validating a host specific identity to an > application specific identity. The current draft allows this. Correct. >> That said, we need to be aware that if such usage arises in the future, >> someone might write a document that updates or obsoletes this I-D; in >> fact the present authors very much expect that such documents will >> emerge after the Internet community (specifically certification >> authorities, application service providers, and application client >> developers) have gained more experience with PKIX certificates in the >> context of various application technologies. > > Sounds reasonable. I'm looking forward to further work in this area. Peter -- Peter Saint-Andre https://stpeter.im/ From shuque@isc.upenn.edu Mon Sep 13 10:03:14 2010 Return-Path: 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 647453A6A87; Mon, 13 Sep 2010 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599] 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 J9FZZ0iQud1N; Mon, 13 Sep 2010 10:03:13 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 456843A6A85; Mon, 13 Sep 2010 10:03:13 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 4CDC62713; Mon, 13 Sep 2010 13:03:39 -0400 (EDT) Date: Mon, 13 Sep 2010 13:03:39 -0400 From: Shumon Huque To: Peter Saint-Andre Message-ID: <20100913170339.GB9709@isc.upenn.edu> References: <4C8E4EB8.8030905@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C8E4EB8.8030905@stpeter.im> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 17:03:14 -0000 On Mon, Sep 13, 2010 at 10:18:00AM -0600, Peter Saint-Andre wrote: > On 9/9/10 1:36 PM, Stefan Santesson wrote: > > On 10-09-09 8:38 PM, "Shumon Huque" wrote: > > > >> Earlier in RFC 4985, it says: > >> > >> The SRVName, if present, MUST contain a service name and a domain > >> name in the following form: > >> > >> _Service.Name > >> > >> The content of the components of this name form MUST be consistent > >> with the corresponding definition of these components in an SRV RR > >> according to RFC 2782 > >> > >> I think this was actually clear enough. The subsequent statement that > >> Name is "The DNS domain name of the domain where the specified service > >> is located." (which could mean any of a number of things) confused the > >> issue, and probably should not have been in the document. > > > > Agreed, but since it will be an errata, the text must be corrected. > > > > Do you agree with my proposal? > > > > "The DNS domain name of a domain for which the certified subject > > is authorized to provide the identified service." > > Authorized by whom? I *think* that here the DNS domain name is one that > the certified subject has itself authorized (perhaps even "established" > is better) to provide the desired service. Therefore I suggest an > alternative wording: > > "A DNS domain name which the certified subject has > authorized to provide the identified service." > > Peter I don't think the term "authorized" makes the situation any clearer. Let's take a concrete example: an IMAP client attempting to connect to and use the IMAP service at "example.com". It needs to lookup the "_imap._tcp.example.com." DNS SRV record to figure out which servers and ports to connect to. And in the presented certificate, it needs to expect to find an SRVName identifier with "_imap.example.com" as its contents, where the _Service and Name components were the same ones it used in the SRV query. There is no need to figure out who authorized what. -- Shumon Huque University of Pennsylvania. From rbarnes@bbn.com Mon Sep 13 10:00:51 2010 Return-Path: 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 263A83A6A73; Mon, 13 Sep 2010 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, 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 Ro3FTjK4dFsT; Mon, 13 Sep 2010 10:00:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 293303A6A72; Mon, 13 Sep 2010 10:00:50 -0700 (PDT) Received: from [192.1.255.185] (port=54786 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OvCP5-000PoW-GT; Mon, 13 Sep 2010 13:01:15 -0400 Message-Id: From: "Richard L. Barnes" To: Peter Saint-Andre In-Reply-To: <4C8E4EB8.8030905@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 13 Sep 2010 13:01:13 -0400 References: <4C8E4EB8.8030905@stpeter.im> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Mon, 13 Sep 2010 10:03:23 -0700 Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 17:00:51 -0000 On Sep 13, 2010, at 12:18 PM, Peter Saint-Andre wrote: > On 9/9/10 1:36 PM, Stefan Santesson wrote: >> >> >> >> On 10-09-09 8:38 PM, "Shumon Huque" wrote: >> >>> Earlier in RFC 4985, it says: >>> >>> The SRVName, if present, MUST contain a service name and a domain >>> name in the following form: >>> >>> _Service.Name >>> >>> The content of the components of this name form MUST be consistent >>> with the corresponding definition of these components in an SRV RR >>> according to RFC 2782 >>> >>> I think this was actually clear enough. The subsequent statement >>> that >>> Name is "The DNS domain name of the domain where the specified >>> service >>> is located." (which could mean any of a number of things) confused >>> the >>> issue, and probably should not have been in the document. >> >> >> Agreed, but since it will be an errata, the text must be corrected. >> >> Do you agree with my proposal? >> >> "The DNS domain name of a domain for which the certified subject >> is authorized to provide the identified service." > > Authorized by whom? I *think* that here the DNS domain name is one > that > the certified subject has itself authorized (perhaps even > "established" > is better) to provide the desired service. Therefore I suggest an > alternative wording: > > "A DNS domain name which the certified subject has > authorized to provide the identified service." > > Peter I don't think that's right either, since it's the *issuer* of the cert that's making the assertion. Maybe something like the following: " A DNS domain name for which the issuer authorizes the subject to provide the indicated service. " From dave@cridland.net Mon Sep 13 10:04:52 2010 Return-Path: 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 B7D3A3A69F7; Mon, 13 Sep 2010 10:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] 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 5PDCsCBuTyOs; Mon, 13 Sep 2010 10:04:51 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id AC3BB3A69A7; Mon, 13 Sep 2010 10:04:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A990E11680C6; Mon, 13 Sep 2010 18:05:14 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wddZcZww+X5; Mon, 13 Sep 2010 18:05:11 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 92BDC11680AA; Mon, 13 Sep 2010 18:05:11 +0100 (BST) References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> <20100913165259.GA9709@isc.upenn.edu> In-Reply-To: <20100913165259.GA9709@isc.upenn.edu> MIME-Version: 1.0 Message-Id: <8252.1284397511.595153@puncture> Date: Mon, 13 Sep 2010 18:05:11 +0100 From: Dave Cridland To: Shumon Huque , Bernard Aboba , IETF cert-based identity , IETF-Discussion , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" X-Mailman-Approved-At: Mon, 13 Sep 2010 10:07:57 -0700 Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 17:04:52 -0000 On Mon Sep 13 17:52:59 2010, Shumon Huque wrote: > Yes, but whether they are actually "current" best practices is > debatable. I certainly would like them to become best practices. > For example I don't believe any existing commercial CAs issue > certificates with the SRVName or URI SAN name forms. > > They do, I've seen sRVName SANs in some XMPP server certificates. > > Do we have evidence that any existing > > certification authorities issue certificates containing both an > SRVname > > for the source domain (e.g., example.com) and dNSName for the > target > > domain (e.g., apphosting.example.net)? Do we have evidence that > any > > existing application clients perform such checks? If not, I would > > consider such complications to be out of scope for this I-D. > > I think the question is whether we have examples of applications > that need to verify "combinations" of subjectaltname name forms in > certificates. Stefan says there are, but so far no-one has offered > up any public specifications of such apps. So, I think until we > have them, I agree we can defer considerations of them to future > documents. > > I think it's reasonable for this draft to consider multiple identity > types in certificates (eg. common name, dNSName, SRVName) with the > current matching rules of ANY. This might be needed to gradually > transition an app from validating a host specific identity to an > application specific identity. The current draft allows this. > > Isode M-Link will check xmppAddr and dNSName (and I'll add in sRVName soonish, and possibly URI). If no SANs of a supported type exist, then it will fall back to a CN match. It will not check the dNSName against the result of a SRV DNS lookup, ever, nor will it check a dNSName if it has already found a matching xmppAddr (nor vice-versa). As such it's not checking combinations of SANs. Looking at the draft, it seems to read that I should check dNSName first, and then, only if this matches, check xmppAddr or sRVName. This seems odd - sRVName and xmppAddr (and URI) all contain a superset of the data contained, so why look at dNSName if a more specific match exists? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From mrex@sap.com Mon Sep 13 10:48:08 2010 Return-Path: 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 D9A533A69F9 for ; Mon, 13 Sep 2010 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.857 X-Spam-Level: X-Spam-Status: No, score=-9.857 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 8JwnRB7mc-G0 for ; Mon, 13 Sep 2010 10:48:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 5F0D43A6A1A for ; Mon, 13 Sep 2010 10:48:07 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8DHmW9e018571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Sep 2010 19:48:32 +0200 (MEST) From: Martin Rex Message-Id: <201009131748.o8DHmLmE021207@fs4113.wdf.sap.corp> Orig-To: shuque@isc.upenn.edu (Shumon Huque) To: certid@ietf.org Date: Thu, 9 Sep 2010 23:10:35 +0200 (MEST) In-Reply-To: <20100908195349.GA4292@isc.upenn.edu> from "Shumon Huque" at Sep 8, 10 03:53:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: bernard_aboba@hotmail.com, certid@ietf.org, ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 17:48:09 -0000 Shumon Huque wrote: > > On Wed, Sep 08, 2010 at 08:44:56AM -0700, Bernard Aboba wrote: > > > > If the "reference identifier" is _Service.Name then the match is being done > > on the *input* to the SRV lookup process, not the output, and prohibition on > > DNS lookups would not apply (or even make any sense). > > Yes. > > The output of the SRV record lookup contains a target hostname, > not a service name, so it's not applicable to the SRVName name > form. The target could be used in another name form (dNSName) > as the reference identifier, but then the client needs to convince > itself that the lookup was done securely (DNSSEC or some other > means) otherwise there's a security problem. I'm feeling very uneasy with the suggestion that a DNSSEC instead of the DNS lookup might make it less of a security problem. DNSSEC provides only data integrity protection and data origin authentication of the records, and NOTHING beyond that. In particular, it does _NOT_ provide any trust in the conveyed information. But in order to avoid the mentioned security problem, trust in the transformation is an absolute prerequisite for the name transformation in order to use the result in any kind of endpoint identity verification. Although I personally think the trustworthiness of the rootCA certs in web browsers is significantly overrated, there seems to be some understanding out there that there is a huge difference between cryptographic protection and trust, so there are browser vendors that require CAs to apply a certain amount of scrutiny before issuing certificates and subject themselves to an audit for a non-negligable amount of cost before the browser vendors are going to include the CAs self-signed rootCA cert as pre-trusted with their browser. Are DNS domain admins going to be required to apply as much scrutiny for each and every DNS record in their zone and have to succeed a comparable audit of their DNS record maintenance procedures before their parent domain will sign their zone signing keys? DNS is an important an vital part of the internet, and it needs to remain fast, efficient and free in order to remain useful. Besides, even if DNSSEC signed records are being made available in increasing numbers, that information is not visible to >90% of the end users of the internet (like DSL subscribers) and is going to remain invisible for most of them for many years to come. -Martin From stefan@aaa-sec.com Mon Sep 13 10:58:43 2010 Return-Path: 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 EB0743A6A94 for ; Mon, 13 Sep 2010 10:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Fbh2RcJgSCbr for ; Mon, 13 Sep 2010 10:58:43 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id D6ACC3A6A92 for ; Mon, 13 Sep 2010 10:58:42 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 29B7D320A73 for ; Mon, 13 Sep 2010 19:59:14 +0200 (CEST) Received: (qmail 52140 invoked from network); 13 Sep 2010 17:59:07 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 Sep 2010 17:59:07 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 13 Sep 2010 19:59:03 +0200 From: Stefan Santesson To: Shumon Huque , Peter Saint-Andre Message-ID: Thread-Topic: [certid] Review of draft-saintandre-tls-server-id-check Thread-Index: ActTbVma/TRtM5Ny6EieGip83nO2vw== In-Reply-To: <20100913170339.GB9709@isc.upenn.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 17:58:44 -0000 On 10-09-13 7:03 PM, "Shumon Huque" wrote: >> >> Authorized by whom? I *think* that here the DNS domain name is one that >> the certified subject has itself authorized (perhaps even "established" >> is better) to provide the desired service. Therefore I suggest an >> alternative wording: >> >> "A DNS domain name which the certified subject has >> authorized to provide the identified service." >> >> Peter > > I don't think the term "authorized" makes the situation any > clearer. > > Let's take a concrete example: an IMAP client attempting to > connect to and use the IMAP service at "example.com". > > It needs to lookup the "_imap._tcp.example.com." DNS SRV record > to figure out which servers and ports to connect to. > > And in the presented certificate, it needs to expect to find an > SRVName identifier with "_imap.example.com" as its contents, > where the _Service and Name components were the same ones it used > in the SRV query. > > There is no need to figure out who authorized what. I agree here. Both to this and to former speakers stating that the assertion is made by the CA and no the subject. I'm struggling with the most easy to understand text, but I think this says at least the correct thing: "A DNS domain name, representing a domain for which the certificate issuer has asserted that the certified subject is a legitimate provider of the identified service." /Stefan From stefan@aaa-sec.com Mon Sep 13 11:40:39 2010 Return-Path: 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 E3A1E3A6A8E for ; Mon, 13 Sep 2010 11:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 pgyl5dpuuW51 for ; Mon, 13 Sep 2010 11:40:37 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 336133A6AC3 for ; Mon, 13 Sep 2010 11:39:45 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B83873873F8 for ; Mon, 13 Sep 2010 20:39:54 +0200 (CEST) Received: (qmail 57043 invoked from network); 13 Sep 2010 18:39:47 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 13 Sep 2010 18:39:47 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Mon, 13 Sep 2010 20:39:43 +0200 From: Stefan Santesson To: Peter Saint-Andre , Shumon Huque Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActTcwf0udnggguB60aSFg5RUAFEuw== In-Reply-To: <4C8E4C6B.3040803@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, daedulus@btconnect.com Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 18:40:40 -0000 Peter, On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: > > Hi Shumon, > > As I see it, this I-D is attempting to capture best current practices > regarding the issuance and checking of certificates containing > application server identities. Do we have evidence that any existing > certification authorities issue certificates containing both an SRVname > for the source domain (e.g., example.com) and dNSName for the target > domain (e.g., apphosting.example.net)? Do we have evidence that any > existing application clients perform such checks? If not, I would > consider such complications to be out of scope for this I-D. > > That said, we need to be aware that if such usage arises in the future, > someone might write a document that updates or obsoletes this I-D; in > fact the present authors very much expect that such documents will > emerge after the Internet community (specifically certification > authorities, application service providers, and application client > developers) have gained more experience with PKIX certificates in the > context of various application technologies. > > Peter I would like to turn the question around and ask why this specification need to have an opinion on whether a relying party feels he have to check both host name and service? I'm not against describing the typical case, as long as this specification does not imply that a relying party that has a reason to check two name types is doing something wrong. I have no extremely good examples of practical implementation here but checking both host name and service seems like both extremely easy and good practice. /Stefan From stpeter@stpeter.im Mon Sep 13 11:42:12 2010 Return-Path: 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 E9DE23A6A7E; Mon, 13 Sep 2010 11:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.976 X-Spam-Level: X-Spam-Status: No, score=-100.976 tagged_above=-999 required=5 tests=[AWL=-1.577, BAYES_50=0.001, J_CHICKENPOX_27=0.6, 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 CSlciaEA65Vi; Mon, 13 Sep 2010 11:42:09 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5ECB73A6AA8; Mon, 13 Sep 2010 11:41:59 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7CD03400EE; Mon, 13 Sep 2010 12:45:23 -0600 (MDT) Message-ID: <4C8E704B.1030307@stpeter.im> Date: Mon, 13 Sep 2010 12:41:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: James Schaad References: <000701cb4e4b$8f8f5480$aeadfd80$@nwlink.com> In-Reply-To: <000701cb4e4b$8f8f5480$aeadfd80$@nwlink.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: certid@ietf.org, tls@ietf.org, jeff.hodges@paypal.com Subject: Re: [certid] [TLS] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 18:42:12 -0000 Thanks for your careful review. Comments inline. On 9/6/10 11:14 PM, James Schaad wrote: > 1. There are those who say that the DNS system is dead for dealing with > identification of items. That the main way that people find items these > days is by doing searches. This should perhaps be acknowledged in > section 1.3 under the DNS domain names section. I.e. we use DNS names > still for some things (such as SMTP servers), but for many things the > name that the user knows is obtained in a very indirect manner. (search, > URL click, address book entry) In a similar manner today people don’t > remember telephone numbers as they are all indirectly obtained, but they > do write them down to give to other people. Yes, that is a good point. Complicated, but good. We somewhat address it in this paragraph: Finally, we do not discuss attributes unrelated to DNS domain names, such as those defined in [X.520] and other such specifications (e.g., organizational attributes, geographical attributes, company logos, and the like). It seems to me that this relates to the expectations of human users more than our relatively clear-cut discussion of DNS domain names. For example, supposedly some large percentage of the searches on Yahoo! are for "Google" (and vice-versa); clearly the folks who are doing such searches are from our perspective rather unsophisticated users of the Internet, and they might know that they're on "Google" when they see the company logo (which changes on special days!) not when they see "http://www.google.com/" in the address bar of their browser. The authors of this I-D have not completed any research into the expectations of such users (although Jeff has better knowledge of the literature than I do), so it seems inappropriate for us to say much about the matter. However, I agree that this would be a good topic for further research and discussion (e.g., perhaps "petnames" might make sense here). > 2. Do you consider an HTTP redirect to still be a direct name or is > this now an indirect name? The simplest method would be to go from an > http: to an https: but other types of redirects are also interesting – > not the least is just clicking w/o actually looking at where you are going. IMHO the name received via an HTTP redirect is an indirect name (e.g., I typed "exmaple.com" but my browser is redirected to "example.com"). Naturally that applies only to domain redirects -- a redirect from one URL to another URL within the same domain would preserve the same DNS domain name for identity checking purposes. > 3. You might want to also give a domain-component (dc=) version of the > common name for doing identifiers – and then say it is out of scope. > i.e. “dc=com, dc=example, dc=www†Earlier versions of this I-D (up through -06) talked about domain components as something not to do, but that seems to have caused more confusion than clarity so we removed the text. > 4. You might want to add to the implementation note on page 15 that > there is not always agreement about the order that the strings should be > displayed in. Thus for some the root RDN is displayed first but for > others it is displayed last. (Thus the CERT_NAME_STR_REVERSE_FLAG for > the CertStrToName function from Microsoft.) Yes, there was much discussion about that topic on the certid@ietf.org list. We currently have this sentence: However, because a Relative Distinguished Name (RDN) is an unordered group of attribute-type-and-value pairs, the string representation of an RDN can differ from the canonical DER encoding. Does adding the parenthetical clause at the end of the following text address your concern? However, because a Relative Distinguished Name (RDN) is an unordered group of attribute-type-and-value pairs, the string representation of an RDN can differ from the canonical DER encoding (and the order of attribute-type-and-value pairs can differ in the string representations or display orders provided by various implementations). > 5. In section 3, what about URI-ID and SVN-ID – are multiple of these > name forms allowed or not? Since 5 is explicit on CN-ID and DNS-ID I > think that the other two name forms should be covered as well. I agree that we need to be clear about that, and I think that it is acceptable to include multiple instances of those identifier types. > 6. I am not really happy with the choice of wording for ‘and aborting > the search’ – in my mind you abort for bad conditions and not for good > conditions. Stop the search, exit the search are all reasonable and > don’t imply an error state. In the working copy I've changed "aborting" to "stopping". > 7. I got confused and started to say that you needed to do wildcards in > section 4.4.1 because that is not referenced in the text of section > 4.4. Yes, adding a forward pointer from 4.4 to 4.4.3 makes sense. > It is not clear how the wildcard label matching should be done > dependent on the tradition vs. internationalized domain name difference. > > The client MUST match the source domain of a reference identifier > according to the following rules. The rules used depends on whether the > source domain is a "traditional domain name" or an "internationalized > domain name" as previously defined, and if wildcard labels are permitted. I see your point. In our working copy I've adjusted Section 4.4 to read as follows (thus pointing to the sections that follow): ### 4.4. Verifying a Domain Name The client MUST match the source domain of a reference identifier according to the following rules. The rules differ depending on whether the source domain is a "traditional domain name" or an "internationalized domain name" (as previously defined). Furthermore, the source domain (whether a traditional domain name or an internationalized domain name) might contain the wildcard character '*' as the left-most label, so we define a supplemental rule for so-called "wildcard domains". Finally, we specify the circumstances under which it is acceptable to check the "CN-ID" identifier type. ### > 8. Does the following statement apply in section 4.4.2? What does it > mean for 4.4.1 if a wildcard is present? > > Each label MUST match in order for the names to be considered to match. > > I think that it is confusing and should potentially be > removed. Yes, that applies to both traditional domain names and internationalized domain names. I have added the sentence to the paragraph in Section 4.4.2. However, I have slightly modified the text to address your point about wildcard labels, as follows: ### 4.4.1. Checking of Traditional Domain Names If the source domain of a reference identifier is a "traditional domain name", then matching of the reference identifier against the presented identifier is performed by comparing the set of domain name components using a case-insensitive ASCII comparison, as clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to "www.example.com" for comparison purposes). Each label MUST match in order for the names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 4.4.3). 4.4.2. Checking of Internationalized Domain Names If the source domain of a reference identifier is an internationalized domain name, then an implementation MUST convert every label in the domain name to an A-label before checking the domain name. Each label MUST match in order for the names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 4.4.3). 4.4.3. Checking of Wildcard Labels A client employing this specification's rules MAY match the reference identifier against a presented identifier whose DNS domain name contains one instance of the wildcard character '*', but only if that character is the complete left-most label of the domain name, e.g. *.example.com (following the definition of "label" from [DNS]). If the wildcard character '*' is the complete left-most label of a traditional domain name or internationalized domain name, the wildcard MUST be used to match only the one position-wise corresponding label (thus *.example.com matches foo.example.com but not bar.foo.example.com or example.com). The client MUST fail to match a presented identifier in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net), or in which the wildcard character does not comprise the left-most label in the presented identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net are allowed). [...] ### > 9. In section 4.6.2 – I can understand that a certificate “change†by > having the certification path change. However if one were to change the > DNS domain name, identifiers, issuer or expiration date, I don’t > understand how one would say that it is the same cached certificate? Do > you expect clients to cache the certificate based one something other > than the actual bytes of the certificate? i.e. the public key and > subject name? Or are you trying to address the case where for the > specific reference identifier there exists a cached certificate and the > certificate that was presented is a different certificate from the one > that was cached? (In which case one should potentially say that one > needs to fall into the 4.6.3 logic after informing the user of the fact.) We care about the latter case, which means we can simplify the text in Section 4.6.2, as follows: ### 4.6.2. Case #2: No Match Found, Cached Certificate If the client finds no presented identifier that matches any of the reference identifiers but a natural person has permanently accepted the certificate during a previous connection attempt or via configured preferences, the certificate is cached. In this case, the client MUST verify that the presented certificate matches the cached certificate; if the presented certificate does not match the cached certificate then the client MUST proceed as described under Case #3 below. ### Thanks again for the review. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Sep 13 11:48:33 2010 Return-Path: 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 A786B3A6A8D; Mon, 13 Sep 2010 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, 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 yXzgs1-D48cm; Mon, 13 Sep 2010 11:48:32 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 62F963A6A21; Mon, 13 Sep 2010 11:48:32 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C3FE9400EE; Mon, 13 Sep 2010 12:53:03 -0600 (MDT) Message-ID: <4C8E7218.6010204@stpeter.im> Date: Mon, 13 Sep 2010 12:48:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Dave Cridland References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> <20100913165259.GA9709@isc.upenn.edu> <8252.1284397511.595153@puncture> In-Reply-To: <8252.1284397511.595153@puncture> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , IETF-Discussion Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 18:48:33 -0000 On 9/13/10 11:05 AM, Dave Cridland wrote: > On Mon Sep 13 17:52:59 2010, Shumon Huque wrote: >> Yes, but whether they are actually "current" best practices is >> debatable. I certainly would like them to become best practices. >> For example I don't believe any existing commercial CAs issue >> certificates with the SRVName or URI SAN name forms. >> >> > They do, I've seen sRVName SANs in some XMPP server certificates. > > >> > Do we have evidence that any existing >> > certification authorities issue certificates containing both an SRVname >> > for the source domain (e.g., example.com) and dNSName for the target >> > domain (e.g., apphosting.example.net)? Do we have evidence that any >> > existing application clients perform such checks? If not, I would >> > consider such complications to be out of scope for this I-D. >> >> I think the question is whether we have examples of applications >> that need to verify "combinations" of subjectaltname name forms in >> certificates. Stefan says there are, but so far no-one has offered >> up any public specifications of such apps. So, I think until we >> have them, I agree we can defer considerations of them to future >> documents. >> >> I think it's reasonable for this draft to consider multiple identity >> types in certificates (eg. common name, dNSName, SRVName) with the >> current matching rules of ANY. This might be needed to gradually >> transition an app from validating a host specific identity to an >> application specific identity. The current draft allows this. >> >> > Isode M-Link will check xmppAddr and dNSName (and I'll add in sRVName > soonish, and possibly URI). If no SANs of a supported type exist, then > it will fall back to a CN match. > > It will not check the dNSName against the result of a SRV DNS lookup, > ever, nor will it check a dNSName if it has already found a matching > xmppAddr (nor vice-versa). As such it's not checking combinations of SANs. > > Looking at the draft, it seems to read that I should check dNSName > first, and then, only if this matches, check xmppAddr or sRVName. This > seems odd - sRVName and xmppAddr (and URI) all contain a superset of the > data contained, so why look at dNSName if a more specific match exists? Earlier versions of this draft had somewhat elaborate rules about ordering of reference identifiers. Those rules were removed in -09 because folks on the certid@ietf.org list argued persuasively that they were not necessary because "first match wins" is good enough. Naturally, an implementation might have a preference order of reference identifiers, but such an order is not mandated by this I-D. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Sep 13 11:49:36 2010 Return-Path: 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 4D9E23A6A22; Mon, 13 Sep 2010 11:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 IX4kVhmDa90j; Mon, 13 Sep 2010 11:49:34 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BF4843A6A21; Mon, 13 Sep 2010 11:49:34 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 679C6400EE; Mon, 13 Sep 2010 12:54:06 -0600 (MDT) Message-ID: <4C8E7257.5050700@stpeter.im> Date: Mon, 13 Sep 2010 12:49:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , daedulus@btconnect.com, IETF cert-based identity , ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 18:49:36 -0000 On 9/13/10 11:59 AM, Stefan Santesson wrote: > > > On 10-09-13 7:03 PM, "Shumon Huque" wrote: >>> >>> Authorized by whom? I *think* that here the DNS domain name is one that >>> the certified subject has itself authorized (perhaps even "established" >>> is better) to provide the desired service. Therefore I suggest an >>> alternative wording: >>> >>> "A DNS domain name which the certified subject has >>> authorized to provide the identified service." >>> >>> Peter >> >> I don't think the term "authorized" makes the situation any >> clearer. >> >> Let's take a concrete example: an IMAP client attempting to >> connect to and use the IMAP service at "example.com". >> >> It needs to lookup the "_imap._tcp.example.com." DNS SRV record >> to figure out which servers and ports to connect to. >> >> And in the presented certificate, it needs to expect to find an >> SRVName identifier with "_imap.example.com" as its contents, >> where the _Service and Name components were the same ones it used >> in the SRV query. >> >> There is no need to figure out who authorized what. > > I agree here. Both to this and to former speakers stating that the assertion > is made by the CA and no the subject. > > I'm struggling with the most easy to understand text, but I think this says > at least the correct thing: > > "A DNS domain name, representing a domain for which the certificate > issuer has asserted that the certified subject is a legitimate > provider of the identified service." +1 From dave@cridland.net Mon Sep 13 12:12:27 2010 Return-Path: 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 87D6A3A6A97; Mon, 13 Sep 2010 12:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] 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 2HXpL8Gl+-pZ; Mon, 13 Sep 2010 12:12:25 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id A61EF3A69A1; Mon, 13 Sep 2010 12:12:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 46B5711680C3; Mon, 13 Sep 2010 20:12:50 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjKgYVxG0MgK; Mon, 13 Sep 2010 20:12:47 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5318011680AA; Mon, 13 Sep 2010 20:12:47 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <8252.1284405167.326805@puncture> Date: Mon, 13 Sep 2010 20:12:47 +0100 From: Dave Cridland To: Stefan Santesson , Bernard Aboba , IETF cert-based identity , IETF-Discussion , Shumon Huque , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 19:12:27 -0000 On Mon Sep 13 18:59:03 2010, Stefan Santesson wrote: > I agree here. Both to this and to former speakers stating that the > assertion > is made by the CA and no the subject. > > Well, I'd say the assertion is the presence of the SAN in the cert. I mean, an assertion is a positive statement made *without* evidence. The evidence is then the signature of the issuer, who certifies the assertion - it doesn't matter who makes that assertion. But anyway, that's somewhat moot, and as Shumon points out, we needn't care about who authorized what unto whom. > I'm struggling with the most easy to understand text, but I think > this says > at least the correct thing: > > "A DNS domain name, representing a domain for which the > certificate > issuer has asserted that the certified subject is a > legitimate > provider of the identified service." "The requested DNS domain name for the specified service. That is, the domain name which would be found in the URI for the service, and other protocol identifiers of a similar nature. Where the service is directly requested by hostname, this domain name would be the requested hostname." I think that covers all the cases I'd expect by example, without worrying about who's asserting and certifying. No doubt someone will reword with a sprinkling of 2119. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Mon Sep 13 12:16:38 2010 Return-Path: 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 A6EE23A6A97; Mon, 13 Sep 2010 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, 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 GAYuM0Q0z7EW; Mon, 13 Sep 2010 12:16:33 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E844B3A6A70; Mon, 13 Sep 2010 12:16:32 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5BEAE400EE; Mon, 13 Sep 2010 13:21:04 -0600 (MDT) Message-ID: <4C8E78A9.7040608@stpeter.im> Date: Mon, 13 Sep 2010 13:16:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , daedulus@btconnect.com, ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 19:16:38 -0000 On 9/13/10 12:39 PM, Stefan Santesson wrote: > Peter, > > On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: >> >> Hi Shumon, >> >> As I see it, this I-D is attempting to capture best current practices >> regarding the issuance and checking of certificates containing >> application server identities. Do we have evidence that any existing >> certification authorities issue certificates containing both an SRVname >> for the source domain (e.g., example.com) and dNSName for the target >> domain (e.g., apphosting.example.net)? Do we have evidence that any >> existing application clients perform such checks? If not, I would >> consider such complications to be out of scope for this I-D. >> >> That said, we need to be aware that if such usage arises in the future, >> someone might write a document that updates or obsoletes this I-D; in >> fact the present authors very much expect that such documents will >> emerge after the Internet community (specifically certification >> authorities, application service providers, and application client >> developers) have gained more experience with PKIX certificates in the >> context of various application technologies. >> >> Peter > > I would like to turn the question around and ask why this specification need > to have an opinion on whether a relying party feels he have to check both > host name and service? Stop right there. :) I sense a possible source of confusion. What do you mean by "host name" and what do you mean by "service"? In this I-D, we talk about "DNS domain name" and "service type", which map quite well to _Service.Name from RFC 4985: the DNS domain name is the "source domain" provided by the user or configured into the client (e.g., "example.com") and the "service type" is a given application protocol that could be serviced by the source domain (e.g., "IMAP"). This I-D is attempting to gently nudge people in the direction of checking both the DNS domain name and the service type. IMHO this is consistent with considering the SRVName and uniformResourceIdentifier subjectAltName entries as more tightly scoped than dNSName or CN, and therefore as potentially more "secure" in some sense (the subject might want to limit use of a particular certificate to only the service type identified in the SRVName or uniformResourceIdentifier). If by "host name" you mean "target domain" as defined in the I-D (and mapping to "Target" from RFC 2782) then we have more to discuss. > I'm not against describing the typical case, as long as this specification > does not imply that a relying party that has a reason to check two name > types is doing something wrong. That is not the intent of this I-D, however that would be functionality over and above what this I-D defines. > I have no extremely good examples of practical implementation here but > checking both host name and service seems like both extremely easy and good > practice. With respect to revisions to this I-D, the lack of good examples troubles me because we have been trying to abstract from common usage, not to define guidelines for use cases that have not yet been defined, implemented, and deployed. Given that you would prefer to leave the door open to more advanced checking rules, I think you would object to this text in Section 4.3: Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. It does so by seeking a match and stopping the search if any presented identifier matches one of its reference identifiers. The search fails if the client exhausts its list of reference identifiers without finding a match. You are saying that it is not necessarily appropriate to stop the search once a single match is found, because the client might be configured to look for multiple matches (e.g., a match against both the source domain and the target domain). Would you like to suggest text that covers such a case? Here is a possible rewrite of Section 4.3 that might address your concern. ### 4.3. Seeking a Match Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. The search fails if the client exhausts its list of reference identifiers without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search. Implementation Note: A client might be configured to perform multiple searches, i.e., to match more than one reference identifier; although such behavior is not forbidden by this document, rules for matching multiple reference identifiers are a matter for implementation or future specification. Security Note: A client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include an SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName entry types supported by the client. Detailed comparison rules for finding a match are provided in the following sections. ### Peter -- Peter Saint-Andre https://stpeter.im/ From dave@cridland.net Mon Sep 13 12:17:59 2010 Return-Path: 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 A1C5B3A6A70; Mon, 13 Sep 2010 12:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] 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 WA8Pc8kSS-Tu; Mon, 13 Sep 2010 12:17:52 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 6CB8A3A6A93; Mon, 13 Sep 2010 12:17:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 0472C11680C3; Mon, 13 Sep 2010 20:18:16 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkI05ZPijiTi; Mon, 13 Sep 2010 20:18:13 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 0516311680AA; Mon, 13 Sep 2010 20:18:13 +0100 (BST) References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> <20100913165259.GA9709@isc.upenn.edu> <8252.1284397511.595153@puncture> <4C8E7218.6010204@stpeter.im> In-Reply-To: <4C8E7218.6010204@stpeter.im> MIME-Version: 1.0 Message-Id: <8252.1284405493.018713@puncture> Date: Mon, 13 Sep 2010 20:18:13 +0100 From: Dave Cridland To: Peter Saint-Andre , Shumon Huque , Bernard Aboba , IETF cert-based identity , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 19:17:59 -0000 On Mon Sep 13 19:48:56 2010, Peter Saint-Andre wrote: > On 9/13/10 11:05 AM, Dave Cridland wrote: > > Looking at the draft, it seems to read that I should check dNSName > > first, and then, only if this matches, check xmppAddr or sRVName. > This > > seems odd - sRVName and xmppAddr (and URI) all contain a superset > of the > > data contained, so why look at dNSName if a more specific match > exists? > > Earlier versions of this draft had somewhat elaborate rules about > ordering of reference identifiers. Those rules were removed in -09 > because folks on the certid@ietf.org list argued persuasively that > they > were not necessary because "first match wins" is good enough. > Naturally, > an implementation might have a preference order of reference > identifiers, but such an order is not mandated by this I-D. Ah, I see my confusion. §4.4 says: 4.4. Verifying a Domain Name The client MUST match the source domain of a reference identifier according to the following rules And §4.5 says: 4.5. Verifying an Application Type A client SHOULD check not only the domain name but also the service type of the service to which it connects. Now, I misconstrued that to mean "MUST use dNSName, SHOULD use sRVName", which is purely me misreading. Up to you whether you think other people will be as silly as me, and what to do about it if so. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Mon Sep 13 12:21:36 2010 Return-Path: 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 B572F3A69F9; Mon, 13 Sep 2010 12:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 Cmw1uv2rf+Se; Mon, 13 Sep 2010 12:21:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 710E03A69A1; Mon, 13 Sep 2010 12:21:35 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0C1A8400EE; Mon, 13 Sep 2010 13:26:06 -0600 (MDT) Message-ID: <4C8E79D7.3080507@stpeter.im> Date: Mon, 13 Sep 2010 13:21:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Dave Cridland References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> <20100913165259.GA9709@isc.upenn.edu> <8252.1284397511.595153@puncture> <4C8E7218.6010204@stpeter.im> <8252.1284405493.018713@puncture> In-Reply-To: <8252.1284405493.018713@puncture> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Bernard Aboba , IETF cert-based identity , IETF-Discussion Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 19:21:36 -0000 On 9/13/10 1:18 PM, Dave Cridland wrote: > On Mon Sep 13 19:48:56 2010, Peter Saint-Andre wrote: >> On 9/13/10 11:05 AM, Dave Cridland wrote: >> > Looking at the draft, it seems to read that I should check dNSName >> > first, and then, only if this matches, check xmppAddr or sRVName. This >> > seems odd - sRVName and xmppAddr (and URI) all contain a superset of >> the >> > data contained, so why look at dNSName if a more specific match exists? >> >> Earlier versions of this draft had somewhat elaborate rules about >> ordering of reference identifiers. Those rules were removed in -09 >> because folks on the certid@ietf.org list argued persuasively that they >> were not necessary because "first match wins" is good enough. Naturally, >> an implementation might have a preference order of reference >> identifiers, but such an order is not mandated by this I-D. > > Ah, I see my confusion. §4.4 says: > > 4.4. Verifying a Domain Name > > The client MUST match the source domain of a reference identifier > according to the following rules > > And §4.5 says: > > 4.5. Verifying an Application Type > > A client SHOULD check not only the domain name but also the service > type of the service to which it connects. > > Now, I misconstrued that to mean "MUST use dNSName, SHOULD use sRVName", > which is purely me misreading. > > Up to you whether you think other people will be as silly as me, and > what to do about it if so. A forward reference seem appropriate: The client MUST match the source domain of a reference identifier according to the following rules (and SHOULD also check the service type as described under Section 4.5). Peter -- Peter Saint-Andre https://stpeter.im/ From dave@cridland.net Mon Sep 13 12:29:27 2010 Return-Path: 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 DBA223A69F9; Mon, 13 Sep 2010 12:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 6hK06wp6+O1W; Mon, 13 Sep 2010 12:29:27 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id CE7E53A6A0B; Mon, 13 Sep 2010 12:29:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id A895A11680C4; Mon, 13 Sep 2010 20:29:51 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPnqggHkXqYy; Mon, 13 Sep 2010 20:29:48 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 88ED011680AA; Mon, 13 Sep 2010 20:29:48 +0100 (BST) References: <20100908195349.GA4292@isc.upenn.edu> <20100909182253.GB3460@isc.upenn.edu> <4C8E4C6B.3040803@stpeter.im> <20100913165259.GA9709@isc.upenn.edu> <8252.1284397511.595153@puncture> <4C8E7218.6010204@stpeter.im> <8252.1284405493.018713@puncture> <4C8E79D7.3080507@stpeter.im> In-Reply-To: <4C8E79D7.3080507@stpeter.im> MIME-Version: 1.0 Message-Id: <8252.1284406188.558423@puncture> Date: Mon, 13 Sep 2010 20:29:48 +0100 From: Dave Cridland To: Peter Saint-Andre , Shumon Huque , Bernard Aboba , IETF cert-based identity , IETF-Discussion Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 19:29:27 -0000 On Mon Sep 13 20:21:59 2010, Peter Saint-Andre wrote: > On 9/13/10 1:18 PM, Dave Cridland wrote: > > Up to you whether you think other people will be as silly as me, > and > > what to do about it if so. > > A forward reference seem appropriate: > > The client MUST match the source domain of a reference identifier > according to the following rules (and SHOULD also check the > service > type as described under Section 4.5). Spot on. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stefan@aaa-sec.com Mon Sep 13 17:03:21 2010 Return-Path: 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 A27563A681A for ; Mon, 13 Sep 2010 17:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 UB3jC74rsqHf for ; Mon, 13 Sep 2010 17:03:20 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id DD9BA3A6801 for ; Mon, 13 Sep 2010 17:03:19 -0700 (PDT) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 23FAB36DF63 for ; Tue, 14 Sep 2010 02:03:53 +0200 (CEST) Received: (qmail 59411 invoked from network); 14 Sep 2010 00:03:43 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Sep 2010 00:03:43 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 14 Sep 2010 02:03:39 +0200 From: Stefan Santesson To: Peter Saint-Andre Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActToEi29JGU7yV3PUu6c9ACKgGvzg== In-Reply-To: <4C8E78A9.7040608@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , daedulus@btconnect.com, ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 00:03:21 -0000 Peter, Comments in line; On 10-09-13 9:16 PM, "Peter Saint-Andre" wrote: > On 9/13/10 12:39 PM, Stefan Santesson wrote: >> Peter, >> >> On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: >>> >>> Hi Shumon, >>> >>> As I see it, this I-D is attempting to capture best current practices >>> regarding the issuance and checking of certificates containing >>> application server identities. Do we have evidence that any existing >>> certification authorities issue certificates containing both an SRVname >>> for the source domain (e.g., example.com) and dNSName for the target >>> domain (e.g., apphosting.example.net)? Do we have evidence that any >>> existing application clients perform such checks? If not, I would >>> consider such complications to be out of scope for this I-D. >>> >>> That said, we need to be aware that if such usage arises in the future, >>> someone might write a document that updates or obsoletes this I-D; in >>> fact the present authors very much expect that such documents will >>> emerge after the Internet community (specifically certification >>> authorities, application service providers, and application client >>> developers) have gained more experience with PKIX certificates in the >>> context of various application technologies. >>> >>> Peter >> >> I would like to turn the question around and ask why this specification need >> to have an opinion on whether a relying party feels he have to check both >> host name and service? > > Stop right there. :) I sense a possible source of confusion. What do you > mean by "host name" and what do you mean by "service"? > Sorry for sloppy use of words. With host name I mean here the actual DNS name of the host, which might be host1.example.com (dNSName) By service I mean the service under a given domain, which for the same host might be _xmpp.example.com (SRVName) Under the current rules, using this example I read it that the following apply: - If you are just checking the SRVName you will not learn the legitimate host DNS name. So a certificate issued to host2.example.com will be accepted even if you intended to contact host1.example.com (even if that information is in the cert). - If you just check the dNSName, you will miss the fact that you talk to the desiganted ldap server and not the xmpp server (even if that information is in the cert). > In this I-D, we talk about "DNS domain name" and "service type", which > map quite well to _Service.Name from RFC 4985: the DNS domain name is > the "source domain" provided by the user or configured into the client > (e.g., "example.com") and the "service type" is a given application > protocol that could be serviced by the source domain (e.g., "IMAP"). > > This I-D is attempting to gently nudge people in the direction of > checking both the DNS domain name and the service type. IMHO this is > consistent with considering the SRVName and uniformResourceIdentifier > subjectAltName entries as more tightly scoped than dNSName or CN, and > therefore as potentially more "secure" in some sense (the subject might > want to limit use of a particular certificate to only the service type > identified in the SRVName or uniformResourceIdentifier). > > If by "host name" you mean "target domain" as defined in the I-D (and > mapping to "Target" from RFC 2782) then we have more to discuss. > >> I'm not against describing the typical case, as long as this specification >> does not imply that a relying party that has a reason to check two name >> types is doing something wrong. > > That is not the intent of this I-D, however that would be functionality > over and above what this I-D defines. > >> I have no extremely good examples of practical implementation here but >> checking both host name and service seems like both extremely easy and good >> practice. > > With respect to revisions to this I-D, the lack of good examples > troubles me because we have been trying to abstract from common usage, > not to define guidelines for use cases that have not yet been defined, > implemented, and deployed. > > Given that you would prefer to leave the door open to more advanced > checking rules, I think you would object to this text in Section 4.3: > > Once the client has constructed its list of reference identifiers and > has received the server's presented identifiers in the form of a PKIX > certificate, the client checks its reference identifiers against the > presented identifiers for the purpose of finding a match. It does so > by seeking a match and stopping the search if any presented > identifier matches one of its reference identifiers. The search > fails if the client exhausts its list of reference identifiers > without finding a match. > > You are saying that it is not necessarily appropriate to stop the search > once a single match is found, because the client might be configured to > look for multiple matches (e.g., a match against both the source domain > and the target domain). Would you like to suggest text that covers such > a case? Here is a possible rewrite of Section 4.3 that might address > your concern. > > ### > > 4.3. Seeking a Match > > Once the client has constructed its list of reference identifiers and > has received the server's presented identifiers in the form of a PKIX > certificate, the client checks its reference identifiers against the > presented identifiers for the purpose of finding a match. The search > fails if the client exhausts its list of reference identifiers > without finding a match. The search succeeds if any presented > identifier matches one of the reference identifiers, at which point > the client SHOULD stop the search. > > Implementation Note: A client might be configured to perform > multiple searches, i.e., to match more than one reference > identifier; although such behavior is not forbidden by this > document, rules for matching multiple reference identifiers are a > matter for implementation or future specification. > > Security Note: A client MUST NOT seek a match for a reference > identifier of CN-ID if the presented identifiers include an > SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName > entry types supported by the client. > > Detailed comparison rules for finding a match are provided in the > following sections. > This sounds better to me. If I'm not totally wrong in my example above I also think it would be good with a security note stating that an SRVName may not provide the full host DNS name, and if it is important to verify the host DNS name, you must verify the dNSName in addition to what else you are checking. /Stefan From stpeter@stpeter.im Mon Sep 13 20:32:47 2010 Return-Path: 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 AD9083A689C; Mon, 13 Sep 2010 20:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, 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 Wr4cMd3uXfdm; Mon, 13 Sep 2010 20:32:38 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 1792F3A688C; Mon, 13 Sep 2010 20:32:37 -0700 (PDT) Received: from squire.local (dsl-251-240.dynamic-dsl.frii.net [216.17.251.240]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 15A38400EE; Mon, 13 Sep 2010 21:37:09 -0600 (MDT) Message-ID: <4C8EECDA.7090703@stpeter.im> Date: Mon, 13 Sep 2010 21:32:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , daedulus@btconnect.com, ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 03:32:48 -0000 On 9/13/10 6:03 PM, Stefan Santesson wrote: > Peter, > Comments in line; Ditto. > On 10-09-13 9:16 PM, "Peter Saint-Andre" wrote: > >> On 9/13/10 12:39 PM, Stefan Santesson wrote: >>> Peter, >>> >>> On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: >>>> >>>> Hi Shumon, >>>> >>>> As I see it, this I-D is attempting to capture best current practices >>>> regarding the issuance and checking of certificates containing >>>> application server identities. Do we have evidence that any existing >>>> certification authorities issue certificates containing both an SRVname >>>> for the source domain (e.g., example.com) and dNSName for the target >>>> domain (e.g., apphosting.example.net)? Do we have evidence that any >>>> existing application clients perform such checks? If not, I would >>>> consider such complications to be out of scope for this I-D. >>>> >>>> That said, we need to be aware that if such usage arises in the future, >>>> someone might write a document that updates or obsoletes this I-D; in >>>> fact the present authors very much expect that such documents will >>>> emerge after the Internet community (specifically certification >>>> authorities, application service providers, and application client >>>> developers) have gained more experience with PKIX certificates in the >>>> context of various application technologies. >>>> >>>> Peter >>> >>> I would like to turn the question around and ask why this specification need >>> to have an opinion on whether a relying party feels he have to check both >>> host name and service? >> >> Stop right there. :) I sense a possible source of confusion. What do you >> mean by "host name" and what do you mean by "service"? >> > Sorry for sloppy use of words. > > With host name I mean here the actual DNS name of the host, which might be > host1.example.com (dNSName) Or which might be apphost37.example.net or whatever... > By service I mean the service under a given domain, which for the same host > might be _xmpp.example.com (SRVName) OK. But what does dNSName=host1.example.com + SRVName=_xmpp.example.com actually mean? I see three possibilities: 1. "Connect to example.com's XMPP service only if it's hosted on host1.example.com" 2. "Don't connect to host1.example.com if you are looking for something other than example.com's XMPP service" (i.e., if you want the IMAP service or anything else at example.com, terminate the connection) 3. "The connection is fine if you're looking for (a) any service at host1.example.com, *or* (b) example.com's XMPP service" In my experience running the XMPP ICA for a few years, I found that our root CA would issue dNSName=example.com + SRVName=_xmpp.example.com but not dNSName=host1.example.com + SRVName=_xmpp.example.com (i.e., the name in both dNSName and SRVName was the same). Yes, that is anecdotal, but I think it makes some sense, because IMHO a CA is not going to "get involved" with the particular machine that hosts a service (i.e., to differentiate between the DNS domain name of the application service and the DNS domain name of the hosting machine / provider). > Under the current rules, using this example I read it that the following > apply: > > - If you are just checking the SRVName you will not learn the legitimate > host DNS name. Are there any application clients today that would check only the SRVName? > So a certificate issued to host2.example.com will be accepted > even if you intended to contact host1.example.com (even if that information > is in the cert). In what sense does the application client "intend" to contact host1.example.com? The user controlling a client (a browser or an email client or an IM client or whatever) intends to contact example.com, not host1.example.com or apphost37.example.net or whatever. > - If you just check the dNSName, you will miss the fact that you talk to the > desiganted ldap server and not the xmpp server (even if that information is > in the cert). Correct. If that is a problem in your user community or operating environment, then you need to find a better client. IMHO it is almost a best practice for the DNS domain names in the various presented identifiers of the certificate (dNSName, SRVName, uniformResourceIdentifier, etc.) to be the same. I think we in the Internet community don't yet have enough experience to say that with high confidence, which is why I'm not ready to push on the point in this I-D. However, let us consider the example of a delegated domain, such as dNSName=apphost37.example.net + SRVName=_xmpp.example.com, which might mean: 1. "Connect to example.com's XMPP service only if it's hosted on apphost37.example.com" 2. "Don't connect to apphost37.example.com if you are looking for something other than example.com's XMPP service" (i.e., if you want the IMAP service or anything else at example.com, terminate the connection) 3. "The connection is fine if you're looking for (a) any service at apphost37.example.com, *or* (b) example.com's XMPP service" In this case, I think #3 is clearly wrong because the user doesn't know anything about apphost37.example.net and doesn't intend to connect to that host. #1 and #2 are close to equivalent, because they attempt to establish a firm association between a host name (apphost37.example.net) and an application service (example.com's XMPP service). Is that association desirable? I'm not convinced (mainly because, to reiterate, I think that end users don't know or care about the hosting provider or machine). However, for such an association to be helpful, we'd need (i) clients that consistently check both identifier types and (ii) CAs that certify both the application service and the hosting provider. Further, I think we'd also need (iii) a well-defined semantic that says dNSName is used to represent the DNS domain name of the hosting provider or machine -- and as far as I can see dNSName does not have that meaning. Given that we don't have (i), (ii), or (iii), I question the need for this line of thinking. >> In this I-D, we talk about "DNS domain name" and "service type", which >> map quite well to _Service.Name from RFC 4985: the DNS domain name is >> the "source domain" provided by the user or configured into the client >> (e.g., "example.com") and the "service type" is a given application >> protocol that could be serviced by the source domain (e.g., "IMAP"). >> >> This I-D is attempting to gently nudge people in the direction of >> checking both the DNS domain name and the service type. IMHO this is >> consistent with considering the SRVName and uniformResourceIdentifier >> subjectAltName entries as more tightly scoped than dNSName or CN, and >> therefore as potentially more "secure" in some sense (the subject might >> want to limit use of a particular certificate to only the service type >> identified in the SRVName or uniformResourceIdentifier). >> >> If by "host name" you mean "target domain" as defined in the I-D (and >> mapping to "Target" from RFC 2782) then we have more to discuss. >> >>> I'm not against describing the typical case, as long as this specification >>> does not imply that a relying party that has a reason to check two name >>> types is doing something wrong. >> >> That is not the intent of this I-D, however that would be functionality >> over and above what this I-D defines. >> >>> I have no extremely good examples of practical implementation here but >>> checking both host name and service seems like both extremely easy and good >>> practice. >> >> With respect to revisions to this I-D, the lack of good examples >> troubles me because we have been trying to abstract from common usage, >> not to define guidelines for use cases that have not yet been defined, >> implemented, and deployed. >> >> Given that you would prefer to leave the door open to more advanced >> checking rules, I think you would object to this text in Section 4.3: >> >> Once the client has constructed its list of reference identifiers and >> has received the server's presented identifiers in the form of a PKIX >> certificate, the client checks its reference identifiers against the >> presented identifiers for the purpose of finding a match. It does so >> by seeking a match and stopping the search if any presented >> identifier matches one of its reference identifiers. The search >> fails if the client exhausts its list of reference identifiers >> without finding a match. >> >> You are saying that it is not necessarily appropriate to stop the search >> once a single match is found, because the client might be configured to >> look for multiple matches (e.g., a match against both the source domain >> and the target domain). Would you like to suggest text that covers such >> a case? Here is a possible rewrite of Section 4.3 that might address >> your concern. >> >> ### >> >> 4.3. Seeking a Match >> >> Once the client has constructed its list of reference identifiers and >> has received the server's presented identifiers in the form of a PKIX >> certificate, the client checks its reference identifiers against the >> presented identifiers for the purpose of finding a match. The search >> fails if the client exhausts its list of reference identifiers >> without finding a match. The search succeeds if any presented >> identifier matches one of the reference identifiers, at which point >> the client SHOULD stop the search. >> >> Implementation Note: A client might be configured to perform >> multiple searches, i.e., to match more than one reference >> identifier; although such behavior is not forbidden by this >> document, rules for matching multiple reference identifiers are a >> matter for implementation or future specification. >> >> Security Note: A client MUST NOT seek a match for a reference >> identifier of CN-ID if the presented identifiers include an >> SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName >> entry types supported by the client. >> >> Detailed comparison rules for finding a match are provided in the >> following sections. >> > > This sounds better to me. > > If I'm not totally wrong in my example above I also think it would be good > with a security note stating that an SRVName may not provide the full host > DNS name, and if it is important to verify the host DNS name, you must > verify the dNSName in addition to what else you are checking. See above. You and I seem to continually run aground on a disagreement over whether it makes any sense for an application client (or the user thereof) to know of, care about, or verify the DNS domain name of the hosting machine / service / provider. That's the basis for our previous discussion about RFC 4985 and it's the basis for our current discussion about dNSName vs. SRVName. I simply don't understand why a normal human user of an application client would ever want or need to be aware of the hosting provider for a given application service, why a CA would want to certify an association between a hosting provider and a given application service, or why we would ever assume that the dNSName is meant to identify the hosting provider whereas the SRVName is meant to identify the application service. Cementing such an association in those three ways is outside the scope of this I-D, even if one accepts the premise that such an association is a good idea (which I don't). Can we agree to disagree here and, rather than add a note about the security features of such an association, instead add a note to Section 1.3.2 ("Out of Scope") explaining why any possible association between the application service and the hosting machine / service / provider is out of scope for this I-D? Perhaps in the future we will have advanced far enough to define best practices for such associations, but right now it seems to me that we lack a firm basis for doing so. Peter -- Peter Saint-Andre https://stpeter.im/ From jimsch@nwlink.com Mon Sep 13 22:54:42 2010 Return-Path: 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 CC58A3A684D; Mon, 13 Sep 2010 22:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_27=0.6] 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 w6wKOgJtC8HU; Mon, 13 Sep 2010 22:54:32 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 4839A3A68D5; Mon, 13 Sep 2010 22:54:20 -0700 (PDT) Received: from TITUS (pool-96-225-201-121.ptldor.dsl-w.verizon.net [96.225.201.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.pacifier.net (Postfix) with ESMTP id 6ED236A478; Mon, 13 Sep 2010 22:54:41 -0700 (PDT) From: "James Schaad" To: "'Peter Saint-Andre'" References: <000701cb4e4b$8f8f5480$aeadfd80$@nwlink.com> <4C8E704B.1030307@stpeter.im> In-Reply-To: <4C8E704B.1030307@stpeter.im> Date: Mon, 13 Sep 2010 23:01:45 -0700 Message-ID: <000001cb53d2$52a454d0$f7ecfe70$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQND7Iu6/+NhgYxajluQqz7CT/Ju8wGZuozUArIj8BuP/WH2AA== Content-Language: en-us Cc: certid@ietf.org, tls@ietf.org, jeff.hodges@paypal.com Subject: Re: [certid] [TLS] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 05:54:43 -0000 Here are some additional comments inline. > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Monday, September 13, 2010 11:41 AM > To: James Schaad > Cc: jeff.hodges@paypal.com; certid@ietf.org; tls@ietf.org > Subject: Re: [TLS] Review of draft-saintandre-tls-server-id-check >=20 > Thanks for your careful review. Comments inline. >=20 > On 9/6/10 11:14 PM, James Schaad wrote: > > 1. There are those who say that the DNS system is dead for dealing = with > > identification of items. That the main way that people find items = these > > days is by doing searches. This should perhaps be acknowledged in > > section 1.3 under the DNS domain names section. I.e. we use DNS = names > > still for some things (such as SMTP servers), but for many things = the > > name that the user knows is obtained in a very indirect manner. = (search, > > URL click, address book entry) In a similar manner today people = don=EF=BF=BDt > > remember telephone numbers as they are all indirectly obtained, but = they > > do write them down to give to other people. >=20 > Yes, that is a good point. Complicated, but good. We somewhat address = it > in this paragraph: >=20 > Finally, we do not discuss attributes unrelated to DNS domain > names, such as those defined in [X.520] and other such > specifications (e.g., organizational attributes, geographical > attributes, company logos, and the like). >=20 > It seems to me that this relates to the expectations of human users = more > than our relatively clear-cut discussion of DNS domain names. For > example, supposedly some large percentage of the searches on Yahoo! = are > for "Google" (and vice-versa); clearly the folks who are doing such > searches are from our perspective rather unsophisticated users of the > Internet, and they might know that they're on "Google" when they see = the > company logo (which changes on special days!) not when they see > "http://www.google.com/" in the address bar of their browser. The > authors of this I-D have not completed any research into the > expectations of such users (although Jeff has better knowledge of the > literature than I do), so it seems inappropriate for us to say much > about the matter. However, I agree that this would be a good topic for > further research and discussion (e.g., perhaps "petnames" might make > sense here). I agree that there is an issue. I disagree that this is discussed in = any way. I read the paragraph above as addressing the question of = additional attributes that might appear in a certificate (such as = logotypes) and not as dealing with additional attributes that are = displayed on the screen or indirectly inferred by the user. I still = think that a (short) discussion to the fact that in some cases where the = user did not explicitly enter the reference identifier, there may be = cases that even though all of the details match -- the user will be at = an unexpected location. (This is after all what a phishing attack is = all about.) >=20 > > 2. Do you consider an HTTP redirect to still be a direct name or is > > this now an indirect name? The simplest method would be to go from = an > > http: to an https: but other types of redirects are also interesting = =EF=BF=BD > > not the least is just clicking w/o actually looking at where you are = going. >=20 > IMHO the name received via an HTTP redirect is an indirect name (e.g., = I > typed "exmaple.com" but my browser is redirected to "example.com"). > Naturally that applies only to domain redirects -- a redirect from one > URL to another URL within the same domain would preserve the same DNS > domain name for identity checking purposes. I agree that this is a case of an indirect name. I think therefore that = you need to look at the table in section 2.1 and change the URI-ID to be = "Either" rather than "Yes" in the Direct column. And yes I agree that = if the URL that you are redirected to has the same Domain Name, then it = is a moot point. >=20 > > 3. You might want to also give a domain-component (dc=3D) version = of the > > common name for doing identifiers =EF=BF=BD and then say it is out = of scope. > > i.e. =EF=BF=BDdc=3Dcom, dc=3Dexample, dc=3Dwww=EF=BF=BD >=20 > Earlier versions of this I-D (up through -06) talked about domain > components as something not to do, but that seems to have caused more > confusion than clarity so we removed the text. I understand. >=20 > > 4. You might want to add to the implementation note on page 15 that > > there is not always agreement about the order that the strings = should be > > displayed in. Thus for some the root RDN is displayed first but for > > others it is displayed last. (Thus the CERT_NAME_STR_REVERSE_FLAG = for > > the CertStrToName function from Microsoft.) >=20 > Yes, there was much discussion about that topic on the certid@ietf.org = list. >=20 > We currently have this sentence: >=20 > However, because > a Relative Distinguished Name (RDN) is an unordered group of > attribute-type-and-value pairs, the string representation of an > RDN can differ from the canonical DER encoding. >=20 > Does adding the parenthetical clause at the end of the following text > address your concern? >=20 > However, because > a Relative Distinguished Name (RDN) is an unordered group of > attribute-type-and-value pairs, the string representation of an > RDN can differ from the canonical DER encoding (and the order of > attribute-type-and-value pairs can differ in the string > representations or display orders provided by various > implementations). Sorry - I did not make myself sufficiently clear. There are cases = where the RDNSequence (a SEQUENCE and therefore ordered) is displayed in = reverse order. This is what the flag does. Inside of the RDNSequence = is a RelativeDistinguishedName which is a SET an therefore does not have = order. The order of the RDNSequence is ordered since it is in fact a sequence. = What is not ordered is the attribute value pairs that make up a = RelativeDistinguishedName. Generally an RDN is the same as the RDNSequence. Going back and re-reading the text. It is clear that there is going to = be some confusion about what names are and what the fields of names are. = Certificates use the type RDNSequence as the "Name" field of a = certificate. This corresponds to the DN that you are talking about in = the text. They use the longer RelativeDistinguishedName type as the RDN = that you are talking about in the text. Without some clarification = someplace, there is bound to be some confusing popping up.=20 >=20 > > 5. In section 3, what about URI-ID and SVN-ID =EF=BF=BD are = multiple of these > > name forms allowed or not? Since 5 is explicit on CN-ID and DNS-ID = I > > think that the other two name forms should be covered as well. >=20 > I agree that we need to be clear about that, and I think that it is > acceptable to include multiple instances of those identifier types. I would think that having multiple SVN-IDs make sense - esp since you = can get multiple values from the DNS on the indirect. I am not so sure = that it makes any more sense to allow for multiple URI-ID values unless = they are in the same DNS space - for the same reasons that it does not = make sense to allow for multiple DNS-ID records to be presented. >=20 > > 6. I am not really happy with the choice of wording for = =EF=BF=BDand aborting > > the search=EF=BF=BD =EF=BF=BD in my mind you abort for bad = conditions and not for good > > conditions. Stop the search, exit the search are all reasonable and > > don=EF=BF=BDt imply an error state. >=20 > In the working copy I've changed "aborting" to "stopping". Yes this addresses my issue. >=20 > > 7. I got confused and started to say that you needed to do = wildcards in > > section 4.4.1 because that is not referenced in the text of section > > 4.4. >=20 > Yes, adding a forward pointer from 4.4 to 4.4.3 makes sense. >=20 > > It is not clear how the wildcard label matching should be done > > dependent on the tradition vs. internationalized domain name = difference. > > > > The client MUST match the source domain of a reference identifier > > according to the following rules. The rules used depends on = whether the > > source domain is a "traditional domain name" or an = "internationalized > > domain name" as previously defined, and if wildcard labels are = permitted. >=20 > I see your point. In our working copy I've adjusted Section 4.4 to = read > as follows (thus pointing to the sections that follow): >=20 > ### >=20 > 4.4. Verifying a Domain Name >=20 > The client MUST match the source domain of a reference identifier > according to the following rules. The rules differ depending on > whether the source domain is a "traditional domain name" or an > "internationalized domain name" (as previously defined). > Furthermore, the source domain (whether a traditional domain name = or > an internationalized domain name) might contain the wildcard > character '*' as the left-most label, so we define a supplemental > rule for so-called "wildcard domains". Finally, we specify the > circumstances under which it is acceptable to check the "CN-ID" > identifier type. >=20 > ### Looks good >=20 > > 8. Does the following statement apply in section 4.4.2? What does = it > > mean for 4.4.1 if a wildcard is present? > > > > Each label MUST match in order for the names to be = considered to > match. > > > > I think that it is confusing and should potentially = be > > removed. >=20 > Yes, that applies to both traditional domain names and = internationalized > domain names. I have added the sentence to the paragraph in Section = 4.4.2. >=20 > However, I have slightly modified the text to address your point about > wildcard labels, as follows: >=20 > ### >=20 > 4.4.1. Checking of Traditional Domain Names >=20 > If the source domain of a reference identifier is a "traditional > domain name", then matching of the reference identifier against the > presented identifier is performed by comparing the set of domain = name > components using a case-insensitive ASCII comparison, as clarified = by > [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased to > "www.example.com" for comparison purposes). Each label MUST match = in > order for the names to be considered to match, except as = supplemented > by the rule about checking of wildcard labels (Section 4.4.3). >=20 > 4.4.2. Checking of Internationalized Domain Names >=20 > If the source domain of a reference identifier is an > internationalized domain name, then an implementation MUST convert > every label in the domain name to an A-label before checking the > domain name. Each label MUST match in order for the names to be > considered to match, except as supplemented by the rule about > checking of wildcard labels (Section 4.4.3). >=20 > 4.4.3. Checking of Wildcard Labels >=20 > A client employing this specification's rules MAY match the = reference > identifier against a presented identifier whose DNS domain name > contains one instance of the wildcard character '*', but only if = that > character is the complete left-most label of the domain name, e.g. > *.example.com (following the definition of "label" from [DNS]). >=20 > If the wildcard character '*' is the complete left-most label of a > traditional domain name or internationalized domain name, the > wildcard MUST be used to match only the one position-wise > corresponding label (thus *.example.com matches foo.example.com but > not bar.foo.example.com or example.com). The client MUST fail to > match a presented identifier in which the wildcard character is > contained within a label fragment (e.g., baz*.example.net is not > allowed and MUST NOT be taken to match baz1.example.net and > baz2.example.net), or in which the wildcard character does not > comprise the left-most label in the presented identifier (e.g., > neither bar.*.example.net nor bar.f*o.example.net are allowed). >=20 > [...] >=20 > ### Looks good >=20 > > 9. In section 4.6.2 =EF=BF=BD I can understand that a certificate = =EF=BF=BDchange=EF=BF=BD by > > having the certification path change. However if one were to change = the > > DNS domain name, identifiers, issuer or expiration date, I = don=EF=BF=BDt > > understand how one would say that it is the same cached certificate? = Do > > you expect clients to cache the certificate based one something = other > > than the actual bytes of the certificate? i.e. the public key and > > subject name? Or are you trying to address the case where for the > > specific reference identifier there exists a cached certificate and = the > > certificate that was presented is a different certificate from the = one > > that was cached? (In which case one should potentially say that one > > needs to fall into the 4.6.3 logic after informing the user of the = fact.) >=20 > We care about the latter case, which means we can simplify the text in > Section 4.6.2, as follows: >=20 > ### >=20 > 4.6.2. Case #2: No Match Found, Cached Certificate >=20 > If the client finds no presented identifier that matches any of the > reference identifiers but a natural person has permanently accepted > the certificate during a previous connection attempt or via > configured preferences, the certificate is cached. In this case, = the > client MUST verify that the presented certificate matches the = cached > certificate; if the presented certificate does not match the cached > certificate then the client MUST proceed as described under Case #3 > below. >=20 >=20 > ### Did you mean to lose the case where the certification chain has been = modified from the time where the natural person accepted the = certificate? I can see this as being one case where a different = processing might need to occur. Jim >=20 > Thanks again for the review. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ From stefan@aaa-sec.com Mon Sep 13 23:40:56 2010 Return-Path: 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 062F13A68E0 for ; Mon, 13 Sep 2010 23:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=0.617, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 329vnwIJreYP for ; Mon, 13 Sep 2010 23:40:53 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 1A8553A68E2 for ; Mon, 13 Sep 2010 23:40:52 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 9522C37F118 for ; Tue, 14 Sep 2010 08:41:18 +0200 (CEST) Received: (qmail 34644 invoked from network); 14 Sep 2010 06:41:16 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Sep 2010 06:41:16 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 14 Sep 2010 08:41:11 +0200 From: Stefan Santesson To: Peter Saint-Andre Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActT19GdfCoy95NaE0ycSk3oFkVxmQ== In-Reply-To: <4C8EECDA.7090703@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , daedulus@btconnect.com, ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 06:40:56 -0000 Peter, I'm not driven by any desire to mandate more complex name comparison than is called for. I just tend to think that it is better leave name comparison requirement up to local policy. However I think your argumentation is reasonable here and you convinced me. I agree that in the general cases you are not interested in the host DNS name. I've decided that I'm perfectly fine with your proposed wording. /Stefan On 10-09-14 5:32 AM, "Peter Saint-Andre" wrote: > On 9/13/10 6:03 PM, Stefan Santesson wrote: >> Peter, >> Comments in line; > > Ditto. > >> On 10-09-13 9:16 PM, "Peter Saint-Andre" wrote: >> >>> On 9/13/10 12:39 PM, Stefan Santesson wrote: >>>> Peter, >>>> >>>> On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: >>>>> >>>>> Hi Shumon, >>>>> >>>>> As I see it, this I-D is attempting to capture best current practices >>>>> regarding the issuance and checking of certificates containing >>>>> application server identities. Do we have evidence that any existing >>>>> certification authorities issue certificates containing both an SRVname >>>>> for the source domain (e.g., example.com) and dNSName for the target >>>>> domain (e.g., apphosting.example.net)? Do we have evidence that any >>>>> existing application clients perform such checks? If not, I would >>>>> consider such complications to be out of scope for this I-D. >>>>> >>>>> That said, we need to be aware that if such usage arises in the future, >>>>> someone might write a document that updates or obsoletes this I-D; in >>>>> fact the present authors very much expect that such documents will >>>>> emerge after the Internet community (specifically certification >>>>> authorities, application service providers, and application client >>>>> developers) have gained more experience with PKIX certificates in the >>>>> context of various application technologies. >>>>> >>>>> Peter >>>> >>>> I would like to turn the question around and ask why this specification >>>> need >>>> to have an opinion on whether a relying party feels he have to check both >>>> host name and service? >>> >>> Stop right there. :) I sense a possible source of confusion. What do you >>> mean by "host name" and what do you mean by "service"? >>> >> Sorry for sloppy use of words. >> >> With host name I mean here the actual DNS name of the host, which might be >> host1.example.com (dNSName) > > Or which might be apphost37.example.net or whatever... > >> By service I mean the service under a given domain, which for the same host >> might be _xmpp.example.com (SRVName) > > OK. > > But what does dNSName=host1.example.com + SRVName=_xmpp.example.com > actually mean? I see three possibilities: > > 1. "Connect to example.com's XMPP service only if it's hosted on > host1.example.com" > > 2. "Don't connect to host1.example.com if you are looking for something > other than example.com's XMPP service" (i.e., if you want the IMAP > service or anything else at example.com, terminate the connection) > > 3. "The connection is fine if you're looking for (a) any service at > host1.example.com, *or* (b) example.com's XMPP service" > > In my experience running the XMPP ICA for a few years, I found that our > root CA would issue dNSName=example.com + SRVName=_xmpp.example.com but > not dNSName=host1.example.com + SRVName=_xmpp.example.com (i.e., the > name in both dNSName and SRVName was the same). Yes, that is anecdotal, > but I think it makes some sense, because IMHO a CA is not going to "get > involved" with the particular machine that hosts a service (i.e., to > differentiate between the DNS domain name of the application service and > the DNS domain name of the hosting machine / provider). > >> Under the current rules, using this example I read it that the following >> apply: >> >> - If you are just checking the SRVName you will not learn the legitimate >> host DNS name. > > Are there any application clients today that would check only the SRVName? > >> So a certificate issued to host2.example.com will be accepted >> even if you intended to contact host1.example.com (even if that information >> is in the cert). > > In what sense does the application client "intend" to contact > host1.example.com? The user controlling a client (a browser or an email > client or an IM client or whatever) intends to contact example.com, not > host1.example.com or apphost37.example.net or whatever. > >> - If you just check the dNSName, you will miss the fact that you talk to the >> desiganted ldap server and not the xmpp server (even if that information is >> in the cert). > > Correct. If that is a problem in your user community or operating > environment, then you need to find a better client. > > IMHO it is almost a best practice for the DNS domain names in the > various presented identifiers of the certificate (dNSName, SRVName, > uniformResourceIdentifier, etc.) to be the same. I think we in the > Internet community don't yet have enough experience to say that with > high confidence, which is why I'm not ready to push on the point in this > I-D. However, let us consider the example of a delegated domain, such as > dNSName=apphost37.example.net + SRVName=_xmpp.example.com, which might mean: > > 1. "Connect to example.com's XMPP service only if it's hosted on > apphost37.example.com" > > 2. "Don't connect to apphost37.example.com if you are looking for > something other than example.com's XMPP service" (i.e., if you want the > IMAP service or anything else at example.com, terminate the connection) > > 3. "The connection is fine if you're looking for (a) any service at > apphost37.example.com, *or* (b) example.com's XMPP service" > > In this case, I think #3 is clearly wrong because the user doesn't know > anything about apphost37.example.net and doesn't intend to connect to > that host. > > #1 and #2 are close to equivalent, because they attempt to establish a > firm association between a host name (apphost37.example.net) and an > application service (example.com's XMPP service). Is that association > desirable? I'm not convinced (mainly because, to reiterate, I think that > end users don't know or care about the hosting provider or machine). > However, for such an association to be helpful, we'd need (i) clients > that consistently check both identifier types and (ii) CAs that certify > both the application service and the hosting provider. Further, I think > we'd also need (iii) a well-defined semantic that says dNSName is used > to represent the DNS domain name of the hosting provider or machine -- > and as far as I can see dNSName does not have that meaning. Given that > we don't have (i), (ii), or (iii), I question the need for this line of > thinking. > >>> In this I-D, we talk about "DNS domain name" and "service type", which >>> map quite well to _Service.Name from RFC 4985: the DNS domain name is >>> the "source domain" provided by the user or configured into the client >>> (e.g., "example.com") and the "service type" is a given application >>> protocol that could be serviced by the source domain (e.g., "IMAP"). >>> >>> This I-D is attempting to gently nudge people in the direction of >>> checking both the DNS domain name and the service type. IMHO this is >>> consistent with considering the SRVName and uniformResourceIdentifier >>> subjectAltName entries as more tightly scoped than dNSName or CN, and >>> therefore as potentially more "secure" in some sense (the subject might >>> want to limit use of a particular certificate to only the service type >>> identified in the SRVName or uniformResourceIdentifier). >>> >>> If by "host name" you mean "target domain" as defined in the I-D (and >>> mapping to "Target" from RFC 2782) then we have more to discuss. >>> >>>> I'm not against describing the typical case, as long as this specification >>>> does not imply that a relying party that has a reason to check two name >>>> types is doing something wrong. >>> >>> That is not the intent of this I-D, however that would be functionality >>> over and above what this I-D defines. >>> >>>> I have no extremely good examples of practical implementation here but >>>> checking both host name and service seems like both extremely easy and good >>>> practice. >>> >>> With respect to revisions to this I-D, the lack of good examples >>> troubles me because we have been trying to abstract from common usage, >>> not to define guidelines for use cases that have not yet been defined, >>> implemented, and deployed. >>> >>> Given that you would prefer to leave the door open to more advanced >>> checking rules, I think you would object to this text in Section 4.3: >>> >>> Once the client has constructed its list of reference identifiers and >>> has received the server's presented identifiers in the form of a PKIX >>> certificate, the client checks its reference identifiers against the >>> presented identifiers for the purpose of finding a match. It does so >>> by seeking a match and stopping the search if any presented >>> identifier matches one of its reference identifiers. The search >>> fails if the client exhausts its list of reference identifiers >>> without finding a match. >>> >>> You are saying that it is not necessarily appropriate to stop the search >>> once a single match is found, because the client might be configured to >>> look for multiple matches (e.g., a match against both the source domain >>> and the target domain). Would you like to suggest text that covers such >>> a case? Here is a possible rewrite of Section 4.3 that might address >>> your concern. >>> >>> ### >>> >>> 4.3. Seeking a Match >>> >>> Once the client has constructed its list of reference identifiers and >>> has received the server's presented identifiers in the form of a PKIX >>> certificate, the client checks its reference identifiers against the >>> presented identifiers for the purpose of finding a match. The search >>> fails if the client exhausts its list of reference identifiers >>> without finding a match. The search succeeds if any presented >>> identifier matches one of the reference identifiers, at which point >>> the client SHOULD stop the search. >>> >>> Implementation Note: A client might be configured to perform >>> multiple searches, i.e., to match more than one reference >>> identifier; although such behavior is not forbidden by this >>> document, rules for matching multiple reference identifiers are a >>> matter for implementation or future specification. >>> >>> Security Note: A client MUST NOT seek a match for a reference >>> identifier of CN-ID if the presented identifiers include an >>> SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName >>> entry types supported by the client. >>> >>> Detailed comparison rules for finding a match are provided in the >>> following sections. >>> >> >> This sounds better to me. >> >> If I'm not totally wrong in my example above I also think it would be good >> with a security note stating that an SRVName may not provide the full host >> DNS name, and if it is important to verify the host DNS name, you must >> verify the dNSName in addition to what else you are checking. > > See above. You and I seem to continually run aground on a disagreement > over whether it makes any sense for an application client (or the user > thereof) to know of, care about, or verify the DNS domain name of the > hosting machine / service / provider. That's the basis for our previous > discussion about RFC 4985 and it's the basis for our current discussion > about dNSName vs. SRVName. I simply don't understand why a normal human > user of an application client would ever want or need to be aware of the > hosting provider for a given application service, why a CA would want to > certify an association between a hosting provider and a given > application service, or why we would ever assume that the dNSName is > meant to identify the hosting provider whereas the SRVName is meant to > identify the application service. Cementing such an association in those > three ways is outside the scope of this I-D, even if one accepts the > premise that such an association is a good idea (which I don't). Can we > agree to disagree here and, rather than add a note about the security > features of such an association, instead add a note to Section 1.3.2 > ("Out of Scope") explaining why any possible association between the > application service and the hosting machine / service / provider is out > of scope for this I-D? Perhaps in the future we will have advanced far > enough to define best practices for such associations, but right now it > seems to me that we lack a firm basis for doing so. > > Peter From stefan@aaa-sec.com Mon Sep 13 23:51:07 2010 Return-Path: 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 58A5F3A68E0 for ; Mon, 13 Sep 2010 23:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396, 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 CeAnlQKIWnXa for ; Mon, 13 Sep 2010 23:51:05 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.115]) by core3.amsl.com (Postfix) with ESMTP id 82D893A686A for ; Mon, 13 Sep 2010 23:51:04 -0700 (PDT) Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 5A15437E731 for ; Tue, 14 Sep 2010 08:51:32 +0200 (CEST) Received: (qmail 90003 invoked from network); 14 Sep 2010 06:51:30 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Sep 2010 06:51:30 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 14 Sep 2010 08:51:27 +0200 From: Stefan Santesson To: Peter Saint-Andre Message-ID: Thread-Topic: Review of draft-saintandre-tls-server-id-check Thread-Index: ActT2UDHCsu0s2pQZ0m6ukepEkTH8Q== In-Reply-To: <4C8EECDA.7090703@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Bernard Aboba , IETF cert-based identity , daedulus@btconnect.com, ietf@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 06:51:07 -0000 Peter, After the past discussions, the remaining things on my review list are: General: consider substituting =B3PKIX-based systems=B2 and =B3PKIX Certificates=B2 with =B3PK= I systems based on RFC 5280=B2 and =B3RFC 5280 Certificates=B2, alternatively include [PKIX] brackets to clarify that it references RFC 5280. =20 =20 General:=20 I would consider stating that server certificates according to this profile either MUST or SHOULD have the serverAuth EKU set since it is allways related to the use of TSL and server authentication. At least it MUST be se= t when allowing checks of the CN-ID (see 2.3 below). =20 =20 1.3.2 and section 3 SRVName is described as an extension in 1.3.2, but is in fact a Subject Alt Name (otherName form) RFC 4985. This error is repeated in section 3, bullet 4, on page 16. =20 1.1.=20 s/an application services/an application service =20 1.2 I find the following text is hard to understand: =B3(this document addresses only the DNS domain name of the application service itself, not the entire trust chain)=B2 I=B9m not sure what the DNS domain name has to do with checking the entire trust chain. Further, this document discuss more name forms than the DNS domain name. Perhaps this sentence was meant to say: "(this document only addresses name forms in the leaf server certificate, not any name forms in the chain of certificate used to validate the server certificate)" =20 =20 =20 2.3 It would be good if we could restrict the use of CN-ID for storing a domain name to the case when the serverAuth EKU is set. Requiring the EKU reduce the probability that the CN-ID appears to be a domain name by accident or i= s a domain name in the wrong context. =20 In many deployments, this also affects the name constraints processing to perform domain name constraints also on the CN attribute. =20 There should at least be a rule stating that any client that accepts the CN attribute to carry the domain name MUST also perform name constraints on this attribute using the domain name logic if name constraints is applied t= o the path. Failing this requirement poses a security threat if the claimed domain name in CN-ID violated the name constraints set for domain names. =20 =20 =20 4.4.3 checking wildcard labels The restriction to match against only one subdomain seems to not be compatible with FRC 4592. RFC 4592 states: =20 A wildcard domain name can have subdomains. There is no need to inspect the subdomains to see if there is another asterisk label in any subdomain. =20 Further, I'm pretty sure that the rule of this draft is incompatible with many deployments of wildcard matching. I recall in Microsoft we allowed any number of subdomains when I was involved with the CAPI team. =20 =20 4.6.2=20 States: =20 In this case, the client MUSTverify that the presented certificate matches the cached certificate and (if it is an interactive client) MUST notify the user if the certificate has changed since the last time a secure connection was successfully negotiated =20 How does the client know if the certificate has changed or whether it just obtained an unauthorized certificate? =20 I guess in some cases it would work but I feel sure there are exception cases where the client just has a configured certificate but no knowledge o= f what it obtained the last time it talked to the server. =20 /Stefan =20 =20 From dave@cridland.net Tue Sep 14 00:58:29 2010 Return-Path: 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 EE3833A68FF; Tue, 14 Sep 2010 00:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] 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 9Jn2Omrf4Tc2; Tue, 14 Sep 2010 00:58:27 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 0A19F3A690E; Tue, 14 Sep 2010 00:58:27 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 617E811680C3; Tue, 14 Sep 2010 08:58:52 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQHoW88QfHYd; Tue, 14 Sep 2010 08:58:49 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 46B3111680AA; Tue, 14 Sep 2010 08:58:49 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <8252.1284451129.280251@puncture> Date: Tue, 14 Sep 2010 08:58:49 +0100 From: Dave Cridland To: Stefan Santesson , Bernard Aboba , IETF cert-based identity , IETF-Discussion , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 07:58:29 -0000 On Tue Sep 14 01:03:39 2010, Stefan Santesson wrote: > Under the current rules, using this example I read it that the > following > apply: > > - If you are just checking the SRVName you will not learn the > legitimate > host DNS name. So a certificate issued to host2.example.com will be > accepted > even if you intended to contact host1.example.com (even if that > information > is in the cert). > > But I don't care about the legitimate hostname. All I care about is that my TLS endpoints are me, and the service I wanted. What hostname that service happens to be delivered on is entirely immaterial. If I *did* care about that, I'd surely also want to verify the IP address, and then I'd want to verify the MAC address, and then the CPUID, and then... Surely if an sRVName (or equivalent) fully matches, this is sufficient to verify that the contacted host is authorized to provide that service for that domain? > - If you just check the dNSName, you will miss the fact that you > talk to the > desiganted ldap server and not the xmpp server (even if that > information is > in the cert). > > Kind of. The rules effectively mean that dNSName is treated as a sRVName with a wildcard service type, as I understand it. > If I'm not totally wrong in my example above I also think it would > be good > with a security note stating that an SRVName may not provide the > full host > DNS name, and if it is important to verify the host DNS name, you > must > verify the dNSName in addition to what else you are checking. I don't see any time when it's desirable, from a security perspective, to check the host name in addition to the service domain name. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From wjhns1@hardakers.net Mon Sep 13 20:58:26 2010 Return-Path: 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 9004C3A688A; Mon, 13 Sep 2010 20:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 kVqYMcWuE2JD; Mon, 13 Sep 2010 20:58:25 -0700 (PDT) Received: from mail.hardakers.net (hardaker-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::af]) by core3.amsl.com (Postfix) with ESMTP id A85533A6881; Mon, 13 Sep 2010 20:58:24 -0700 (PDT) Received: from localhost (unknown [10.1.0.2]) by mail.hardakers.net (Postfix) with ESMTPSA id F1E4298075; Mon, 13 Sep 2010 20:58:49 -0700 (PDT) From: Wes Hardaker To: tls@ietf.org, certid@ietf.org, Peter Saint-Andre , ietf@ietf.org Organization: Sparta Date: Mon, 13 Sep 2010 20:58:49 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Tue, 14 Sep 2010 04:46:56 -0700 Subject: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 03:58:26 -0000 I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good document and support it's forward progress. I do have a few comments though: (*): Applies to many of the comments below: some parts of the document read like a BCP in the way it tries to rationalize things. A number of these text sections really don't help the document, though, as it adds unneeded ambiguity. Examples of this are marked below with (*). Section 1.1: (*) I don't think you should be spelling out the popularity of TLS vs DTLS. While it may be true today, this is intended to be a proposed standard and thus doesn't need to specify that one is potentially more popular than the other. The document should be targeting the use of both regardless of how well DTLS is used at the moment. Suggested: OLD: When a client connects to an application services using Transport Layer Security [TLS] (or, less commonly, Datagram Transport Layer Security [DTLS]), it references some conception of the server's identity while attempting to establish a secure connection (e.g., "the web site at example.com"). New: When a client connects to an application services using Transport Layer Security [TLS] or Datagram Transport Layer Security [DTLS], it references some conception of the server's identity while attempting to establish a secure connection (e.g., "the web site at example.com"). Section 1.1 and the appendices: You could now, if you wanted, add SNMP over (D)TLS: RFC5953. If you're going to copy into the appendix as well, the text to copy is from the snmpTlstmAddrTable object in that document. Section 1.3.2: (*) This section is full of text that is subjective and really isn't needed in the first place. Nearly every paragraph contains text that may be true today but might not be in the future or is subject to interpretation. While I agree with most of the conclusions, I don't think it's worth putting the text into the document; especially when the text is simply defining what's out of scope. I don't think you need to spend effort rationalizing what's out of scope. Suggestion: keep the bullets, ditch the paragraphs. Phrasing examples (IE, an incomplete list) that are questionable: "service operators have less experience with client certificates" "Most fundamentally, most users find DNS domain names much easier to work with than IP addresses, which is why the domain name system was designed in the first place. "Furthermore, application technologies have less experience with IPsec than with TLS, thus making it more difficult to gather feedback on proposed best practices." Section 1.4, "Target Domain" It took me far too long into reading this document to remember what a "target domain" really meant. IMHO, a better term that already conveys the proper meaning to most readers would be a "derived domain". Think about a global search and replace for target->derived? Section 3, bullet 5: Unfortunately, this is the one rule I think will be broken the most often. Fortunately, checking from the client side says to ignore the CN-ID if it can match on other things as well. Because of this, the only thing this particular rule hurts is the software that isn't going to conform to this document because the code is already too old. It's basically a "should upgrade" statement. I think an extra sentence here might be helpful, though I don't have a suggestion at the moment. Section 4.3, security note: I actually think wording these things is tricky when the future is unknown. I think it's generally safer to describe the only conditions which are valid for checking a CN-ID instead of trying to list all the "MUST NOT" cases, which is more likely to change with the addition of future specs into the spec tree. I didn't have time to fully think out replacement text, but I'd start it with "A client MUST only seek a match for a reference identifier of a CN-ID if it is the only available presented identifier." Or something like that. Section 5, Security Considerations: The interesting thing about this specification is that we're leaving a fairly broad range of potential "success" matches. Not only that, but future specifications may lead to future reference identity matches that previously didn't work. Fortunately, I can't come up with an example that works all that well to describe it but somehow I'm left feeling nervous that a server cert could have a clause the clients don't understand currently but might later after a software upgrade and an admin that expects a failure may suddenly see a success. You can ignore this paragraph if you fail to grasp what I'm trying to say, as I'm not at all stating it well. Section 5.1, Service Delegation: You discuss interactive clients and how the the source domain name MUST be provided by a human user. But the odd case that I couldn't figure out what it mapped to was references from an original source. EG, images or javascript elements in a web page aren't "provided by the user", but a web-browser is certainly interactive. This sort of "snow ball" domain list probably should be discussed at least in brief. Section 5.1, Service Delegation: I read the last paragraph (which is one sentence) multiple times and I only barely feel that I understand what it's saying. I'd suggest rewording it for clarity and splitting it into multiple sentences. I'd offer suggestive text, but then I'd prove that I really didn't understand it. General: Some of the possible combinations and options that may exist could really use an "examples" section or something that had example info from a certificate combined with example list of expected reference indenties. Though this would be nice, it's not at all critical. -- Wes Hardaker Cobham Analytic Solutions From shuque@isc.upenn.edu Tue Sep 14 08:44:49 2010 Return-Path: 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 736ED3A6987; Tue, 14 Sep 2010 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599] 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 ZNlfTZvJhtWz; Tue, 14 Sep 2010 08:44:47 -0700 (PDT) Received: from talkeetna.isc-net.upenn.edu (TALKEETNA.isc-net.upenn.edu [128.91.197.188]) by core3.amsl.com (Postfix) with ESMTP id 592CB3A6944; Tue, 14 Sep 2010 08:44:47 -0700 (PDT) Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id D54942724; Tue, 14 Sep 2010 11:45:12 -0400 (EDT) Date: Tue, 14 Sep 2010 11:45:12 -0400 From: Shumon Huque To: Dave Cridland Message-ID: <20100914154512.GA8206@isc.upenn.edu> References: <8252.1284405167.326805@puncture> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8252.1284405167.326805@puncture> User-Agent: Mutt/1.4.2.1i Organization: University of Pennsylvania Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , IETF-Discussion Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 15:44:49 -0000 On Mon, Sep 13, 2010 at 08:12:47PM +0100, Dave Cridland wrote: > On Mon Sep 13 18:59:03 2010, Stefan Santesson wrote: > >I agree here. Both to this and to former speakers stating that the > >assertion > >is made by the CA and no the subject. > > > Well, I'd say the assertion is the presence of the SAN in the cert. I > mean, an assertion is a positive statement made *without* evidence. > The evidence is then the signature of the issuer, who certifies the > assertion - it doesn't matter who makes that assertion. But anyway, > that's somewhat moot, and as Shumon points out, we needn't care about > who authorized what unto whom. Yeah, that's what I meant. Thanks for articulating that more clearly than I did Dave! RFC 4985 specifies the SRVName othername form. The act of authorizing a particular identity to be in a certificate is more related to who issued and signed the certificate, and the act of verifying that authorization is related to the client authenticating the signature of the certificate and building a chain of trust from the issuer back to a trust anchor that it has configured. 4985 doesn't need to say any more on that subject since it's already covered by base PKIX specs. > "The requested DNS domain name for the specified service. That is, > the domain name which would be found in the URI for the service, and > other protocol identifiers of a similar nature. Where the service is > directly requested by hostname, this domain name would be the > requested hostname." > > I think that covers all the cases I'd expect by example, without > worrying about who's asserting and certifying. No doubt someone will > reword with a sprinkling of 2119. > > Dave. This particular sub thread is about errata to 4985, right? If so, I don't think it should mention "URI" or "identifiers of a similar nature". Or are you proposing more general text for inclusion in draft-saintandre-tls-server-id-check? For 4985, I think your first sentence is sufficient by itself. "The requested DNS domain name for the specified service." Or, if we want to elaborate more, I'd suggest: "The requested DNS domain name for the specified service. This is the "Name" component of the corresponding DNS SRV record." Actually, what would be really useful is if the document provided an actual example of an SRV record and and SRVName, right after the definitions in Section 2. Lack of clear examples is a very common problem with many IETF specifications. -- Shumon Huque University of Pennsylvania. From turners@ieca.com Tue Sep 14 09:06:46 2010 Return-Path: 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 3AFD03A683A for ; Tue, 14 Sep 2010 09:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 2hCVdsUTSopV for ; Tue, 14 Sep 2010 09:06:45 -0700 (PDT) Received: from smtp113.biz.mail.mud.yahoo.com (smtp113.biz.mail.mud.yahoo.com [209.191.68.78]) by core3.amsl.com (Postfix) with SMTP id BCCFD3A6919 for ; Tue, 14 Sep 2010 09:06:43 -0700 (PDT) Received: (qmail 53679 invoked from network); 14 Sep 2010 16:07:04 -0000 Received: from thunderfish.local (turners@96.231.127.24 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 14 Sep 2010 09:07:04 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 6YKkNfkVM1kyELf2yVmV7QSu9z17oIk.eGChTtd3smXW._g kPqmBGn9vb..UBU78Re.0rzK1GMKdblvGkiUvgSW9QG44r06U0uROUhT98Y5 qgHvKy3RLTDcM20MIG9u2jB9u2eiPslsOlJSxjx3LaALc2RTiAJFog5sF6XO kJ1A0GC.yqJT.AfExP0o9MPQBM_Drsyon5H5wlS.xsw9n84EgvsPJU7znYo0 UfQJbSFzsG4a6CLOCQY3spEl_J.iFn4J19CYq3Ix9e8x6HDOUUHMHi1qIGsW UUaG3PIFgcKAs8aqyAb7W1UlpVoYNq4.GUhCnqPpqHm.FD.BsESfXKPhQbiQ 1r3CZ04Qj X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8F9DA7.90701@ieca.com> Date: Tue, 14 Sep 2010 12:07:03 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Saint-Andre References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org, tls@ietf.org, ietf@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:06:46 -0000 I'd offered to review this version during the TLS session at IETF 78, but I think I'm going to wait for the next version ;) spt Wes Hardaker wrote: > I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good > document and support it's forward progress. I do have a few comments > though: > > (*): > Applies to many of the comments below: some parts of the document > read like a BCP in the way it tries to rationalize things. A number > of these text sections really don't help the document, though, as it > adds unneeded ambiguity. Examples of this are marked below with (*). > > Section 1.1: (*) > I don't think you should be spelling out the popularity of TLS vs > DTLS. While it may be true today, this is intended to be a proposed > standard and thus doesn't need to specify that one is potentially more > popular than the other. The document should be targeting the use of > both regardless of how well DTLS is used at the moment. Suggested: > > OLD: > When a client connects to an > application services using Transport Layer Security [TLS] (or, less > commonly, Datagram Transport Layer Security [DTLS]), it references > some conception of the server's identity while attempting to > establish a secure connection (e.g., "the web site at example.com"). > > New: > When a client connects to an > application services using Transport Layer Security [TLS] or > Datagram Transport Layer Security [DTLS], it references some > conception of the server's identity while attempting to establish a > secure connection (e.g., "the web site at example.com"). > > Section 1.1 and the appendices: > You could now, if you wanted, add SNMP over (D)TLS: RFC5953. If > you're going to copy into the appendix as well, the text to copy is > from the snmpTlstmAddrTable object in that document. > > Section 1.3.2: (*) > This section is full of text that is subjective and really isn't > needed in the first place. Nearly every paragraph contains text that > may be true today but might not be in the future or is subject to > interpretation. While I agree with most of the conclusions, I don't > think it's worth putting the text into the document; especially when > the text is simply defining what's out of scope. I don't think you > need to spend effort rationalizing what's out of scope. > > Suggestion: keep the bullets, ditch the paragraphs. > > Phrasing examples (IE, an incomplete list) that are questionable: > > "service operators have less experience with client certificates" > > "Most fundamentally, most users find DNS domain names much easier to > work with than IP addresses, which is why the domain name system was > designed in the first place. > > "Furthermore, application technologies have less experience with > IPsec than with TLS, thus making it more difficult to gather > feedback on proposed best practices." > > Section 1.4, "Target Domain" > It took me far too long into reading this document to remember what a > "target domain" really meant. IMHO, a better term that already > conveys the proper meaning to most readers would be a "derived > domain". Think about a global search and replace for target->derived? > > Section 3, bullet 5: > Unfortunately, this is the one rule I think will be > broken the most often. Fortunately, checking from the client side > says to ignore the CN-ID if it can match on other things as well. > Because of this, the only thing this particular rule hurts is the > software that isn't going to conform to this document because the code > is already too old. It's basically a "should upgrade" statement. I > think an extra sentence here might be helpful, though I don't have a > suggestion at the moment. > > Section 4.3, security note: > I actually think wording these things is tricky when the future is > unknown. I think it's generally safer to describe the only conditions > which are valid for checking a CN-ID instead of trying to list all the > "MUST NOT" cases, which is more likely to change with the addition of > future specs into the spec tree. I didn't have time to fully think > out replacement text, but I'd start it with "A client MUST only seek a > match for a reference identifier of a CN-ID if it is the only > available presented identifier." Or something like that. > > Section 5, Security Considerations: > The interesting thing about this specification is that we're leaving a > fairly broad range of potential "success" matches. Not only that, but > future specifications may lead to future reference identity matches > that previously didn't work. Fortunately, I can't come up with an > example that works all that well to describe it but somehow I'm left > feeling nervous that a server cert could have a clause the clients > don't understand currently but might later after a software upgrade > and an admin that expects a failure may suddenly see a success. You > can ignore this paragraph if you fail to grasp what I'm trying to say, > as I'm not at all stating it well. > > Section 5.1, Service Delegation: > You discuss interactive clients and how the the source domain name > MUST be provided by a human user. But the odd case that I couldn't > figure out what it mapped to was references from an original source. > EG, images or javascript elements in a web page aren't "provided by > the user", but a web-browser is certainly interactive. This sort of > "snow ball" domain list probably should be discussed at least in > brief. > > Section 5.1, Service Delegation: > I read the last paragraph (which is one sentence) multiple times and I > only barely feel that I understand what it's saying. I'd suggest > rewording it for clarity and splitting it into multiple sentences. > I'd offer suggestive text, but then I'd prove that I really didn't > understand it. > > General: > Some of the possible combinations and options that may exist could > really use an "examples" section or something that had example info > from a certificate combined with example list of expected reference > indenties. Though this would be nice, it's not at all critical. > From stpeter@stpeter.im Tue Sep 14 09:12:32 2010 Return-Path: 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 7FD693A68F8; Tue, 14 Sep 2010 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, 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 Qsgx0P-zA0tM; Tue, 14 Sep 2010 09:12:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 980853A682D; Tue, 14 Sep 2010 09:12:30 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B098440337; Tue, 14 Sep 2010 10:17:06 -0600 (MDT) Message-ID: <4C8F9F05.2030703@stpeter.im> Date: Tue, 14 Sep 2010 10:12:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Sean Turner References: <4C8F9DA7.90701@ieca.com> In-Reply-To: <4C8F9DA7.90701@ieca.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org, tls@ietf.org, ietf@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:12:32 -0000 On 9/14/10 10:07 AM, Sean Turner wrote: > I'd offered to review this version during the TLS session at IETF 78, > but I think I'm going to wait for the next version ;) Yes, the authors will work to submit a revised I-D soon, based on all the feedback received so far. Peter -- Peter Saint-Andre https://stpeter.im/ From stefan@aaa-sec.com Tue Sep 14 09:52:42 2010 Return-Path: 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 6B7453A69EB for ; Tue, 14 Sep 2010 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 LuczpZll-mt8 for ; Tue, 14 Sep 2010 09:52:25 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.111]) by core3.amsl.com (Postfix) with ESMTP id 967363A6AB8 for ; Tue, 14 Sep 2010 09:52:17 -0700 (PDT) Received: from s19.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id B188638F52F for ; Tue, 14 Sep 2010 18:52:41 +0200 (CEST) Received: (qmail 9987 invoked from network); 14 Sep 2010 16:52:35 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.17]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 14 Sep 2010 16:52:35 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 14 Sep 2010 18:52:29 +0200 From: Stefan Santesson To: RFC Errata System , , , , , IETF cert-based identity Message-ID: Thread-Topic: [Technical Errata Reported] RFC4985 (2520) Thread-Index: ActULTdnmFYa2WQffEG3V4guTdnSDg== In-Reply-To: <20100914163434.9E6BEE06E9@rfc-editor.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: pkix@ietf.org, sts@aaa-sec.com Subject: Re: [certid] [Technical Errata Reported] RFC4985 (2520) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 16:52:42 -0000 I have submitted the following errata as a result of the discussions concerning draft-saintandre-tls-server-id-check. The updated text has been agreed on during these discussions. This is not considered to be a change of the RFC since the correct definition is given in two other places (explained in the errata). This is thus just an error fix to remove an ambiguity and to bring the document in alignment with itself. /Stefan On 10-09-14 6:34 PM, "RFC Errata System" wrote: > > The following errata report has been submitted for RFC4985, > "Internet X.509 Public Key Infrastructure Subject Alternative Name for > Expression of Service Name". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4985&eid=2520 > > -------------------------------------- > Type: Technical > Reported by: Stefan Santesson > > Section: 2 > > Original Text > ------------- > Name > > The DNS domain name of the domain where the specified service > > is located. > > Corrected Text > -------------- > Name > > A DNS domain name, representing a domain for which the certificate > > issuer has asserted that the certified subject is a legitimate > > provider of the identified service. > > Notes > ----- > The current text is ambiguous compared with the defined meaning of this name > form given in the RFC. > > > > The definition of this component is given in the overall definition as: > > > > "The content of the components of this name form MUST be consistent > > with the corresponding definition of these components in an SRV RR > > according to RFC 2782 [N3]." > > > > And later in the same section: > > > > "The purpose of the SRVName is limited to authorization of > > service provision within a domain." > > > > The changed text makes it clear that the domain is the domain where the > certified host is a legitimate service provider, which may or may not be the > domain where the same host is located. Thus the changed text harmonize with > the rest of the document. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4985 (draft-ietf-pkix-srvsan-05) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Subject > Alternative Name for Expression of Service Name > Publication Date : August 2007 > Author(s) : S. Santesson > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG From dave@cridland.net Tue Sep 14 11:44:32 2010 Return-Path: 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 C82243A6B05; Tue, 14 Sep 2010 11:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] 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 O41Qgvnx1QEc; Tue, 14 Sep 2010 11:44:29 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 483423A6A9F; Tue, 14 Sep 2010 11:44:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 6631B11680C3; Tue, 14 Sep 2010 19:44:19 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aCBICYZROEU; Tue, 14 Sep 2010 19:44:16 +0100 (BST) Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 3D22C11680AA; Tue, 14 Sep 2010 19:44:16 +0100 (BST) References: <8252.1284405167.326805@puncture> <20100914154512.GA8206@isc.upenn.edu> In-Reply-To: <20100914154512.GA8206@isc.upenn.edu> MIME-Version: 1.0 Message-Id: <8252.1284489856.244254@puncture> Date: Tue, 14 Sep 2010 19:44:16 +0100 From: Dave Cridland To: Shumon Huque , Stefan Santesson , Bernard Aboba , IETF cert-based identity , IETF-Discussion , Peter Saint-Andre Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 18:44:32 -0000 On Tue Sep 14 16:45:12 2010, Shumon Huque wrote: > On Mon, Sep 13, 2010 at 08:12:47PM +0100, Dave Cridland wrote: > > "The requested DNS domain name for the specified service. That is, > > the domain name which would be found in the URI for the service, > and > > other protocol identifiers of a similar nature. Where the service > is > > directly requested by hostname, this domain name would be the > > requested hostname." > > > > I think that covers all the cases I'd expect by example, without > > worrying about who's asserting and certifying. No doubt someone > will > > reword with a sprinkling of 2119. > > > > Dave. > > This particular sub thread is about errata to 4985, right? If so, > I don't think it should mention "URI" or "identifiers of a similar > nature". Or are you proposing more general text for inclusion in > draft-saintandre-tls-server-id-check? > > For 4985. The reason I mention URIs and suchlike is that if someone is attempting to verify a certificate for, say, xmpp://dwd@dave.cridland.net/, the Name is the domain in the URI, and not any intermediate form. > Actually, what would be really useful is if the document provided an > actual example of an SRV record and and SRVName, right after the > definitions in Section 2. Lack of clear examples is a very common > problem with many IETF specifications. An example speaks a thousand normative statements, as they say. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter@stpeter.im Tue Sep 14 15:16:54 2010 Return-Path: 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 24D7F3A677C; Tue, 14 Sep 2010 15:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, 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 AJNqDeViqoMe; Tue, 14 Sep 2010 15:16:52 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8F0123A67B3; Tue, 14 Sep 2010 15:16:52 -0700 (PDT) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A7C23400EE; Tue, 14 Sep 2010 16:21:29 -0600 (MDT) Message-ID: <4C8FF46C.90108@stpeter.im> Date: Tue, 14 Sep 2010 16:17:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: Dave Cridland References: <8252.1284451129.280251@puncture> In-Reply-To: <8252.1284451129.280251@puncture> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , Stefan Santesson , IETF cert-based identity , IETF-Discussion Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 22:16:54 -0000 On 9/14/10 1:58 AM, Dave Cridland wrote: > On Tue Sep 14 01:03:39 2010, Stefan Santesson wrote: > >> - If you just check the dNSName, you will miss the fact that you talk >> to the >> desiganted ldap server and not the xmpp server (even if that >> information is >> in the cert). >> >> > Kind of. The rules effectively mean that dNSName is treated as a sRVName > with a wildcard service type, as I understand it. That's a good way to put it. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 15 13:20:00 2010 Return-Path: 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 E9E863A68C5 for ; Wed, 15 Sep 2010 13:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, 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 XvNd7yMH6WCp for ; Wed, 15 Sep 2010 13:19:58 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 76DB93A694C for ; Wed, 15 Sep 2010 13:19:58 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 09C7E400EE for ; Wed, 15 Sep 2010 14:24:39 -0600 (MDT) Message-ID: <4C912A86.3040402@stpeter.im> Date: Wed, 15 Sep 2010 14:20:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100824 Thunderbird/3.0.7 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 20:20:00 -0000 FYI. -------- Original Message -------- Subject: secdir review of draft-saintandre-tls-server-id-check-09 Date: Tue, 14 Sep 2010 17:39:40 -0400 From: Barry Leiba Reply-To: barryleiba@computer.org To: draft-saintandre-tls-server-id-check.all@tools.ietf.org CC: iesg@ietf.org, secdir@ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Please forgive the lateness of this review; I really meant to have it done sooner. First, I found the document to be a tough read, and I can't really pin down why. I started reviewing it several times, and restarted, before I finally got through it. I can't give any advice with this comment, so just take it as it is. Second, there's a mixture of "natural person" and "human user" in the document, and my sense is that you mean the same thing by both. If you do, you should switch to one term (I prefer the latter; "natural person" sounds odd). If they're meant to be different, you should make it clear what the difference is. Third, I'll note the earlier discussion of issues with IDN comparisons. I have nothing to add to that discussion, and it may be that the best thing is to leave things as they are. Comments are in order of appearance, not significance: -- Page 16, bullet 6: The certificate MAY contain more than one DNS-ID, but SHOULD NOT contain more than one CN-ID. Why "SHOULD NOT", and not "MUST NOT" ? I'm not challenging this; it's a question. -- Page 17, sec 4.2, first graf: Before connecting to the server, the client MUST construct a list of acceptable reference identifiers. Why MUST it be done "before"? Can anyone detect, or does it hurt interoperability, if it's done, say, in parallel with connection, or while the client is waiting for the server to return the certificate? -- Page 18, sec 4.2, last bullet: o The list SHOULD NOT include a CN-ID; however, the CN-ID (if included) MUST be constructed only from the source domain and never from a target domain. I find this oddly put. How about "The list SHOULD NOT include a CN-ID. If a CN-ID is used despite this advice, it MUST be..." ? I'd also like to take the security note from section 4.3 and echo it here. So maybe this?: << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite this advice, it MUST be constructed only from the source domain and never from a target domain. Further, it MUST NOT be used unless there are no other supported identifiers present in the certificate. >> -- Page 18, sec 4.3, first graf: by seeking a match and aborting the search if any presented identifier matches one of its reference identifiers. "Aborting" has the connotation of premature termination, before completion, and that's not the case here; you're saying that the match completes the process. How about, simply, "stopping", or "ending" ? -- Page 19, sec 4.4.3: I think implementers might think that you're simply allowing any leading wildcard character, so we should explicitly dissuade them. So, in the first graf: the wildcard character '*', but only as the left-most label of the domain name, make it "only as the complete value of the left-most label". And in the second graf: in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) change to: baz1.example.net and baz2.example.net; also, *bozz.example.net is not allowed and MUST NOT be taken to match frobozz.example.net) -- Page 19, sec 4.4.3, last graf: A specification that references the rules defined in this document can specify that the wildcard character is not allowed in certificates used by the relevant application protocol or community of interest. How about “...can strengthen this section by ruling out wildcard matching altogether for the relevant...†? -- Page 20, sec 4.4.4, second graf: entry types supported by the client), the client MAY as a fallback check for a string whose form matches that of a fully-qualified DNS domain name in the CN-ID. Back in section 4.2, you say that the client SHOULD NOT include CN-ID in the list, and here you're saying that it MAY make such a comparison. That seems oddly contradictory to me, though one can certainly argue that SHOULD NOT implies MAY. I'd prefer to see this worded differently. -- Page 21, sec 4.6.2: client MUST verify that the presented certificate matches the cached certificate and (if it is an interactive client) MUST notify the user if the certificate has changed since the last time a secure connection was successfully negotiated (where causes of change include but are not limited to changes in the DNS domain name, identifiers, issuer, certification path, and expiration date). I worry about this kind of advice. It violates my rule that says, "Don't ask the user a question that he's not qualified to answer." Of course, "notify the user" can mean a lot of things, but too many clients will implement something like this with a popup that will be meaningless to 99% of the people who use it. -- Page 21, sec 4.6.3, last graf: Instead, the client MUST proceed as follows. I like a colon there, instead of the full stop. -- Page 21, sec 4.6.3.1, security note: caution, for example by first encouraging the user to terminate the connection, forcing the user to view the entire certification path, and allowing the user to accept the certificate only on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session). Same comment as for 4.6.2. Most users will not understand certificate problems, and will have no idea what they should do about them. Always remember the "Barry's mother problem". My mother will *never* want to see an "entire certification path", let alone appreciate being "forced" to. -- Page 22, sec 5.1: 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. Does this mean that a client specifically designed for the "gumbo" service can't automatically use the service type "gumbo", without the user's involvement? Or that a client put out by example.net can't assume a host name of services.example.net in the absence of user input that says otherwise? Further, it's entirely reasonable for a program to have a user enter something like "gmail", and have the client turn that into something like "mail.google.com", deriving it from the user's input in an automated fashion. Do we really want to forbid that sort of thing? -- Barry Leiba From hotz@jpl.nasa.gov Wed Sep 15 16:57:43 2010 Return-Path: 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 27B4D3A6AE4 for ; Wed, 15 Sep 2010 16:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 eWYk6xb4Adwk for ; Wed, 15 Sep 2010 16:57:42 -0700 (PDT) Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id 13FB03A6AE2 for ; Wed, 15 Sep 2010 16:57:42 -0700 (PDT) Received: from dhcp-137-79-176-142.jpl.nasa.gov (dhcp-137-79-176-142.jpl.nasa.gov [137.79.176.142]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8FNw3XN014105 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 15 Sep 2010 16:58:05 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4C912A86.3040402@stpeter.im> Date: Wed, 15 Sep 2010 16:58:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <58606B11-D4CC-43F4-8971-90D51780A21B@jpl.nasa.gov> References: <4C912A86.3040402@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1081) X-Source-IP: dhcp-137-79-176-142.jpl.nasa.gov [137.79.176.142] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: barryleiba@computer.org, IETF cert-based identity Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 23:57:43 -0000 On Sep 15, 2010, at 1:20 PM, Peter Saint-Andre wrote: > -- Page 22, sec 5.1: > 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. >=20 > Does this mean that a client specifically designed for the "gumbo" > service can't automatically use the service type "gumbo", without the > user's involvement? Or that a client put out by example.net can't > assume a host name of services.example.net in the absence of user > input that says otherwise? >=20 > Further, it's entirely reasonable for a program to have a user enter > something like "gmail", and have the client turn that into something > like "mail.google.com", deriving it from the user's input in an > automated fashion. Do we really want to forbid that sort of thing? That strikes me as an awfully blase comment for a security review. = Whatever process translates the user input into the name that's used to = verify the server's id is a critical part of the verification. If you = can subvert the translation, then you can subvert the server ID check, = which is the whole point of this draft. I'm not opposed to the idea of name canonicalization, but it has to be = done in an authoritative, secure fashion, and that's probably out of = scope for this draft. For discussion's sake, how about changing the MUST NOT to SHOULD NOT and = adding a big "here there be dragons" to the text? I might prefer = leaving it as-is, since we can always write a new RFC that defines how = the automated translation can be done in a safe way. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From mrex@sap.com Wed Sep 15 18:08:08 2010 Return-Path: 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 95E3B3A6AD2 for ; Wed, 15 Sep 2010 18:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.64 X-Spam-Level: X-Spam-Status: No, score=-8.64 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 75YbQ4V8kaVC for ; Wed, 15 Sep 2010 18:08:06 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 7A5E33A6AAB for ; Wed, 15 Sep 2010 18:08:05 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8G18UUa011593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 03:08:30 +0200 (MEST) From: Martin Rex Message-Id: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 16 Sep 2010 03:08:28 +0200 (MEST) In-Reply-To: <4C912A86.3040402@stpeter.im> from "Peter Saint-Andre" at Sep 15, 10 02:20:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 01:08:08 -0000 some personal comments on (parts of) Barry's review. Peter Saint-Andre wrote: > > Comments are in order of appearance, not significance: > > -- Page 16, bullet 6: > The certificate MAY contain more than one DNS-ID, but SHOULD NOT > contain more than one CN-ID. > > Why "SHOULD NOT", and not "MUST NOT" ? I'm not challenging this; it's > a question. This was supposed to be a BCP. The current implementation practice is that many existing clients honor/match only the "most specific" CN (as per rfc-2818), but do _not_ abort when multiple CNs are present, and a small number of clients match all CNs. A "MUST NOT" would be a change to what is out there any make the entire installed base non-compliant that does not abort on the presence of multiple CN AVAs in a server cert. But there is another issue. This document is directed to a non-obviously large and diverse target audience, and takes short cuts. - Server admins MUST NOT create or request server certs with multiple CN-IDs. - CAs MUST NOT sign/issue server certificates with multiple CN-IDs. - Servers should not use certificates with multiple CN-IDs. - Clients SHOULD NOT match CN-IDs if SRV-IDs or DNS-IDs are present in a server cert. If client match CN-IDs anyhow, as a fallback for server certs without SRV-IDs and DNS-IDs, then they should match only the "most specific" CN as per rfc-2818. - architecture-wise I personally think of the CN-ID match as a fallback for DNS-ID matching rather than an entirely seperate reference identifier. > > -- Page 17, sec 4.2, first graf: > Before connecting to the server, the client MUST construct a list of > acceptable reference identifiers. > > Why MUST it be done "before"? Can anyone detect, or does it hurt > interoperability, if it's done, say, in parallel with connection, or > while the client is waiting for the server to return the certificate? This imperative MUST is underexplained. It's likely possible to convey the underlying idea without an rfc2119 imperative. rfc-2119 MUST and MUST NOT always translate to code in the implementation and to test cases for compliance in validation test suites. "needs to / will have to", while conveying a very similar message at the natural language level, doesn't have such impact on the code. The client consists of several different layers/components, The application client (above TLS) and the TLS client implementation. What is probably meant is that the application client needs to produce a list of acceptable reference identifiers before asking the TLS client implementation to start a TLS handshake. The TLS client implementation will need the DNS-ID for composing a TLS ClientHello with a TLS extension "Server Name Indication" (SNI). As a rule of thumb (netiquette/politeness), you should make up your mind whether you want to enter before you rap on a door (dial a phone number or connect some network service) in order not to annoy those who answer. :) > > -- Page 18, sec 4.2, last bullet: > o The list SHOULD NOT include a CN-ID; however, the CN-ID (if > included) MUST be constructed only from the source domain and > never from a target domain. > > I find this oddly put. How about "The list SHOULD NOT include a > CN-ID. If a CN-ID is used despite this advice, it MUST be..." ? I think its fine to use the term CN-ID when describing actual components of a certificate, but for the actual matching of the server endpoint identity, I would always implement CN-ID matching as a fallback of DNS-ID matching, not as matching of a conceptually distinct reference identifier. > > -- Page 18, sec 4.3, first graf: > by seeking a match and aborting the search if any presented > identifier matches one of its reference identifiers. > > "Aborting" has the connotation of premature termination, before > completion, and that's not the case here; you're saying that the match > completes the process. How about, simply, "stopping", or "ending" ? maybe "succeeding the search" or "successfully stop the search"? > > -- Page 19, sec 4.4.3: > I think implementers might think that you're simply allowing any > leading wildcard character, so we should explicitly dissuade them. > > So, in the first graf: > the wildcard character '*', but only as the left-most label of the > domain name, > make it "only as the complete value of the left-most label". Now that you mention it: 4.4.3. Checking of Wildcard Labels (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) This is in clear contradiction to the wildcard matching specified in rfc-2818 Section 3.1. And without any rationale for this U-Turn, that seems to be entirely inappropriate for a BCP. In my implementation of RFC-2818 wildcard matching, I deliberately ignore DNS names that contain more than one wildcard character, have a wildcard character in different but the leftmost label or have a wildcard character and less than 3 DNS labels. But I certainly do the substring match specified in rfc-2818 and I'm not going to remove the substring match from my implementation without a convincing rationale... What exactly is the benefit of allowing a full wildcard match but prohibiting a partial/substring wildcard match of the leftmost label? > > -- Page 19, sec 4.4.3, last graf: > A specification that references the rules defined in this document > can specify that the wildcard character is not allowed in > certificates used by the relevant application protocol or community > of interest. To me this sounds awkward. It implies that either the CA has a flawed CPS can not appropriately deal with wildcard reference identifiers in certs, or is in general not trustworthy or that the wildcard-scheme too dangerous (=too difficult to handle safely) for server admins. > > How about “...can strengthen this section by ruling out wildcard > matching altogether for the relevant...†? > > -- Page 20, sec 4.4.4, second graf: > entry types supported by the client), the client MAY as a fallback > check for a string whose form matches that of a fully-qualified DNS > domain name in the CN-ID. > > Back in section 4.2, you say that the client SHOULD NOT include CN-ID > in the list, and here you're saying that it MAY make such a > comparison. That seems oddly contradictory to me, though one can > certainly argue that SHOULD NOT implies MAY. I'd prefer to see this > worded differently. Yup, there is a disconnect. Although at the colloquial level, "should not" is often treated as a "may", there is a sigificant difference for these imperatives in technical specs. SHOULD NOT http://tools.ietf.org/html/rfc2119#section-4 MAY http://tools.ietf.org/html/rfc2119#section-5 MAY indicates something truely optional, completely at the discretion of the target audience of this imperative, not requiring considerations one way or the other, whereas "SHOULD NOT" is a clear recommendation, that requires a rationale in the spec so that the target audience of this imperative can "understand and carefully weigh the full implications" before deciding to not follow the recommendation. > > -- Page 21, sec 4.6.2: > client MUST verify that the presented certificate matches the cached > certificate and (if it is an interactive client) MUST notify the user > if the certificate has changed since the last time a secure > connection was successfully negotiated (where causes of change > include but are not limited to changes in the DNS domain name, > identifiers, issuer, certification path, and expiration date). > > I worry about this kind of advice. It violates my rule that says, > "Don't ask the user a question that he's not qualified to answer." SSH's traditional behaviour in a comparable situation would be to print a warning an fail (no offering of an _easy_ leap-of-faith override for something that shouldn't happen). What confuses me is that 4.6.1 + 4.6.2 + 4.6.3 would allow a server, which originally offered an inadequate server certificate which the user manually confirmed, to unconditionally and silently bypass the users manual confirmation with appropriately looking server cert from any arbitrary trust anchor. This doesn't seem right. The option of memorizing a server certificate for future reconnects would significantly improve the security. Once a client caches a server cert that is manually confirmed by the user, this could protect a user on future reconnects to the same server from an attacker that succeeds subverting a trusted CA. Even from full compromise of all CAs by that attacker. I wondering why PKIX designed trust in X.509 PKIs so much different to trust relationship of human beings. Human Trust starts with initial (leap-of-)faith and grows stronger over time. Memorizing server certs and first contact would match this much better than the traditional Web Browser model, where the millionth TLS handshake to the same peer is just as vulnerable to the full scope of attacks as the very first TLS handshake. SSH got this one right from the beginning, whereas in SSL/TLS the absence of secure re-authentication looks like a genetic defect that has prevailed through all protocol and browser generations (inherited from X.509 PKI). -Martin From matt@mattmccutchen.net Wed Sep 15 20:04:21 2010 Return-Path: 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 1DA263A6AD9 for ; Wed, 15 Sep 2010 20:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 CxwhxNq+sKxS for ; Wed, 15 Sep 2010 20:04:20 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 045D73A6AF7 for ; Wed, 15 Sep 2010 20:04:19 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 301D98C06C; Wed, 15 Sep 2010 20:04:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=dqsUYfvWF7I0mynN7vRcJkDELAYIMqU4h/dFHNyNu91 cRn9BayREOKjklDyYNg0sMeweCVdeKkliwxXhoEp19Lg9PCrRNwAp1uwY//+6SxO sO6auYFU1qWNMcjEK7aKckh1fCONNkN/IYeWPdjbzE8rNmXA7R0zoCNpmHloQJt8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=OpX+AUIiBWkbxuYi/C9perdMgtU=; b=vJYZoXU7xp 09zbHDxErvQELuczoI79g/U42WtEF45XIZtXcqsklOE9WyO/EceBHEBNEEw9qw2C CHRSIftoKIdYq+ovfKOGZEOYiUXl3c6d5oxvgpWxtop/vXgqShKb5NRko9G0tXCt 0C/Fuf1pgLDS01a14f3xtG6/mafW7G8UQ= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPA id B13748C06A; Wed, 15 Sep 2010 20:04:44 -0700 (PDT) From: Matt McCutchen To: Martin Rex In-Reply-To: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp> References: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Wed, 15 Sep 2010 23:04:43 -0400 Message-ID: <1284606283.5722.21.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 03:04:21 -0000 On Thu, 2010-09-16 at 03:08 +0200, Martin Rex wrote: > What confuses me is that 4.6.1 + 4.6.2 + 4.6.3 would allow a server, > which originally offered an inadequate server certificate which the > user manually confirmed, to unconditionally and silently bypass > the users manual confirmation with appropriately looking server cert > from any arbitrary trust anchor. This doesn't seem right. I disagree. The user's confirmation was to accept the certificate, not to use it exclusively. I have taken advantage of this behavior on https://mattmccutchen.net . > The option of memorizing a server certificate for future reconnects > would significantly improve the security. Once a client caches > a server cert that is manually confirmed by the user, this could > protect a user on future reconnects to the same server from > an attacker that succeeds subverting a trusted CA. Even from > full compromise of all CAs by that attacker. The certificate exception mechanism serves the limited purpose of making it possible for users to connect to servers with unverifiable certificates, without which they would be unable to get work done in some cases. It looks like you're trying to replace the public-CA trust model, which is a much more ambitious goal, and it's not clear that your suggested change to the exception mechanism is anything near an appropriate or comprehensive solution. Let's have that discussion elsewhere and let the server-id-check draft proceed with its original scope. -- Matt From matt@mattmccutchen.net Wed Sep 15 20:47:37 2010 Return-Path: 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 55AFD3A68F1 for ; Wed, 15 Sep 2010 20:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 204Z22OvuRPM for ; Wed, 15 Sep 2010 20:47:32 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 860603A67FA for ; Wed, 15 Sep 2010 20:47:32 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id ABD128C06A; Wed, 15 Sep 2010 20:47:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=lmFnHfnjndVin7vSZEZC6tFV6ROnpA3oXI9Gw6z3wBu TB1W3Vnv4lheREADlrBdEaW1NPh6khk0aEWxpewNoFSZcbnQDYq9/G5y+ab2NoWC QekF6YADlWtrSrel/LRrYjgoiZVdEZghDcFtNPy0Ybycxp1DxErFASi8Mlic1Rq0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=pI9YIJcEuKnBztoeJ8hg3+BonR0=; b=bGuIOypRuv WXvd2cj8UDQKrocYLW7Chff0yxGpheptF8omPPhmN2AezM9AaLqxeDQIHwto4rMW bLjmGLFF1howg6zwixM0U+yfZIYpJM8Keaj4qFyC6MFpLh8N2fmW0Sa0HVK/U+Ua LdDMsYkrhdyIfjm32cqXP0tUcBBGfR4oQ= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPA id 3635B8C063; Wed, 15 Sep 2010 20:47:57 -0700 (PDT) From: Matt McCutchen To: "Henry B. Hotz" In-Reply-To: <58606B11-D4CC-43F4-8971-90D51780A21B@jpl.nasa.gov> References: <4C912A86.3040402@stpeter.im> <58606B11-D4CC-43F4-8971-90D51780A21B@jpl.nasa.gov> Content-Type: text/plain; charset="UTF-8" Date: Wed, 15 Sep 2010 23:47:56 -0400 Message-ID: <1284608876.5722.56.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF, barryleiba@computer.org, cert-based identity Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 03:47:37 -0000 On Wed, 2010-09-15 at 16:58 -0700, Henry B. Hotz wrote: > On Sep 15, 2010, at 1:20 PM, Peter Saint-Andre wrote: > > > -- Page 22, sec 5.1: > > 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. > > > > Does this mean that a client specifically designed for the "gumbo" > > service can't automatically use the service type "gumbo", without the > > user's involvement? Or that a client put out by example.net can't > > assume a host name of services.example.net in the absence of user > > input that says otherwise? > > > > Further, it's entirely reasonable for a program to have a user enter > > something like "gmail", and have the client turn that into something > > like "mail.google.com", deriving it from the user's input in an > > automated fashion. Do we really want to forbid that sort of thing? > > > That strikes me as an awfully blase comment for a security review. > Whatever process translates the user input into the name that's used > to verify the server's id is a critical part of the verification. If > you can subvert the translation, then you can subvert the server ID > check, which is the whole point of this draft. > > I'm not opposed to the idea of name canonicalization, but it has to be > done in an authoritative, secure fashion Exactly. > and that's probably out of scope for this draft. Is it? We may be able to make a useful general statement. There are two issues here: 1. "Authoritative": different applications and even users may have different ideas of what name canonicalization processes are "authoritative", so all we can ask of compliant implementations is to document which processes they use. "Profiles" of server-id-check may fill in more details. 2. "Secure": given that the point of TLS is to protect against network attackers, it makes no sense to use a name canonicalization process that is vulnerable to them. We can say, "Any process by which the source domain is derived from user input MUST NOT be subject to subversion by network attackers", or some such. Tangent: I know we want to avoid implementations that do foolish things being claimed as compliant, but IMO, the requirement that input come from a "human user" is goofy for a technical specification and in practice a non-starter. A web browser that followed a HTTP redirection to a https: URL would violate it. The web has evolved toward complex applications in which all pretense that the user is mediating the issuance of HTTP requests has been abandoned, which brings major productivity benefits as well as major security implications; ignoring this would be a mistake. -- Matt From mrex@sap.com Wed Sep 15 22:27:31 2010 Return-Path: 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 9D3A13A6879 for ; Wed, 15 Sep 2010 22:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.535 X-Spam-Level: X-Spam-Status: No, score=-9.535 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] 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 2hgTJeulCQdE for ; Wed, 15 Sep 2010 22:27:30 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C8A103A67E1 for ; Wed, 15 Sep 2010 22:27:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8G5RrWH011417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 07:27:53 +0200 (MEST) From: Martin Rex Message-Id: <201009160527.o8G5RoxM013370@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 16 Sep 2010 07:27:50 +0200 (MEST) In-Reply-To: <4C912A86.3040402@stpeter.im> from "Peter Saint-Andre" at Sep 15, 10 02:20:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 05:27:31 -0000 Peter Saint-Andre wrote: > > -- Page 22, sec 5.1: > 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. > > Does this mean that a client specifically designed for the "gumbo" > service can't automatically use the service type "gumbo", without the > user's involvement? The current wording does not seem to adequately illustrate the characteristics that are important here. "MUST NOT be derived from the user inputs in an automated fashion" could be very misleading. The real problem is with using using information from untrusted sources or performing transformations of (originally user-supplied or user-confirmed) untrusted information prior to matching the server endpoint. There are situations where the implicit assertion of the protocol "gumbo" is fully aligned with the intention of the user and is safe to use for matching SRV-IDs. s/gumbo/xmpp/g wash,rinse,repeat. Clearly unsafe operations: - building a reference identifier from the result of a DNS CNAME lookup (the use of DNSSEC does not make this safe) - retrieving the URL to a HTTPS resource from a HTML page that was loaded through HTTP based on information provided by the user. > > Or that a client put out by example.net can't > assume a host name of services.example.net in the absence of user > input that says otherwise? It depends. It is OK when it is sufficiently aligned with the users intention (although some users may not be fully aware of all technical details). > > Further, it's entirely reasonable for a program to have a user enter > something like "gmail", and have the client turn that into something > like "mail.google.com", deriving it from the user's input in an > automated fashion. Do we really want to forbid that sort of thing? That should be fine as long at it is sufficiently aligned with the users intention and this translation is based purely on trusted sources of information and protected access to these information sources. This precludes both, DNS and DNSSEC lookups. Sufficiently protected local configuration options or protected local mappings should be fine. (meaning protected from changes without explicit consent and awareness of the user). -Martin From matt@mattmccutchen.net Wed Sep 15 22:39:31 2010 Return-Path: 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 EA14B3A68A6 for ; Wed, 15 Sep 2010 22:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 n+bydDwEBaI1 for ; Wed, 15 Sep 2010 22:39:12 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id A53163A6AF9 for ; Wed, 15 Sep 2010 22:38:51 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 27865578073; Wed, 15 Sep 2010 22:39:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=AoJzwYFjJgJL1vazctjg7z+sS1SHFcDGXG+Lb497+dm CDRnNjQYSG8tN38g0uu3wuhqGwD84h5gEhpc3ubnI3q4bbiQPYg45JzMYsNZ1D5U iUu6b0ocHTONqjooKIC1skkb+iqKzLRYyxQLo99jdr9kFvm8qPN/+xrIpzF39Up4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=ebZBGmENcIIvCWOMbdrn+bE/agc=; b=LTXUBizyOh 3iLNFHlLpA2XlQjc8ILSIKChT0cXhBsEXp6qtjxGvw86kOWMq5f3L0NzWVeFXfmr 08/bJQRXbV88l/pGSikzYYMY+QXUYWosVA/22S3h8BtSKP++kM2Ns4RVV+WAxHCX bKpg8++KsvAQICZvLtFjoJddq0T2ss4xs= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id BD7A8578069; Wed, 15 Sep 2010 22:39:16 -0700 (PDT) From: Matt McCutchen To: Martin Rex In-Reply-To: <201009160527.o8G5RoxM013370@fs4113.wdf.sap.corp> References: <201009160527.o8G5RoxM013370@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Thu, 16 Sep 2010 01:39:15 -0400 Message-ID: <1284615555.5722.92.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 05:39:52 -0000 On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > Clearly unsafe operations: > > - building a reference identifier from the result of a > DNS CNAME lookup > (the use of DNSSEC does not make this safe) Why not? I'm not saying it's good practice, but I don't see an actual vulnerability. I agree with everything else you said; nicely put. -- Matt From hallam@gmail.com Thu Sep 16 07:11:31 2010 Return-Path: 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 2E6353A6A3D for ; Thu, 16 Sep 2010 07:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.09 X-Spam-Level: X-Spam-Status: No, score=-1.09 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 N3KO8h1s5Bhc for ; Thu, 16 Sep 2010 07:11:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id AB7F23A6B4E for ; Thu, 16 Sep 2010 07:11:11 -0700 (PDT) Received: by wwe15 with SMTP id 15so264836wwe.13 for ; Thu, 16 Sep 2010 07:11:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BClFqxyCgXhc7tE/o8DTYb170mdozaFPSZoRWUywdec=; b=Jo0IWdMc/RwHAroWQnKjVPy8M/bx+8GWTzfpVLcMq0Or6KhT1IvPHqPv6AlUvjYx/4 /TSd0LWcqeq5DJj9BaGoVbDWwn2dEn3JR/4FQvfKm59ZsQaRmMUTC91Ts1q3/HRjVBUT XPyYd/F5K2OdNbfsaC2oQ3Xus2aX38FnKDY1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LR1xl9qo2QvN8E7rtn2ll3WAsmqu6osRYEE9x5Qv4t4d2BBQ0eCyuv5BRB9ghHgmik WlJmHdXEpl3zzmqb6P9WPFpObv57PmoWz1yM38wvgRW8vbh0U4CNNOiGbpY+7RMppXN+ ul2fzgTz0fTrE2n0iySwS4VzeOTuTLWh0Kddc= MIME-Version: 1.0 Received: by 10.227.138.141 with SMTP id a13mr2728631wbu.208.1284646296583; Thu, 16 Sep 2010 07:11:36 -0700 (PDT) Received: by 10.216.163.195 with HTTP; Thu, 16 Sep 2010 07:11:36 -0700 (PDT) In-Reply-To: <1284615555.5722.92.camel@mattlaptop2.local> References: <201009160527.o8G5RoxM013370@fs4113.wdf.sap.corp> <1284615555.5722.92.camel@mattlaptop2.local> Date: Thu, 16 Sep 2010 10:11:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Matt McCutchen Content-Type: multipart/alternative; boundary=00163646bb322b82060490610620 Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 14:11:31 -0000 --00163646bb322b82060490610620 Content-Type: text/plain; charset=ISO-8859-1 The question in my view is what you intend to do with the certificate information. Let us consider some outsourcing cases: A) Alice writes a blog, she has her own DNS name and the Web site is hosted as a virtual Web server on a machine with 1000 other blogs B) Bob writes a blog, but he rents use of a whole machine, not just a virtual partition. C) Carol writes a blog and also sells T-shirts with witty slogans on that people buy through a hosted checkout. D) Doug runs a business with a large e-commerce shop and manages the credit card data directly. Question, which ones of these should be using SSL? Answer, all of them. Question, which identity should the application client be presenting to the user. Answer: Doug is the only party that has a corporate identity. Alice, Bob and Carol probably don't want to reveal their personal identity so the only identity we have that we can present is a domain name. The reason I raise this is that I see several possible conclusions that can result from cert processing query: 1) Organizational Validation or Extended Validation that establishes accountability. 2) Certificate is bound to the domain name on which the resolution process was begun 3) Certificate is bound to a domain name to which the resolution points 4) There is no particular connection between the cert and the domain name. Which outcome is sufficient depends on whether your objective is to turn on use of crypto or tell the user that they are safe. Another point to bear in mind is that applications are not necessarily applying the traditional SSL model in which the application looks at the information provided by the Web site and determines if that meets a particular safety threshold and the user is responsible for working out if they are safe or not. For the past five years or so, the model that has been emerging is one in which the application takes data from multiple sources and fuses them to establish a safety evaluation. For example, if a domain name is on the Anti-Phishing Working Group suspicious URL list, the browser might well want to block access regardless of whether the Web Site has a certificate or not. So rather than having a spec state what is 'safe' and what is not. We really need to look at how many potential points of vulnerability have accumulated. Running Web servers and running DNS servers 24/7 is complex and time consuming. There are clear economies of scale. So people are inevitably going to outsource. The number of potential points of vulnerability are a consequence of the outsourcing and not the use of CNAME. The use of CNAME is merely a consequence of the easiest way to implement outsourcing. More points of vulnerability does not correspond to higher risk. What matters is the vulnerability of the weakest link in a chain (or the weakest critical path in a redundant mesh). On Thu, Sep 16, 2010 at 1:39 AM, Matt McCutchen wrote: > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > Clearly unsafe operations: > > > > - building a reference identifier from the result of a > > DNS CNAME lookup > > > (the use of DNSSEC does not make this safe) > > Why not? I'm not saying it's good practice, but I don't see an actual > vulnerability. > > I agree with everything else you said; nicely put. > > -- > Matt > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid > -- Website: http://hallambaker.com/ --00163646bb322b82060490610620 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The question in my view is what you intend to do with the certificate infor= mation.

Let us consider some outsourcing cases:

A) =A0Alice writes a blog, she has her own DNS name and th= e Web site is hosted as a virtual Web server on a machine with 1000 other b= logs

B) Bob writes a blog, but he rents use of a whole machi= ne, not just a virtual partition.

C) Carol writes = a blog and also sells T-shirts with witty slogans on that people buy throug= h a hosted checkout.

D) Doug runs a business with a large e-commerce shop an= d manages the credit card data directly.


Question, which ones of these should be using SSL?
Answer, = all of them.

Question, which identity should the application client = be presenting to the user.
Answer: Doug is the only party that ha= s a corporate identity.
Alice, Bob and Carol probably don't w= ant to reveal their personal identity so the only identity we have that we = can present is a domain name.


The reason I raise this is that I see se= veral possible conclusions that can result from cert processing query:

1) Organizational Validation or Extended Validation th= at establishes accountability.

2) Certificate is bound to the domain name on which the= resolution process was begun

3) Certificate is bo= und to a domain name to which the resolution points

4) There is no particular connection between the cert and the domain n= ame.


Which outcome is sufficient de= pends on whether your objective is to turn on use of crypto or tell the use= r that they are safe.

Another point to bear in mind is that applications are = not necessarily applying the traditional SSL model in which the application= looks at the information provided by the Web site and determines if that m= eets a particular safety threshold and the user is responsible for working = out if they are safe or not.

For the past five years or so, the model that has been = emerging is one in which the application takes data from multiple sources a= nd fuses them to establish a safety evaluation. For example, if a domain na= me is on the Anti-Phishing Working Group suspicious URL list, the browser m= ight well want to block access regardless of whether the Web Site has a cer= tificate or not.


So rather than having a spec state what = is 'safe' and what is not. We really need to look at how many poten= tial points of vulnerability have accumulated.

Running Web servers and running DNS servers 24/7 is complex and time consum= ing. There are clear economies of scale. So people are inevitably going to = outsource.

The number of potential points of vulne= rability are a consequence of the outsourcing and not the use of CNAME. The= use of CNAME is merely a consequence of the easiest way to implement outso= urcing.=A0

More points of vulnerability does not correspond to hig= her risk. What matters is the vulnerability of the weakest link in a chain = (or the weakest critical path in a redundant mesh).=A0



On Thu, Sep 16, 2010 at = 1:39 AM, Matt McCutchen <matt@mattmccutchen.net> wrote:
On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote:
> Clearly unsafe operations:
>
> =A0 - building a reference identifier from the result of a
> =A0 =A0 DNS CNAME lookup

> (the use of DNSSEC does not make this safe)

Why not? =A0I'm not saying it's good practice, but I don't see = an actual
vulnerability.

I agree with everything else you said; nicely put.

--
Matt

_______________________________________________
certid mailing list
certid@ietf.org
= https://www.ietf.org/mailman/listinfo/certid



--
Website: http://hallambaker.com/

--00163646bb322b82060490610620-- From mrex@sap.com Thu Sep 16 08:33:41 2010 Return-Path: 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 CADD73A6B64 for ; Thu, 16 Sep 2010 08:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.836 X-Spam-Level: X-Spam-Status: No, score=-9.836 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 BEK0CSGAYnqn for ; Thu, 16 Sep 2010 08:33:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 8F72E3A6B83 for ; Thu, 16 Sep 2010 08:33:25 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8GFXmPg027004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 17:33:48 +0200 (MEST) From: Martin Rex Message-Id: <201009161533.o8GFXlAG016810@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Thu, 16 Sep 2010 17:33:47 +0200 (MEST) In-Reply-To: <1284615555.5722.92.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 16, 10 01:39:15 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 15:33:42 -0000 Matt McCutchen wrote: > > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > Clearly unsafe operations: > > > > - building a reference identifier from the result of a > > DNS CNAME lookup > > > > (the use of DNSSEC does not make this safe) > > Why not? I'm not saying it's good practice, but I don't see an actual > vulnerability. You need two characteristics: (1) trustworty information source for a name transformation (2) protected access to this trustworthy source DNSSEC meets (2) but not (1) DNSSEC provides only data integrity protection and data origin authentication for the distribution of the informtion, it has zero impact on the quality, accuracy and trustworthyness of the underlying information source. If Wikipedia enables TLS on their web-servers tomorrow so that you can access it through https://www.wikipedia.org/ what impact will this have on the trustworthyness of the information in Wikipedia articles? When there is not change to how others can can access wikipedia and edit the information there, the impact of you using TLS to access wikipedia will have exactly zero _impact_ on the trustworthyness of the information in wikipedia. -Martin From hotz@jpl.nasa.gov Thu Sep 16 09:55:15 2010 Return-Path: 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 4DF393A68F6 for ; Thu, 16 Sep 2010 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.39 X-Spam-Level: X-Spam-Status: No, score=-6.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4KFd5tEBcigI for ; Thu, 16 Sep 2010 09:55:12 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.105]) by core3.amsl.com (Postfix) with ESMTP id ECC9E3A6832 for ; Thu, 16 Sep 2010 09:55:10 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8GGtYiv030158 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 16 Sep 2010 09:55:35 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp> Date: Thu, 16 Sep 2010 09:55:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5F42C835-3211-48A7-9375-CE45A9C53739@jpl.nasa.gov> References: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp> To: "mrex@sap.com" X-Mailer: Apple Mail (2.1081) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "certid@ietf.org" Subject: Re: [certid] Fwd: secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 16:55:15 -0000 On Sep 15, 2010, at 6:08 PM, Martin Rex wrote: >> -- Page 19, sec 4.4.3, last graf: >> A specification that references the rules defined in this document >> can specify that the wildcard character is not allowed in >> certificates used by the relevant application protocol or community >> of interest. >=20 > To me this sounds awkward. It implies that either the CA has a flawed = CPS > can not appropriately deal with wildcard reference identifiers in = certs, > or is in general not trustworthy or that the wildcard-scheme too = dangerous > (=3Dtoo difficult to handle safely) for server admins. I believe wildcards are a misfeature, because a wildcard cert doesn't = identify the server well enough that it should be trusted. I believe = that "Best Practice" is to never use the feature, and for clients to = raise flags if presented with it. Of course "Current" practice is to make maximal use of the feature = because: 1) nobody understands how to make the names match in real deployments. 2) the CA's pricing model makes it cheaper to buy a wildcard cert than = the full collection of multiple-alias certs you really need. Getting back to the point: I think it's perfectly appropriate for a = Practice document to restrict when and how much you use a Standard = feature. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From mrex@sap.com Thu Sep 16 11:38:38 2010 Return-Path: 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 12E6E3A6B95 for ; Thu, 16 Sep 2010 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.843 X-Spam-Level: X-Spam-Status: No, score=-9.843 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 28BF+-vhiYpT for ; Thu, 16 Sep 2010 11:38:35 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id D4DCA3A6B42 for ; Thu, 16 Sep 2010 11:38:30 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8GIcriq005732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 16 Sep 2010 20:38:53 +0200 (MEST) From: Martin Rex Message-Id: <201009161838.o8GIcqBt027471@fs4113.wdf.sap.corp> To: hotz@jpl.nasa.gov (Henry B. Hotz) Date: Thu, 16 Sep 2010 20:38:52 +0200 (MEST) In-Reply-To: <5F42C835-3211-48A7-9375-CE45A9C53739@jpl.nasa.gov> from "Henry B. Hotz" at Sep 16, 10 09:55:34 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 18:38:38 -0000 Personally, I do _not_ see a problem with wildcard certs. And neither with partial/substring wildcard matching defined in rfc-2818. They're perfectly sensible, but should only be employed with caution after understanding and carefully weighing the full implications of the intended usage scenario. I do see a huge problem with the constant bending of the details of server name matching. The proverb says: if you bend it too often it'll break. What we currently have is a mess, and applying any further changes, such as dropping partial wildcard matches while retaining full wildcard matches and app-specific ignore-wildcard is going to make the mess bigger and is IMHO a bad idea. Partial wildcard match will allow you to use one single server cert for a server farm behind a load-balancing NAT with hostnames such as "www1.example.com", "www2.example.com", ... "wwwNN.,example.com" by using the pattern "www*.example.com" that will neither match "kdc.example.com", "ldap.example.com", nor "imap.example.com" To me, that seems significantly more useful than only a full wildcard match. The current draft could be read to mean (without a single word of rationale) that partial wildcard matching is so much more dangerous than full wildcard matching that MUST NOT be used by anyone anymore. If this is not removed from the draft, this will result in a completely inconsistent behaviour within the installed based causing headaches with no ends to end-users, admins and helpdesks--for those servers that actively use this sensible alternative to full wildcard certs as specified in rfc-2818. One should be looking at the bigger picture, what does changing the spec mean for the (consistency) accross the installed base? Start with the history of how server-name matching developed: 1. matching hostnames to CN-ID 2. allowing (full) wildcards in CN-ID 3. matching hostnames to DNS-ID in addition to CN-ID 4. (rfc-2818) recommending DNS-ID, specifying IP-ID, deprecating CN-ID, recommending only "most specific" CN-ID matching, asking to ignore CN-ID when DNS-ID or IP-ID is present specifying partial wildcard match, 5. TLS server name indication (SNI) explicit non-support of IP-ID within SNI, but leaving IP-ID matching based on rfc-2818 perfectly valid. unreasonably specifying hostname in SNI with UTF8-encoding, instead of IA5-String punicode 6. (draft-saintandre-tls-server-id-check) prohibiting partial wildcard match?? suggesting app-specific wildcard-matching enabling. Now look at how the work of actually matching has been shared between the calling application above TLS and the TLS client implementation. Many TLS implementations offer a convenience/utility function to application callers of the TLS client to perform the server endpoint identification for them, sometimes as a default "added value". There is an API call in the TLS client implementation where the application caller can pass the target hostname of the server as an argument, and the TLS client implementation does all the rest. Depending on the API architecture (service-API or callback) this may be a call prior to the handshake or the call the starts the handshake (like the target_name parameter of InitializeSecurityContext for the Microsoft SChannel SSP). But there are also client apps that have been doing the server endpoint identification all by themselves, exactly as it is has always been and still is suggested by the TLS spec, last sentence of section 1 of every TLS spec (2246,4346,5246): the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. Where the TLS client implementation offered to perform the matching, and the calling client application on top of TLS used that service, passing down the target hostname, the migration from CN-ID matching to the scheme described by rfc-2818 is easy, straigtforward and transparent to the application. When the client TLS implementation wants the target hostname prior the TLS handshake or at the beginning of the handshake (not as a callback when the servers certificate is received), the TLS client application can conveniently provide implementing client-side TLS session caching (Note however, that for adequate client-side cache management the client application should really include the Port/service behind the hostname from the URL instead of blindly assuming that server-side TLS session caches are unconditionally shared across all service endpoints of a host.) >From what I can see, the most recent fine-tuning proposals are likely difficult to add into existing deployments where the client application conveniently relies on the convenience function supplied by the TLS client implementation in matching the server endpoint identity, client apps may face a lot of work (which significantly reduces the chances that its adopted by the installed base). Keep in mind that often, TLS implementations and calling client applications are independently maintained, If your app is built on top of Microsoft Schannel and relies on what that does about server endpoint identification based on the target_name passed to InitializeSecurityContext() to the Schannel SSP, then your app may have little choices. The exact matching is whatever Microsoft has shipped. Special requirements, such as - "for this server, I want no rfc-2818 partial wildcard matching" - "for the other server over there, I need rfc-2818 partial wildard matching for in order not to break a productive usage scenario" - "and for that server I want no wildcard matching at all, because the app-spec says so (keep in mind that the TLS client implementation does neither know nor care what app protocol is used inside). - "and for the server over there I want no CN-ID fallback when there no DNS-IDs in the server cert" - "and here's yet another server where I would prefer SRV-ID matching, to DNS-ID matching (but I have no clue how to request this...)" IMHO, any backwards-incompatible changes to server endpoint identification with regards to rfc-2818 ought to come with a very convincing rationale, or they are likely to make things worse ... much worse from what we currently have. -Martin Henry B. Hotz wrote: > > On Sep 15, 2010, at 6:08 PM, Martin Rex wrote: > > > >> -- Page 19, sec 4.4.3, last graf: > >> A specification that references the rules defined in this document > >> can specify that the wildcard character is not allowed in > >> certificates used by the relevant application protocol or community > >> of interest. > > > > To me this sounds awkward. It implies that either the CA has a flawed CPS > > can not appropriately deal with wildcard reference identifiers in certs, > > or is in general not trustworthy or that the wildcard-scheme too dangerous > > (=too difficult to handle safely) for server admins. > > > I believe wildcards are a misfeature, because a wildcard cert doesn't > identify the server well enough that it should be trusted. I believe > that "Best Practice" is to never use the feature, and for clients to > raise flags if presented with it. > > Of course "Current" practice is to make maximal use of the feature because: > > 1) nobody understands how to make the names match in real deployments. > > 2) the CA's pricing model makes it cheaper to buy a wildcard cert > than the full collection of multiple-alias certs you really need. > > > Getting back to the point: I think it's perfectly appropriate for a > Practice document to restrict when and how much you use a Standard feature. From Jeff.Hodges@KingsMountain.com Thu Sep 16 13:37:57 2010 Return-Path: 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 B105D3A6986 for ; Thu, 16 Sep 2010 13:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.095 X-Spam-Level: X-Spam-Status: No, score=-102.095 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 GFZx7uUxhmSF for ; Thu, 16 Sep 2010 13:37:36 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 4B4073A6918 for ; Thu, 16 Sep 2010 13:37:35 -0700 (PDT) Received: (qmail 32751 invoked by uid 0); 16 Sep 2010 20:37:58 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 16 Sep 2010 20:37:58 -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:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=mAERNR10RDku8cPWkVrP0w6g/PPqjraUqStivECADvlYdKMrFnWLK518/85LmwuAX2wQtBref953cxl3jNDZ9NrDwIWjxIjNOUInr0p3kUQmZu85EOV0AlbizJyuWC8A; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OwLDS-0003Io-93 for certid@ietf.org; Thu, 16 Sep 2010 14:37:58 -0600 Message-ID: <4C928024.3070605@KingsMountain.com> Date: Thu, 16 Sep 2010 13:37:56 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [certid] fwd: jhut: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 20:38:00 -0000 X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3 From: Jeffrey Hutzelman date: Wednesday, September 15, 2010 11:31 AM To: barryleiba@computer.org; draft-saintandre-tls-server-id-check.all@tools.ietf.org Cc: iesg@ietf.org; secdir@ietf.org; jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 Mime-Version: 1.0 Content-Type: text/plain --On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba wrote: > Second, there's a mixture of "natural person" and "human user" in the > document, and my sense is that you mean the same thing by both. If > you do, you should switch to one term (I prefer the latter; "natural > person" sounds odd). If they're meant to be different, you should > make it clear what the difference is. When I hear "natural person", I think "as opposed to corporation". I'm pretty sure that's not what's meant here, and I agree it sounds odd. > -- Page 21, sec 4.6.2: > client MUST verify that the presented certificate matches the cached > certificate and (if it is an interactive client) MUST notify the user > if the certificate has changed since the last time a secure > connection was successfully negotiated (where causes of change > include but are not limited to changes in the DNS domain name, > identifiers, issuer, certification path, and expiration date). > > I worry about this kind of advice. It violates my rule that says, > "Don't ask the user a question that he's not qualified to answer." Of > course, "notify the user" can mean a lot of things, but too many > clients will implement something like this with a popup that will be > meaningless to 99% of the people who use it. In practice, this advice is meaningless, as the described situation cannot happen. This case happens only when "a natural person has permanently accepted the certificate", which implies the presented certificate is the same as the cached certificate. I think what this section is trying to describe is a situation where the user has permanently accepted _some_ certificate for the service in question. In this situation, the presented certificate should be accepted if it matches the cached one, and should not be accepted if it does not. In the latter case, the UI experience will not end up being noticeably different from that of 4.6.3 -- the presented cert can be accepted temporarily, permanently, or not at all, but someone or some policy has to make that decision. However, I think there does need to be a difference in how the user is presented with a mismatched certificate for a service with an existing cached cert as opposed to one without. In a leap-of-faith model, you want to accept a certificate for a previously-unknown service, but reject a wrong certificate for an already-known service. > -- Page 21, sec 4.6.3, last graf: > Instead, the client MUST proceed as follows. > > I like a colon there, instead of the full stop. > > -- Page 21, sec 4.6.3.1, security note: > caution, for example by first encouraging the user to terminate > the connection, forcing the user to view the entire certification > path, and allowing the user to accept the certificate only on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session). > > Same comment as for 4.6.2. Most users will not understand certificate > problems, and will have no idea what they should do about them. > Always remember the "Barry's mother problem". My mother will *never* > want to see an "entire certification path", let alone appreciate being > "forced" to. In fact, I see two problems with the quoted advice. First, since we're talking about a certificate name mismatch, the rest of the certification chain really isn't relevant. It would be if the problem were a chain that doesn't lead to a suitable trust anchor, but that's not what this document is about. That said, Barry, your mother is not an "advanced user" in the sense intended by this document, and should never even be given the option to accept a certificate that doesn't validate. The second issue is the advice that the user should be allowed to accept a certificate with a mismatched name only on a temporary basis. This is almost certain to be the wrong thing to do; if a name mismatch is acceptable, it's also not likely to change anytime soon, and requiring the user to accept the certificate again in a later session just because the client has restarted is just annoying with no security benefit. If we were talking about path validation rather than server naming, I'd point out that accepting a certificate only temporarily doesn't give you the benefit of being able to detect future changes, and so actually _reduces_ security. With names, this isn't a big deal, as it's relatively easy to decide whether foo.bank.com and foo.attacker.org are the same or not (well, unless the bank and attacker have the same name). > -- Page 22, sec 5.1: > 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. > > Does this mean that a client specifically designed for the "gumbo" > service can't automatically use the service type "gumbo", without the > user's involvement? I don't think it does. If a user is running a gumbo client, I think it's implied that he meant to talk to the gumbo service. But if he's running a web browser, the browser should not decide that the user meant to use the gumbo service by the presence of gumbo.example.com (or a corresponding SRV record) in the DNS, any more than it should assume from the presence of an alias www.example.com =3D> gumbo.example.com that gumbo.example.com is an acceptable server name when the user typed www.example.com. > Or that a client put out by example.net can't > assume a host name of services.example.net in the absence of user > input that says otherwise? Again, I think this is fine; the client defines the lack of a user-specified name to mean something specific. What's not fine is to take the name given by the user and apply an insecure translation such as an unprotected DNS lookup. I think the advice in this paragraph is a little over-restrictive. What should be prohibited is not automated rewriting, but automated rewriting based on the use of insecure sources. RFC4120 has the following to say on this subject, as it relates to Kerberos: One can also rely on trusted third parties to make this determination, but only when the data obtained from the third party is suitably integrity-protected while resident on the third-party server and when transmitted. Thus, for example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, accepting the primary name as the party that one intends to contact, since an attacker can modify the mapping and impersonate the party. > Further, it's entirely reasonable for a program to have a user enter > something like "gmail", and have the client turn that into something > like "mail.google.com", deriving it from the user's input in an > automated fashion. Not if the client does so by rewriting "gmail" as "www.gmail.com", looking that up in the DNS, and using the target of the resulting alias. Most web browsers already get this right, thankfully. -- Jeff From mrex@sap.com Thu Sep 16 15:34:02 2010 Return-Path: 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 B1B323A6A0C for ; Thu, 16 Sep 2010 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 Zdi+8NQEtVv8 for ; Thu, 16 Sep 2010 15:34:01 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 5CCE83A69F3 for ; Thu, 16 Sep 2010 15:34:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8GMYPNv017695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Sep 2010 00:34:25 +0200 (MEST) From: Martin Rex Message-Id: <201009162234.o8GMYJZg010452@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 17 Sep 2010 00:34:19 +0200 (MEST) In-Reply-To: <201009161533.o8GFXlAG016810@fs4113.wdf.sap.corp> from "Martin Rex" at Sep 16, 10 05:33:47 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Fwd: secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 22:34:02 -0000 Cleanup of my prior message: Matt McCutchen wrote: > > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > Clearly unsafe operations: > > > > - building a reference identifier from the result of a > > DNS CNAME lookup > > > > (the use of DNSSEC does not make this safe) > > Why not? I'm not saying it's good practice, but I don't see an actual > vulnerability. You need two characteristics: (1) _trustworty_ information source for a name transformation (2) _protected_access_ to the information source DNSSEC meets (2) but not (1) DNSSEC provides only data integrity protection and data origin authentication for the distribution of the informtion. The use of DNSSEC for distribution of DNS data has zero impact on the quality, accuracy and trustworthyness of the underlying DNS information source. If Wikipedia enables TLS on their web-servers tomorrow so that you can access it through https://www.wikipedia.org/ what impact will this have on the trustworthyness of the information in Wikipedia articles? When there is no change to how others can access wikipedia and edit the content, your selection of accessing Wikipedia through HTTPS instead of HTTP will have exactly _zero_ impact on the trustworthyness of the information in wikipedia articles. -Martin From matt@mattmccutchen.net Thu Sep 16 20:12:48 2010 Return-Path: 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 88FA73A6ADD for ; Thu, 16 Sep 2010 20:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 vkgYzhuL7P53 for ; Thu, 16 Sep 2010 20:12:46 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 0FF403A6BB5 for ; Thu, 16 Sep 2010 20:12:45 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id BE8343BC063; Thu, 16 Sep 2010 20:13:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=uEBnanV93cVAYAuNbvS5hC1hxVxq2eP1TRSay763UfS Z2H17MlcfLx2ind74Zx3IX0ySCley9D8nk8cNFk8kEorGp1o3eQSI9GU8Ce7GzHm K2sqhVmPilnVP9ga7JX9ikT6BxtOQxibVuTHDWzApjUmiYR9kivH1IgATALkBIjY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Q0sIp8FyZUSEem1B++ArwIKJXvg=; b=PGiJ5FVBeP mhwankb4maEb7MKbMBmVn70yD0kjj8DCT/D9YUEwGM5lREZeUE5dXp+R3PpsPa8q NlbpbZueEohjVOqWioxdSt6ogzqGE/9Pynhko0Ak1sxe2xir0luZYBASUmLdwl1E j0d6bHP1YiwSDXY/l3cuB4g1f7g1kjE04= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id 7C0843BC062; Thu, 16 Sep 2010 20:13:10 -0700 (PDT) From: Matt McCutchen To: Martin Rex In-Reply-To: <201009162234.o8GMYJZg010452@fs4113.wdf.sap.corp> References: <201009162234.o8GMYJZg010452@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Thu, 16 Sep 2010 23:13:09 -0400 Message-ID: <1284693189.5722.209.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: [certid] DNSSEC-based name canonicalization X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 03:12:48 -0000 On Fri, 2010-09-17 at 00:34 +0200, Martin Rex wrote: > Cleanup of my prior message: > > > Matt McCutchen wrote: > > > > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > > Clearly unsafe operations: > > > > > > - building a reference identifier from the result of a > > > DNS CNAME lookup > > > > > > (the use of DNSSEC does not make this safe) > > > > Why not? I'm not saying it's good practice, but I don't see an actual > > vulnerability. > > You need two characteristics: > > (1) _trustworty_ information source for a name transformation > (2) _protected_access_ to the information source > > DNSSEC meets (2) but not (1) Why not (1)? It should go without saying that by DNSSEC I meant "DNSSEC with a set of trustworthy trust anchors that will get us to the desired signed zone". From there, the DNS admin has full authority to say what certificates a client trying to connect to a host in her zone should accept. We could have a record, CERTNAME or something, that specifies the hostname for which the certificate should be valid (via keyassure or PKIX + server-id-check). I realize now that it would be dangerous to reinterpret CNAME for this purpose, just as it is dangerous to reinterpret CERT as making an assurance, but that is a separate issue. I still wouldn't advise doing it unless we come up with a compelling use case. -- Matt From matt@mattmccutchen.net Thu Sep 16 20:37:41 2010 Return-Path: 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 06FAF3A6BE0 for ; Thu, 16 Sep 2010 20:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 FxqR1bjFwhX3 for ; Thu, 16 Sep 2010 20:37:31 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 4DE573A6BC5 for ; Thu, 16 Sep 2010 20:37:14 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id BAFEB280063 for ; Thu, 16 Sep 2010 20:37:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=GdNlt2MW/gkNbrnjsPvZTzbPEZjeSbQCKyDZ2ur3muJ q/DpKkXWVyme9X49xwEPzLYpf9a4lw23BDdUS+RxqzhEEigZaNtj2UzQhLeVtZlZ xElmpkfpIlB6IAkTFoBw7UJkJd8XmI6GpE7ZqfUteD0ct6NAH38d5orYhLdnMY2A = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=8Lq9rQqvnSFFfznCoUF4O7oOQFE=; b=aAd+CFxcCm E0qRv9hCJJ42Wc1nrcrnXpZn1ZNhTGb9rKjmcZ1aNxs19DHgZ+iB962trLwgCYPH FeKLXx2Z13TdZCN+slHtaJj7UcGcDKIf7G6XH1r6QFdeSu83hfZ+oiKt8a8OSsEr StS14eQYV3Kb5nM8VsyMijvJnLeBbCND4= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 8A027280062 for ; Thu, 16 Sep 2010 20:37:32 -0700 (PDT) From: Matt McCutchen To: certid@ietf.org In-Reply-To: <5F42C835-3211-48A7-9375-CE45A9C53739@jpl.nasa.gov> References: <201009160108.o8G18Sdm028897@fs4113.wdf.sap.corp> <5F42C835-3211-48A7-9375-CE45A9C53739@jpl.nasa.gov> Content-Type: text/plain; charset="UTF-8" Date: Thu, 16 Sep 2010 23:37:31 -0400 Message-ID: <1284694651.5722.234.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Subject: [certid] Wildcards for serving untrusted web content / same origin policy X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 03:37:41 -0000 On Thu, 2010-09-16 at 09:55 -0700, Henry B. Hotz wrote: > I believe wildcards are a misfeature [...] One important use case for wildcards is a web server that serves untrusted content spread out over a large or infinite set of subdomains to get increased protection from the same origin policy implemented by modern browsers. The server may use one subdomain per user who publishes content, or even a fresh subdomain for every request. A wildcard certificate is a much cleaner solution than having to automate the generation of a certificate per user, let alone per request. We can absolutely blame the inflexible same origin policy for necessitating the use of different host names (which also breaks TLS session sharing), but realistically it isn't changing any time soon. (Pardon me if this has already been pointed out.) -- Matt From mrex@sap.com Thu Sep 16 22:21:39 2010 Return-Path: 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 AE2253A6849 for ; Thu, 16 Sep 2010 22:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.833 X-Spam-Level: X-Spam-Status: No, score=-9.833 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 ejt6QbDElp8O for ; Thu, 16 Sep 2010 22:21:36 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5DE6A3A67E6 for ; Thu, 16 Sep 2010 22:21:36 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8H5M0Mm016125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Sep 2010 07:22:00 +0200 (MEST) From: Martin Rex Message-Id: <201009170521.o8H5LxdZ003712@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 17 Sep 2010 07:21:59 +0200 (MEST) In-Reply-To: <1284693189.5722.209.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 16, 10 11:13:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] DNSSEC-based name canonicalization X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 05:21:39 -0000 Matt McCutchen wrote: > > On Fri, 2010-09-17 at 00:34 +0200, Martin Rex wrote: > > Cleanup of my prior message: > > > > > > Matt McCutchen wrote: > > > > > > On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: > > > > Clearly unsafe operations: > > > > > > > > - building a reference identifier from the result of a > > > > DNS CNAME lookup > > > > > > > > (the use of DNSSEC does not make this safe) > > > > > > Why not? I'm not saying it's good practice, but I don't see an actual > > > vulnerability. > > > > You need two characteristics: > > > > (1) _trustworty_ information source for a name transformation > > (2) _protected_access_ to the information source > > > > DNSSEC meets (2) but not (1) > > Why not (1)? It should go without saying that by DNSSEC I meant "DNSSEC > with a set of trustworthy trust anchors that will get us to the desired > signed zone". From there, the DNS admin has full authority to say what > certificates a client trying to connect to a host in her zone should > accept. DNS needs to be available, fast, efficient and low-low-low cost. The cost of creating and maintaining DNS records with any trustworthyness that is measurably distinct from zero, with the necessary expertise to set up and devotion to practise scrutiny for every change to the data is probably going to far exceed the funding of most, if not all DNS admins. Are there already workable procedures and APIs for software to distinguish "normal" DNSSEC lookup results from "trustworthy" DNSSEC lookup results with some level of portability? How and how often would admins/consumers have to update and reconfirm every "trustworthy" DNSSEC key they keep? > > We could have a record, CERTNAME or something, that specifies the > hostname for which the certificate should be valid (via keyassure or > PKIX + server-id-check). I realize now that it would be dangerous to > reinterpret CNAME for this purpose, just as it is dangerous to > reinterpret CERT as making an assurance, but that is a separate issue. > I still wouldn't advise doing it unless we come up with a compelling use > case. DNS domains is a resource that is managed pretty arbitrary on a first-come first-served basis. It has some loose "a domain is leased to at most one entity at any single time" provision, that's it. DNS is vital for the internet, so it needs to remain fast, efficient and free, and all of that combined makes it hardly usable to bootstrap an infrastructure of trust, with any meaningful level of trust. The fraction of resources that web browsers accesses through HTTPS, where the first HTTPS link is served through a page received via HTTP in a completely untrusted fashion is mindboggling. Example "ebay". What do you think: how many users that login through the ebay sign-in page via HTTPS every day, have supplied the URL of the signin page in a trusted&secure fashion, and how many open http://www.ebay. and click a link on that page? How about online banking? An internet commerce that cares strongly about security should serve only one single "301 Moved Permanently" page with an HTTPS url on port 80, making it difficult to bookmark anything else than a HTTPS urls to this site. "Secure" electronic commerce on the internet is often like a handful of iron rings that are quickly attached to each other with tiny rubber bands from the kitchen drawer in order to give the impression of a chain. Occasionally, some of these "chains" rip apart by their own weight alone. -Martin From pgut001@cs.auckland.ac.nz Fri Sep 17 00:52:20 2010 Return-Path: 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 CAF0E3A6A4E for ; Fri, 17 Sep 2010 00:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 oUQMFOzticHa for ; Fri, 17 Sep 2010 00:52:16 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 6FE823A6AAF for ; Fri, 17 Sep 2010 00:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1284709962; x=1316245962; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[certid]=20DNSSEC-ba sed=20name=20canonicalization|Cc:=20certid@ietf.org |In-Reply-To:=20<201009170521.o8H5LxdZ003712@fs4113.wdf.s ap.corp>|Message-Id:=20|Date:=20Fri,=2017=20Sep=202010=2019:52:3 9=20+1200; bh=CwtKvY8APZTGt7pKKXkl9IwvcqzaNThRBJcl6AhRR5w=; b=J2I24rXvrlKmX3pyHsExFf2CiICKDMWEMw5cBr43b7K30/K1+tJrlOep AgtrNRs+OIAfpWFzc9EjyJjdve6GLwfySq+0rLWAXGToI5ylGrxxu0Pnh 2UD6DpNZoAWQSdaSdp/DQ/MnWJsKeRO7/01FQExxgFAsMpHO+wh/Mp0xW E=; X-IronPort-AV: E=Sophos;i="4.56,381,1280664000"; d="scan'208";a="27018437" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.207.92 - Outgoing - Outgoing Received: from wintermute02.cs.auckland.ac.nz ([130.216.207.92]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Sep 2010 19:52:39 +1200 Received: from pgut001 by wintermute02.cs.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1OwVkN-00022p-Ct; Fri, 17 Sep 2010 19:52:39 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201009170521.o8H5LxdZ003712@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 17 Sep 2010 19:52:39 +1200 Cc: certid@ietf.org Subject: Re: [certid] DNSSEC-based name canonicalization X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 07:52:20 -0000 Martin Rex writes: >Are there already workable procedures and APIs for software to distinguish >"normal" DNSSEC lookup results from "trustworthy" DNSSEC lookup results with >some level of portability? If you mean "is there a way to say 'I don't care about authentication, just gimme an address, dammit'", i.e. a getaddrinfo_unauthenticated(), then no, this was explicitly excluded from the DNSSEC work with a let-them-eat-cake argument that if anyone cared about this then they could just hack around at the res_query() level themselves. Note that this is just for basic DNS vs. DNSSEC lookups, given that you can't even do that I doubt there's any way to do vanilla DNSSEC vs. EV-cert-equivalent DNSSEC. Peter. From stpeter@stpeter.im Wed Sep 22 08:58:50 2010 Return-Path: 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 C220428C115; Wed, 22 Sep 2010 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 CQPO1TcLaW+h; Wed, 22 Sep 2010 08:58:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AB30228C116; Wed, 22 Sep 2010 08:58:48 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1DBCE40074; Wed, 22 Sep 2010 10:04:07 -0600 (MDT) Message-ID: <4C9A27D0.7030909@stpeter.im> Date: Wed, 22 Sep 2010 09:59:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: barryleiba@computer.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IETF cert-based identity , IETF discussion list , Barry Leiba , tls@ietf.org, secdir@ietf.org Subject: Re: [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 15:58:50 -0000 Barry, thank you for your review. Jeff and I are working through all the feedback that's been provided so far, and we'll be replying in various threads and cc'ing all appropriate lists as we (the editorial team) reach agreement on how to proceed. On 9/14/10 3:39 PM, Barry Leiba wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Please forgive the lateness of this review; I really meant to have it > done sooner. > > First, I found the document to be a tough read, and I can't really pin > down why. I started reviewing it several times, and restarted, before > I finally got through it. I can't give any advice with this comment, > so just take it as it is. Thanks for the feedback. The subject-matter is more dense than one might expect, and we attempted to be as thorough as possible so as to remove ambiguities. As a way of orienting the reader, we are thinking about adding a paragraph or two to the introduction briefly outlining our conclusions, but we don't yet have text to propose. > Second, there's a mixture of "natural person" and "human user" in the > document, and my sense is that you mean the same thing by both. If > you do, you should switch to one term (I prefer the latter; "natural > person" sounds odd). If they're meant to be different, you should > make it clear what the difference is. In our working copy we've changed "natural person" to "human user" in all instances. > Third, I'll note the earlier discussion of issues with IDN > comparisons. I have nothing to add to that discussion, and it may be > that the best thing is to leave things as they are. IDN-related topics are indeed always challenging, but we think that the current text meets the needs of this specification. > Comments are in order of appearance, not significance: > > -- Page 16, bullet 6: > The certificate MAY contain more than one DNS-ID, but SHOULD NOT > contain more than one CN-ID. > > Why "SHOULD NOT", and not "MUST NOT" ? I'm not challenging this; it's > a question. In an earlier version of this specification, we had "MUST NOT" instead of "SHOULD NOT". Discussion on the certid@ietf.org list led us to change it to "SHOULD NOT", because folks argued that if a certificate contains multiple DNS-IDs then it might appropriately contain one CN-ID corresponding to each DNS-ID. Jeff said he needs to review the older discussion again before the editors agree on how to proceed. > -- Page 17, sec 4.2, first graf: > Before connecting to the server, the client MUST construct a list of > acceptable reference identifiers. > > Why MUST it be done "before"? Can anyone detect, or does it hurt > interoperability, if it's done, say, in parallel with connection, or > while the client is waiting for the server to return the certificate? The current wording is unfortunate, because it is not temporal order that matters; what matters is that the client constructs its list of reference identifiers without being influenced by the presented identifiers provided in the certificate that's being checked. Therefore Jeff and I propose the following corrected text: Based on the source domain and the type of service to which the client is connecting, the client MUST construct a list of acceptable reference identifiers. > -- Page 18, sec 4.2, last bullet: > o The list SHOULD NOT include a CN-ID; however, the CN-ID (if > included) MUST be constructed only from the source domain and > never from a target domain. > > I find this oddly put. How about "The list SHOULD NOT include a > CN-ID. If a CN-ID is used despite this advice, it MUST be..." ? We have changed it to: o The list SHOULD NOT include a CN-ID; however, if a CN-ID is included despite this advice, it MUST be constructed only from the source domain and never from a target domain. > I'd also like to take the security note from section 4.3 and echo it > here. So maybe this?: > > << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite > this advice, it MUST be constructed only from the source domain and > never from a target domain. Further, it MUST NOT be used unless there > are no other supported identifiers present in the certificate. >> The last sentence does not apply in Section 4.2, because that section concerns construction of the list of reference identifiers and as stated above the client needs to do so without being influenced by the contents of the certificate presented by the server. > -- Page 18, sec 4.3, first graf: > by seeking a match and aborting the search if any presented > identifier matches one of its reference identifiers. > > "Aborting" has the connotation of premature termination, before > completion, and that's not the case here; you're saying that the match > completes the process. How about, simply, "stopping", or "ending" ? In our working copy, that paragraph now reads: Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. The search fails if the client exhausts its list of reference identifiers without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search. > -- Page 19, sec 4.4.3: > I think implementers might think that you're simply allowing any > leading wildcard character, so we should explicitly dissuade them. > > So, in the first graf: > the wildcard character '*', but only as the left-most label of the > domain name, > make it "only as the complete value of the left-most label". > > And in the second graf: > in which the wildcard character is contained within a label fragment > (e.g., baz*.example.net is not allowed and MUST NOT be taken to match > baz1.example.net and baz2.example.net) > change to: > baz1.example.net and baz2.example.net; also, *bozz.example.net is > not allowed and MUST NOT be taken to match frobozz.example.net) We've tightened up that text, as follows: ### A client employing this specification's rules MAY match the reference identifier against a presented identifier in which a traditional domain name or internationalized domain name contains one instance of the wildcard character '*', but only if that character is the complete left-most label of the domain name (as "label" is defined in [DNS]). The following rules apply: 1. The client MUST NOT match a presented identifier in which the wildcard character is not the only character of the label; e.g., baz*.example.net and *baz.example.net and b*z.example.net are not allowed and MUST NOT be taken to match baz1.example.net and foobaz.example.net and buzz.example.net. 2. The client MUST NOT match a presented identifier in which the wildcard character comprises a label other than the left-most label; e.g., bar.*.example.net is not allowed. 3. The client MUST compare the wildcard character only against the left-most label; e.g., *.example.com matches foo.example.com but not bar.foo.example.com or example.com. ### > -- Page 19, sec 4.4.3, last graf: > A specification that references the rules defined in this document > can specify that the wildcard character is not allowed in > certificates used by the relevant application protocol or community > of interest. > > How about “...can strengthen this section by ruling out wildcard > matching altogether for the relevant...†? Changed in our working copy to: A specification that references the rules defined in this document can strengthen the generic recommendations herein by disallowing wildcard matching altogether for the relevant application protocol or community of interest. > -- Page 20, sec 4.4.4, second graf: > entry types supported by the client), the client MAY as a fallback > check for a string whose form matches that of a fully-qualified DNS > domain name in the CN-ID. > > Back in section 4.2, you say that the client SHOULD NOT include CN-ID > in the list, and here you're saying that it MAY make such a > comparison. That seems oddly contradictory to me, though one can > certainly argue that SHOULD NOT implies MAY. I'd prefer to see this > worded differently. Good catch. Jeff and I do indeed mean to say that CN-ID is NOT RECOMMENDED, not that it is OPTIONAL (the two are not equivalent, as I recently learned by re-reading RFC 2119). Therefore we have provisionally modified the text in Section 4.4.4 to read: As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include an SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName entry types supported by the client. Therefore, if and only if the set of identifiers does not include a subjectAltName entry of type dNSName, SRVName, or uniformResourceIdentifier (or any application-specific subjectAltName entry types supported by the client), as a fallback the client is allowed to check the CN-ID for a string whose form matches that of a fully-qualified DNS domain name. Despite the fact that this behavior is NOT RECOMMENDED, if the client does compare a reference identifier of type CN-ID against that string obtained from a CN-ID presented in the certificate, it MUST follow the comparison rules for the source domain of an identifier of type DNS-ID, SRV-ID, or URI-ID, as described under Section 4.4. Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if"). Jeff is a bit uncomfortable with that because CN-ID is such a common practice, but I'm comfortable with it because of the hypothetical nature of the recommendation. He will review the earlier discussions on this topic before we finalize that text. > -- Page 21, sec 4.6.2: > client MUST verify that the presented certificate matches the cached > certificate and (if it is an interactive client) MUST notify the user > if the certificate has changed since the last time a secure > connection was successfully negotiated (where causes of change > include but are not limited to changes in the DNS domain name, > identifiers, issuer, certification path, and expiration date). > > I worry about this kind of advice. It violates my rule that says, > "Don't ask the user a question that he's not qualified to answer." Of > course, "notify the user" can mean a lot of things, but too many > clients will implement something like this with a popup that will be > meaningless to 99% of the people who use it. Based on feedback from other threads, that section now reads: ### 4.6.2. Case #2: No Match Found, Cached Certificate If the client finds no presented identifier that matches any of the reference identifiers but a human user has permanently accepted the certificate during a previous connection attempt or via configured preferences, the certificate has already been cached. In this case, the client MUST verify that the presented certificate matches the cached certificate; if the presented certificate does not match the cached certificate then the client MUST proceed as described under Case #3 below. ### See also our reply below regarding Section 4.3.6.1. > -- Page 21, sec 4.6.3, last graf: > Instead, the client MUST proceed as follows. > > I like a colon there, instead of the full stop. I used to like colons in such places, but I've migrated to full stop. We'll see what the RFC Editor has to say. :) > -- Page 21, sec 4.6.3.1, security note: > caution, for example by first encouraging the user to terminate > the connection, forcing the user to view the entire certification > path, and allowing the user to accept the certificate only on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session). > > Same comment as for 4.6.2. Most users will not understand certificate > problems, and will have no idea what they should do about them. > Always remember the "Barry's mother problem". My mother will *never* > want to see an "entire certification path", let alone appreciate being > "forced" to. The part of the text that you have not quoted does say that this practice is typically offered only to advanced users (and I don't think that Barry's mother counts as an advanced user). However, we've provisionally made the text even more scary, as follows: Security Note: Some existing interactive user agents give advanced users the option of proceeding despite an identity mismatch. Although this behavior can be appropriate in certain specialized circumstances, in general it needs to be exposed only to advanced users and even then needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the connection and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to accept the certificate on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session, but not for connection attempts during future application sessions). Jeff still needs to review that text before we finalize it. > -- Page 22, sec 5.1: > 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. > > Does this mean that a client specifically designed for the "gumbo" > service can't automatically use the service type "gumbo", without the > user's involvement? Or that a client put out by example.net can't > assume a host name of services.example.net in the absence of user > input that says otherwise? IMHO that is a matter of user configuration, or user acknowledgement of a service agreement, so it falls under the text in this I-D about allowing the client to check the certificate against a DNS domain name that is explicitly associated with the source domain by means of user configuration. > Further, it's entirely reasonable for a program to have a user enter > something like "gmail", and have the client turn that into something > like "mail.google.com", deriving it from the user's input in an > automated fashion. Do we really want to forbid that sort of thing? Yes, we do, because although you happen to "just know" that mail.google.com is a legitimate DNS domain name to connect to when interacting with the gmail.com service, Barry's mother might not have that kind of knowledge and as a general rule it's a very bad idea to assume that it's just fine to connect to some domain at foo.com when interacting with a service at bar.com. However, service delegation is a difficult topic and there are ongoing discussions among various IETF participants about how to do service delegation securely; one thing I think we can safely say is that it's not the task of this I-D to solve the problem of secure service delegation. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 09:21:15 2010 Return-Path: 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 5D83D3A698B; Wed, 22 Sep 2010 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 IOD+VtBr4zxg; Wed, 22 Sep 2010 09:21:13 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0E2393A692E; Wed, 22 Sep 2010 09:21:13 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3E4E40074; Wed, 22 Sep 2010 10:26:33 -0600 (MDT) Message-ID: <4C9A2D12.3020409@stpeter.im> Date: Wed, 22 Sep 2010 10:21:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Stefan Santesson References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: IETF cert-based identity , ietf@ietf.org, tls@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 16:21:15 -0000 On 9/14/10 12:51 AM, Stefan Santesson wrote: > Peter, > > After the past discussions, the remaining things on my review list are: Jeff and I would like to thank you for sticking with us as we slowly work through the feedback we've received. Comments inline. > General: > consider substituting ³PKIX-based systems² and ³PKIX Certificates² with ³PKI > systems based on RFC 5280² and ³RFC 5280 Certificates², alternatively > include [PKIX] brackets to clarify that it references RFC 5280. Jeff and I would prefer to define "PKIX" in the terminology section and then use that definition as the basis for the terms "PKIX-based system" and "PKIX certificate". We propose to define "PKIX" as follows: PKIX is a short name for RFC 5280 [PKIX], which comprises a profile of the X.509v3 certificate specifications and X.509v2 certificate revocation list (CRL) specifications for use in the Internet. > General: > I would consider stating that server certificates according to this profile > either MUST or SHOULD have the serverAuth EKU set since it is allways > related to the use of TSL and server authentication. At least it MUST be set > when allowing checks of the CN-ID (see 2.3 below). Jeff and I are still discussing this topic and do not yet have editorial agreement about how to proceed. > 1.3.2 and section 3 > SRVName is described as an extension in 1.3.2, but is in fact a Subject Alt > Name (otherName form) RFC 4985. > This error is repeated in section 3, bullet 4, on page 16. Fixed. > 1.1. > s/an application services/an application service Fixed. > 1.2 > I find the following text is hard to understand: > ³(this document addresses only the DNS domain name of the application > service itself, not the entire trust chain)² > I¹m not sure what the DNS domain name has to do with checking the entire > trust chain. Further, this document discuss more name forms than the DNS > domain name. > Perhaps this sentence was meant to say: > "(this document only addresses name forms in the leaf server certificate, > not any name forms in the chain of certificate used to validate the server > certificate)" That's better. Thanks for the text. > 2.3 > It would be good if we could restrict the use of CN-ID for storing a domain > name to the case when the serverAuth EKU is set. Requiring the EKU reduce > the probability that the CN-ID appears to be a domain name by accident or is > a domain name in the wrong context. > > In many deployments, this also affects the name constraints processing to > perform domain name constraints also on the CN attribute. > > There should at least be a rule stating that any client that accepts the CN > attribute to carry the domain name MUST also perform name constraints on > this attribute using the domain name logic if name constraints is applied to > the path. Failing this requirement poses a security threat if the claimed > domain name in CN-ID violated the name constraints set for domain names. See above; Jeff and I are still discussing this topic. > 4.4.3 checking wildcard labels > The restriction to match against only one subdomain seems to not be > compatible with FRC 4592. RFC 4592 states: > > A wildcard domain name can have subdomains. There is no need to > inspect the subdomains to see if there is another asterisk label in > any subdomain. Speaking for myself, not for Jeff, I think the entire notion of a subdomain is suspect and very poorly defined, which is why the XMPP WG did away with it in rfc3920bis. For example, is foo.co.uk a subdomain of co.uk? No. And I think we really don't want to pull in a normative reference to the public suffix list in this specification! > Further, I'm pretty sure that the rule of this draft is incompatible with > many deployments of wildcard matching. I recall in Microsoft we allowed any > number of subdomains when I was involved with the CAPI team. It also seems to me that allowing recursive wildcards (e.g., allowing *.*.example.com via *.example.com) is a major expansion beyond RFC 2818 or current verification methods. Jeff would like to check the relevant specifications (all of the specs in the "Prior Art" appendix) and the previous discussion threads on the certid@ietf.org list before coming to a conclusion on this matter. > 4.6.2 > States: > > In this case, the > client MUSTverify that the presented certificate matches the cached > certificate and (if it is an interactive client) MUST notify the > user if the certificate has changed since the last time a secure > connection was successfully negotiated > > How does the client know if the certificate has changed or whether it just > obtained an unauthorized certificate? If the client has lost its cache then it simply needs to proceed as described under "Case #3: No Match Found, Uncached Certificate". > I guess in some cases it would work but I feel sure there are exception > cases where the client just has a configured certificate but no knowledge of > what it obtained the last time it talked to the server. Is your concern about caching the certificate or keeping track of what the client received the actual "last time" it connected? The mention of "last time" is meant to ensure continuity of checking, not to force the client to keep track of particular connection attempts. Therefore in our working copy we have changed that paragraph to read: If the client finds no presented identifier that matches any of the reference identifiers but a human user has permanently accepted the certificate during a previous connection attempt or via configured preferences, the certificate has already been cached. In this case, the client MUST verify that the presented certificate matches the cached certificate; if the presented certificate does not match the cached certificate then the client MUST proceed as described under Case #3 below. Thanks again for your feedback. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 09:32:40 2010 Return-Path: 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 F089D28C0DC; Wed, 22 Sep 2010 09:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.254 X-Spam-Level: X-Spam-Status: No, score=-102.254 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 INiWxTXspKo9; Wed, 22 Sep 2010 09:32:38 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 36EDD3A6A97; Wed, 22 Sep 2010 09:32:38 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B078A40074; Wed, 22 Sep 2010 10:37:58 -0600 (MDT) Message-ID: <4C9A2FBF.30007@stpeter.im> Date: Wed, 22 Sep 2010 10:33:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: "t.petch" References: <4C8E78A9.7040608@stpeter.im> <007c01cb55a9$b2175a60$4001a8c0@gateway.2wire.net> In-Reply-To: <007c01cb55a9$b2175a60$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba , IETF cert-based identity , ietf@ietf.org, tls@ietf.org Subject: Re: [certid] Review of draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 16:32:40 -0000 On 9/16/10 8:15 AM, t.petch wrote: > ----- Original Message ----- > From: "Peter Saint-Andre" > To: "Stefan Santesson" > Sent: Monday, September 13, 2010 9:16 PM > >> On 9/13/10 12:39 PM, Stefan Santesson wrote: >>> On 10-09-13 6:08 PM, "Peter Saint-Andre" wrote: >>>> >>>> Hi Shumon, >>>> >>>> As I see it, this I-D is attempting to capture best current practices >>>> regarding the issuance and checking of certificates containing >>>> application server identities. Do we have evidence that any existing >>>> certification authorities issue certificates containing both an SRVname >>>> for the source domain (e.g., example.com) and dNSName for the target >>>> domain (e.g., apphosting.example.net)? Do we have evidence that any >>>> existing application clients perform such checks? If not, I would >>>> consider such complications to be out of scope for this I-D. >>>> >>>> That said, we need to be aware that if such usage arises in the future, >>>> someone might write a document that updates or obsoletes this I-D; in >>>> fact the present authors very much expect that such documents will >>>> emerge after the Internet community (specifically certification >>>> authorities, application service providers, and application client >>>> developers) have gained more experience with PKIX certificates in the >>>> context of various application technologies. >>>> >>>> Peter >>> >>> I would like to turn the question around and ask why this specification need >>> to have an opinion on whether a relying party feels he have to check both >>> host name and service? >> >> Stop right there. :) I sense a possible source of confusion. What do you >> mean by "host name" and what do you mean by "service"? >> >> In this I-D, we talk about "DNS domain name" and "service type", which >> map quite well to _Service.Name from RFC 4985: the DNS domain name is >> the "source domain" provided by the user or configured into the client >> (e.g., "example.com") and the "service type" is a given application >> protocol that could be serviced by the source domain (e.g., "IMAP"). >> >> This I-D is attempting to gently nudge people in the direction of >> checking both the DNS domain name and the service type. IMHO this is >> consistent with considering the SRVName and uniformResourceIdentifier >> subjectAltName entries as more tightly scoped than dNSName or CN, and >> therefore as potentially more "secure" in some sense (the subject might >> want to limit use of a particular certificate to only the service type >> identified in the SRVName or uniformResourceIdentifier). > > > Ah, that explains a lot; I knew I smelt a rat, I just did not realise how big it > was:-) It is fine if you want to nudge Certificate Authorities into issuing > certs with SRVName but you should put that up front, in the Abstract eg > "This memo encourages Certificate Authorities to issue certificates with SRVName > names" > > Otherwise people are likely to expend effort on this memo which will turn out to > be unproductive; as this thread has established, SRVName do exist, but not in > many places, which makes this memo of rather limited scope. > > I wondered why the emphasis on server names had grown and grown, in the I-D and > on this thread, an emphasis which to me seemed a distraction and irrelevance, > and now I see why; nothing wrong, just needs making this explicit. > > Tom Petch > > Thanks for your feedback. As a way of orienting the reader, Jeff and I are discussing the possibility of adding a section to the introduction that provides an informational overview of the recommendations contained in the document. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Wed Sep 22 09:44:12 2010 Return-Path: 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 C873D3A6A4B; Wed, 22 Sep 2010 09:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.305 X-Spam-Level: X-Spam-Status: No, score=-101.305 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 uEPGYNYXgR1E; Wed, 22 Sep 2010 09:44:11 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id CE08F3A6A74; Wed, 22 Sep 2010 09:44:02 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o8MGiFsq020194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 09:44:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C9A2D12.3020409@stpeter.im> References: <4C9A2D12.3020409@stpeter.im> Date: Wed, 22 Sep 2010 09:44:13 -0700 To: Peter Saint-Andre , Stefan Santesson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IETF cert-based identity , ietf@ietf.org, tls@ietf.org Subject: [certid] Why require EKU for certid? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 16:44:13 -0000 At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >On 9/14/10 12:51 AM, Stefan Santesson wrote: > > General: >> I would consider stating that server certificates according to this profile >> either MUST or SHOULD have the serverAuth EKU set since it is allways >> related to the use of TSL and server authentication. At least it MUST be set >> when allowing checks of the CN-ID (see 2.3 below). > >Jeff and I are still discussing this topic and do not yet have editorial >agreement about how to proceed. This is not editorial, this is definitely technical. What possible advantage is there to making certificates that do not have this flag set be excluded from the practices you are defining? That is, if a TLS client gets a certificate from a TLS server that the TLS server says is its authentication certificate, why should the client care whether or not that flag is set? That flag is an assertion from the CA, not from the server who is authenticating. > > 2.3 > > It would be good if we could restrict the use of CN-ID for storing a domain > > name to the case when the serverAuth EKU is set. Requiring the EKU reduce > > the probability that the CN-ID appears to be a domain name by accident or is > > a domain name in the wrong context. That makes no sense from an operational standpoint. The inclusion of an EKU has nothing to do with the decision-making for the domain name location. > > In many deployments, this also affects the name constraints processing to >> perform domain name constraints also on the CN attribute. True, and irrelevant. > > There should at least be a rule stating that any client that accepts the CN >> attribute to carry the domain name MUST also perform name constraints on >> this attribute using the domain name logic if name constraints is applied to >> the path. Failing this requirement poses a security threat if the claimed >> domain name in CN-ID violated the name constraints set for domain names. Fully disagree. --Paul Hoffman, Director --VPN Consortium From stpeter@stpeter.im Wed Sep 22 10:08:51 2010 Return-Path: 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 19D923A698B; Wed, 22 Sep 2010 10:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 JV3iVJNJ35OD; Wed, 22 Sep 2010 10:08:45 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B47C53A686D; Wed, 22 Sep 2010 10:08:43 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5F6FA40074; Wed, 22 Sep 2010 11:14:00 -0600 (MDT) Message-ID: <4C9A382F.80501@stpeter.im> Date: Wed, 22 Sep 2010 11:09:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Wes Hardaker References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org, tls@ietf.org, ietf@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 17:08:51 -0000 Wes, thank you for reviewing this document. Jeff and I provide replies inline using the editorial "we". On 9/13/10 9:58 PM, Wes Hardaker wrote: > > I've reviewed draft-saintandre-tls-server-id-check-09 and find it a good > document and support it's forward progress. I do have a few comments > though: > > (*): > Applies to many of the comments below: some parts of the document > read like a BCP in the way it tries to rationalize things. A number > of these text sections really don't help the document, though, as it > adds unneeded ambiguity. Examples of this are marked below with (*). > > Section 1.1: (*) > I don't think you should be spelling out the popularity of TLS vs > DTLS. While it may be true today, this is intended to be a proposed > standard and thus doesn't need to specify that one is potentially more > popular than the other. The document should be targeting the use of > both regardless of how well DTLS is used at the moment. Suggested: > > OLD: > When a client connects to an > application services using Transport Layer Security [TLS] (or, less > commonly, Datagram Transport Layer Security [DTLS]), it references > some conception of the server's identity while attempting to > establish a secure connection (e.g., "the web site at example.com"). > > New: > When a client connects to an > application services using Transport Layer Security [TLS] or > Datagram Transport Layer Security [DTLS], it references some > conception of the server's identity while attempting to establish a > secure connection (e.g., "the web site at example.com"). Fixed in our working copy. > Section 1.1 and the appendices: > You could now, if you wanted, add SNMP over (D)TLS: RFC5953. If > you're going to copy into the appendix as well, the text to copy is > from the snmpTlstmAddrTable object in that document. Thanks for the pointer; we'll incorporate some of the text from RFC 5953 into our "Prior Art" appendix. > Section 1.3.2: (*) > This section is full of text that is subjective and really isn't > needed in the first place. The authors have lost count of how many times commenters have said "why doesn't this spec talk about X and Y and Z?" We think it's valuable to explain why the scope is as limited as it is, in part to motivate others to work on specs about X and Y and Z. > Nearly every paragraph contains text that > may be true today but might not be in the future Clearly we can't write about the future yet. However, we fully expect to update this document once the Internet community has gained more experience with the technologies under discussion. That "C" in BCP does stand for "current". :) > or is subject to > interpretation. While I agree with most of the conclusions, I don't > think it's worth putting the text into the document; especially when > the text is simply defining what's out of scope. I don't think you > need to spend effort rationalizing what's out of scope. We do. See above. > Suggestion: keep the bullets, ditch the paragraphs. > > Phrasing examples (IE, an incomplete list) that are questionable: > > "service operators have less experience with client certificates" > > "Most fundamentally, most users find DNS domain names much easier to > work with than IP addresses, which is why the domain name system was > designed in the first place. > > "Furthermore, application technologies have less experience with > IPsec than with TLS, thus making it more difficult to gather > feedback on proposed best practices." Those statements seem to us like truisms at this point in the evolution of the Internet. > Section 1.4, "Target Domain" > It took me far too long into reading this document to remember what a > "target domain" really meant. IMHO, a better term that already > conveys the proper meaning to most readers would be a "derived > domain". Think about a global search and replace for target->derived? We borrowed the term "target" from RFC 2782, because in DNS SRV records the "target" is the result of an automated lookup for what we're calling a "source domain". However, we tend to agree with you that "derived domain" probably captures the concept better, so are looking into changing it (we haven't yet made that change because we want to be sure it doesn't have implications we haven't had time to consider). > Section 3, bullet 5: That is: 5. The certificate SHOULD NOT represent the server's fully-qualified DNS domain name in a CN-ID, even though many deployed clients still check for this legacy identifier configuration within certificate subject name. > Unfortunately, this is the one rule I think will be > broken the most often. Fortunately, checking from the client side > says to ignore the CN-ID if it can match on other things as well. > Because of this, the only thing this particular rule hurts is the > software that isn't going to conform to this document because the code > is already too old. It's basically a "should upgrade" statement. I > think an extra sentence here might be helpful, though I don't have a > suggestion at the moment. Jeff and I are discussing what text to add here. > Section 4.3, security note: > I actually think wording these things is tricky when the future is > unknown. Is there a time when the future is not unknown? ;-) > I think it's generally safer to describe the only conditions > which are valid for checking a CN-ID instead of trying to list all the > "MUST NOT" cases, which is more likely to change with the addition of > future specs into the spec tree. Sure, which is why we expect to update this document when reality has changed enough to justify the effort. > I didn't have time to fully think > out replacement text, but I'd start it with "A client MUST only seek a > match for a reference identifier of a CN-ID if it is the only > available presented identifier." Or something like that. How about this? A client SHALL seek a match for a reference identifier of CN-ID only if the certificate contains no other presented identifiers. That does seem better -- it's good to future-proof the spec where possible, I just don't think it's always possible. I'll ask Jeff to review that text, too, because I came up with it just now while replying to you. > Section 5, Security Considerations: > The interesting thing about this specification is that we're leaving a > fairly broad range of potential "success" matches. Not only that, but > future specifications may lead to future reference identity matches > that previously didn't work. Fortunately, I can't come up with an > example that works all that well to describe it but somehow I'm left > feeling nervous that a server cert could have a clause the clients > don't understand currently but might later after a software upgrade > and an admin that expects a failure may suddenly see a success. You > can ignore this paragraph if you fail to grasp what I'm trying to say, > as I'm not at all stating it well. I have a sense of what you're getting at, but I'm not deeply concerned about it because I think we'll be updating this document in the future. > Section 5.1, Service Delegation: > You discuss interactive clients and how the the source domain name > MUST be provided by a human user. But the odd case that I couldn't > figure out what it mapped to was references from an original source. > EG, images or javascript elements in a web page aren't "provided by > the user", but a web-browser is certainly interactive. This sort of > "snow ball" domain list probably should be discussed at least in > brief. That is an excellent catch. Jeff and I are discussing how to address this matter and will post again once we have proposed text. > Section 5.1, Service Delegation: > I read the last paragraph (which is one sentence) multiple times and I > only barely feel that I understand what it's saying. That is: There are several scenarios in which it can be legitimate for an interactive client to override the recommendation in the foregoing rule. Examples include: 2. A human user has explicitly agreed to trust a service that provides mappings of source domains to target domains, such as a dedicated discovery service or an identity service that securely redirects requests from the source domain to a target domain (however, such an arrangement is not encouraged and if a client supports such a service then it needs to disable it by default and carefully warn the user about the possible negative consequences of trusting such a service). > I'd suggest > rewording it for clarity and splitting it into multiple sentences. > I'd offer suggestive text, but then I'd prove that I really didn't > understand it. During an earlier review, Stefan Santesson suggested adding some text about trusted mapping services, and the quoted text is the result. Although there are cases when trusted mapping services are well-defined (e.g., some SAML-based services), in general we agree with you that the concept of a trusted mapping service is vague and difficult to grok. We'd be open to removing that paragraph entirely, if Stefan would not object too strongly. :) > General: > Some of the possible combinations and options that may exist could > really use an "examples" section or something that had example info > from a certificate combined with example list of expected reference > indenties. Though this would be nice, it's not at all critical. Good suggestion. We will work to add a section of examples. See for instance Section 13.7.1.2.2 (!) of draft-ietf-xmpp-3920bis-15 for the kind of thing we'll include. Thanks again for your feedback. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 10:17:26 2010 Return-Path: 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 3C87D3A6B00; Wed, 22 Sep 2010 10:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 PnFYPrjvdQor; Wed, 22 Sep 2010 10:17:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2FD483A6A7F; Wed, 22 Sep 2010 10:17:24 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5020F40074; Wed, 22 Sep 2010 11:22:43 -0600 (MDT) Message-ID: <4C9A3A3B.9090908@stpeter.im> Date: Wed, 22 Sep 2010 11:17:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Matt McCutchen References: <4C912A86.3040402@stpeter.im> <58606B11-D4CC-43F4-8971-90D51780A21B@jpl.nasa.gov> <1284608876.5722.56.camel@mattlaptop2.local> In-Reply-To: <1284608876.5722.56.camel@mattlaptop2.local> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity , tls@ietf.org, barryleiba@computer.org, IETF discussion list Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 17:17:26 -0000 On 9/15/10 9:47 PM, Matt McCutchen wrote: > On Wed, 2010-09-15 at 16:58 -0700, Henry B. Hotz wrote: >> On Sep 15, 2010, at 1:20 PM, Peter Saint-Andre wrote: >> >>> -- Page 22, sec 5.1: >>> 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. >>> >>> Does this mean that a client specifically designed for the "gumbo" >>> service can't automatically use the service type "gumbo", without the >>> user's involvement? Or that a client put out by example.net can't >>> assume a host name of services.example.net in the absence of user >>> input that says otherwise? >>> >>> Further, it's entirely reasonable for a program to have a user enter >>> something like "gmail", and have the client turn that into something >>> like "mail.google.com", deriving it from the user's input in an >>> automated fashion. Do we really want to forbid that sort of thing? >> >> >> That strikes me as an awfully blase comment for a security review. >> Whatever process translates the user input into the name that's used >> to verify the server's id is a critical part of the verification. If >> you can subvert the translation, then you can subvert the server ID >> check, which is the whole point of this draft. >> >> I'm not opposed to the idea of name canonicalization, but it has to be >> done in an authoritative, secure fashion > > Exactly. > >> and that's probably out of scope for this draft. > > Is it? We may be able to make a useful general statement. There are > two issues here: > > 1. "Authoritative": different applications and even users may have > different ideas of what name canonicalization processes are > "authoritative", so all we can ask of compliant implementations is to > document which processes they use. "Profiles" of server-id-check may > fill in more details. > > 2. "Secure": given that the point of TLS is to protect against network > attackers, it makes no sense to use a name canonicalization process that > is vulnerable to them. We can say, "Any process by which the source > domain is derived from user input MUST NOT be subject to subversion by > network attackers", or some such. Over a year ago, Alexey Melnikov suggested adding text along those lines and somehow it got lost during the revision process. We'll add something to that effect back to the spec. The text that Alexey suggested was similar to text from RFC 4513, and you can see it in version -02 of draft-saintandre-tls-server-id-check: 4. Before attempting to find a match in relation to a particular presented identity, the client MAY map the reference identity to a different identity type. Such a mapping MAY be performed for any available subjectAltName type to which the reference identity can be mapped; however, the reference identity SHOULD be mapped only to types for which the mapping is either inherently secure (e.g., extracting the DNS name from a URI to compare with a subjectAltName of type dNSName or SRVName) or for which the mapping is performed in a secure manner (e.g., using [DNSSEC], or using a user-configured or admin-configured lookup table for host-to-address or address-to-host translations). > Tangent: I know we want to avoid implementations that do foolish things > being claimed as compliant, but IMO, the requirement that input come > from a "human user" is goofy for a technical specification and in > practice a non-starter. A web browser that followed a HTTP redirection > to a https: URL would violate it. The web has evolved toward complex > applications in which all pretense that the user is mediating the > issuance of HTTP requests has been abandoned, which brings major > productivity benefits as well as major security implications; ignoring > this would be a mistake. Wes Hardaker also raised this issue in his review. Jeff and I agree that this is an open issue and are working to address it. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 10:52:53 2010 Return-Path: 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 85E013A685B; Wed, 22 Sep 2010 10:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 RfzMhVET+LeV; Wed, 22 Sep 2010 10:52:51 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BF92F3A694D; Wed, 22 Sep 2010 10:52:51 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8624340074; Wed, 22 Sep 2010 11:58:12 -0600 (MDT) Message-ID: <4C9A428C.2030807@stpeter.im> Date: Wed, 22 Sep 2010 11:53:16 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> In-Reply-To: <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, barryleiba@computer.org, IETF cert-based identity , iesg@ietf.org, secdir@ietf.org Subject: Re: [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 17:52:53 -0000 On 9/15/10 12:30 PM, Jeffrey Hutzelman wrote: > --On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba > wrote: >> -- Page 21, sec 4.6.3.1, security note: >> caution, for example by first encouraging the user to terminate >> the connection, forcing the user to view the entire certification >> path, and allowing the user to accept the certificate only on a >> temporary basis (i.e., for this connection attempt and all >> subsequent connection attempts for the life of the application >> session). >> >> Same comment as for 4.6.2. Most users will not understand certificate >> problems, and will have no idea what they should do about them. >> Always remember the "Barry's mother problem". My mother will *never* >> want to see an "entire certification path", let alone appreciate being >> "forced" to. > > In fact, I see two problems with the quoted advice. First, since we're > talking about a certificate name mismatch, the rest of the certification > chain really isn't relevant. It would be if the problem were a chain > that doesn't lead to a suitable trust anchor, but that's not what this > document is about. For context, the "quoted advice" is mostly a description of current usage in some existing user agents. Incorporating Barry's suggestions, that text currently reads as follows in our working copy: Security Note: Some existing interactive user agents give advanced users the option of proceeding despite an identity mismatch. Although this behavior can be appropriate in certain specialized circumstances, in general it ought to be exposed only to advanced users and even then needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the connection and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to accept the certificate on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session, but not for connection attempts during future application sessions). Your document editors will take up this issue during our discussion of open issues with the spec. > That said, Barry, your mother is not an "advanced > user" in the sense intended by this document, and should never even be > given the option to accept a certificate that doesn't validate. > > The second issue is the advice that the user should be allowed to accept > a certificate with a mismatched name only on a temporary basis. This is > almost certain to be the wrong thing to do; if a name mismatch is > acceptable, it's also not likely to change anytime soon, and requiring > the user to accept the certificate again in a later session just because > the client has restarted is just annoying with no security benefit. That's an interesting point. In feedback we received from implementers of interactive user agents (most browsers), we heard that at least some user agents do enforce a distinction between accepting an identity mismatch temporarily and accepting it permenantly. The security properties of that distinction did not come up in previous mailing list threads about this I-D, but your editorial team will do a bit more research and might return with proposed text changes. > If we were talking about path validation rather than server naming, I'd > point out that accepting a certificate only temporarily doesn't give you > the benefit of being able to detect future changes, and so actually > _reduces_ security. With names, this isn't a big deal, as it's > relatively easy to decide whether foo.bank.com and foo.attacker.org are > the same or not (well, unless the bank and attacker have the same name). > >> -- Page 22, sec 5.1: >> 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. >> >> Does this mean that a client specifically designed for the "gumbo" >> service can't automatically use the service type "gumbo", without the >> user's involvement? > > I don't think it does. If a user is running a gumbo client, I think > it's implied that he meant to talk to the gumbo service. But if he's > running a web browser, the browser should not decide that the user meant > to use the gumbo service by the presence of gumbo.example.com (or a > corresponding SRV record) in the DNS, any more than it should assume > from the presence of an alias www.example.com => gumbo.example.com that > gumbo.example.com is an acceptable server name when the user typed > www.example.com. > > >> Or that a client put out by example.net can't >> assume a host name of services.example.net in the absence of user >> input that says otherwise? > > Again, I think this is fine; the client defines the lack of a > user-specified name to mean something specific. What's not fine is to > take the name given by the user and apply an insecure translation such > as an unprotected DNS lookup. > > I think the advice in this paragraph is a little over-restrictive. What > should be prohibited is not automated rewriting, but automated rewriting > based on the use of insecure sources. RFC4120 has the following to say > on this subject, as it relates to Kerberos: > > > One can also rely on trusted third parties to make this > determination, but only when the data obtained from the third party > is suitably integrity-protected while resident on the third-party > server and when transmitted. Thus, for example, one should not rely > on an unprotected DNS record to map a host alias to the primary name > of a server, accepting the primary name as the party that one intends > to contact, since an attacker can modify the mapping and impersonate > the party. Thanks for the pointer to RFC 4120. We're looking into how to appropriate reference that in the next version of this spec. >> Further, it's entirely reasonable for a program to have a user enter >> something like "gmail", and have the client turn that into something >> like "mail.google.com", deriving it from the user's input in an >> automated fashion. > > Not if the client does so by rewriting "gmail" as "www.gmail.com", > looking that up in the DNS, and using the target of the resulting > alias. Most web browsers already get this right, thankfully. Again, we agree with you that secure service delegation is outside the scope of this I-D, as we expressed in our reply to Barry's review. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 10:58:25 2010 Return-Path: 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 2877A3A69B4; Wed, 22 Sep 2010 10:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 RxfRqoZC9JzO; Wed, 22 Sep 2010 10:58:24 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id F41613A685B; Wed, 22 Sep 2010 10:58:23 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 361F640074; Wed, 22 Sep 2010 12:03:45 -0600 (MDT) Message-ID: <4C9A43D9.6060809@stpeter.im> Date: Wed, 22 Sep 2010 11:58:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Paul Hoffman References: <4C9A2D12.3020409@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefan Santesson , IETF cert-based identity , ietf@ietf.org, tls@ietf.org Subject: Re: [certid] Why require EKU for certid? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 17:58:25 -0000 On 9/22/10 10:44 AM, Paul Hoffman wrote: > At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>> General: I would consider stating that server certificates >>> according to this profile either MUST or SHOULD have the >>> serverAuth EKU set since it is allways related to the use of TSL >>> and server authentication. At least it MUST be set when allowing >>> checks of the CN-ID (see 2.3 below). >> >> Jeff and I are still discussing this topic and do not yet have >> editorial agreement about how to proceed. > > This is not editorial, this is definitely technical. Sorry, by "editorial agreement" I meant consensus between the document editors about how we think it's best to address the issue that Stefan raised. Jeff and I have discussed many of the issues that have been raised, but haven't yet had a chance to discuss this one. > What possible > advantage is there to making certificates that do not have this flag > set be excluded from the practices you are defining? That is, if a > TLS client gets a certificate from a TLS server that the TLS server > says is its authentication certificate, why should the client care > whether or not that flag is set? That flag is an assertion from the > CA, not from the server who is authenticating. > >>> 2.3 It would be good if we could restrict the use of CN-ID for >>> storing a domain name to the case when the serverAuth EKU is set. >>> Requiring the EKU reduce the probability that the CN-ID appears >>> to be a domain name by accident or is a domain name in the wrong >>> context. > > That makes no sense from an operational standpoint. The inclusion of > an EKU has nothing to do with the decision-making for the domain name > location. > >>> In many deployments, this also affects the name constraints >>> processing to perform domain name constraints also on the CN >>> attribute. > > True, and irrelevant. > >>> There should at least be a rule stating that any client that >>> accepts the CN attribute to carry the domain name MUST also >>> perform name constraints on this attribute using the domain name >>> logic if name constraints is applied to the path. Failing this >>> requirement poses a security threat if the claimed domain name in >>> CN-ID violated the name constraints set for domain names. > > Fully disagree. Thanks for your input. Our little editors team will take your comments under advisement during our discussion of this open issue. :) Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba@gmail.com Wed Sep 22 09:34:26 2010 Return-Path: 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 6651E3A69CA; Wed, 22 Sep 2010 09:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599] 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 v1lQUfhiQqla; Wed, 22 Sep 2010 09:34:23 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 609F43A6900; Wed, 22 Sep 2010 09:34:23 -0700 (PDT) Received: by gya1 with SMTP id 1so2089gya.31 for ; Wed, 22 Sep 2010 09:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+COdUx65lKGmMyU4EmpsPQmZQuFbOIB4l81+6dA7Mbg=; b=B4t2onz7GT8Nf5QGYObGs2yY4/h6PJwj88DrvmtGtSD29j5o9hmtlv/b04ZeMzHgUQ g42ZMXgzWG0wQiLqgvkn5eaPLugqu00RW0aL0VMED205uq2YKdjCoBLhXlNOkmC+MIx0 A3mxZ56DonCupjYZ4oWOaxC5S0Xthy20+gDjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tmktZyA3BwO/yYq4VxKdvPRM16+pSgfhE2IzaaolAbZBHog/v6AO9U43VyL/IOMnvl LlxD4TRasPoWQKJXDDPGkQPq+M8sRBnUAXjmEFC4Wtvq6RQNq2qLQEowxpN3sLg4BlyV e390dJltidgfcqzDBxZjHFcxYOr5rAquNKUGg= MIME-Version: 1.0 Received: by 10.150.217.9 with SMTP id p9mr1441203ybg.80.1285173290320; Wed, 22 Sep 2010 09:34:50 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.199.66 with HTTP; Wed, 22 Sep 2010 09:34:50 -0700 (PDT) In-Reply-To: <4C9A27D0.7030909@stpeter.im> References: <4C9A27D0.7030909@stpeter.im> Date: Wed, 22 Sep 2010 12:34:50 -0400 X-Google-Sender-Auth: kupZ6sAWANBwT_q5CpOlf5olsQ4 Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 22 Sep 2010 11:02:19 -0700 Cc: IETF discussion list , IETF cert-based identity , tls@ietf.org, secdir@ietf.org Subject: Re: [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 16:34:26 -0000 Hi, Peter. Thanks for the response, and I'm very happy with nearly all the changes you've adopted. I'll not quote and comment on it all, except to make the general statement: Great work! >> I'd also like to take the security note from section 4.3 and echo it >> here. =A0So maybe this?: >> >> << The list SHOULD NOT include a CN-ID. =A0If a CN-ID is used despite >> this advice, it MUST be constructed only from the source domain and >> never from a target domain. =A0Further, it MUST NOT be used unless there >> are no other supported identifiers present in the certificate. >> > > The last sentence does not apply in Section 4.2, because that section > concerns construction of the list of reference identifiers and as stated > above the client needs to do so without being influenced by the contents > of the certificate presented by the server. I see your point, and I agree. Still, it might be useful at this point to explain WHY the list SHOULD NOT include a CN-ID. I'll leave it there, with no further argument... it's certainly explained later, so perhaps that's good enough, and there's no reason to spend further time on this here. > Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if"). > Jeff is a bit uncomfortable with that because CN-ID is such a common > practice, but I'm comfortable with it because of the hypothetical nature > of the recommendation. He will review the earlier discussions on this > topic before we finalize that text. I agree with you, Peter: I think the text is fine as you've given it. > The part of the text that you have not quoted does say that this > practice is typically offered only to advanced users (and I don't think > that Barry's mother counts as an advanced user). True; I'd missed that point, and I'm happy with the newer, scarier text. The only point I still want to push on is this one: >> =A0 =A0When the connecting application is an interactive client, the sou= rce >> =A0 =A0domain name and service type MUST be provided by a human user (e.= g. >> =A0 =A0when specifying the server portion of the user's account name on = the >> =A0 =A0server or when explicitly configuring the client to connect to a >> =A0 =A0particular host or URI as in [SIP-LOC]) and MUST NOT be derived f= rom >> =A0 =A0the user inputs in an automated fashion (e.g., a host name or dom= ain >> =A0 =A0name discovered through DNS resolution of the source domain). =A0= This >> =A0 =A0rule is important because only a match between the user inputs (i= n >> =A0 =A0the form of a reference identifier) and a presented identifier >> =A0 =A0enables the client to be sure that the certificate can legitimate= ly >> =A0 =A0be used to secure the connection. >> >> Does this mean that a client specifically designed for the "gumbo" >> service can't automatically use the service type "gumbo", without the >> user's involvement? =A0Or that a client put out by example.net can't >> assume a host name of services.example.net in the absence of user >> input that says otherwise? > > IMHO that is a matter of user configuration, or user acknowledgement of > a service agreement, so it falls under the text in this I-D about > allowing the client to check the certificate against a DNS domain name > that is explicitly associated with the source domain by means of user > configuration. > >> Further, it's entirely reasonable for a program to have a user enter >> something like "gmail", and have the client turn that into something >> like "mail.google.com", deriving it from the user's input in an >> automated fashion. =A0Do we really want to forbid that sort of thing? > > Yes, we do, because although you happen to "just know" that > mail.google.com is a legitimate DNS domain name to connect to when > interacting with the gmail.com service, Barry's mother might not have > that kind of knowledge and as a general rule it's a very bad idea to > assume that it's just fine to connect to some domain at foo.com when > interacting with a service at bar.com. However, service delegation is a > difficult topic and there are ongoing discussions among various IETF > participants about how to do service delegation securely; one thing I > think we can safely say is that it's not the task of this I-D to solve > the problem of secure service delegation. There's a distinction, here, between a protocol and a user interface for configuration. My mother doesn't know whom to trust, except that she knows that she (at least kinda-sorta) trusts the mail program she's decided to use, and an entity she calls "gmail" (not "google.com", not "gmail.com", but just "gmail"). She's relying to the mail program's "easy configuration feature" to sort this out. The text I reviewed appeared to be saying normative things about what client software MUST and MUST NOT do with regard to this sort of configuration situation, which goes well beyond what the client software is doing on the wire. Unless I'm mis-reading it, it's explicitly saying that my client software is not allowed to do something like this, for example: 1. Ask the user, "What email service do you use?" 2. Receive the answer "gmail" from the user. 3. Auto-configure itself for the known gmail servers based only on that user input. If I am, indeed, misreading it, please tell me... and perhaps tweak the wording to make it less likely that someone else will misread it the same way. Again, this is my only remaining quibble with the document, and, again, it's a very good piece of work. Barry From barryleiba@gmail.com Wed Sep 22 10:44:24 2010 Return-Path: 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 1451C3A6A7E; Wed, 22 Sep 2010 10:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] 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 FaydDdHD0A5m; Wed, 22 Sep 2010 10:44:21 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 614E23A6AD8; Wed, 22 Sep 2010 10:44:20 -0700 (PDT) Received: by gwb20 with SMTP id 20so320168gwb.31 for ; Wed, 22 Sep 2010 10:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=nCDzBiA7DTCSA77b+nmmxHqYPUoVSNqJE7IRZImMnj8=; b=SstImxJEzNh8ZzTmiqfKZpxHYXP9HQ2An96RYLs7wLDfQ+VMpVGmeEDYXC79xa7YC9 TN0YA6TC+1qaA/yQk/G+7AwjWEu5YCzUm12wSqZ4TtWKYz1z83AxndyN3ZCqeUbo9xZF N8rlaazJhvDpmh0/FrWFikOcRkqFnmBLwEyPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=WA7g/yZweoBB4ZYuiwQodCbCGQ01XaEUxsXPOyN2RDjpTQCgg9uDlJs3xerhk3A/Wt nfyld73VJ5o4v7q01rzuuU2grK0eqwoNkhf6cuKCrM5xIzb0R4nSEtjli/2d8JKGjAzU leMtwnaMcuUqwUa6E+ducNKX3uDf2ZBnrhKTI= MIME-Version: 1.0 Received: by 10.150.140.14 with SMTP id n14mr1422108ybd.268.1285177487557; Wed, 22 Sep 2010 10:44:47 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.199.66 with HTTP; Wed, 22 Sep 2010 10:44:47 -0700 (PDT) In-Reply-To: <4C9A3A3B.9090908@stpeter.im> References: <4C912A86.3040402@stpeter.im> <58606B11-D4CC-43F4-8971-90D51780A21B@jpl.nasa.gov> <1284608876.5722.56.camel@mattlaptop2.local> <4C9A3A3B.9090908@stpeter.im> Date: Wed, 22 Sep 2010 13:44:47 -0400 X-Google-Sender-Auth: XnDYq2UStfpt9F1xtclgS3JkVTI Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 22 Sep 2010 11:02:19 -0700 Cc: IETF cert-based identity , tls@ietf.org, IETF discussion list Subject: Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 17:44:24 -0000 >> Tangent: I know we want to avoid implementations that do foolish things >> being claimed as compliant, but IMO, the requirement that input come >> from a "human user" is goofy for a technical specification and in >> practice a non-starter. =A0A web browser that followed a HTTP redirectio= n >> to a https: URL would violate it. =A0The web has evolved toward complex >> applications in which all pretense that the user is mediating the >> issuance of HTTP requests has been abandoned, which brings major >> productivity benefits as well as major security implications; ignoring >> this would be a mistake. > > Wes Hardaker also raised this issue in his review. Jeff and I agree that > this is an open issue and are working to address it. Addressing that would likely satisfy my issue nicely. Barry From stpeter@stpeter.im Wed Sep 22 11:11:19 2010 Return-Path: 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 933A53A6A46; Wed, 22 Sep 2010 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 Tz4ZXrdbYQEv; Wed, 22 Sep 2010 11:11:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7EDF53A6A30; Wed, 22 Sep 2010 11:11:17 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 577D540074; Wed, 22 Sep 2010 12:16:38 -0600 (MDT) Message-ID: <4C9A46DD.7010502@stpeter.im> Date: Wed, 22 Sep 2010 12:11:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Barry Leiba References: <4C9A27D0.7030909@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF discussion list , IETF cert-based identity , tls@ietf.org, secdir@ietf.org Subject: Re: [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:11:19 -0000 On 9/22/10 10:34 AM, Barry Leiba wrote: > Hi, Peter. Thanks for the response, and I'm very happy with nearly > all the changes you've adopted. I'll not quote and comment on it all, > except to make the general statement: Great work! Thanks! Comments inline. >>> I'd also like to take the security note from section 4.3 and echo it >>> here. So maybe this?: >>> >>> << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite >>> this advice, it MUST be constructed only from the source domain and >>> never from a target domain. Further, it MUST NOT be used unless there >>> are no other supported identifiers present in the certificate. >> >> >> The last sentence does not apply in Section 4.2, because that section >> concerns construction of the list of reference identifiers and as stated >> above the client needs to do so without being influenced by the contents >> of the certificate presented by the server. > > I see your point, and I agree. > Still, it might be useful at this point to explain WHY the list SHOULD > NOT include a CN-ID. I'll leave it there, with no further argument... > it's certainly explained later, so perhaps that's good enough, and > there's no reason to spend further time on this here. You're right, it's not good to baldly state this SHOULD NOT without justification. We'll work to propose appropriate text. >> Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if"). >> Jeff is a bit uncomfortable with that because CN-ID is such a common >> practice, but I'm comfortable with it because of the hypothetical nature >> of the recommendation. He will review the earlier discussions on this >> topic before we finalize that text. > > I agree with you, Peter: I think the text is fine as you've given it. > >> The part of the text that you have not quoted does say that this >> practice is typically offered only to advanced users (and I don't think >> that Barry's mother counts as an advanced user). > > True; I'd missed that point, and I'm happy with the newer, scarier text. In this context, scary is good. :) > The only point I still want to push on is this one: > >>> 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. >>> >>> Does this mean that a client specifically designed for the "gumbo" >>> service can't automatically use the service type "gumbo", without the >>> user's involvement? Or that a client put out by example.net can't >>> assume a host name of services.example.net in the absence of user >>> input that says otherwise? >> >> IMHO that is a matter of user configuration, or user acknowledgement of >> a service agreement, so it falls under the text in this I-D about >> allowing the client to check the certificate against a DNS domain name >> that is explicitly associated with the source domain by means of user >> configuration. >> >>> Further, it's entirely reasonable for a program to have a user enter >>> something like "gmail", and have the client turn that into something >>> like "mail.google.com", deriving it from the user's input in an >>> automated fashion. Do we really want to forbid that sort of thing? >> >> Yes, we do, because although you happen to "just know" that >> mail.google.com is a legitimate DNS domain name to connect to when >> interacting with the gmail.com service, Barry's mother might not have >> that kind of knowledge and as a general rule it's a very bad idea to >> assume that it's just fine to connect to some domain at foo.com when >> interacting with a service at bar.com. However, service delegation is a >> difficult topic and there are ongoing discussions among various IETF >> participants about how to do service delegation securely; one thing I >> think we can safely say is that it's not the task of this I-D to solve >> the problem of secure service delegation. > > There's a distinction, here, between a protocol and a user interface > for configuration. My mother doesn't know whom to trust, except that > she knows that she (at least kinda-sorta) trusts the mail program > she's decided to use, and an entity she calls "gmail" (not > "google.com", not "gmail.com", but just "gmail"). She's relying to > the mail program's "easy configuration feature" to sort this out. > > The text I reviewed appeared to be saying normative things about what > client software MUST and MUST NOT do with regard to this sort of > configuration situation, which goes well beyond what the client > software is doing on the wire. Unless I'm mis-reading it, it's > explicitly saying that my client software is not allowed to do > something like this, for example: > 1. Ask the user, "What email service do you use?" > 2. Receive the answer "gmail" from the user. > 3. Auto-configure itself for the known gmail servers based only on > that user input. > > If I am, indeed, misreading it, please tell me... and perhaps tweak > the wording to make it less likely that someone else will misread it > the same way. > > Again, this is my only remaining quibble with the document, and, > again, it's a very good piece of work. Aha, thanks for the more detailed description of the scenario you had in mind. I see your point. We certainly don't mean the recommendations in this document to make life more difficult for your mother as she interacts with her auto-configuring email client! Off the top of my head I don't have a proposed solution, but I have added this to the list of open issues that Jeff and I need to discuss, and we'll be back with proposed text just as soon as we're able. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 11:13:32 2010 Return-Path: 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 6F4DA3A6ABC; Wed, 22 Sep 2010 11:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 qLy5VWFc+Alc; Wed, 22 Sep 2010 11:13:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3AD193A6A30; Wed, 22 Sep 2010 11:13:29 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E3DE40074; Wed, 22 Sep 2010 12:18:50 -0600 (MDT) Message-ID: <4C9A4762.6090100@stpeter.im> Date: Wed, 22 Sep 2010 12:13:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> <4C9A428C.2030807@stpeter.im> <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu> In-Reply-To: <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, barryleiba@computer.org, IETF cert-based identity , tls@ietf.org, secdir@ietf.org Subject: Re: [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:13:32 -0000 On 9/22/10 12:07 PM, Jeffrey Hutzelman wrote: > --On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre > wrote: > >>> The second issue is the advice that the user should be allowed to accept >>> a certificate with a mismatched name only on a temporary basis. This is >>> almost certain to be the wrong thing to do; if a name mismatch is >>> acceptable, it's also not likely to change anytime soon, and requiring >>> the user to accept the certificate again in a later session just because >>> the client has restarted is just annoying with no security benefit. >> >> That's an interesting point. In feedback we received from implementers >> of interactive user agents (most browsers), we heard that at least some >> user agents do enforce a distinction between accepting an identity >> mismatch temporarily and accepting it permenantly. The security >> properties of that distinction did not come up in previous mailing list >> threads about this I-D, but your editorial team will do a bit more >> research and might return with proposed text changes. > > I have no issue with making that distinction, and indeed, many existing > user agents do so. I take issue only with the argument that user agents > should disallow the "permanent" option in the name of "security", when > doing so is in fact counterproductive. I had not previously considered the point, but I think you're right. >>> I think the advice in this paragraph is a little over-restrictive. What >>> should be prohibited is not automated rewriting, but automated rewriting >>> based on the use of insecure sources. RFC4120 has the following to say >>> on this subject, as it relates to Kerberos: >>> >>> >>> One can also rely on trusted third parties to make this >>> determination, but only when the data obtained from the third party >>> is suitably integrity-protected while resident on the third-party >>> server and when transmitted. Thus, for example, one should not rely >>> on an unprotected DNS record to map a host alias to the primary name >>> of a server, accepting the primary name as the party that one intends >>> to contact, since an attacker can modify the mapping and impersonate >>> the party. >> >> Thanks for the pointer to RFC 4120. We're looking into how to >> appropriate reference that in the next version of this spec. > > I'm not sure a reference is the best approach, since in fact we're not > talking here about Kerberos and that might just be confusing. But > borrowing some of the language might be appropriate. Yes, that's what I meant -- we shall probably engage in some creative borrowing of the concept, which might be worded similarly or differently (that's yet to be determined). Peter -- Peter Saint-Andre https://stpeter.im/ From jhutz@cmu.edu Wed Sep 22 11:07:04 2010 Return-Path: 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 191993A67D4; Wed, 22 Sep 2010 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ZvcP5ctfuFE6; Wed, 22 Sep 2010 11:07:03 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id D2D9B3A6A70; Wed, 22 Sep 2010 11:07:02 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8MI7SjV015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 14:07:28 -0400 (EDT) Date: Wed, 22 Sep 2010 14:07:28 -0400 From: Jeffrey Hutzelman To: Peter Saint-Andre Message-ID: <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu> In-Reply-To: <4C9A428C.2030807@stpeter.im> References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> <4C9A428C.2030807@stpeter.im> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 X-Mailman-Approved-At: Wed, 22 Sep 2010 11:14:11 -0700 Cc: secdir@ietf.org, IETF cert-based identity , tls@ietf.org, iesg@ietf.org, barryleiba@computer.org, jhutz@cmu.edu Subject: Re: [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:07:04 -0000 --On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre wrote: >> The second issue is the advice that the user should be allowed to accept >> a certificate with a mismatched name only on a temporary basis. This is >> almost certain to be the wrong thing to do; if a name mismatch is >> acceptable, it's also not likely to change anytime soon, and requiring >> the user to accept the certificate again in a later session just because >> the client has restarted is just annoying with no security benefit. > > That's an interesting point. In feedback we received from implementers > of interactive user agents (most browsers), we heard that at least some > user agents do enforce a distinction between accepting an identity > mismatch temporarily and accepting it permenantly. The security > properties of that distinction did not come up in previous mailing list > threads about this I-D, but your editorial team will do a bit more > research and might return with proposed text changes. I have no issue with making that distinction, and indeed, many existing user agents do so. I take issue only with the argument that user agents should disallow the "permanent" option in the name of "security", when doing so is in fact counterproductive. >> I think the advice in this paragraph is a little over-restrictive. What >> should be prohibited is not automated rewriting, but automated rewriting >> based on the use of insecure sources. RFC4120 has the following to say >> on this subject, as it relates to Kerberos: >> >> >> One can also rely on trusted third parties to make this >> determination, but only when the data obtained from the third party >> is suitably integrity-protected while resident on the third-party >> server and when transmitted. Thus, for example, one should not rely >> on an unprotected DNS record to map a host alias to the primary name >> of a server, accepting the primary name as the party that one intends >> to contact, since an attacker can modify the mapping and impersonate >> the party. > > Thanks for the pointer to RFC 4120. We're looking into how to > appropriate reference that in the next version of this spec. I'm not sure a reference is the best approach, since in fact we're not talking here about Kerberos and that might just be confusing. But borrowing some of the language might be appropriate. -- Jeff From jhutz@cmu.edu Wed Sep 22 11:13:43 2010 Return-Path: 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 ADA9028C126; Wed, 22 Sep 2010 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zT1SpgyfQVLa; Wed, 22 Sep 2010 11:13:40 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 2649728C121; Wed, 22 Sep 2010 11:13:40 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8MIE1nW000952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 14:14:01 -0400 (EDT) Date: Wed, 22 Sep 2010 14:14:01 -0400 From: Jeffrey Hutzelman To: Barry Leiba , Peter Saint-Andre Message-ID: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> In-Reply-To: <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 X-Mailman-Approved-At: Wed, 22 Sep 2010 11:14:11 -0700 Cc: jhutz@cmu.edu, secdir@ietf.org, IETF cert-based identity , IETF discussion list , tls@ietf.org Subject: Re: [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:13:44 -0000 --On Wednesday, September 22, 2010 12:34:50 PM -0400 Barry Leiba wrote: > There's a distinction, here, between a protocol and a user interface > for configuration. My mother doesn't know whom to trust, except that > she knows that she (at least kinda-sorta) trusts the mail program > she's decided to use, and an entity she calls "gmail" (not > "google.com", not "gmail.com", but just "gmail"). She's relying to > the mail program's "easy configuration feature" to sort this out. > > The text I reviewed appeared to be saying normative things about what > client software MUST and MUST NOT do with regard to this sort of > configuration situation, which goes well beyond what the client > software is doing on the wire. Unless I'm mis-reading it, it's > explicitly saying that my client software is not allowed to do > something like this, for example: > 1. Ask the user, "What email service do you use?" > 2. Receive the answer "gmail" from the user. > 3. Auto-configure itself for the known gmail servers based only on > that user input. I think that's reasonable behavior _if_ the mail client knows that "gmail" is "mail.google.com". What's _not_ reasonable is for it to arbitrarily transform "gmail" into a domain by adding ".com", then look up "gmail.com" and see that it is an alias for "mail.google.com" and not only follow the (insecure) alias to mail.google.com but also use it to decide that "mail.google.com" is an appropriate name to find in a certificate. If your mother's mail client does that, then all I have to do to steal her password is convince said client that "gmail.com" is actually an alias for "stealgmailpassword.attacker.org". From stpeter@stpeter.im Wed Sep 22 11:18:28 2010 Return-Path: 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 963D73A6A58; Wed, 22 Sep 2010 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 xN7CQuKlMNM9; Wed, 22 Sep 2010 11:18:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 771133A6A30; Wed, 22 Sep 2010 11:18:27 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C397140074; Wed, 22 Sep 2010 12:23:48 -0600 (MDT) Message-ID: <4C9A488D.20705@stpeter.im> Date: Wed, 22 Sep 2010 12:18:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jeffrey Hutzelman References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> In-Reply-To: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity , secdir@ietf.org, Barry Leiba , IETF discussion list , tls@ietf.org Subject: Re: [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:18:28 -0000 On 9/22/10 12:14 PM, Jeffrey Hutzelman wrote: > --On Wednesday, September 22, 2010 12:34:50 PM -0400 Barry Leiba > wrote: > >> There's a distinction, here, between a protocol and a user interface >> for configuration. My mother doesn't know whom to trust, except that >> she knows that she (at least kinda-sorta) trusts the mail program >> she's decided to use, and an entity she calls "gmail" (not >> "google.com", not "gmail.com", but just "gmail"). She's relying to >> the mail program's "easy configuration feature" to sort this out. >> >> The text I reviewed appeared to be saying normative things about what >> client software MUST and MUST NOT do with regard to this sort of >> configuration situation, which goes well beyond what the client >> software is doing on the wire. Unless I'm mis-reading it, it's >> explicitly saying that my client software is not allowed to do >> something like this, for example: >> 1. Ask the user, "What email service do you use?" >> 2. Receive the answer "gmail" from the user. >> 3. Auto-configure itself for the known gmail servers based only on >> that user input. > > I think that's reasonable behavior _if_ the mail client knows that > "gmail" is "mail.google.com". What's _not_ reasonable is for it to > arbitrarily transform "gmail" into a domain by adding ".com", then look > up "gmail.com" and see that it is an alias for "mail.google.com" and not > only follow the (insecure) alias to mail.google.com but also use it to > decide that "mail.google.com" is an appropriate name to find in a > certificate. > > If your mother's mail client does that, then all I have to do to steal > her password is convince said client that "gmail.com" is actually an > alias for "stealgmailpassword.attacker.org". In my experience, some user agents have interface elements such as a drop-down box that lists popular service providers, and the account configuration wizard behaves differently (e.g., asks for different information) depending on which popular service provider the user chooses. Peter -- Peter Saint-Andre https://stpeter.im/ From ark@eltex.net Wed Sep 22 11:31:26 2010 Return-Path: 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 73A453A6A92; Wed, 22 Sep 2010 11:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 lInLHlAxs-2l; Wed, 22 Sep 2010 11:31:25 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id DC8803A6A8E; Wed, 22 Sep 2010 11:31:24 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o8MIVhb2011722; Wed, 22 Sep 2010 22:31:43 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o8MIVhdV008046; Wed, 22 Sep 2010 22:31:43 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Wed, 22 Sep 2010 22:31:43 +0400 From: ArkanoiD To: Jeffrey Hutzelman Message-ID: <20100922183143.GA23200@eltex.net> References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org Subject: Re: [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:31:26 -0000 BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate for mail.google.com. But i've yet to see any web browser to complain! Where is the magic? From marsh@extendedsubset.com Wed Sep 22 12:37:33 2010 Return-Path: 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 7DDEB3A69A8; Wed, 22 Sep 2010 12:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.468 X-Spam-Level: *** X-Spam-Status: No, score=3.468 tagged_above=-999 required=5 tests=[AWL=-5.093, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, SARE_URI_EQUALS=1.666] 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 SMS6iU9eKXOT; Wed, 22 Sep 2010 12:37:32 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id CA5183A697E; Wed, 22 Sep 2010 12:37:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1OyV8e-000FOA-LT; Wed, 22 Sep 2010 19:37:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4F2C3601B; Wed, 22 Sep 2010 19:37:54 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/McQjaZjnfhlHi92k0Dhlm/+vqXeVrxMo= Message-ID: <4C9A5B13.1040802@extendedsubset.com> Date: Wed, 22 Sep 2010 14:37:55 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: ArkanoiD References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> In-Reply-To: <20100922183143.GA23200@eltex.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Sep 2010 13:11:17 -0700 Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, Jeffrey Hutzelman Subject: Re: [certid] [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 19:37:33 -0000 On 09/22/2010 01:31 PM, ArkanoiD wrote: > BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate > for mail.google.com. But i've yet to see any web browser to complain! Where is the magic? Seems totally relevant to me. Going to https://gmail.com/ I get some kind of redirection to https://www.google.com/accounts/ServiceLogin... I can confirm the silent redirect behavior on FF, an associate reports it on IE9. I tried IE8 but get the expected "cert was issued for a different website's address" error. Hopefully I'm overlooking something simple, but at first glance it would seem like either of these two conditions are true: 1. Multiple vendors are putting some kind of override table in their browsers with an entry for gmail.com. 2. Browsers are running script from badly authenticated sources. So what does gmail.com have in this situation that an attacker couldn't obtain for phonygmail.com? - Marsh marsh@lamb:/tmp$ dig -t any gmail.com ; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;gmail.com. IN ANY ;; ANSWER SECTION: gmail.com. 300 IN A 74.125.227.22 gmail.com. 300 IN A 74.125.227.21 gmail.com. 300 IN A 74.125.227.24 gmail.com. 300 IN A 74.125.227.23 gmail.com. 86400 IN NS ns4.google.com. gmail.com. 86400 IN NS ns1.google.com. gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 1427981 21600 3600 1209600 300 gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" ;; ADDITIONAL SECTION: ns4.google.com. 85092 IN A 216.239.38.10 ns1.google.com. 85092 IN A 216.239.32.10 ;; Query time: 54 msec ;; SERVER: 192.168.1.3#53(192.168.1.3) ;; WHEN: Wed Sep 22 14:26:29 2010 ;; MSG SIZE rcvd: 330 marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 ... subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA ... --- GET / HTTP/1.0 HTTP/1.0 200 OK Date: Wed, 22 Sep 2010 19:31:43 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Set-Cookie: PREF=ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com Set-Cookie: NID=39=nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i-CvhRU1DrDDYvExygPnpew69GRLaWZeI0; expires=Thu, 24-Mar-2011 19:31:43 GMT; path=/; domain=.google.com; HttpOnly Server: gws X-XSS-Protection: 1; mode=block Google


Go to classic Google.
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 D89D83A685B; Wed, 22 Sep 2010 12:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.56 X-Spam-Level: *** X-Spam-Status: No, score=3.56 tagged_above=-999 required=5 tests=[AWL=-4.401, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, SARE_URI_EQUALS=1.666] 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 jYA6RkyatneU; Wed, 22 Sep 2010 12:42:39 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 075393A6B41; Wed, 22 Sep 2010 12:42:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mRjYM1wYA7MobX4v6rYGypyk4Zaeg2A5fscVcTwbPKUfyOK9emxCOu44dYnFq6E5; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OyVDd-00018h-Fk; Wed, 22 Sep 2010 15:43:05 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 22 Sep 2010 15:43:05 -0400 Message-ID: <20847695.1285184585494.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Wed, 22 Sep 2010 14:43:05 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Marsh Ray , ArkanoiD Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b06bb0baee4cfae0c770b9a8809f9c8b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 X-Mailman-Approved-At: Wed, 22 Sep 2010 13:11:17 -0700 Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, Jeffrey Hutzelman Subject: Re: [certid] [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 19:42:41 -0000 Marsh and all, Thanks for confirming what I have seen far to often in respect to gmail.com. -----Original Message----- >From: Marsh Ray >Sent: Sep 22, 2010 2:37 PM >To: ArkanoiD >Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, Jeffrey Hutzelman >Subject: Re: [TLS] [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 > >On 09/22/2010 01:31 PM, ArkanoiD wrote: >> BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate >> for mail.google.com. But i've yet to see any web browser to complain! Where is the magic? > >Seems totally relevant to me. > >Going to https://gmail.com/ I get some kind of redirection to >https://www.google.com/accounts/ServiceLogin... > >I can confirm the silent redirect behavior on FF, an associate reports >it on IE9. I tried IE8 but get the expected "cert was issued for a >different website's address" error. > >Hopefully I'm overlooking something simple, but at first glance it would >seem like either of these two conditions are true: > >1. Multiple vendors are putting some kind of override table in their >browsers with an entry for gmail.com. > >2. Browsers are running script from badly authenticated sources. > >So what does gmail.com have in this situation that an attacker couldn't >obtain for phonygmail.com? > >- Marsh > > >marsh@lamb:/tmp$ dig -t any gmail.com > >; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091 >;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2 > >;; QUESTION SECTION: >;gmail.com. IN ANY > >;; ANSWER SECTION: >gmail.com. 300 IN A 74.125.227.22 >gmail.com. 300 IN A 74.125.227.21 >gmail.com. 300 IN A 74.125.227.24 >gmail.com. 300 IN A 74.125.227.23 >gmail.com. 86400 IN NS ns4.google.com. >gmail.com. 86400 IN NS ns1.google.com. >gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 1427981 >21600 3600 1209600 300 >gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. >gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. >gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. >gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" > >;; ADDITIONAL SECTION: >ns4.google.com. 85092 IN A 216.239.38.10 >ns1.google.com. 85092 IN A 216.239.32.10 > >;; Query time: 54 msec >;; SERVER: 192.168.1.3#53(192.168.1.3) >;; WHEN: Wed Sep 22 14:26:29 2010 >;; MSG SIZE rcvd: 330 > > > >marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 >... >subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com >issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >... >--- >GET / HTTP/1.0 > >HTTP/1.0 200 OK >Date: Wed, 22 Sep 2010 19:31:43 GMT >Expires: -1 >Cache-Control: private, max-age=0 >Content-Type: text/html; charset=ISO-8859-1 >Set-Cookie: >PREF=ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; >expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com >Set-Cookie: >NID=39=nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i-CvhRU1DrDDYvExygPnpew69GRLaWZeI0; >expires=Thu, 24-Mar-2011 19:31:43 GMT; path=/; domain=.google.com; HttpOnly >Server: gws >X-XSS-Protection: 1; mode=block > >content="text/html; >charset=ISO-8859-1">Googlebgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000 >onload="document.f.q.focus();if(document.images)new >Image().src='/images/srpr/nav_logo14.png'" >

id=lgpd>
height=110 border=0>
Go to href="http://www.google.com/">classic Google.action="/search" name=f>
>_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From marsh@extendedsubset.com Wed Sep 22 12:57:08 2010 Return-Path: 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 933FF3A6A3F; Wed, 22 Sep 2010 12:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599] 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 nJ9EcCwK8bNJ; Wed, 22 Sep 2010 12:57:05 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6C5CD3A685B; Wed, 22 Sep 2010 12:57:05 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1OyVRa-000AJk-7L; Wed, 22 Sep 2010 19:57:30 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 632806018; Wed, 22 Sep 2010 19:57:27 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19oex24i/q18w/PsQMTFPY8Pp08N9CCoTs= Message-ID: <4C9A5FA8.7050605@extendedsubset.com> Date: Wed, 22 Sep 2010 14:57:28 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: ArkanoiD References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> <4C9A5B13.1040802@extendedsubset.com> In-Reply-To: <4C9A5B13.1040802@extendedsubset.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Sep 2010 13:11:18 -0700 Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, Jeffrey Hutzelman Subject: Re: [certid] [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 19:57:08 -0000 On 09/22/2010 01:31 PM, ArkanoiD wrote: > BTW, slightly offtopic here: whenever i connect to gmail.com, i get > certificate for mail.google.com. But i've yet to see any web browser > to complain! Where is the magic? On 09/22/2010 02:37 PM, Marsh Ray wrote: > > Hopefully I'm overlooking something simple, but at first glance it would > seem like either of these two conditions are true: > > 1. Multiple vendors are putting some kind of override table in their > browsers with an entry for gmail.com. This search http://mxr.mozilla.org/mozilla1.9.2/search?string=[^%40]gmail.com®exp=1&hitlimit=&tree=mozilla1.9.2 Doesn't return any hits. That search page is a little tricky though. It kept wanting to change my "^@" to "\0"! :-) Which suggests that: > 2. Browsers are running script from badly authenticated sources. - Marsh From mrex@sap.com Wed Sep 22 14:20:09 2010 Return-Path: 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 17EA728C10E for ; Wed, 22 Sep 2010 14:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.155 X-Spam-Level: X-Spam-Status: No, score=-8.155 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 RYduGiskzQRN for ; Wed, 22 Sep 2010 14:20:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B8F7728C0EE for ; Wed, 22 Sep 2010 14:20:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8MLKSAK022441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Sep 2010 23:20:33 +0200 (MEST) From: Martin Rex Message-Id: <201009222120.o8MLKS7H005526@fs4113.wdf.sap.corp> Orig-To: marsh@extendedsubset.com (Marsh Ray) To: certid@ietf.org Date: Wed, 22 Sep 2010 23:17:58 +0200 (MEST) In-Reply-To: <4C9A5B13.1040802@extendedsubset.com> from "Marsh Ray" at Sep 22, 10 02:37:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: mrex@sap.com X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org, tls@ietf.org Subject: Re: [certid] [TLS] [secdir] secdir X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 21:20:09 -0000 Marsh Ray wrote: > > On 09/22/2010 01:31 PM, ArkanoiD wrote: > > BTW, slightly offtopic here: whenever i connect to gmail.com, > > i get certificate for mail.google.com. > > But i've yet to see any web browser to complain! Where is the magic? > > Seems totally relevant to me. > > Going to https://gmail.com/ I get some kind of redirection to > https://www.google.com/accounts/ServiceLogin... When I check https://gmail.com/ with my own command line tool (which doesn't send TLS extension SNI) I get back a cert with only a CN-ID for mail.google.com and no DNS-IDs along with a certificat mismatch error from my tool. When I trace a FF connect to https://gmail.com/ I see that FF sends TLS extension SNI and the server returns a server certificate with a CN-ID for gmail.com (again no DNS-IDs). > > marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 > ... > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com > issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA Maybe the openssl s_client (at least the one that you are using or in the fashion that you are using it) does not send TLS extension SNI ? I'm confused about the IE8 vs. IE9 behaviour that you report-- could it be that for your IE8 is running on a platform that does not implement TLS extensions (XP,2003) or has the TLSv1.x protocols disabled for some reason? -Martin From hotz@jpl.nasa.gov Wed Sep 22 15:10:54 2010 Return-Path: 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 474B128C13A; Wed, 22 Sep 2010 15:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mMoeWsCMfGgr; Wed, 22 Sep 2010 15:10:51 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by core3.amsl.com (Postfix) with ESMTP id 2F99328C12C; Wed, 22 Sep 2010 15:10:51 -0700 (PDT) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8MMBGxu000831 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Wed, 22 Sep 2010 15:11:17 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <4C9A382F.80501@stpeter.im> Date: Wed, 22 Sep 2010 15:11:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <52B5123E-208D-44B6-BB95-92D5B44D4654@jpl.nasa.gov> References: <4C9A382F.80501@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1081) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized Cc: "ietf@ietf.org" , "certid@ietf.org" , "tls@ietf.org" , Wes Hardaker Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 22:10:54 -0000 On Sep 22, 2010, at 10:09 AM, Peter Saint-Andre wrote: > 2. A human user has explicitly agreed to trust a service that > provides mappings of source domains to target domains, such as a > dedicated discovery service or an identity service that securely > redirects requests from the source domain to a target domain > (however, such an arrangement is not encouraged and if a client > supports such a service then it needs to disable it by default > and carefully warn the user about the possible negative > consequences of trusting such a service). Pure wordsmithing. Make sure this still says what you want: 2. A human user has explicitly agreed to trust a service that provides = mapping of source domains to target domains. For example the user may = trust a dedicated discovery service or identity service that securely = redirects requests from the source to a target domain. =20 Such an arrangement is not encouraged. If a client supports such a = service then it needs to disable it by default, and it MUST carefully = warn the user about the possible negative consequences of trusting such = a service. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From mrex@sap.com Wed Sep 22 18:47:49 2010 Return-Path: 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 F417B3A6876; Wed, 22 Sep 2010 18:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.792 X-Spam-Level: X-Spam-Status: No, score=-9.792 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 kuIRTTzdRQT6; Wed, 22 Sep 2010 18:47:48 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id B7B343A6827; Wed, 22 Sep 2010 18:47:47 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8N1mANw024380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Sep 2010 03:48:10 +0200 (MEST) From: Martin Rex Message-Id: <201009230148.o8N1m825020375@fs4113.wdf.sap.corp> To: hotz@jpl.nasa.gov (Henry B. Hotz) Date: Thu, 23 Sep 2010 03:48:08 +0200 (MEST) In-Reply-To: <52B5123E-208D-44B6-BB95-92D5B44D4654@jpl.nasa.gov> from "Henry B. Hotz" at Sep 22, 10 03:11:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: wjhns1@hardakers.net, certid@ietf.org, ietf@ietf.org, tls@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 01:47:49 -0000 Henry B. Hotz wrote: > > [...] For example the user may trust a dedicated discovery service > or identity service that securely redirects requests from the source > to a target domain. Thinking about it, I feel slightly uneasy about some redirects, such as https://gmail.com -> 301 -> https://mail.google.com/mail I think these should never go without a warning. If my banks online-banking portal (https://www..de) would suddently redirect me to https://www..com before asking me for credentials and transaction authorization codes, that would be a real security problem, because www..com is not leased by my bank (it is apparently not currently leased to anyone) A hacker that breaks into a web-site in order to do trap victims might be less easily detected if he doesn't subvert the entire site and tries to send collected data to external places, but instead puts redirects into place that browsers will blindly and silently follow, maybe additionally filtering the clients that will be redirected based on their origin, so that the helpdesk and security guys can not immediately repro it with their browsers. Should a users decision to trust a particular service with a particular issue always imply that this particular service is a fully trusted naming service (i.e. one that performs secure name transformations)? -Martin From ietf@augustcellars.com Wed Sep 22 19:28:38 2010 Return-Path: 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 0455D3A6A64; Wed, 22 Sep 2010 19:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PBrepEOUvQ4B; Wed, 22 Sep 2010 19:28:37 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 019F33A6A2D; Wed, 22 Sep 2010 19:28:37 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 9EC3D6A423; Wed, 22 Sep 2010 19:29:04 -0700 (PDT) From: "Jim Schaad" To: "'Paul Hoffman'" , "'Peter Saint-Andre'" , "'Stefan Santesson'" References: <4C9A2D12.3020409@stpeter.im> In-Reply-To: Date: Wed, 22 Sep 2010 19:36:20 -0700 Message-ID: <001301cb5ac8$1d01fe20$5705fa60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQD4cSCKDZYsaq0DFZ4yur+K64x8SgEr1WV4AyGf4EKUokHOsA== Content-Language: en-us X-Mailman-Approved-At: Thu, 23 Sep 2010 08:33:42 -0700 Cc: 'IETF cert-based identity' , ietf@ietf.org, tls@ietf.org Subject: Re: [certid] [TLS] Why require EKU for certid? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 02:28:38 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul > Hoffman > Sent: Wednesday, September 22, 2010 9:44 AM > To: Peter Saint-Andre; Stefan Santesson > Cc: IETF cert-based identity; ietf@ietf.org; tls@ietf.org > Subject: [TLS] Why require EKU for certid? > > At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: > >On 9/14/10 12:51 AM, Stefan Santesson wrote: > > > General: > >> I would consider stating that server certificates according to this > >> profile either MUST or SHOULD have the serverAuth EKU set since it is > >> allways related to the use of TSL and server authentication. At least > >> it MUST be set when allowing checks of the CN-ID (see 2.3 below). > > > >Jeff and I are still discussing this topic and do not yet have > >editorial agreement about how to proceed. > > This is not editorial, this is definitely technical. What possible advantage is > there to making certificates that do not have this flag set be excluded from the > practices you are defining? That is, if a TLS client gets a certificate from a TLS > server that the TLS server says is its authentication certificate, why should the > client care whether or not that flag is set? That flag is an assertion from the CA, > not from the server who is authenticating. > > > > 2.3 > > > It would be good if we could restrict the use of CN-ID for storing a > > > domain name to the case when the serverAuth EKU is set. Requiring > > > the EKU reduce the probability that the CN-ID appears to be a domain > > > name by accident or is a domain name in the wrong context. > > That makes no sense from an operational standpoint. The inclusion of an EKU > has nothing to do with the decision-making for the domain name location. > > > > In many deployments, this also affects the name constraints > > > processing to > >> perform domain name constraints also on the CN attribute. > > True, and irrelevant. > > > > There should at least be a rule stating that any client that accepts > > > the CN > >> attribute to carry the domain name MUST also perform name constraints > >> on this attribute using the domain name logic if name constraints is > >> applied to the path. Failing this requirement poses a security threat > >> if the claimed domain name in CN-ID violated the name constraints set for > domain names. > > Fully disagree. I also agree that this is not something that I would ever like to see as a required element. Applying name constraint logic in places that it should not be performed is something that is very hard on any certificate evaluation logic. I think it would be much more an issue of "asking" CAs not to issue certificates that have this characteristic. Jim > > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From marsh@extendedsubset.com Thu Sep 23 08:56:49 2010 Return-Path: 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 DFA543A6B0E; Thu, 23 Sep 2010 08:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599] 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 ZPvoH0LItmOd; Thu, 23 Sep 2010 08:56:49 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 73DC83A698F; Thu, 23 Sep 2010 08:56:48 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1OyoAf-000NXC-Pd; Thu, 23 Sep 2010 15:57:17 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 975CA6029; Thu, 23 Sep 2010 15:57:09 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/2JR+pKoEGJ4hjZWy81NDrlQDQhsP/hNk= Message-ID: <4C9B78D5.4090907@extendedsubset.com> Date: Thu, 23 Sep 2010 10:57:09 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <201009230148.o8N1m825020375@fs4113.wdf.sap.corp> In-Reply-To: <201009230148.o8N1m825020375@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: certid@ietf.org, ietf@ietf.org, tls@ietf.org Subject: Re: [certid] [TLS] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 15:56:50 -0000 On 09/22/2010 08:48 PM, Martin Rex wrote: > Henry B. Hotz wrote: >> >> [...] For example the user may trust a dedicated discovery service >> or identity service that securely redirects requests from the source >> to a target domain. > > Thinking about it, I feel slightly uneasy about some redirects, such as > https://gmail.com -> 301 -> https://mail.google.com/mail > > I think these should never go without a warning. That bugs me too. Lots of sites do it though, usually with Javascript. > If my banks online-banking portal (https://www..de) > would suddently redirect me to https://www..com before > asking me for credentials and transaction authorization codes, > that would be a real security problem, because www..com > is not leased by my bank (it is apparently not currently leased to anyone) Yep. There are often ways to make that happen with just a blind plaintext injection capability, too. > A hacker that breaks into a web-site in order to do trap > victims The site is now 100% (to use the technical term) "pwned". It's not possible for a network security protocol to survive the compromise of one of the endpoints. We can no longer reason about Alice and Bob if Bob is allowed to be under the hypnotic control of Eve. I think it's dangerous to try. We're likely to optimize for cases of dubious security at the expense of some properly functioning cases. > might be less easily detected if he doesn't subvert > the entire site and tries to send collected data to external > places, but instead puts redirects into place that browsers > will blindly and silently follow, maybe additionally filtering > the clients that will be redirected based on their origin, > so that the helpdesk and security guys can not immediately > repro it with their browsers. > > Should a users decision to trust a particular service with > a particular issue always imply that this particular service > is a fully trusted naming service (i.e. one that performs > secure name transformations)? There are lots of ways a site can delegate its security like that. They could load Javascript or HTML from external sites, for example. They can use headers and script to broaden the origin which the browser trusts. http://code.google.com/p/browsersec/wiki/Part2 Not to mention that they could simply proxy the requests on the server side, outsource their servers to someone untrustworthy, add insecure 3rd party tracking cookies, redirect via non-SSL HTTP, and so on. Once your browser trusts a server to serve some domain/origin, there's almost nothing that server can't do with its identity, including delegate it to someone else (intentionally or not). - Marsh From mrex@sap.com Thu Sep 23 09:13:27 2010 Return-Path: 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 BD5F33A697E; Thu, 23 Sep 2010 09:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 99N0vi-d7QG3; Thu, 23 Sep 2010 09:13:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 438743A698F; Thu, 23 Sep 2010 09:13:23 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8NGDjsu020575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Sep 2010 18:13:50 +0200 (MEST) From: Martin Rex Message-Id: <201009231613.o8NGDiL2016566@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 23 Sep 2010 18:13:44 +0200 (MEST) In-Reply-To: from "Paul Hoffman" at Sep 22, 10 09:44:13 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: stefan@aaa-sec.com, certid@ietf.org, ietf@ietf.org, tls@ietf.org Subject: Re: [certid] Why require EKU for certid? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 16:13:28 -0000 Paul Hoffman wrote: > >>> There should at least be a rule stating that any client that accepts the CN >>> attribute to carry the domain name MUST also perform name constraints on >>> this attribute using the domain name logic if name constraints is applied to >>> the path. Failing this requirement poses a security threat if the claimed >>> domain name in CN-ID violated the name constraints set for domain names. > > Fully disagree. I do agree with Paul that something is very wrong about this paragraph. What it seems to request is that dNSName SAN name constraints ought to be performed on CN-ID if server endpoint identification is performed with CN-ID. Since there is a requirement to use (issue) DNS-IDs in server certs, and a requirement to ignore CN-ID when DNS-ID is present, such a name constraints processing scheme looks awkward to me. Name Constraints (and its processing) is something that is specified in PKIX Internet Certificate and CRL profile (rfc-5280 and its predecessor rfc-3280) plus some ISO-specs (btw. are these publicly available anywhere), and that is normally implemented entirely within the certificate path validation of the PKI software. The BCP for server endpoint identification with TLS is something, that according to the last sentence of section 1 of all TLS specs is a matter of the application on top of TLS. A CA with name constraints for DNSName SANs (required critical according to rfc5280, mind you) in its own CA certificate that issues TLS server certificates without dNSName SANs yields "fubar" on my scorecard. The support of CN-IDs is "legacy" and retained for backwards compatibility with the installed base. Those that need the backwards compatibility will _not_ disable the matching fallback if DNSName SANs are present, and they're even more unlikely to adopt such a weird name constraints processing of a fallback they shouldn't be doing in the first place and keep doing only to not interfere with installed base. -Martin From hotz@jpl.nasa.gov Thu Sep 23 10:43:33 2010 Return-Path: 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 DF5F43A6A5D; Thu, 23 Sep 2010 10:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8Cqei4oHC7NX; Thu, 23 Sep 2010 10:43:32 -0700 (PDT) Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id 7AFC73A6964; Thu, 23 Sep 2010 10:43:32 -0700 (PDT) Received: from [192.168.2.2] (netblock-72-25-120-25.dslextreme.com [72.25.120.25]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id o8NHhoiG016354 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Thu, 23 Sep 2010 10:43:51 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: Date: Thu, 23 Sep 2010 10:43:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <76232140-6713-416F-8758-8042A82B8857@jpl.nasa.gov> References: <4C9A2D12.3020409@stpeter.im> To: Paul Hoffman X-Mailer: Apple Mail (2.1081) X-Source-IP: netblock-72-25-120-25.dslextreme.com [72.25.120.25] X-Source-Sender: hotz@jpl.nasa.gov X-Spamclassfication-Commtouch: not spam X-SpamRefId: str=0001.0A090207.4C9B91DA.0098,ss=1,fgs=0 Cc: Stefan Santesson , IETF cert-based identity , "ietf@ietf.org" , "tls@ietf.org" Subject: Re: [certid] Why require EKU for certid? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 17:43:34 -0000 On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: > At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>> General: >>> I would consider stating that server certificates according to this = profile >>> either MUST or SHOULD have the serverAuth EKU set since it is = allways >>> related to the use of TSL and server authentication. At least it = MUST be set >>> when allowing checks of the CN-ID (see 2.3 below). >>=20 >> [..snip..] >=20 > What possible advantage is there to making certificates that do not = have this flag set be excluded from the practices you are defining? That = is, if a TLS client gets a certificate from a TLS server that the TLS = server says is its authentication certificate, why should the client = care whether or not that flag is set? That flag is an assertion from the = CA, not from the server who is authenticating. Does this point need discussion? Without checking, I suspect that 5280 = says you obey the EKU, period. OTOH I think Paul raises a valid point. OTOH (again) one could argue that the EKU provides a way to prevent a = stolen cert/key issued to the machine for a different function from = being repurposed to support a fake server. (I'm not convinced this is = significant, but it's something.) Absent discussion and consensus, I vote for whatever 5280 says, which I = suppose is what the current silence on the topic equates to. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From rbarnes@bbn.com Thu Sep 23 11:11:35 2010 Return-Path: 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 F23113A6A85; Thu, 23 Sep 2010 11:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.387 X-Spam-Level: X-Spam-Status: No, score=-97.387 tagged_above=-999 required=5 tests=[AWL=-4.971, BAYES_05=-1.11, FB_WORD2_END_DOLLAR=3.294, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, SARE_URI_EQUALS=1.666, 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 A785w47WBaKG; Thu, 23 Sep 2010 11:11:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id AA21A3A6943; Thu, 23 Sep 2010 11:11:03 -0700 (PDT) Received: from [192.1.255.185] (port=58400 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OyqFt-0009h1-5x; Thu, 23 Sep 2010 14:10:49 -0400 Message-Id: <93037048-4609-40F7-BCC0-D635301E4042@bbn.com> From: "Richard L. Barnes" To: Marsh Ray In-Reply-To: <4C9A5B13.1040802@extendedsubset.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 23 Sep 2010 14:10:48 -0400 References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> <4C9A5B13.1040802@extendedsubset.com> X-Mailer: Apple Mail (2.936) Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org Subject: Re: [certid] [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 18:11:36 -0000 There is no black magic here, only the magic of the TLS server_name extension. If the client provides server_name=gmail.com, the server provides a gmail.com cert, otherwise it defaults to mail.google.com. Your browser is following two secure delegations before it lands at www.google.com (gmail.com -> mail.google.com -> www.google.com). My guess based on the anecdotes in the thread is that IE8 doesn't support it. (You should also be more careful about your HTTP emulation! "A client MUST include a Host header field in all HTTP/1.1 request messages .") In full detail: rbarnes$ openssl s_client -connect gmail.com:443 -servername gmail.com [...] subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority [...] GET / HTTP/1.1 Host: gmail.com HTTP/1.1 301 Moved Permanently Location: https://mail.google.com/mail/ [...] rbarnes$ openssl s_client -connect mail.google.com:443 -servername mail.google.com [...] subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ CN=mail.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA [...] GET /mail/ HTTP/1.1 Host: mail.google.com HTTP/1.1 302 Moved Temporarily Location: https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dl&bsv=1eic6yu9oa4y3&ss=1&scc=1<mpl=default<mplcache=2 [...] rbarnes$ openssl s_client -connect www.google.com:443 -servername www.google.com [...] subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA [...] GET /accounts/ServiceLogin? service=mail&passive=true&rm=false&continue=https%3A%2F %2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy %3Dl&bsv=1eic6yu9oa4y3&ss=1&scc=1<mpl=default<mplcache=2 HTTP/1.1 Host: www.google.com HTTP/1.1 200 OK [...] On Sep 22, 2010, at 3:37 PM, Marsh Ray wrote: > On 09/22/2010 01:31 PM, ArkanoiD wrote: >> BTW, slightly offtopic here: whenever i connect to gmail.com, i get >> certificate >> for mail.google.com. But i've yet to see any web browser to >> complain! Where is the magic? > > Seems totally relevant to me. > > Going to https://gmail.com/ I get some kind of redirection to https://www.google.com/accounts/ServiceLogin > ... > > I can confirm the silent redirect behavior on FF, an associate > reports it on IE9. I tried IE8 but get the expected "cert was issued > for a different website's address" error. > > Hopefully I'm overlooking something simple, but at first glance it > would seem like either of these two conditions are true: > > 1. Multiple vendors are putting some kind of override table in their > browsers with an entry for gmail.com. > > 2. Browsers are running script from badly authenticated sources. > > So what does gmail.com have in this situation that an attacker > couldn't obtain for phonygmail.com? > > - Marsh > > > marsh@lamb:/tmp$ dig -t any gmail.com > > ; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;gmail.com. IN ANY > > ;; ANSWER SECTION: > gmail.com. 300 IN A 74.125.227.22 > gmail.com. 300 IN A 74.125.227.21 > gmail.com. 300 IN A 74.125.227.24 > gmail.com. 300 IN A 74.125.227.23 > gmail.com. 86400 IN NS ns4.google.com. > gmail.com. 86400 IN NS ns1.google.com. > gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. > 1427981 21600 3600 1209600 300 > gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. > gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" > > ;; ADDITIONAL SECTION: > ns4.google.com. 85092 IN A 216.239.38.10 > ns1.google.com. 85092 IN A 216.239.32.10 > > ;; Query time: 54 msec > ;; SERVER: 192.168.1.3#53(192.168.1.3) > ;; WHEN: Wed Sep 22 14:26:29 2010 > ;; MSG SIZE rcvd: 330 > > > > marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 > ... > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ > CN=mail.google.com > issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > ... > --- > GET / HTTP/1.0 > > HTTP/1.0 200 OK > Date: Wed, 22 Sep 2010 19:31:43 GMT > Expires: -1 > Cache-Control: private, max-age=0 > Content-Type: text/html; charset=ISO-8859-1 > Set-Cookie: > PREF > =ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; > expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com > Set-Cookie: > NID > = > 39 > = > nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i > -CvhRU1DrDDYvExygPnpew69GRLaWZeI0; expires=Thu, 24-Mar-2011 19:31:43 > GMT; path=/; domain=.google.com; HttpOnly > Server: gws > X-XSS-Protection: 1; mode=block > > content="text/html; charset=ISO-8859-1">Google</ > title > > > < > script > >window.google={kEI:"n1maTNKCA5O8zAXDpJFW",kEXPI:"24956,26758",kCSI: > {e > :"24956,26758 > ",ei:"n1maTNKCA5O8zAXDpJFW",expi:"24956,26758"},ml:function() > {},kHL:"en",time:function(){return(new > Date).getTime()},log:function(b,d,c){var a=new > Image > ,e=google,g=e.lc,f=e.li;a.onerror=(a.onload=(a.onabort=function() > {delete g[f]}));g[f]=a;c=c||"/gen_204?atyp=i&ct="+b+"&cad="+d > +"&zx="+google.time();a.src=c;e.li=f+1},lc:[],li:0,Toolbelt:{}}; > window.google.sn="webhp";window.google.timers={load:{t:{start:(new > Date).getTime()}}};try{}catch(u){}window.google.jsrt_kill=1; > var _gjwl=location;function _gjuc(){var > e=_gjwl.href.indexOf("#");if(e>=0){var > a=_gjwl.href.substring(e);if(a.indexOf("&q=")>0||a.indexOf("#q=")>=0) > {a=a.substring(1);if(a.indexOf("#")==-1){for(var c=0;c<a.length;) > {var d=c;if(a.charAt(d)=="&")++d;var > b=a.indexOf("&",d);if(b==-1)b=a.length;var > f=a.substring(d,b);if(f.indexOf("fp=")==0){a=a.substring(0,c) > +a.substring(b,a.length);b=c}else if(f=="cad=h")return > 0;c=b}_gjwl.href="/search?"+a+"&cad=h";return 1}}}return 0}function > _gjp(){!(window._gjwl.hash&& > window._gjuc())&&setTimeout(_gjp,500)}; > window._gjp && _gjp()</script><style id=gstyle>body{margin: > 0}#gog{padding:3px 8px 0}td{line-height:.8em}.gac_m td{line-height: > 17px}form{margin-bottom:20px}body,td,a,p,.h{font-family:arial,sans- > serif}.h{color:#36c;font-size:20px}.q{color:#00c}.ts td{padding: > 0}.ts{border-collapse:collapse}em{font-weight:bold;font- > style:normal}.lst{width:496px}.tiah{width:458px}input{font- > family:inherit}a.gb1,a.gb2,a.gb3,a.gb4{color:#11c ! > important}#gog{background:#fff}#gbar,#guser{font-size:13px;padding- > top:1px !important}#gbar{float:left;height:22px}#guser{padding- > bottom:7px !important;text-align:right}.gbh,.gbd{border-top:1px > solid #c9d7f1;font-size:1px}.gbh{height:0;position:absolute;top: > 24px;width:100%}#gbs,.gbm{background:#fff;left: > 0;position:absolute;text-align:left;visibility:hidden;z-index: > 1000}.gbm{border:1px solid;border-color:#c9d7f1 #36c #36c #a2bae7;z- > index:1001}.gb1{margin-right:.5em}.gb1,.gb3{zoom: > 1}.gb2{display:block;padding:.2em .5em}.gb2,.gb3{text- > decoration:none;border- > bottom:none}a.gb1,a.gb2,a.gb3,a.gb4{color:#00c ! > important}a.gb2:hover{background:#36c;color:#fff ! > important}#gbar{display: none}#gbe{display: > none}body{background:#fff;color:black}input{-moz-box-sizing:content- > box}a{color:#11c;text-decoration:none}a:hover,a:active{text- > decoration:underline}.fl > a{color:#4272db}a:visited{color:#551a8b}a.gb1,a.gb4{text- > decoration:underline}a.gb3:hover{text-decoration:none}#ghead > a.gb2:hover{color:#fff!important}.ds{display:-moz-inline- > box}.ds{border-bottom:solid 1px #e7e7e7;border-right:solid 1px > #e7e7e7;display:inline-block;margin:3px 0 4px;margin-left: > 4px}.sblc{padding-top:5px}.sblc a{display:block;margin:2px 0;margin- > left:13px;font-size:11px;}.lsbb{background:#eee;border:solid > 1px;border-color:#ccc #999 #999 #ccc;height: > 30px;display:block}.lsb{background:url(/images/srpr/nav_logo14.png) > bottom;font:15px arial,sans- > serif;border:none;color:#000;cursor:pointer;height:30px;margin: > 0;outline:0;vertical- > align:top > }.lsb:active{background:#ccc}.lst:focus{outline:none}.ftl,#fll > a{margin:0 12px}#addlang a{padding:0 3px}.gac_v > div{display:none}.gac_v .gac_v2,.gac_bt{display:block!important}</ > style><script>google.y={};google.x=function(e,g) > {google.y[e.id]=[e,g];return false};window.gbar={qs:function() > {},tg:function(e){var o={id:'gbar'};for(i in > e)o[i]=e[i];google.x(o,function(){gbar.tg(o)})}};</script></ > head><body bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b > alink=#ff0000 onload="document.f.q.focus();if(document.images)new > Image().src='/images/srpr/nav_logo14.png'" ><textarea id=csi > style=display:none></textarea><iframe name=wgjf style=display:none></ > iframe><div id=ghead><div id=gog><div id=guser > width=100%><nobr><span id=gbn class=gbi></span><span id=gbf > class=gbf></span><span id=gbe><a href="/url?sa=p&pref=ig&pval=3&q=http://www.google.com/ig%3Fhl%3Den%26source%3Diglk&usg=AFQjCNFA18XPfgb7dKnXfKz7x7g1GDH1tg > " class=gb4>iGoogle</a> | </span><a href="/preferences?hl=en" > class=gb4>Search settings</a> | <a href="https://www.google.com/accounts/Login?hl=en&continue=https://www.google.com/ > " class=gb4>Sign in</a></nobr></div><div class=gbh style=left:0></ > div><div class=gbh style=right:0></div></div></div> <center><br > clear=all id=lgpd><div id=lga><img src="images/logos/ > ssl_logo_lg.gif" width=276 height=110 border=0><br></div><font > size=-1>Go to <a href="http://www.google.com/">classic Google</a>.</ > font><form action="/search" name=f><table cell > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From mrex@sap.com Thu Sep 23 11:15:15 2010 Return-Path: <mrex@sap.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 F2F6E3A6AC4; Thu, 23 Sep 2010 11:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.804 X-Spam-Level: X-Spam-Status: No, score=-9.804 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 kQVhLCdkpw0M; Thu, 23 Sep 2010 11:15:13 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 77B4F3A6A94; Thu, 23 Sep 2010 11:15:12 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8NIFejf024879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Sep 2010 20:15:40 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009231815.o8NIFdDi023872@fs4113.wdf.sap.corp> To: tls@ietf.org, certid@ietf.org Date: Thu, 23 Sep 2010 20:15:39 +0200 (MEST) In-Reply-To: <4C9B78D5.4090907@extendedsubset.com> from "Marsh Ray" at Sep 23, 10 10:57:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out Cc: certid@ietf.org, ietf@ietf.org, tls@ietf.org Subject: Re: [certid] [TLS] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Thu, 23 Sep 2010 18:15:15 -0000 Marsh Ray wrote: > > Martin Rex wrote: > > > > Thinking about it, I feel slightly uneasy about some redirects, such as > > https://gmail.com -> 301 -> https://mail.google.com/mail > > > > I think these should never go without a warning. > > That bugs me too. Lots of sites do it though, usually with Javascript. > > > If my banks online-banking portal (https://www.<mybank>.de) > > would suddently redirect me to https://www.<mybank>.com before > > asking me for credentials and transaction authorization codes, > > that would be a real security problem, because www.<mybank>.com > > is not leased by my bank (it is apparently not currently leased to anyone) > > > > A hacker that breaks into a web-site in order to do trap > > victims > > The site is now 100% (to use the technical term) "pwned". > > It's not possible for a network security protocol to survive the > compromise of one of the endpoints. We can no longer reason about Alice > and Bob if Bob is allowed to be under the hypnotic control of Eve. True. I used the wrong words in what I was trying to say. There is definitely little that you can do about a full compromise of the real server. But blindly trusting browsers may easily turn seemingly small security vulnerability (every XSS, CSRF, content upload), that enables diverting a victim to the attackers own server seamlessly, close to equivalent to a full compromise of the real server for the purpose of capturing sensible or confidential information from the victim. -Martin From marsh@extendedsubset.com Thu Sep 23 11:33:37 2010 Return-Path: <marsh@extendedsubset.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 0BC083A6943; Thu, 23 Sep 2010 11:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599] 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 BVmtvTvX55eH; Thu, 23 Sep 2010 11:33:31 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 735E43A69D0; Thu, 23 Sep 2010 11:33:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OyqcI-00039r-Kp; Thu, 23 Sep 2010 18:33:58 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7388D601A; Thu, 23 Sep 2010 18:33:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18hrXgaUBVAOwL33tya7/0QAtzYvVEk96E= Message-ID: <4C9B9D92.1060406@extendedsubset.com> Date: Thu, 23 Sep 2010 13:33:54 -0500 From: Marsh Ray <marsh@extendedsubset.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Richard L. Barnes" <rbarnes@bbn.com> References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> <4C9A5B13.1040802@extendedsubset.com> <93037048-4609-40F7-BCC0-D635301E4042@bbn.com> In-Reply-To: <93037048-4609-40F7-BCC0-D635301E4042@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF discussion list <ietf@ietf.org>, secdir@ietf.org, Barry Leiba <barryleiba.mailing.lists@gmail.com>, IETF cert-based identity <certid@ietf.org>, tls@ietf.org Subject: Re: [certid] [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 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: Thu, 23 Sep 2010 18:33:37 -0000 On 09/23/2010 01:10 PM, Richard L. Barnes wrote: > There is no black magic here, only the magic of the TLS server_name > extension. If the client provides server_name=gmail.com, the server > provides a gmail.com cert, otherwise it defaults to mail.google.com. > Your browser is following two secure delegations before it lands at > www.google.com (gmail.com -> mail.google.com -> www.google.com). I'd not even considered SNI. > My guess based on the anecdotes in the thread is that IE8 doesn't > support it. Not IE8, but the pre-Vista Windows I was testing it on that doesn't do extensions by default. Which is why I'd not considered that gmail would depend on SNI for its operation. I'd forgotten that this is Google we were talking about and not any other company in the world that would put support for MSIE on Windows XP ahead of protocol standards. :-) > (You should also be more careful about your HTTP emulation! "A client > MUST include a Host header field in all HTTP/1.1 request messages > .") Yep, that's why I requested HTTP/1.0. - Marsh From matt@mattmccutchen.net Thu Sep 23 18:09:56 2010 Return-Path: <matt@mattmccutchen.net> 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 CB83F3A68F1 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 18:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FTylkXUMu763 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 18:09:55 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id B14133A6851 for <certid@ietf.org>; Thu, 23 Sep 2010 18:09:55 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 45E8C1D0064 for <certid@ietf.org>; Thu, 23 Sep 2010 18:10:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=M9WW9/MjCU9ce70O5mc+AlH12wV2oe48d93feZMsjyX 4wXeU6UeU/GA81NoD6mqJq9j/tizcnUUO9L6Oq7Tq6l//hruvmCARnD0UaCD70I5 +teuU4n1Vm2eEFeCSF20NPYiGOVT5yJwi649SWkOaR5bzuBAGE9NF7m1cnQHfTaA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=wmNkWeJ7k+ZSFX9ebHiAUpOen7M=; b=Og9ORhUz9O +C0LzMMznbJJ6/uXV76/pkZOWgcHXO0B8+3TNsMcXBi+fsh3mFdHxhI+qCyzSIBZ W9QYdSzvk4c772Psp5dDs0HWq35dUh3HwHF0WKFnqnYZiarcT9IE0LCUqhBHLTaE T8DVdQbjPx2f8Cq4E2pofLH87AHW8nZUU= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 06E0A1D0063 for <certid@ietf.org>; Thu, 23 Sep 2010 18:10:23 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: certid@ietf.org In-Reply-To: <201009231613.o8NGDiL2016566@fs4113.wdf.sap.corp> References: <201009231613.o8NGDiL2016566@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Thu, 23 Sep 2010 21:10:22 -0400 Message-ID: <1285290623.1939.15.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Subject: [certid] CN-ID and name constraints 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: Fri, 24 Sep 2010 01:09:56 -0000 On Thu, 2010-09-23 at 18:13 +0200, Martin Rex wrote: > Paul Hoffman wrote: > > > >>> There should at least be a rule stating that any client that accepts the CN > >>> attribute to carry the domain name MUST also perform name constraints on > >>> this attribute using the domain name logic if name constraints is applied to > >>> the path. Failing this requirement poses a security threat if the claimed > >>> domain name in CN-ID violated the name constraints set for domain names. > > > > Fully disagree. > > I do agree with Paul that something is very wrong about this paragraph. > > What it seems to request is that dNSName SAN name constraints ought > to be performed on CN-ID if server endpoint identification is > performed with CN-ID. > > Since there is a requirement to use (issue) DNS-IDs in server certs, > and a requirement to ignore CN-ID when DNS-ID is present, such a > name constraints processing scheme looks awkward to me. [...] > A CA with name constraints for DNSName SANs (required critical according > to rfc5280, mind you) in its own CA certificate that issues TLS server > certificates without dNSName SANs yields "fubar" on my scorecard. But if by doing that they can issue certificates that clients will accept for server names the superior CA did not intend, that's a big security problem. > Those that need the backwards compatibility will _not_ disable > the matching fallback if DNSName SANs are present, NSS doesn't: https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName The idea is that by including a dNSName SAN, the CA opts out of the backward compatibility. I don't think anyone issues certificates with both dNSName SAN and CN with the intent that the CN be honored as a server name. > and they're > even more unlikely to adopt such a weird name constraints > processing of a fallback they shouldn't be doing in the > first place and keep doing only to not interfere with > installed base. Those that need backwards compatibility, name constraints, and security need to do something about this issue. Some previous discussion: http://www.ietf.org/mail-archive/web/pkix/current/msg27619.html -- Matt From mrex@sap.com Thu Sep 23 19:39:03 2010 Return-Path: <mrex@sap.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 6F8413A68C8 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 19:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 GK84hOnsPH4H for <certid@core3.amsl.com>; Thu, 23 Sep 2010 19:39:02 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B39BA3A6851 for <certid@ietf.org>; Thu, 23 Sep 2010 19:39:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8O2dUKo007863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 04:39:30 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009240239.o8O2dTQY022491@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 24 Sep 2010 04:39:29 +0200 (MEST) In-Reply-To: <1285290623.1939.15.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 23, 10 09:10:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Fri, 24 Sep 2010 02:39:03 -0000 Matt McCutchen wrote: > > > A CA with name constraints for DNSName SANs (required critical according > > to rfc5280, mind you) in its own CA certificate that issues TLS server > > certificates without dNSName SANs yields "fubar" on my scorecard. > > But if by doing that they can issue certificates that clients will > accept for server names the superior CA did not intend, that's a big > security problem. No, there is absolutely no security problem involved. This is a plain and simple liability issue. If the superior CA can not manage the risk appropriately so that the issuing CA will not do this, then either the superior CA MUST NOT certify that issuing CA, or the clients MUST NOT trust the superior CA. It is really as simple as that. Btw. is it completely ridiculous to put Constraints into certificates for a resource that is managed aribraritly on a first-come, first-served basis such as DNS hostnames and think of it as a security feature. What some entirely fail to understand is that this is about a backwards compatibility issue with the installed base, and no amount of praying, cursing and issuing of new Specs with MUST NOTs in them will change the behaviour of the installed base in any way or form. New specs affect only new stuff (implementations and CAs), and to a very limited amount patches into the installed base, under the condition that the change DOES NOT BREAK existing productive usage scenarios. NameConstraints are ill-designed to support what some people intend to do with them. They're specify to constrain only name components that are present, not name components that are absent. Go kick the PKIX folks if you don't like how it is spec'ed, but leave the apps folks alone. I believe that asking the apps folks to regurgitate and re-chew stuff that the PKIX part didn't process to someone's satisfaction is an _extremely_ bad idea. As far as Joe Average User is concerned, which of the CAs shipping in current Browsers does have the alleged security problem anyway? The way they're specified, NameConstraints are not a security feature, but rather a means to enforce a business model, because NameConstraints can no longer securely if there is more than one trust anchor. TLS as used on the internet is approaching 100 seperate trust anchors... > > > Those that need the backwards compatibility will _not_ disable > > the matching fallback if DNSName SANs are present, > > NSS doesn't: > > https://mxr.mozilla.org/mozilla/ident?i=CERT_VerifyCertName > > The idea is that by including a dNSName SAN, the CA opts out of the > backward compatibility. I don't think anyone issues certificates with > both dNSName SAN and CN with the intent that the CN be honored as a > server name. Well no, this is another absolute nonsense, because again it completely ignores the (behaviour of) the installed base. The only way to opt out of CN-ID matching is to issue server certs entirely without CN AVAs in the subject name. Anything else than CN=f.q.d.n or NO CN AVA is non-sensical. The only problem with CN-less subject names is, that it might create serious usability issues with a number of existing certificate maintenance UIs... > > > and they're > > even more unlikely to adopt such a weird name constraints > > processing of a fallback they shouldn't be doing in the > > first place and keep doing only to not interfere with > > installed base. > > Those that need backwards compatibility, name constraints, and security > need to do something about this issue. I'm not aware of a reasonable justification for the existance of PolicyConstraints and NameConstraints in certificates other than governmental agencies and military would like to use it eventually and still be able to procure on the commodity market. The situation for ECC crypto is similar. Although there may be some usefulness in having alternative algorithm to RSA at some point in the future when all of the annoying patents have expired. -Martin From matt@mattmccutchen.net Thu Sep 23 22:01:25 2010 Return-Path: <matt@mattmccutchen.net> 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 CE1FE3A6A7E for <certid@core3.amsl.com>; Thu, 23 Sep 2010 22:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] 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 MG9-+7i05Nub for <certid@core3.amsl.com>; Thu, 23 Sep 2010 22:01:24 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 7B3943A68DF for <certid@ietf.org>; Thu, 23 Sep 2010 22:01:24 -0700 (PDT) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 6E87263406F; Thu, 23 Sep 2010 22:01:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=siiuoAzIsSjP32/Y9VnXb8waizttHfeZAfhVRclJABe hzjQdI9xWNoInXcYXQhouYPeWYM0eXDomhd2t6PHlCPv7n/d0dzULvsAm0yhj/+d inuFkJ90SRPoBAKIqEUTxYKBTHwNpvH3E7cbWxeMeCPLv0UCJ1Dzy3KhSO+XIIDw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=XTobrlGOi849yb8DBThrncTKRTo=; b=MhqRsd/sFi B4Rqylkj0TK5MqL1yPYE0VwjjhvzucEXwXiB9RIIyRidMWoJbwVBHH6BxVaGjhCV gKJAFITwr1WJaCT2CWUsXjnnMvgg/rAj7mqfRr0phLJ5OR725QMLzXxgkMFhBMRc eLKgTLrPwpln8KIFvWHNFlU92D4pufttQ= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id 1D18863406C; Thu, 23 Sep 2010 22:01:55 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009240239.o8O2dTQY022491@fs4113.wdf.sap.corp> References: <201009240239.o8O2dTQY022491@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Sep 2010 01:01:54 -0400 Message-ID: <1285304514.1939.337.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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: Fri, 24 Sep 2010 05:01:25 -0000 On Fri, 2010-09-24 at 04:39 +0200, Martin Rex wrote: > Matt McCutchen wrote: > > > > > A CA with name constraints for DNSName SANs (required critical according > > > to rfc5280, mind you) in its own CA certificate that issues TLS server > > > certificates without dNSName SANs yields "fubar" on my scorecard. > > > > But if by doing that they can issue certificates that clients will > > accept for server names the superior CA did not intend, that's a big > > security problem. > > No, there is absolutely no security problem involved. > > This is a plain and simple liability issue. If the superior CA > can not manage the risk appropriately so that the issuing CA will > not do this, then either the superior CA MUST NOT certify that > issuing CA, or the clients MUST NOT trust the superior CA. Name constraints are designed to support secure delegation of the ability to issue certificates for a portion of the namespace. Why wouldn't CAs use them for that purpose? Just because you said so? A certificate that violates a name constraint is invalid, and under any sane contract or legal system, the superior CA will not be liable to anyone who relies on an invalid certificate. > Btw. is it completely ridiculous to put Constraints into > certificates for a resource that is managed aribraritly on a > first-come, first-served basis such as DNS hostnames and > think of it as a security feature. What exact use case do you speak of? The typical use case is to give the owner of a DNS zone the ability to issue certificates for names within that zone that will validate for the duration of the ownership. > What some entirely fail to understand is that this is about > a backwards compatibility issue with the installed base, > and no amount of praying, cursing and issuing of new Specs with > MUST NOTs in them will change the behaviour of the installed base > in any way or form. > > New specs affect only new stuff (implementations and CAs), > and to a very limited amount patches into the installed base, > under the condition that the change DOES NOT BREAK existing > productive usage scenarios. Matching a reference server name against a CN-ID that violates a dNSName constraint defeats the purpose of name constraints. With respect to clients willing to do this, a name constraint is a security no-op. In general, IETF seeks to make the features that it introduces work as intended. So it makes complete sense to me that secure handling of name constraints would be a condition of conformance to the server-id-check standard. Old clients that take a useless interpretation of name constraints can continue to exist, they just can't claim conformance to the standard, and that's their problem. NSS now enforces name constraints on the CN-ID (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains backward compatible with the web by virtue of the fact that the public CAs aren't using name constraints yet. If the CAs start doing so, all an inferior CA has to do for things to work is to include a dNSName SAN, which is a SHOULD anyway. > NameConstraints are ill-designed to support what some people > intend to do with them. In what way are they ill-designed to support secure delegation of the ability to issue certificates for a portion of the namespace? > They're specify to constrain only > name components that are present, not name components that > are absent. What do you mean? > Go kick the PKIX folks if you don't like how it is spec'ed, > but leave the apps folks alone. I believe that asking the apps > folks to regurgitate and re-chew stuff that the PKIX part didn't > process to someone's satisfaction is an _extremely_ bad idea. server-id-check is built on PKIX, not vice versa, so server-id-check is responsible for the security consequences of the CN-ID that it defines for the name constraints defined by PKIX. It has the option to solve the problem or say "this breaks the security of name constraints and we know it", which would be laughable for a standard. > As far as Joe Average User is concerned, which of the CAs shipping > in current Browsers does have the alleged security problem anyway? None; obviously the CAs won't use a feature that presents a security problem. The relevant question is whether they would start using it if the problem were solved, and that I can't answer. Those that charge for each end-entity certificate would certainly charge through the roof to delegate an entire domain. > The way they're specified, NameConstraints are not a security feature, > but rather a means to enforce a business model, because NameConstraints > can no longer securely if there is more than one trust anchor. > TLS as used on the internet is approaching 100 seperate trust anchors... No. All name constraints do is constrain sub-CAs, and they are secure for that purpose. PKIX assumes you trust your trust anchors. If you don't, that's a problem that has to be solved by other means. > > The idea is that by including a dNSName SAN, the CA opts out of the > > backward compatibility. I don't think anyone issues certificates with > > both dNSName SAN and CN with the intent that the CN be honored as a > > server name. > > Well no, this is another absolute nonsense, because again it > completely ignores the (behaviour of) the installed base. > The only way to opt out of CN-ID matching is to issue server > certs entirely without CN AVAs in the subject name. > Anything else than CN=f.q.d.n or NO CN AVA is non-sensical. I'm not sure what installed base you are talking about, but the interpretation I described is stated in RFC 2818 and followed by all major browsers. server-id-check is right to choose it. But this is a separate issue from name constraints on the CN-ID. > I'm not aware of a reasonable justification for the existance > of PolicyConstraints and NameConstraints in certificates other > than governmental agencies and military would like to use it > eventually and still be able to procure on the commodity market. I gave one above. A public CAs can give a DNS zone owner the ability to issue certificates within the zone without posing a risk to anyone else. -- Matt From matt@mattmccutchen.net Thu Sep 23 22:14:28 2010 Return-Path: <matt@mattmccutchen.net> 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 428D13A6AA2 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 22:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] 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 zyUp4VXGffwN for <certid@core3.amsl.com>; Thu, 23 Sep 2010 22:14:23 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 780CB3A6A3F for <certid@ietf.org>; Thu, 23 Sep 2010 22:13:55 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 582FD3BC065; Thu, 23 Sep 2010 22:14:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=mVVDc6BHOA1UfePTF7YlqEbeQu389w3B2mJa5MdUVRf ZjKV0i4VatPBuqr8A3aVURgygtoF8VgduRt7el2fI7nnHG6jndnxORUZYMXnfTaR 9NXv4SyRdO3wSIBAq3EN9GoV+qa/paqDe9VzF0RvNUkkSXPKnC7YA+zTh2h49PYE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=mSt3y2ql6iXJBpffdPnPb13e1Ik=; b=H8yh6s6eQe DKqT/o0mPSxlyqqXR0C7EkqhF0rI6jphY1OFBFsOtcuYGq3Q5WPJrS421HNNSLoP wW9TVAjboGiDR1W1YP0pireaMWV85MTguMGrFkphqPMoo6z1XLDQgimSC/ZmHX/M sio8AtDoRs+zRMA9Kxm9VkNAoCX8zPd4w= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPA id F21AF3BC063; Thu, 23 Sep 2010 22:14:04 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009230148.o8N1m825020375@fs4113.wdf.sap.corp> References: <201009230148.o8N1m825020375@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Sep 2010 01:14:04 -0400 Message-ID: <1285305244.1939.353.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 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: Fri, 24 Sep 2010 05:14:28 -0000 On Thu, 2010-09-23 at 03:48 +0200, Martin Rex wrote: > Henry B. Hotz wrote: > > > > [...] For example the user may trust a dedicated discovery service > > or identity service that securely redirects requests from the source > > to a target domain. > > Thinking about it, I feel slightly uneasy about some redirects, such as > https://gmail.com -> 301 -> https://mail.google.com/mail The point from the draft was about a service that maps source domains to target domains. A HTTP redirect is different: it is an instruction to restart the process with a new source domain. -- Matt From matt@mattmccutchen.net Thu Sep 23 22:24:48 2010 Return-Path: <matt@mattmccutchen.net> 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 A13163A68DF for <certid@core3.amsl.com>; Thu, 23 Sep 2010 22:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] 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 f0cbvHkF89Fr for <certid@core3.amsl.com>; Thu, 23 Sep 2010 22:24:47 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 8FD903A6A7D for <certid@ietf.org>; Thu, 23 Sep 2010 22:24:47 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 98759280069; Thu, 23 Sep 2010 22:25:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=iniJ7/mmxCt06QHx9Hy+Hzh+kCNBWgPfjAZA57FGDFP csNA8lhGu7MmXnd3B1LYkE9l0GB+U6KbCsRnkXrtt5oHNWqKxpWqEjEenyaO22lQ ajAzTumHspOrh0YCfCBDYoMdzygnBLkkpvQRkez0fK37NMGjAYnSeu6bDYeVzCg0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=pXv/vYG81ADm0xx+UrsoOC4kAKQ=; b=CVwzHZPD3h OzoR8p2L0zwYRVkyUB/d2n/Yl30eLk3mwTRRDJa18z3+8nkkZLw+tVHYmGOUuNvO jn68crsBW5Ln0TJawqZ/trd2NSjdeS6WyKD4jbPDnnXFmKfsMQFQnKfJRZuI0C5Q GBdp1GFK0zfP2lsh+rQ2Xvmbzd1iO0PZM= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 53A94280062; Thu, 23 Sep 2010 22:25:18 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009231815.o8NIFdDi023872@fs4113.wdf.sap.corp> References: <201009231815.o8NIFdDi023872@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Sep 2010 01:25:17 -0400 Message-ID: <1285305917.1939.380.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 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: Fri, 24 Sep 2010 05:24:48 -0000 On Thu, 2010-09-23 at 20:15 +0200, Martin Rex wrote: > Marsh Ray wrote: > > It's not possible for a network security protocol to survive the > > compromise of one of the endpoints. We can no longer reason about Alice > > and Bob if Bob is allowed to be under the hypnotic control of Eve. > > True. I used the wrong words in what I was trying to say. > > There is definitely little that you can do about a full compromise of > the real server. > > But blindly trusting browsers may easily turn seemingly small security > vulnerability (every XSS, CSRF, content upload), that enables diverting > a victim to the attackers own server seamlessly, close to equivalent to > a full compromise of the real server for the purpose of capturing > sensible or confidential information from the victim. This is the design of the browser. Trying to prevent it in server-id-check (of all places) makes no design sense and would cause many more problems than it solves. -- Matt From matt@mattmccutchen.net Thu Sep 23 23:24:12 2010 Return-Path: <matt@mattmccutchen.net> 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 BA2403A6844 for <certid@core3.amsl.com>; Thu, 23 Sep 2010 23:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] 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 vgz3BXDnlZzX for <certid@core3.amsl.com>; Thu, 23 Sep 2010 23:24:11 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 65DD33A6A9B for <certid@ietf.org>; Thu, 23 Sep 2010 23:24:11 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id E86858C06A; Thu, 23 Sep 2010 23:24:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=TBMU5WBLyQNHlL12qElJPnipp2qEGP1J/GeXk20bIGM woN1AmhuTUtlgCW2KQrFW05I6+APZZfg9yKKOarhd99D63SXgHEP2K+NeT2Aj/vy TWyhOljr4QTz0IoxfG5YbfAk6vTCS08NzR2xv7kZ+wz0JxtY1gCMMmkJ5kKrGTFA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=qdA0JPIfKF2VOUqPUURJT9Rxfog=; b=MqrT3cucgH Pn/rdqJ5UM+MscmvJ+Dr2879ilwEzIH/Es6noDVGDOucFWX11OLaOW5tNSxo6Lvt IQ71XH3ZoiQ7erLwXpqf4dmRfJE4kZOt2aCVgC24uhDO7ysOUIDXuDYtr/RqUC3V dv3ETGWJ9jd8+og2YYQi1h6/dy0F6pfGw= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPA id A22128C063; Thu, 23 Sep 2010 23:24:40 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: Peter Saint-Andre <stpeter@stpeter.im> In-Reply-To: <4C9A27D0.7030909@stpeter.im> References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Sep 2010 02:24:39 -0400 Message-ID: <1285309479.1939.430.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: [certid] Bad certificate handling 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: Fri, 24 Sep 2010 06:24:12 -0000 On Wed, 2010-09-22 at 09:59 -0600, Peter Saint-Andre wrote: > The part of the text that you have not quoted does say that this > practice is typically offered only to advanced users (and I don't think > that Barry's mother counts as an advanced user). However, we've > provisionally made the text even more scary, as follows: > > Security Note: Some existing interactive user agents give advanced > users the option of proceeding despite an identity mismatch. > Although this behavior can be appropriate in certain specialized > circumstances, in general it needs to be exposed only to advanced > users and even then needs to be handled with extreme caution, for > example by first encouraging even an advanced user to terminate > the connection and, if the advanced user chooses to proceed > anyway, by forcing the user to view the entire certification path > and only then allowing the user to accept the certificate on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session, but not for connection attempts during future application > sessions). > > Jeff still needs to review that text before we finalize it. There is a trade-off in making the acceptance temporary. If the certificate belongs to a MITM attacker, the user avoids becoming permanently vulnerable to that particular attacker. If it belongs to the desired server, he misses an opportunity to cache it permanently and avoid developing a habit of accepting a bad certificate on every session, which would make him vulnerable to MITM every time. Of course, there is no way to know which is the case. If the user provides a password after accepting the certificate, one can argue that he has already lost everything in the case of an attack, and hence he should focus on securing the other case by accepting the certificate permanently. It can also be useful to cache the certificate received over a relatively more trustworthy network connection for later use on a less trustworthy one (e.g., the proverbial public wireless access point). The current remark about temporary acceptance might suggest to readers that it is better than permanent acceptance, which is at best an oversimplification and possibly untrue. Thus, I propose that the remark be removed. Separately, I wonder if it makes sense for server-id-check to specifically discuss the handling of certificates that don't match a reference identifier when the considerations are essentially the same for certificates with other problems (most commonly, expired or untrusted issuer) and, indeed, modern browsers tend to provide a single UI for these three most common problems. I'm not sure where would be the right place to standardize handling of bad certificates in general. There is a W3C document, but it only applies to interactive user agents: http://www.w3.org/TR/wsc-ui/#def-pinned-cert -- Matt From mrex@sap.com Fri Sep 24 08:11:00 2010 Return-Path: <mrex@sap.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 644B63A6A94 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 08:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.812 X-Spam-Level: X-Spam-Status: No, score=-9.812 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 0N9FErdgoHno for <certid@core3.amsl.com>; Fri, 24 Sep 2010 08:10:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 5A2993A6AAD for <certid@ietf.org>; Fri, 24 Sep 2010 08:10:50 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8OFBG3O006274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 17:11:21 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009241511.o8OFBFO9005613@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 24 Sep 2010 17:11:14 +0200 (MEST) In-Reply-To: <1285305244.1939.353.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 24, 10 01:14:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Fri, 24 Sep 2010 15:11:00 -0000 Matt McCutchen wrote: > > On Thu, 2010-09-23 at 03:48 +0200, Martin Rex wrote: > > > > Thinking about it, I feel slightly uneasy about some redirects, such as > > https://gmail.com -> 301 -> https://mail.google.com/mail > > The point from the draft was about a service that maps source domains to > target domains. A HTTP redirect is different: it is an instruction to > restart the process with a new source domain. Admittedly, the processing of redirects happens at application software layers higher up the stack and for seperate TLS handshakes, whereas server endpoint identification is performed for a single TLS-Handshake directly above TLS. But that does not mean that there is no security problem. I'm trying to describe this behaviour in real world terms, maybe it becomes clearer that way. The current "server endpoint identification" would mean for the real world that you perform the matching when you enter the building (a store, gov. agency, bank, hotel, ...), and from that point on, blindly trust everything what happens to you. Now imagine a subsidiary of Western Union on an exceptionally busy time of the day with several people waiting in line waiting to arrage for a money order with cash they're carrying. Someone approaches a customer waiting in line and tells him that they've set up an additional teller in a camping truck across the street where they can place their money order. The browser behaviour, to blindly following 301 to other servers without second thoughts is a serious security problem. The problem arises because of the complete disconnect between the authentication (or its weak server identification substitute) of an area (or building) on entrance and the expectation what kind of protection this actually provides on the valuable/sensitive/confidential data of the end user. This is much less an issue of vulnerabilities in terms of probabilistic infeasibility, but instead a matter of sensible risk management. Server endpoint identification performed by current browsers, even when performed technically as described in the current draft, provides an extremely false sense of security to the end user. The "secure link" between the end users intention (who supplied https://gmail.com) and what the browser actually does (blindly follow the redirect to https://mail.google.com) is missing. The reference identifier that is passed into the server endpoint identification for the TLS handshake performed with https://mail.google.com results from an untrusted name transformation, and this is very relevant for the security considerations of this I-D. Getting trust decisions right is *much* harder than encrypting and integrity protecting communication data or performing certificate path validations. -Martin From Jeff.Hodges@KingsMountain.com Fri Sep 24 12:32:22 2010 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 A5DD43A6B66 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 12:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 HTBmw8nYC0Fn for <certid@core3.amsl.com>; Fri, 24 Sep 2010 12:32:21 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 6B3943A6978 for <certid@ietf.org>; Fri, 24 Sep 2010 12:32:21 -0700 (PDT) Received: (qmail 17670 invoked by uid 0); 24 Sep 2010 19:32:53 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 24 Sep 2010 19:32:53 -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:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=DGGwk/ylIU3sQahFQQLjqqunnurrQDrBZETPBvzBIbfqTKKwx0dr1N7y6vspLam0c9mpt+6YFj7lZTi68giYYtpOHMhUcNZW0KnZoKOG9Ej3W1eYl8JXDeDxPL32cXED; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OzE0r-0001Pj-2k for certid@ietf.org; Fri, 24 Sep 2010 13:32:53 -0600 Message-ID: <4C9CFCE4.1050801@KingsMountain.com> Date: Fri, 24 Sep 2010 12:32:52 -0700 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity <certid@ietf.org> 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Bad certificate handling 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: Fri, 24 Sep 2010 19:32:22 -0000 matt@mattmccutchen.net said: > On Wed, 2010-09-22 at 09:59 -0600, Peter Saint-Andre wrote: > > The part of the text that you have not quoted does say that this > > practice is typically offered only to advanced users (and I don't think > > that Barry's mother counts as an advanced user). However, we've > > provisionally made the text even more scary, as follows: > > > > Security Note: Some existing interactive user agents give advanced > > users the option of proceeding despite an identity mismatch. > > Although this behavior can be appropriate in certain specialized > > circumstances, in general it needs to be exposed only to advanced > > users and even then needs to be handled with extreme caution, for > > example by first encouraging even an advanced user to terminate > > the connection and, if the advanced user chooses to proceed > > anyway, by forcing the user to view the entire certification path > > and only then allowing the user to accept the certificate on a > > temporary basis (i.e., for this connection attempt and all > > subsequent connection attempts for the life of the application > > session, but not for connection attempts during future application > > sessions). > > > > Jeff still needs to review that text before we finalize it. > > There is a trade-off in making the acceptance temporary. ... > > The current remark about temporary acceptance might suggest to readers > that it is better than permanent acceptance, which is at best an > oversimplification and possibly untrue. Thus, I propose that the remark > be removed. agreed. Jhutz also suggested such. > Separately, I wonder if it makes sense for server-id-check to > specifically discuss the handling of certificates that don't match a > reference identifier when the considerations are essentially the same > for certificates with other problems (most commonly, expired or > untrusted issuer) and, indeed, modern browsers tend to provide a single > UI for these three most common problems. I'm not sure where would be > the right place to standardize handling of bad certificates in general. > There is a W3C document, but it only applies to interactive user agents: > > http://www.w3.org/TR/wsc-ui/ [WSC-UI] Which is entitled: "Web Security Context: User Interface Guidelines" Note that we already cite this doc (tho we need to update our cite because it is now a Recommendation). In any case, this is a good catch, thanks. In reading WSC-UI, it appears to overall address our needs for more full explanation of interactive user agent behavior in error condition cases (although it doesn't differentiate between "pinning" a cert temporarily vs permanently). Given all this, I suggest we change the last part of the last sentence of the "Security Note" quoted above to something like.. ..., by forcing the user to view the entire certification path and only then allowing the user to choose whether to accept the certificate on a temporary or permanent basis. See [WSC-UI] for further guidance. ..and leave it at that in -tls-server-id-check. We should also consider making [WSC-UI] a normative reference now that it is at Recommendation maturity level. =JeffH From mrex@sap.com Fri Sep 24 13:29:29 2010 Return-Path: <mrex@sap.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 5CD333A6A8B; Fri, 24 Sep 2010 13:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.817 X-Spam-Level: X-Spam-Status: No, score=-9.817 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 CLtWF4w-rNkA; Fri, 24 Sep 2010 13:29:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0936E3A69EE; Fri, 24 Sep 2010 13:29:27 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8OKTr1A002212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 22:29:53 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Fri, 24 Sep 2010 22:29:52 +0200 (MEST) In-Reply-To: <4C9A428C.2030807@stpeter.im> from "Peter Saint-Andre" at Sep 22, 10 11:53:16 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: secdir@ietf.org, jhutz@cmu.edu, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, tls@ietf.org Subject: Re: [certid] [TLS] [secdir] secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Fri, 24 Sep 2010 20:29:29 -0000 Peter Saint-Andre wrote: > > For context, the "quoted advice" is mostly a description of current > usage in some existing user agents. Incorporating Barry's suggestions, > that text currently reads as follows in our working copy: > > Security Note: Some existing interactive user agents give advanced > users the option of proceeding despite an identity mismatch. > Although this behavior can be appropriate in certain specialized > circumstances, in general it ought to be exposed only to advanced > users and even then needs to be handled with extreme caution, for > example by first encouraging even an advanced user to terminate > the connection and, if the advanced user chooses to proceed > anyway, by forcing the user to view the entire certification path > and only then allowing the user to accept the certificate on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session, but not for connection attempts during future application > sessions). This whole paragraph is evil and completely wrong. It's bad enough that the web browser crowds replaced a useful option and important security feature with an extremely evil scary page. The IETF should definitely not put this non-sense into a BCP or standard. Offering to end-users, in a single-time-only leap-of-faith approach similar to what SSH has been successfully doing since its invention to memorize the peers certificate is magnitudes more secure than the endpoint identification linking to one of a hundred trust anchors, provisionally preconfigured by your software supplier. The IETF, its standards & BCPs ought to stand clear from recommendations that impair the usability or incur additional cost for using the TLS technology between components of home networks. The scary-pages presented by newer Browsers and the UI suggestions in the quoted paragraph amounts to turning the entire TLS technology into "nagware" for commercial pre-trusted CAs. The most recent browser scary-pages are worse than most nagware. I'm not intimidated on the initial install of my DSL-router, neither when logging in to the webadmin page for the first time, nor when configuring my WPA2-PSK key. Why on earth am I intimidated so badly when I activate TLS for the webadmin UI of my home NAS and connect to it with my browser for the first time? Can't we do better than specifying the use of HTTP over TLS instead of HTTP-only to access devices on my home network should not be allowed to users that are not "advanced", and even those must be badly intimidated when they try? Even when servers use server certs from commercial pre-trusted CAs, the options for end users to manually confirm the server cert to have it cached/memorized and verified on future visits will significantly improve the security for the user, because it protects from later subversion of (the issuing procedures) of any of the thousands CAs signed by any of the hundred preconfigured trust anchors as well as bugs such as the OID-integer wraparound and NUL-character in Hostname. -Martin From matt@mattmccutchen.net Fri Sep 24 13:56:10 2010 Return-Path: <matt@mattmccutchen.net> 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 167A83A6A4C for <certid@core3.amsl.com>; Fri, 24 Sep 2010 13:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] 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 ZCTOJiPWCe+Q for <certid@core3.amsl.com>; Fri, 24 Sep 2010 13:56:08 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id AF5B53A69FB for <certid@ietf.org>; Fri, 24 Sep 2010 13:56:08 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 1FACA10AFB7; Fri, 24 Sep 2010 13:56:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=kfPWIfDv9AGQLtjDjxSWRQsFZ1naH/nZXJfdLAcYBaT LsXgUgMWUAObU74RCWsHYPaLWB90wJ/m7IFryZdRngeejlPZ4a3tRgQQu46CZP9X O8uqA/BrxiqsdRpb2//xFATkIIaiFL7iTPkrgr17BRuflPRhq2tD0cweP+sGP8kU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=c6pnf3uc9bH5/cmnA5Wf4HgjNeM=; b=OlcKJO4ABz H0yQ4MrFWHt3tLus9mZYl8Q2bozROhwYSBoncta30BTrN72Ld3iBJ5lU8GQxJoiw 47OvMA+zd9FT9pjUHbOAY8q+3Gfw1K/EE+lZ+atqRcOmfHXx4Vki0D8VQswQdxyb rD+xi9Ipk56LJV+muNDjwRRP0+2It3D2w= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPA id ADF3F10AFB5; Fri, 24 Sep 2010 13:56:40 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009241511.o8OFBFO9005613@fs4113.wdf.sap.corp> References: <201009241511.o8OFBFO9005613@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Sep 2010 16:56:39 -0400 Message-ID: <1285361799.1962.4.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 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: Fri, 24 Sep 2010 20:56:10 -0000 On Fri, 2010-09-24 at 17:11 +0200, Martin Rex wrote: > Matt McCutchen wrote: > > > > On Thu, 2010-09-23 at 03:48 +0200, Martin Rex wrote: > > > > > > Thinking about it, I feel slightly uneasy about some redirects, such as > > > https://gmail.com -> 301 -> https://mail.google.com/mail > > > > The point from the draft was about a service that maps source domains to > > target domains. A HTTP redirect is different: it is an instruction to > > restart the process with a new source domain. > > > Admittedly, the processing of redirects happens at application software > layers higher up the stack and for seperate TLS handshakes, whereas > server endpoint identification is performed for a single TLS-Handshake > directly above TLS. But that does not mean that there is no security > problem. OK, so you are alleging a security problem that is unrelated to the provision in server-id-check for name-mapping services. > I'm trying to describe this behaviour in real world terms, maybe > it becomes clearer that way. > > > The current "server endpoint identification" would mean for the > real world that you perform the matching when you enter the > building (a store, gov. agency, bank, hotel, ...), and from > that point on, blindly trust everything what happens to you. > > Now imagine a subsidiary of Western Union on an exceptionally > busy time of the day with several people waiting in line > waiting to arrage for a money order with cash they're carrying. > > Someone approaches a customer waiting in line and tells him > that they've set up an additional teller in a camping truck > across the street where they can place their money order. > The browser behaviour, to blindly following 301 to other > servers without second thoughts is a serious security problem. This is a false analogy. In the Western Union building, it's expected that there may be other people you don't necessarily trust. But on https://gmail.com, assuming your browser and the server are designed properly and the trusted CAs don't mess up, there is no way for an attacker to introduce a redirect that is not authorized by the registrant of gmail.com. > The "secure link" between the end users intention (who supplied > https://gmail.com) and what the browser actually does > (blindly follow the redirect to https://mail.google.com) is missing. A user who visits https://gmail.com with a modern browser intends the browser to do whatever https://gmail.com says, which in this case is to follow a redirect. > The reference identifier that is passed into the server endpoint > identification for the TLS handshake performed with https://mail.google.com > results from an untrusted name transformation, and this > is very relevant for the security considerations of this I-D. I'm not sure what kind of trust you were expecting here, but the transformation is authorized by https://gmail.com, so there is no reason the user shouldn't trust it for the purpose of interacting with the service she knows as https://gmail.com . It's true that the security considerations section of the draft states, "When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user", but I think that is pretty bogus. HTTP redirects in a web browser are one of many cases in which using a source domain from a source other than the user is the expected behavior. These cases are not going to go away with the publication of the standard. I would prefer to limit the scope of server-id-check to what happens after the source domain is provided (e.g., as an argument to an API call of the client library) and simply emphasize that a conformant client is only as secure as the source domain it is given. In a larger application, it's necessary to ensure that the manner in which the source domain is obtained meets the user's security expectations, but that's something to address in the documentation or standard for the application. -- Matt From matt@mattmccutchen.net Fri Sep 24 14:45:53 2010 Return-Path: <matt@mattmccutchen.net> 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 0A9DA3A6A84 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 14:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 QSqtjxS84Lqf for <certid@core3.amsl.com>; Fri, 24 Sep 2010 14:45:51 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 01B6E3A6A87 for <certid@ietf.org>; Fri, 24 Sep 2010 14:45:50 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 9356B280072; Fri, 24 Sep 2010 14:46:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=UTA/6bJYLYXXw3Ryzt8McJW5UeZmI+mbz1Nh/EFc53X cLQdzf7sCDC4kJp+XiSUa+jtYp2ondwr1aUFcpD+TuyYwkx3f7M8NyEGbSHA0Wwr IVllaCMc/sm/PL7f5iUgI6JxLQDqLRracspBwiutY9OPcxisVFSp5hq9Eg2O5nVE = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=1wT5MXk6pFK078n/TOoj0xUj0/o=; b=trE0Fu4zod VAUeG+jjCF91HKKEednL+fIiSZqn9i1hssVtGhiICzzVnbPjXOenkWpWeoaA7ea0 2X/HzbGKjZ55DUcEPoZD77htxAoJJuNt2jAx/sV7rT3zsJmuQmIZNG004nOe/aDO ZUGIF+wvkeGWhe4TW8OM0gaeLlmyBTWvs= Received: from [206.196.160.254] (wireless-206-196-160-254.umd.edu [206.196.160.254]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 469E5280070; Fri, 24 Sep 2010 14:46:23 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: =JeffH <Jeff.Hodges@KingsMountain.com> In-Reply-To: <4C9CFCE4.1050801@KingsMountain.com> References: <4C9CFCE4.1050801@KingsMountain.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 24 Sep 2010 17:46:11 -0400 Message-ID: <1285364771.1962.39.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Bad certificate handling 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: Fri, 24 Sep 2010 21:45:53 -0000 On Fri, 2010-09-24 at 12:32 -0700, =JeffH wrote: > matt@mattmccutchen.net said: > > Separately, I wonder if it makes sense for server-id-check to > > specifically discuss the handling of certificates that don't match a > > reference identifier when the considerations are essentially the same > > for certificates with other problems (most commonly, expired or > > untrusted issuer) and, indeed, modern browsers tend to provide a single > > UI for these three most common problems. I'm not sure where would be > > the right place to standardize handling of bad certificates in general. > > There is a W3C document, but it only applies to interactive user agents: > > > > http://www.w3.org/TR/wsc-ui/ [WSC-UI] > > Which is entitled: "Web Security Context: User Interface Guidelines" > > Note that we already cite this doc (tho we need to update our cite because it > is now a Recommendation). > > In any case, this is a good catch, thanks. In reading WSC-UI, it appears to > overall address our needs for more full explanation of interactive user agent > behavior in error condition cases (although it doesn't differentiate between > "pinning" a cert temporarily vs permanently). > > Given all this, I suggest we change the last part of the last sentence of the > "Security Note" quoted above to something like.. > > ..., by forcing the user to view the entire certification path > and only then allowing the user to choose whether to accept the > certificate on a temporary or permanent basis. See [WSC-UI] for > further guidance. > > ..and leave it at that in -tls-server-id-check. We should also consider making > [WSC-UI] a normative reference now that it is at Recommendation maturity level. OK. I suggest s/to choose whether //; the point is that the user accepts the certificate. Another issue with WSC-UI that I neglected to point out earlier: it only discusses pinning of certificates with untrusted issuers, so we should make explicit that we are recommending that the WSC-UI treatment of untrusted issuers be applied to name mismatches. And it's awkward to do that if the omission of pinning for name mismatches from WSC-UI was intentional (i.e., the authors thought it was a bad idea). Does anyone know if this is case? -- Matt From rrelyea@redhat.com Fri Sep 24 15:00:18 2010 Return-Path: <rrelyea@redhat.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 399603A6AA7; Fri, 24 Sep 2010 15:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.008 X-Spam-Level: X-Spam-Status: No, score=-110.008 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, 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 cH79sicS8fHQ; Fri, 24 Sep 2010 15:00:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 169963A6A9C; Fri, 24 Sep 2010 15:00:16 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8OM0ihY007067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 18:00:44 -0400 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8OM0efJ003448; Fri, 24 Sep 2010 18:00:40 -0400 Message-ID: <4C9D1F8E.70608@REDHAT.COM> Date: Fri, 24 Sep 2010 15:00:46 -0700 From: Robert Relyea <rrelyea@redhat.com> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5 MIME-Version: 1.0 To: mrex@sap.com References: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> In-Reply-To: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070600000007040902010805" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Mailman-Approved-At: Fri, 24 Sep 2010 15:00:33 -0700 Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, jhutz@cmu.edu Subject: Re: [certid] [TLS] [secdir] secdir review of 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: Fri, 24 Sep 2010 22:00:18 -0000 This is a cryptographically signed message in MIME format. --------------ms070600000007040902010805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/24/2010 01:29 PM, Martin Rex wrote: > Peter Saint-Andre wrote: > =20 >> For context, the "quoted advice" is mostly a description of current >> usage in some existing user agents. Incorporating Barry's suggestions,= >> that text currently reads as follows in our working copy: >> >> Security Note: Some existing interactive user agents give advanc= ed >> users the option of proceeding despite an identity mismatch. >> Although this behavior can be appropriate in certain specialized= >> circumstances, in general it ought to be exposed only to advance= d >> users and even then needs to be handled with extreme caution, fo= r >> example by first encouraging even an advanced user to terminate >> the connection and, if the advanced user chooses to proceed >> anyway, by forcing the user to view the entire certification pat= h >> and only then allowing the user to accept the certificate on a >> temporary basis (i.e., for this connection attempt and all >> subsequent connection attempts for the life of the application >> session, but not for connection attempts during future applicati= on >> sessions). >> =20 > This whole paragraph is evil and completely wrong. > > It's bad enough that the web browser crowds replaced a useful option > and important security feature with an extremely evil scary page. > =20 No, this paragraph is exactly what should happen. Click through dialogs are demonsterably useless. They train users to ignore them. The only place for them is if you decide that validation is not necessary. > Offering to end-users, in a single-time-only leap-of-faith approach sim= ilar > to what SSH has been successfully doing since its invention to memorize= > the peers certificate is magnitudes more secure than the endpoint > identification linking to one of a hundred trust anchors, provisionally= > preconfigured by your software supplier. > =20 SSH is good for small numbers of point to point connections where the user controls both sides. SSH model is not appropriate for the general population connection to millions of webservers. That is why SSH is used extensively in admin deployments (where the admin controls both machines) and is not used for e-commerce. If you want that semantic use SSH. If you want security for the masses, use SSL (with full PKI). [ case where SSL is being used for an SSH use case deleted] bob --------------ms070600000007040902010805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDkyNDIyMDA0NlowIwYJKoZIhvcNAQkEMRYEFOtidkjS6BikRuNHtB4ALmY7eawBMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAJfiL29MZ3MUi9xWIQkWENNLk6TkHp55v/VyezpHbeeXM1InFMCk Brw9SKKv/20HeIkKSQqlCkUVuQRT7pKpD+wRiWPA8HQineQW6qAwn94j/Bg9s2NlV3GC0WUY KZZtWwYa+ngemVM3oYlq8bN5FjV+6AXiWGEZ1ZeOdosht5fff306yaThdmWmY5MaWcNF4py2 xOcgZxZSvTpXU+wRegf+8N7IGFpHK81LrkNWbcQ2h2OV9bTSLo/43R2r19unpR9WBheVFy/q /sDLasHZoVTJoSAJKk3fdbFDbmeBJjpk4uRQhZutN0Vp2bj3a01+eAgvpDobVoymhEdkGow1 RUoAAAAAAAA= --------------ms070600000007040902010805-- From jwkckid1@ix.netcom.com Fri Sep 24 15:15:21 2010 Return-Path: <jwkckid1@ix.netcom.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 8D3283A6AC0; Fri, 24 Sep 2010 15:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 A0--0CpZLpnt; Fri, 24 Sep 2010 15:15:16 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 345863A6A91; Fri, 24 Sep 2010 15:15:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=I8hsuBhNeUkoFqFeoP9Fn9By1K3xWOzCmQYrq/KFrNqN8WxY8PuGYwHceJsKTpWE; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1OzGYK-00071t-8I; Fri, 24 Sep 2010 18:15:36 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 24 Sep 2010 18:15:35 -0400 Message-ID: <7248432.1285366536103.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Fri, 24 Sep 2010 17:15:35 -0500 (GMT-05:00) From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com> To: Robert Relyea <rrelyea@redhat.com>, mrex@sap.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c2c6bf9cb4ca647aad8afc34653425aa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, jhutz@cmu.edu Subject: Re: [certid] [TLS] [secdir] secdir review of X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com> 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: Fri, 24 Sep 2010 22:15:22 -0000 bob and all, I think Bob's exactly right here. Thanks bob for being so concise. >:) -----Original Message----- >From: Robert Relyea <rrelyea@redhat.com> >Sent: Sep 24, 2010 5:00 PM >To: mrex@sap.com >Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, jhutz@cmu.edu >Subject: Re: [TLS] [secdir] secdir review of > >On 09/24/2010 01:29 PM, Martin Rex wrote: >> Peter Saint-Andre wrote: >> >>> For context, the "quoted advice" is mostly a description of current >>> usage in some existing user agents. Incorporating Barry's suggestions, >>> that text currently reads as follows in our working copy: >>> >>> Security Note: Some existing interactive user agents give advanced >>> users the option of proceeding despite an identity mismatch. >>> Although this behavior can be appropriate in certain specialized >>> circumstances, in general it ought to be exposed only to advanced >>> users and even then needs to be handled with extreme caution, for >>> example by first encouraging even an advanced user to terminate >>> the connection and, if the advanced user chooses to proceed >>> anyway, by forcing the user to view the entire certification path >>> and only then allowing the user to accept the certificate on a >>> temporary basis (i.e., for this connection attempt and all >>> subsequent connection attempts for the life of the application >>> session, but not for connection attempts during future application >>> sessions). >>> >> This whole paragraph is evil and completely wrong. >> >> It's bad enough that the web browser crowds replaced a useful option >> and important security feature with an extremely evil scary page. >> > >No, this paragraph is exactly what should happen. Click through dialogs >are demonsterably useless. They train users to ignore them. The only >place for them is if you decide that validation is not necessary. >> Offering to end-users, in a single-time-only leap-of-faith approach similar >> to what SSH has been successfully doing since its invention to memorize >> the peers certificate is magnitudes more secure than the endpoint >> identification linking to one of a hundred trust anchors, provisionally >> preconfigured by your software supplier. >> >SSH is good for small numbers of point to point connections where the >user controls both sides. SSH model is not appropriate for the general >population connection to millions of webservers. That is why SSH is used >extensively in admin deployments (where the admin controls both >machines) and is not used for e-commerce. If you want that semantic use >SSH. If you want security for the masses, use SSL (with full PKI). > > >[ case where SSL is being used for an SSH use case deleted] > >bob > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From Jeff.Hodges@KingsMountain.com Fri Sep 24 15:46:43 2010 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 59C363A6AC0 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 15:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.122 X-Spam-Level: X-Spam-Status: No, score=-102.122 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 3rTE-7sFxqdT for <certid@core3.amsl.com>; Fri, 24 Sep 2010 15:46:43 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 29B7A3A69A8 for <certid@ietf.org>; Fri, 24 Sep 2010 15:46:43 -0700 (PDT) Received: (qmail 15512 invoked by uid 0); 24 Sep 2010 22:39:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 24 Sep 2010 22:39:55 -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=QsdB4qDzlq7iIgDlWq/z12+aJU7Hyt1GUx21EJdL0kgHycejmkMfBJHeus4Moc+mI0Pg074FBGsvYdD41IeYXTDf4peNZYc5onN1UazBGT6me/C9OiZE0v95o874+mlo; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OzGvr-0000Mn-JM; Fri, 24 Sep 2010 16:39:55 -0600 Message-ID: <4C9D28BB.7010604@KingsMountain.com> Date: Fri, 24 Sep 2010 15:39:55 -0700 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Rex <mrex@sap.com> 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, jhutz@cmu.edu Subject: Re: [certid] [TLS] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 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: Fri, 24 Sep 2010 22:46:43 -0000 On 09/24/2010 01:29 PM, Martin Rex wrote: > Peter Saint-Andre wrote: > >> For context, the "quoted advice" is mostly a description of current >> usage in some existing user agents. Incorporating Barry's suggestions, >> that text currently reads as follows in our working copy: >> >> Security Note: Some existing interactive user agents give advanced >> users the option of proceeding despite an identity mismatch. >> Although this behavior can be appropriate in certain specialized >> circumstances, in general it ought to be exposed only to advanced >> users and even then needs to be handled with extreme caution, for >> example by first encouraging even an advanced user to terminate >> the connection and, if the advanced user chooses to proceed >> .... > > This whole paragraph is evil and completely wrong. PeterSA and I disagree, and echo rrelyea's sentiments. For some background context, see.. ForceHTTPS: Protecting High-Security Web Sites from Network Attacks Collin Jackson and Adam Barth In Proceedings of the 17th International World Wide Web Conference (WWW2008) https://crypto.stanford.edu/forcehttps/forcehttps.pdf See also.. HTTP Strict Transport Security (HSTS) http://tools.ietf.org/html/draft-hodges-strict-transport-sec Firefox 4.0 beta 5 <http://blog.mozilla.com/blog/2010/09/07/firefox-4-beta-with-faster-graphics-and-new-audio-capabilities-for-the-web/> "HTTP Strict Transport Security (HSTS) is a new security protocol in Firefox 4 Beta..." =JeffH From Jeff.Hodges@KingsMountain.com Fri Sep 24 16:00:55 2010 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 506053A6B63 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 16:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 qARkU-SGFuPE for <certid@core3.amsl.com>; Fri, 24 Sep 2010 16:00:54 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 3BBE83A6B54 for <certid@ietf.org>; Fri, 24 Sep 2010 16:00:54 -0700 (PDT) Received: (qmail 12605 invoked by uid 0); 24 Sep 2010 23:01:26 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 24 Sep 2010 23:01:26 -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:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=Met8jSEZxjhuU/xWcCyxjBuBYx/Fk8NixCDsr8afstlMNdryZDXGlRc1zVrQfXon9EwLZ0iKvB1jzLYecuM72l73D4FRrQkptscXHxrrIEBgwHT3p5QcjgccCQSM1q6z; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OzHGg-0002dh-JV for certid@ietf.org; Fri, 24 Sep 2010 17:01:26 -0600 Message-ID: <4C9D2DC6.3000202@KingsMountain.com> Date: Fri, 24 Sep 2010 16:01:26 -0700 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity <certid@ietf.org> 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] Bad certificate handling 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: Fri, 24 Sep 2010 23:00:55 -0000 > > Given all this, I suggest we change the last part of the last sentence of > > the "Security Note" quoted above to something like.. > > > > ..., by forcing the user to view the entire certification path > > and only then allowing the user to choose whether to accept the > > certificate on a temporary or permanent basis. See [WSC-UI] for > > further guidance. > > > > ..and leave it at that in -tls-server-id-check. We should also consider > > making [WSC-UI] a normative reference now that it is at Recommendation > > maturity level. > > OK. I suggest s/to choose whether //; the point is that the user > accepts the certificate. I tend to think we ought to at least mention the notion that the cert can be accepted either temporarily or permanently. > Another issue with WSC-UI that I neglected to point out earlier: it only > discusses pinning of certificates with untrusted issuers hm, indeed. This would be an issue if we were to cite WSC-UI normatively, but not if we do so only informatively, so I'm now thinking we ought to keep it as the latter. > if the omission of pinning for name mismatches from WSC-UI was > intentional (i.e., the authors thought it was a bad idea). Does anyone > know if this is case? don't know, but it's easy to ask. =JeffH From mrex@sap.com Fri Sep 24 16:27:00 2010 Return-Path: <mrex@sap.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 372B83A69A8 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 16:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.823 X-Spam-Level: X-Spam-Status: No, score=-9.823 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 mcjpLIeaeYKQ for <certid@core3.amsl.com>; Fri, 24 Sep 2010 16:26:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B40693A6814 for <certid@ietf.org>; Fri, 24 Sep 2010 16:26:58 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8ONRP8d026535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Sep 2010 01:27:30 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009242327.o8ONRErW003884@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Sat, 25 Sep 2010 01:27:14 +0200 (MEST) In-Reply-To: <1285361799.1962.4.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 24, 10 04:56:39 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Fri, 24 Sep 2010 23:27:00 -0000 Matt McCutchen wrote: > > A user who visits https://gmail.com with a modern browser intends the > browser to do whatever https://gmail.com says, which in this case is to > follow a redirect. But what if he does not? As if he had a choice. The only intention that can be reliably deduced from a user supplying an hostname as a target address, is that a user wants to "enter" exactly _that_ site. And server endpoint identification does nothing else than a plausibility check whether the user is entering where he asked to enter. What you describe, and what web browsers are doing, appears to be a pretty bold and unwarranted assertion about what the users intentions must be "by using a modern browser" (I don't think that is a _new_ browser behaviour). > > > The reference identifier that is passed into the server endpoint > > identification for the TLS handshake performed with https://mail.google.com > > results from an untrusted name transformation, and this > > is very relevant for the security considerations of this I-D. > > I'm not sure what kind of trust you were expecting here, but the > transformation is authorized by https://gmail.com, so there is no reason > the user shouldn't trust it for the purpose of interacting with the > service she knows as https://gmail.com . This transformation is _NOT_ authorized by the user, so if anything deserves a scary warning page, then it's this transition. The user only said "enter that site", I do not think it is appropriate for the browser to turn this into "go to that site and totally enslave me". Not everyone might be thrilled by such conduct as much as you make it appear. > > It's true that the security considerations section of the draft states, > "When the connecting application is an interactive client, the source > domain name and service type MUST be provided by a human user", but I > think that is pretty bogus. The intention of this is right on the spot, but it falls short. The important part is that the reference identifier comes only from a source that is trusted by the user or admin of the system, which may be a local preconfiguration, a persisted prior target (e.g. bookmark), or a configuration for a non-interactive client software. If all web-servers on the internet would enable TLS (which is what Google has suggested), your line of thought would mean that everyone will trust everybode else with everything on the internet, starting with a https://www.google.com search. Perfect world? You sure? > > HTTP redirects in a web browser are one of many cases in which using > a source domain from a source other than the user is the expected > behavior. It is expected behaviour for HTTP. Retaining such behaviour for HTTPS will wash most of the original security down the drain. > > These cases are not going to go away > with the publication of the standard. Correct. But "new/modern" browsers are so extremely buggy and dangerous^W^W^Wfeature-rich and constantly enhanced that people will quickly and eagerly upgrade to every new version coming out (so I've been told). > > I would prefer to limit the scope of server-id-check to what happens > after the source domain is provided (e.g., as an argument to an API call > of the client library) and simply emphasize that a conformant client is > only as secure as the source domain it is given. Doing server-id-check for the sole purpose of labeling a software as "RFCxxxx compliant" would be somewhat of a waste of IETF resources. The original idea behind server-id-check was that the client software could ensure that a users valuable or sensitive information is NOT going to be sent to some other site than the one the user requested. By disconnecting the server-id-check requested by the user from the server identity to which the users data will actually be sent, there is nothing much left in terms of security from the original server endpoint identification (which, when based on a software suppliers pre-configured list of ~100 trust anchors, wasn't terribly strong to begin with). -Martin From Jeff.Hodges@KingsMountain.com Fri Sep 24 17:22:07 2010 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 073813A6B89 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 17:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.127 X-Spam-Level: X-Spam-Status: No, score=-102.127 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 gj+nRT7p9ceD for <certid@core3.amsl.com>; Fri, 24 Sep 2010 17:22:05 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id C19B43A6B6A for <certid@ietf.org>; Fri, 24 Sep 2010 17:22:05 -0700 (PDT) Received: (qmail 6905 invoked by uid 0); 25 Sep 2010 00:22:38 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 25 Sep 2010 00:22:38 -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:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=KgZ+xziV4kDY5NU98JwGSzwPUm+AY1ymuSc8oSuFeHNrPKSAogju0f2ZhBqyIfm8TwFk3qSh4l22d1f/hChUWDkNzt6MAI1n/TbDbmNiwqHAz8Kww2l9YR92Gxq9yOXV; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OzIXG-0003Oc-9S; Fri, 24 Sep 2010 18:22:38 -0600 Message-ID: <4C9D40CF.6050107@KingsMountain.com> Date: Fri, 24 Sep 2010 17:22:39 -0700 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity <certid@ietf.org>, Martin Rex <mrex@sap.com> 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] user agent redirection is inherently "insecure" (was: Re: review of draft-saintandre-tls-server-id-check-09) 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: Sat, 25 Sep 2010 00:22:07 -0000 I sense topic-drift and a rat-hole here. I'm gonna try to put a concise box over the hole.. Martin replied: > > Matt replied: > >> Martin wrote: >> > The only intention that can be reliably deduced from a user supplying > an hostname as a target address, is that a user wants to "enter" > exactly _that_ site. > > ... > >> > The reference identifier that is passed into the server endpoint >> > identification for the TLS handshake performed with https://mail.google.com >> > results from an untrusted name transformation, and this >> > is very relevant for the security considerations of this I-D. >> >> I'm not sure what kind of trust you were expecting here, but the >> transformation is authorized by https://gmail.com, so there is no reason >> the user shouldn't trust it for the purpose of interacting with the >> service she knows as https://gmail.com . > > This transformation is _NOT_ authorized by the user, so if anything > deserves a scary warning page, then it's this transition. > > The user only said "enter that site", I do not think it is > appropriate for the browser to turn this into "go to that site > and totally enslave me". The redirect behavior you are complaining about is (as we all know) a core facet of the HTTP protocol. Said protocol doesn't differentiate such behavior based on whether it is running over secure transport or not. This is simply how it works, for better or worse. Also, generously cross-mapping domain names for administrative and user convenience is a common practice. From Google's perspective, the "name" gmail.com maps to mail.google.com, and that's their decision to make since it's their web application they are offering. Its probably more straightforward in their app code for all the app URIs to use the authority component of "mail.google.com" rather than that of whatever entry point (e.g. "gmail.com") the user selected (by whatever means). Kudos to them for doing it all properly over TLS/SSL such that no errors pop up. In any case, HTTP redirects are a fact, as are multiple (DNS) names for (web) applications/services/servers/entities. "the Web" is built on both of these. Doing it all over secure transport isn't *necessarily* different than doing it over unsecured transport. We (who're working on -tls-server-id-check) are not going to address or change the above (in this spec) and so I feel further stepping down this rat-hole is inappropriate in discussing this spec. That said, I acknowledge that HTTP redirects can be put to all sorts of evil use, and perhaps the "Web Security Context: User Interface Guidelines (WSC-UI)" <http://www.w3.org/TR/wsc-ui/> should more explicitly and thoroughly discuss user agent behavior in terms of when one is "redirected away from" a "secure web app". Note that the user agent on its own, without guidance from such an app or prior configuration, determine whether any particular redirect is "authorized" or not (and neither can the user) due to aforementioned DNS name mapping, app linking, etc. We've all seen those app warnings from time to time "you're about to be redirected away from our site/app, just be aware, click here to follow the link..." -- this doesn't appear to be mentioned in WSC-UI. HTH, =JeffH From mrex@sap.com Fri Sep 24 17:22:20 2010 Return-Path: <mrex@sap.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 6A0873A6B6A for <certid@core3.amsl.com>; Fri, 24 Sep 2010 17:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.828 X-Spam-Level: X-Spam-Status: No, score=-9.828 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 YtW7iAp1KCra for <certid@core3.amsl.com>; Fri, 24 Sep 2010 17:22:19 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 434543A6AA5 for <certid@ietf.org>; Fri, 24 Sep 2010 17:22:19 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8P0MpiY003321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Sep 2010 02:22:51 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009250022.o8P0Mo2A007079@fs4113.wdf.sap.corp> To: Jeff.Hodges@KingsMountain.com (=JeffH) Date: Sat, 25 Sep 2010 02:22:50 +0200 (MEST) In-Reply-To: <4C9CFCE4.1050801@KingsMountain.com> from "=JeffH" at Sep 24, 10 12:32:52 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Bad certificate handling X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Sat, 25 Sep 2010 00:22:20 -0000 =JeffH wrote: > > > http://www.w3.org/TR/wsc-ui/ [WSC-UI] > > Which is entitled: "Web Security Context: User Interface Guidelines" Thanks for providing this link !! Section 5.1.4 here: http://www.w3.org/TR/wsc-ui/#selfsignedcerts is much closer what I this would be useful and sensible. "Pinning" of certs is useful for both, certs that validate fine and certs that do not validate for the two reasons "not trusted" and "server-id-mismatch". > > Given all this, I suggest we change the last part of the last sentence of the > "Security Note" quoted above to something like.. > > ..., by forcing the user to view the entire certification path > and only then allowing the user to choose whether to accept the > certificate on a temporary or permanent basis. See [WSC-UI] for > further guidance. What is the idea behind visualizing the full chain? I've seen the same in 5.1.4 of the WSC-UI document but there's no rationale given and I can not think of one. If the purpose is memorizing and "pinning" a server cert, there is no point in visualizing the certificate chain. Either there is no trust, then the chain can be crafted to look like anything, or it is trusted, then -- well it is trusted and there is no point (for Joe Average User) in looking at the chain, because this chain has passed certificate path validation. -Martin From mrex@sap.com Fri Sep 24 20:09:04 2010 Return-Path: <mrex@sap.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 EB8AB3A68A8 for <certid@core3.amsl.com>; Fri, 24 Sep 2010 20:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.233 X-Spam-Level: X-Spam-Status: No, score=-9.233 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] 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 30vYl8SU4O2u for <certid@core3.amsl.com>; Fri, 24 Sep 2010 20:09:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 2B08C3A685B for <certid@ietf.org>; Fri, 24 Sep 2010 20:09:02 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8P39Y2o015666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Sep 2010 05:09:34 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Sat, 25 Sep 2010 05:09:28 +0200 (MEST) In-Reply-To: <1285304514.1939.337.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 24, 10 01:01:54 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Sat, 25 Sep 2010 03:09:05 -0000 Matt McCutchen wrote: > > Name constraints are designed to support secure delegation of the > ability to issue certificates for a portion of the namespace. Why > wouldn't CAs use them for that purpose? Just because you said so? Terminology confusion. Name constraints do not delegate anything. They authorize subordinate CA to issuer certs within specific constraints. And delegation in DNS is represented by DNS "NS" records and managed by domain registrars. > > A certificate that violates a name constraint is invalid, and under any > sane contract or legal system, the superior CA will not be liable to > anyone who relies on an invalid certificate. 99.999% of TLS server certs are accepted by TLS clients is absence of contracts between TLS client and issuing CA. ~50% of the installed base of TLS (Windows XP&2003) does not check vor TLS server cert revocation, although there is probably no CAs left among those ~100 valid pre-trusted RootCAs that do not offer CRLs distribution points or OCSP responders. If there are any relevant contracts involving meaningful liabilities, it is likely among superior and subordinate CAs. Even server cert customers are kept at bay with fancy "Certificate Practice Statements". > > Matching a reference server name against a CN-ID that violates a dNSName > constraint defeats the purpose of name constraints. With respect to > clients willing to do this, a name constraint is a security no-op. No, it is not. If there is anything wrong, then it is the server endpoint identification algorithm that is abusing X.509. Name Constraints processing, as specified by PKIX, is NONE of the apps business. Processing of name constraints is exclusively the task of the certificate path validation implementation within the PKI software, and the app doesn't need to know or care whether and which subtrees were collected while building the certification path and later processed during certificate path validation. > > > Go kick the PKIX folks if you don't like how it is spec'ed, > > but leave the apps folks alone. I believe that asking the apps > > folks to regurgitate and re-chew stuff that the PKIX part didn't > > process to someone's satisfaction is an _extremely_ bad idea. > > server-id-check is built on PKIX, not vice versa, so server-id-check is > responsible for the security consequences of the CN-ID that it defines > for the name constraints defined by PKIX. It has the option to solve > the problem or say "this breaks the security of name constraints and we > know it", which would be laughable for a standard. 10 years ago, the use of CN-ID has been deprecated by rfc-2818 and been specified to not be used when DNSName SAN is present. It seems like a bad idea to massively increase the complexity of a long deprecated server identification scheme, and in a fashion that is not only a magnitude more complex, but also amounts to a gruesome breach of the PKIX architecture. I'm sorry for having totally missed the TLS&IETF consenus to abandon subjectAltNames for server-id-check and to resurrect CN-IDs. There may not be an API in the PKI software for returning to the app the hierarchy of dNSName name constraints collected while composing the cert path and processed during cert path validation, which the app would need for a seconds constraints check when it decides to try a CN-ID matching fallback. If doing DNSName constraints checking proactively during cert path validation should be allowed, then a REALLY big warning label would be necessary that CN AVAs must either contain a valid f.q.d.n or be ABSENT from the server cert subject DName to prevent false negatives (i.e. name constraints violation errors) in those new TLS implementations that adopt this fancy logic. > > NSS now enforces name constraints on the CN-ID > (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains > backward compatible with the web by virtue of the fact that the public > CAs aren't using name constraints yet. If the CAs start doing so, all > an inferior CA has to do for things to work is to include a dNSName SAN, > which is a SHOULD anyway. I think it would be more sensible to let CN-IDs rest in peace and simply skip the CN-ID matching fallback entirely if the CA cert, which signed the server cert, contains a name constraints extension. -Martin From matt@mattmccutchen.net Sat Sep 25 13:30:58 2010 Return-Path: <matt@mattmccutchen.net> 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 2E1813A6B8A for <certid@core3.amsl.com>; Sat, 25 Sep 2010 13:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.985 X-Spam-Level: X-Spam-Status: No, score=-1.985 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] 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 jMEHsTLmYjG6 for <certid@core3.amsl.com>; Sat, 25 Sep 2010 13:30:49 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 4BDE63A69B5 for <certid@ietf.org>; Sat, 25 Sep 2010 13:30:49 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 1F285280074; Sat, 25 Sep 2010 13:31:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=YwoO9LvLU+4wEMeT9M/j1stWf1mvVPj3UMlmWLaKZ6t uoP2BGgniaiDMowX1Mu4MDSPHgoO/BYqLWjJaYSSAiIkaPBcJzwrec5YZH6A+83Q GQ7Eu3sU7biN93n6vWN29uUkqn77g13Rk+vlhIT3gi2B4nyHXTORvnvjN3JP3GI4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=B9UmklgVUR5eKcmVAwtagGcFaIA=; b=qluLLi2K5A cipZ7is8aKJbEhF4uY/Z4GMXdNaLGK1sN3LYEL01uP3dSfXXukoagm2b0EK9G5w9 lyMhFLe1UNmkyxaCthr7TrjeMApfGjBP8P/lBmZsEDmc9wSHZVS+pRNvfHgkljAq m9bbd1CMVm6I+wT4IKUtQ+y9x6SzMC9DA= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id D08FC280073; Sat, 25 Sep 2010 13:31:23 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Sat, 25 Sep 2010 16:31:22 -0400 Message-ID: <1285446682.1940.21.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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: Sat, 25 Sep 2010 20:30:58 -0000 On Sat, 2010-09-25 at 05:09 +0200, Martin Rex wrote: > Matt McCutchen wrote: > > Matching a reference server name against a CN-ID that violates a dNSName > > constraint defeats the purpose of name constraints. With respect to > > clients willing to do this, a name constraint is a security no-op. > > No, it is not. If there is anything wrong, then it is the > server endpoint identification algorithm that is abusing X.509. > > Name Constraints processing, as specified by PKIX, is NONE of the > apps business. Processing of name constraints is exclusively > the task of the certificate path validation implementation > within the PKI software, and the app doesn't need to know or > care whether and which subtrees were collected while > building the certification path and later processed during > certificate path validation. I was making an observation, not discussing blame or design. Do you deny the truth of the observation? > > > Go kick the PKIX folks if you don't like how it is spec'ed, > > > but leave the apps folks alone. I believe that asking the apps > > > folks to regurgitate and re-chew stuff that the PKIX part didn't > > > process to someone's satisfaction is an _extremely_ bad idea. > > > > server-id-check is built on PKIX, not vice versa, so server-id-check is > > responsible for the security consequences of the CN-ID that it defines > > for the name constraints defined by PKIX. It has the option to solve > > the problem or say "this breaks the security of name constraints and we > > know it", which would be laughable for a standard. > > > 10 years ago, the use of CN-ID has been deprecated by rfc-2818 and > been specified to not be used when DNSName SAN is present. Unfortunately, CN-IDs are still widely used, and the browser vendors have little power to push for their eradication. See: https://bugzilla.mozilla.org/show_bug.cgi?id=552346 > > It seems like a bad idea to massively increase the complexity > of a long deprecated server identification scheme, and in a > fashion that is not only a magnitude more complex, but > also amounts to a gruesome breach of the PKIX architecture. > > > I'm sorry for having totally missed the TLS&IETF consenus to abandon > subjectAltNames for server-id-check and to resurrect CN-IDs. > > > There may not be an API in the PKI software for returning to > the app the hierarchy of dNSName name constraints collected while > composing the cert path and processed during cert path validation, > which the app would need for a seconds constraints check > when it decides to try a CN-ID matching fallback. > > If doing DNSName constraints checking proactively during cert path > validation should be allowed, then a REALLY big warning label > would be necessary that CN AVAs must either contain a valid f.q.d.n > or be ABSENT from the server cert subject DName to prevent false > negatives (i.e. name constraints violation errors) in those > new TLS implementations that adopt this fancy logic. Or the server cert can include a dNSName SAN. In that case, the CN is not constrained because it is not used for matching anyway. > > NSS now enforces name constraints on the CN-ID > > (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains > > backward compatible with the web by virtue of the fact that the public > > CAs aren't using name constraints yet. If the CAs start doing so, all > > an inferior CA has to do for things to work is to include a dNSName SAN, > > which is a SHOULD anyway. > > > I think it would be more sensible to let CN-IDs rest in peace and > simply skip the CN-ID matching fallback entirely if the CA cert, > which signed the server cert, contains a name constraints extension. That's another fine option, though it has the same problem -- Matt From matt@mattmccutchen.net Sat Sep 25 13:32:50 2010 Return-Path: <matt@mattmccutchen.net> 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 453143A69B5 for <certid@core3.amsl.com>; Sat, 25 Sep 2010 13:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 FjpdED7D4ucA for <certid@core3.amsl.com>; Sat, 25 Sep 2010 13:32:49 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by core3.amsl.com (Postfix) with ESMTP id 721933A695D for <certid@ietf.org>; Sat, 25 Sep 2010 13:32:49 -0700 (PDT) Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 649A3280073; Sat, 25 Sep 2010 13:33:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=J7BJaTk9Nxn/YN1A9JifWD0uLxBXbwhsdjh2X0atuIJ prJIDO3orwj/D6hDzJmb5Dr4n1/P12LrIYUmb4BADXzRQM61nYIi25g7oxLo0ebp 3hVIiE1bAJ6VszsBF2y+GYy2XrlbjJGWrydn+08XOxGiO65ec5fjZduFNeKI4sPM = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=I8Qj1PkcBiFhIZtkzTQsViXELt4=; b=uHBS3+w1v8 u1DbeRDs22aqhbr8z6voo4uqw4uzLoMJAB7LFvDPp8D4gWHFJb87keUQF43GJ/Y8 yOG0AT+YxaxaoPS1kQkkcgMrjb51Qazfnj8/lKhZHdd+yG9+/UQl+beYxIiriQo0 M57nZhwqSRP+W7aUUffynw0lBxe6c94ug= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPA id E3B4E28006C; Sat, 25 Sep 2010 13:33:23 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <1285446682.1940.21.camel@mattlaptop2.local> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> <1285446682.1940.21.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Sat, 25 Sep 2010 16:33:22 -0400 Message-ID: <1285446802.1940.23.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints (oops) 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: Sat, 25 Sep 2010 20:32:50 -0000 On Sat, 2010-09-25 at 16:31 -0400, Matt McCutchen wrote: > [...] That's another fine option, though it has the same problem Please disregard this unfinished message. I am having a problem with unintentionally hitting my mail client's Send keybinding. I will send a corrected version. -- Matt From matt@mattmccutchen.net Sat Sep 25 14:31:53 2010 Return-Path: <matt@mattmccutchen.net> 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 E15823A6AE7 for <certid@core3.amsl.com>; Sat, 25 Sep 2010 14:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 HjP4PDFjkI21 for <certid@core3.amsl.com>; Sat, 25 Sep 2010 14:31:48 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id 6A49F3A69FB for <certid@ietf.org>; Sat, 25 Sep 2010 14:31:47 -0700 (PDT) Received: from homiemail-a1.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTP id 3E72334806A; Sat, 25 Sep 2010 14:32:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=dn5N1z30dyQOXsuk2tjlCuGv6f1zxPSEUfc8FsIi0q3 0J0RBt2Q8MxOYI/Sev148Y4e1V/EvHxXlE3ZdiHArWg1jPi+jQyRbTKLG47BFUJS PZCkELrWZEW2Wt+hoDYgjUmBm7DhnFGvDrx6Wn5+4TUPXqh4vnzI+XbHGW1vVszA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=NQCea66xvpOUZvJu3HVun6/Uwr4=; b=FcN4MlXKLi BkdkwIh9ChMO5w7y1grZ1OUdf2GYKyz/mA/XcK6ix9yk4gkNqaFe7X4jDEzDdIpJ Nldcof4fQ/BQXOAGLDWU7Nhddmf+hzGH+6J8FBaOd0hyAN2fYOOPcgmCnUT7LN+j YYc7FuXfR0EcHn86LdgslHwHhmIgOP6Io= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a1.g.dreamhost.com (Postfix) with ESMTPA id EFE2E348060; Sat, 25 Sep 2010 14:32:21 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Sat, 25 Sep 2010 17:32:21 -0400 Message-ID: <1285450341.1940.79.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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: Sat, 25 Sep 2010 21:31:53 -0000 On Sat, 2010-09-25 at 05:09 +0200, Martin Rex wrote: > Matt McCutchen wrote: > > Matching a reference server name against a CN-ID that violates a dNSName > > constraint defeats the purpose of name constraints. With respect to > > clients willing to do this, a name constraint is a security no-op. > > No, it is not. If there is anything wrong, then it is the > server endpoint identification algorithm that is abusing X.509. > > Name Constraints processing, as specified by PKIX, is NONE of the > apps business. Processing of name constraints is exclusively > the task of the certificate path validation implementation > within the PKI software, and the app doesn't need to know or > care whether and which subtrees were collected while > building the certification path and later processed during > certificate path validation. I was making an observation, not discussing blame or design. Do you deny the truth of the observation? > 10 years ago, the use of CN-ID has been deprecated by rfc-2818 and > been specified to not be used when DNSName SAN is present. Unfortunately, CN-IDs are still widely used, and the browser vendors have little power to push for their eradication. See https://bugzilla.mozilla.org/show_bug.cgi?id=552346 . > It seems like a bad idea to massively increase the complexity > of a long deprecated server identification scheme, and in a > fashion that is not only a magnitude more complex, but > also amounts to a gruesome breach of the PKIX architecture. Yes, this is a really ugly situation, but I think making name constraints secure should be the first priority. > I'm sorry for having totally missed the TLS&IETF consenus to abandon > subjectAltNames for server-id-check and to resurrect CN-IDs. That is not what is happening. SANs have not been abandoned, and CN-IDs have not been resurrected (they have been carried over from RFC 2818). > There may not be an API in the PKI software for returning to > the app the hierarchy of dNSName name constraints collected while > composing the cert path and processed during cert path validation, > which the app would need for a seconds constraints check > when it decides to try a CN-ID matching fallback. > > If doing DNSName constraints checking proactively during cert path > validation should be allowed, then a REALLY big warning label > would be necessary that CN AVAs must either contain a valid f.q.d.n > or be ABSENT from the server cert subject DName to prevent false > negatives (i.e. name constraints violation errors) in those > new TLS implementations that adopt this fancy logic. Or the server cert can include a dNSName SAN. In that case, the CN is not constrained because it is not used for matching anyway. > > > NSS now enforces name constraints on the CN-ID > > > (https://bugzilla.mozilla.org/show_bug.cgi?id=394919) and remains > > > backward compatible with the web by virtue of the fact that the public > > > CAs aren't using name constraints yet. If the CAs start doing so, all > > > an inferior CA has to do for things to work is to include a dNSName SAN, > > > which is a SHOULD anyway. > > I think it would be more sensible to let CN-IDs rest in peace and > simply skip the CN-ID matching fallback entirely if the CA cert, > which signed the server cert, contains a name constraints extension. That's another fine approach, though the NSS behavior has the advantage of making it possible to cross-certify an existing CA that uses CN-IDs and apply name constraints, which is a huge win for me. I deal with several organizational CAs that I don't want to trust for the entire web but would gladly cross-certify for their own domains, and currently I am adding a certificate exception for each server after manual verification, which is a huge PITA. So there are four viable approaches: 0. Don't use the CN-ID. 1. Use the CN-ID only if there are no name constraints. 2. Use the CN-ID only if it satisfies the name constraints (if any). 3. Have certificate validation apply name constraints to the CN unless there are dNSName SANs or it has some other reason to believe that the CN will not be used as a CN-ID. (Implemented in NSS.) #0 is incompatible with much of today's web. #1 and #2 require the server ID check to know about name constraints. #3 risks rejecting certificates that contain no dNSName SAN and a CN that was not intended as a CN-ID. I propose that section 4.4.4 be changed as follows: Old: "...the client MAY as a fallback check for a string whose form matches that of a fully-qualified DNS domain name in the CN-ID." New: "...the client MAY as a fallback check for a string whose form matches that of a fully-qualified DNS domain name in the CN-ID, provided that this domain name satisfies any name constraints on the certification path as defined by [PKIX] section 4.2.1.10." On a tangent, I'm unhappy with the idea that the server ID check should be separate from certificate validation, or even implemented in the application rather than the TLS library. Applications will screw it up; I'd rather the TLS library get it right once and provide an API that accepts the list of reference identifiers and any other flags necessary to address the needs of applications. And combining the server ID check with certificate validation makes it possible (if desired) to apply name constraints only to the presented identifier that is actually used, which could be useful in some cross-certification scenarios. -- Matt From Nicolas.Williams@oracle.com Fri Sep 24 21:21:55 2010 Return-Path: <Nicolas.Williams@oracle.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 82D173A68BB; Fri, 24 Sep 2010 21:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] 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 gCGswl0JCHub; Fri, 24 Sep 2010 21:21:54 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 78EAF3A6886; Fri, 24 Sep 2010 21:21:54 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8P4MNCh031176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Sep 2010 04:22:24 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8ONQ7iA028003; Sat, 25 Sep 2010 04:22:23 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 629328651285388542; Fri, 24 Sep 2010 21:22:22 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Sep 2010 21:22:22 -0700 Date: Fri, 24 Sep 2010 23:22:17 -0500 From: Nicolas Williams <Nicolas.Williams@oracle.com> To: Robert Relyea <rrelyea@redhat.com> Message-ID: <20100925042217.GI9501@oracle.com> References: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> <4C9D1F8E.70608@REDHAT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9D1F8E.70608@REDHAT.COM> User-Agent: Mutt/1.5.20 (2010-03-02) X-Mailman-Approved-At: Sat, 25 Sep 2010 16:59:57 -0700 Cc: secdir@ietf.org, jhutz@cmu.edu, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, tls@ietf.org Subject: Re: [certid] [TLS] [secdir] secdir review of 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: Sat, 25 Sep 2010 04:21:55 -0000 On Fri, Sep 24, 2010 at 03:00:46PM -0700, Robert Relyea wrote: > SSH is good for small numbers of point to point connections where the > user controls both sides. SSH model is not appropriate for the general > population connection to millions of webservers. That is why SSH is used > extensively in admin deployments (where the admin controls both > machines) and is not used for e-commerce. If you want that semantic use > SSH. If you want security for the masses, use SSL (with full PKI). It shall not surprise anyone that I don't quite agree with the above. That is, I agree with the part about the pre-shared public keys (ssh known_hosts files) not scaling (not even to a corporate network), and the part about ssh leap-of-faith not being a great model (though you were not that specific). In particular, what PKI is this that you speak of? The PKI we have is not really. Even leap-of-faith is better than the "PKI" we have now. The PKI we will have (DNSSEC) (one hopes) won't be a joke. But even a true PKI, with one root (or one root per-country or region of the world) is not quite what we need -- though it just might well do well enough. I would much prefer federated authentication mechanisms + channel binding to TLS -- TLS is the secure transport that we have for HTTP, and TLS is a decent enough secure transport, if you don't care about authentication. Yes, a combination of "PKI" (and "stickiness") may well be part of how federated authentication mechanisms work, but even so, the impact of "PKI" on the user agent and UIs would be minimized, and that'd be a very good thing. Nico -- From matt@mattmccutchen.net Sun Sep 26 08:20:38 2010 Return-Path: <matt@mattmccutchen.net> 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 50DF93A6A96 for <certid@core3.amsl.com>; Sun, 26 Sep 2010 08:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 0RfF7l9OHMiW for <certid@core3.amsl.com>; Sun, 26 Sep 2010 08:20:37 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 2F5CF3A695A for <certid@ietf.org>; Sun, 26 Sep 2010 08:20:37 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id C1B8F51C063; Sun, 26 Sep 2010 08:21:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Dl44w77zvWKBPB/QtBds/lFiUHbRkAMrnTEhVrlhwa8 w+8HY98/cG6hswIWVFmyzNESGi9mZ6/UL7hVR1egchaBJ5DDF+cFLzPtr1sQFOLx cwsbpGGdGH2U5XHRw6F0h+xjDOeS9hkgHxzPKwMwMyZGw8/H6zGMoGl3tSyuOI14 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=4JGTAgjbxmrxU3V8+Mq2PF40dIY=; b=mXalC/w4ty RMIP7PBNcsfDL8/dnmG8zt1rfS3l010aaHDyLbq2XawVJLduOPb2VGlzDmvHCljB oGIwCCIlt11fz8u43f2khvj82onpZQmpel51USoslpsfVbjU29knZb74rv014y9F 3VpB6ZdkSZN9T3pj08Qz2FYQxZaCDYnvs= Received: from [206.196.160.254] (wireless-206-196-160-254.umd.edu [206.196.160.254]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id 6F05E51C062; Sun, 26 Sep 2010 08:21:13 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: mrex@sap.com In-Reply-To: <201009250022.o8P0Mo2A007079@fs4113.wdf.sap.corp> References: <201009250022.o8P0Mo2A007079@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Sep 2010 11:21:08 -0400 Message-ID: <1285514468.2673.8.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Bad certificate handling 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: Sun, 26 Sep 2010 15:20:38 -0000 On Sat, 2010-09-25 at 02:22 +0200, Martin Rex wrote: > Section 5.1.4 here: > > http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > is much closer what I this would be useful and sensible. > > "Pinning" of certs is useful for both, certs that validate fine > and certs that do not validate for the two reasons "not trusted" > and "server-id-mismatch". Once again (http://www.ietf.org/mail-archive/web/certid/current/msg00338.html), the purpose of pinning is to make it possible to connect to servers with unverifiable certificates, not to replace the public-CA trust model, which is much more difficult to do properly. The definition of "strongly TLS-protected" (http://www.w3.org/TR/wsc-ui/#def-strong-tls) includes validated certificates regardless of whether there is a pinned certificate. > What is the idea behind visualizing the full chain? > > I've seen the same in 5.1.4 of the WSC-UI document but there's > no rationale given and I can not think of one. If the purpose is > memorizing and "pinning" a server cert, there is no point in > visualizing the certificate chain. > > Either there is no trust, then the chain can be crafted to look > like anything, Not necessarily. There are some CAs I don't want to enable unconditionally as trust anchors, but whose certificates I am willing to accept after additional manual verification. In that case, I would check the fingerprint of the top certificate of the presented chain against the one I expect. But you're right that "forcing the user to view the entire certification path" may have no real security benefit in general, though it sounds impressive. -- Matt From matt@mattmccutchen.net Sun Sep 26 08:27:37 2010 Return-Path: <matt@mattmccutchen.net> 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 25F743A695A for <certid@core3.amsl.com>; Sun, 26 Sep 2010 08:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 wN5-Q9IyASwm for <certid@core3.amsl.com>; Sun, 26 Sep 2010 08:27:36 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id EEDC73A69AE for <certid@ietf.org>; Sun, 26 Sep 2010 08:27:35 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 72C891D0063; Sun, 26 Sep 2010 08:28:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=pdwde32gmxVQhvn87qOHZBgW2yVR5IfUfLqM58AwofH wBV4VVIiFBMDmP5vUISnoCaA2ogdfXMsJ+qOF9XqGU7KiJ6bk0xyTOBruXDStP6R brrYAROcrUhphoC5++w+c/Vp75YaA9ryzqqEphSkcP11zfK47Hj7iODTMHMoxrOY = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=j9Fq1IMsWzRKDB5RE0ey40l9fIY=; b=M73E+hMcvQ xDkzE0BfIf44pI2W3JmFHlYQg39ZYT3aFzQ2bGL9wFlEM+YzLX1cALziPbGa90PD VGc0P8XDxBLHajttWBaSOhuBaczlgePrusqoLpueEEJtVS8hdBaT6QSWuegIXsy2 ZAprTyyMC2VgHvZuQ9/Cj+ixNi1wBJ6xI= Received: from [206.196.160.254] (wireless-206-196-160-254.umd.edu [206.196.160.254]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPA id 100361D0060; Sun, 26 Sep 2010 08:28:11 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: =JeffH <Jeff.Hodges@KingsMountain.com> In-Reply-To: <4C9D2DC6.3000202@KingsMountain.com> References: <4C9D2DC6.3000202@KingsMountain.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 26 Sep 2010 11:28:10 -0400 Message-ID: <1285514890.2673.14.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Bad certificate handling 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: Sun, 26 Sep 2010 15:27:37 -0000 On Fri, 2010-09-24 at 16:01 -0700, =JeffH wrote: > > > Given all this, I suggest we change the last part of the last sentence of > > > the "Security Note" quoted above to something like.. > > > > > > ..., by forcing the user to view the entire certification path > > > and only then allowing the user to choose whether to accept the > > > certificate on a temporary or permanent basis. See [WSC-UI] for > > > further guidance. > > > > > > ..and leave it at that in -tls-server-id-check. We should also consider > > > making [WSC-UI] a normative reference now that it is at Recommendation > > > maturity level. > > > > OK. I suggest s/to choose whether //; the point is that the user > > accepts the certificate. > > I tend to think we ought to at least mention the notion that the cert can be > accepted either temporarily or permanently. And that remains after my proposed edit. If you want to emphasize that it's the user's choice, try this: "...and only then allowing the user to accept the certificate on a temporary or permanent basis, at his/her option." The problem with the current text is that its negation could be that someone else does the choosing, when it should be that the certificate is not accepted. -- Matt From jwkckid1@ix.netcom.com Sun Sep 26 11:08:10 2010 Return-Path: <jwkckid1@ix.netcom.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 6D5823A69BD for <certid@core3.amsl.com>; Sun, 26 Sep 2010 11:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_50=0.001] 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 nuyXYRWPtfCX for <certid@core3.amsl.com>; Sun, 26 Sep 2010 11:08:08 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 38E283A688F for <certid@ietf.org>; Sun, 26 Sep 2010 11:08:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=DmpcBusgcOKb+r5y9xv+E8YxTIe2ztVd6aB7W7GYOOuciCyRNuYoeWflOGPSt+O4; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1OzveW-0007M4-Cv; Sun, 26 Sep 2010 14:08:44 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Sun, 26 Sep 2010 14:08:44 -0400 Message-ID: <63723.1285524524347.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Sun, 26 Sep 2010 13:08:44 -0500 (GMT-05:00) From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com> To: Matt McCutchen <matt@mattmccutchen.net>, mrex@sap.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c9a28a52eb16ba2b256e11ca41d6788b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Cc: certid@ietf.org Subject: Re: [certid] Bad certificate handling X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com> 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: Sun, 26 Sep 2010 18:08:10 -0000 Matt and all, -----Original Message----- >From: Matt McCutchen <matt@mattmccutchen.net> >Sent: Sep 26, 2010 10:21 AM >To: mrex@sap.com >Cc: certid@ietf.org >Subject: Re: [certid] Bad certificate handling > >On Sat, 2010-09-25 at 02:22 +0200, Martin Rex wrote: >> Section 5.1.4 here: >> >> http://www.w3.org/TR/wsc-ui/#selfsignedcerts >> >> is much closer what I this would be useful and sensible. >> >> "Pinning" of certs is useful for both, certs that validate fine >> and certs that do not validate for the two reasons "not trusted" >> and "server-id-mismatch". > >Once again >(http://www.ietf.org/mail-archive/web/certid/current/msg00338.html), the >purpose of pinning is to make it possible to connect to servers with >unverifiable certificates, not to replace the public-CA trust model, >which is much more difficult to do properly. The definition of >"strongly TLS-protected" (http://www.w3.org/TR/wsc-ui/#def-strong-tls) >includes validated certificates regardless of whether there is a pinned >certificate. > >> What is the idea behind visualizing the full chain? >> >> I've seen the same in 5.1.4 of the WSC-UI document but there's >> no rationale given and I can not think of one. If the purpose is >> memorizing and "pinning" a server cert, there is no point in >> visualizing the certificate chain. >> >> Either there is no trust, then the chain can be crafted to look >> like anything, > >Not necessarily. There are some CAs I don't want to enable >unconditionally as trust anchors, but whose certificates I am willing to >accept after additional manual verification. In that case, I would >check the fingerprint of the top certificate of the presented chain >against the one I expect. But you're right that "forcing the user to >view the entire certification path" may have no real security benefit in >general, though it sounds impressive. You have reiterated two problems here. One which you refer to indirectly is that in effect some, if not many CA's have issued CERTS under questionable circumstances, or have had their CERT database corrupted/hacked and the currently registered CERTS may have been compermised in some way. The second which in a way related to the first, that being a requirement for the user to view the entire certification path, as that path may lead to at any point a false positive. Ergo, Self signing CERTS for me anyway given that the 'Trust Anchors' are of questionable trustworthyness or may come into such a status without the users prior knowledge or awareness, is much more comfortable verification consideration, but of course this my not always be the case. > >-- >Matt > >_______________________________________________ >certid mailing list >certid@ietf.org >https://www.ietf.org/mailman/listinfo/certid Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From mrex@sap.com Mon Sep 27 06:47:52 2010 Return-Path: <mrex@sap.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 3B41E3A6BAE for <certid@core3.amsl.com>; Mon, 27 Sep 2010 06:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.531 X-Spam-Level: X-Spam-Status: No, score=-8.531 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 XL33h4zTyCNb for <certid@core3.amsl.com>; Mon, 27 Sep 2010 06:47:51 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 7FF8A3A6AFF for <certid@ietf.org>; Mon, 27 Sep 2010 06:47:49 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8RDmR0n021653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 27 Sep 2010 15:48:27 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009271348.o8RDmQSj010536@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Mon, 27 Sep 2010 15:48:26 +0200 (MEST) In-Reply-To: <1285514468.2673.8.camel@mattlaptop2.local> from "Matt McCutchen" at Sep 26, 10 11:21:08 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] Bad certificate handling X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Mon, 27 Sep 2010 13:47:52 -0000 Matt McCutchen wrote: > > On Sat, 2010-09-25 at 02:22 +0200, Martin Rex wrote: > > Section 5.1.4 here: > > > > http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > > > is much closer what I this would be useful and sensible. > > > > "Pinning" of certs is useful for both, certs that validate fine > > and certs that do not validate for the two reasons "not trusted" > > and "server-id-mismatch". > > Once again > (http://www.ietf.org/mail-archive/web/certid/current/msg00338.html), the > purpose of pinning is to make it possible to connect to servers with > unverifiable certificates, not to replace the public-CA trust model, > which is much more difficult to do properly. The definition of > "strongly TLS-protected" (http://www.w3.org/TR/wsc-ui/#def-strong-tls) > includes validated certificates regardless of whether there is a pinned > certificate. "Pinning" Certs is extremely sensible, especially for TOR exit nodes. Getting a server cert issued from any one of the ~100 pre-trusted CAs without being rightful owner of a domain is an effort to which you can likely attach an average price tag. Find out the procedures of the CA and determine which is the most cost effective mix of deceiving about real owner ship and bribe that will achieve the objective. Governmental agencies might have additional means of persuaions to get server certs issued for domains that they do not own. Think about wikileaks. Therefore having server-id-check unconditionally and silently override "pinned" server certs with server-certs that chain to one of the ~100 trust anchors preconfigured by the software supplier is a significant security problem. -Martin From ark@eltex.net Mon Sep 27 06:53:45 2010 Return-Path: <ark@eltex.net> 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 4FD693A6B38 for <certid@core3.amsl.com>; Mon, 27 Sep 2010 06:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 PGsPg+PGXpG0 for <certid@core3.amsl.com>; Mon, 27 Sep 2010 06:53:44 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id D85643A6AFF for <certid@ietf.org>; Mon, 27 Sep 2010 06:53:43 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o8RDsKho031738; Mon, 27 Sep 2010 17:54:20 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o8RDsK3O016792; Mon, 27 Sep 2010 17:54:20 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Mon, 27 Sep 2010 17:54:19 +0400 From: ArkanoiD <ark@eltex.net> To: Martin Rex <mrex@sap.com> Message-ID: <20100927135419.GA17889@eltex.net> References: <1285514468.2673.8.camel@mattlaptop2.local> <201009271348.o8RDmQSj010536@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201009271348.o8RDmQSj010536@fs4113.wdf.sap.corp> User-Agent: Mutt/1.4.2.3i Cc: certid@ietf.org Subject: Re: [certid] Bad certificate handling 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: Mon, 27 Sep 2010 13:53:45 -0000 I strongly agree and i address this problem in my software (and i guess so should everyone) On Mon, Sep 27, 2010 at 03:48:26PM +0200, Martin Rex wrote: > > Therefore having server-id-check unconditionally and silently override > "pinned" server certs with server-certs that chain to one of the ~100 > trust anchors preconfigured by the software supplier is a significant > security problem. > From Jeff.Hodges@KingsMountain.com Mon Sep 27 16:22:24 2010 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 0EEB43A6B7E for <certid@core3.amsl.com>; Mon, 27 Sep 2010 16:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 b86xbOmgGxqr for <certid@core3.amsl.com>; Mon, 27 Sep 2010 16:22:23 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 14B0B3A6A40 for <certid@ietf.org>; Mon, 27 Sep 2010 16:22:22 -0700 (PDT) Received: (qmail 23246 invoked by uid 0); 27 Sep 2010 23:23:02 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 27 Sep 2010 23:23:02 -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=HqC+kII1KptWou0BgI+cscLDPPGO4D3ojpg0RN337LFmiYSE4PqHWi6CH/fprmzTQLIsJ4kOLuKGAbRF9dxJVpJ+bUmW1FIBckGgdLlvrLiH1hvfOixWW1StyaESlhpb; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.49.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1P0N2E-0005pm-EO; Mon, 27 Sep 2010 17:23:02 -0600 Message-ID: <4CA12756.6070301@KingsMountain.com> Date: Mon, 27 Sep 2010 16:23:02 -0700 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Matt McCutchen <matt@mattmccutchen.net> 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Bad certificate handling 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: Mon, 27 Sep 2010 23:22:24 -0000 Matt replied.. > > On Fri, 2010-09-24 at 16:01 -0700, =JeffH wrote: >> > > Given all this, I suggest we change the last part of the last sentence of >> > > the "Security Note" quoted above to something like.. >> > > >> > > ..., by forcing the user to view the entire certification path >> > > and only then allowing the user to choose whether to accept the >> > > certificate on a temporary or permanent basis. See [WSC-UI] for >> > > further guidance. >> > > >> > > ..and leave it at that in -tls-server-id-check. We should also consider >> > > making [WSC-UI] a normative reference now that it is at Recommendation >> > > maturity level. >> > >> > OK. I suggest s/to choose whether //; the point is that the user >> > accepts the certificate. >> >> I tend to think we ought to at least mention the notion that the cert can be >> accepted either temporarily or permanently. > > And that remains after my proposed edit. If you want to emphasize that > it's the user's choice, try this: > > "...and only then allowing the user to accept the certificate on a > temporary or permanent basis, at his/her option." > > The problem with the current text is that its negation could be that > someone else does the choosing, when it should be that the certificate > is not accepted. ah, ok, thx, I'd misunderstood your proposed edit, thx for clarification. =JeffH From stpeter@stpeter.im Wed Sep 29 09:47:52 2010 Return-Path: <stpeter@stpeter.im> 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 F38A93A6D2C; Wed, 29 Sep 2010 09:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, 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 PArzjHuOwsfD; Wed, 29 Sep 2010 09:47:50 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C7F2F3A6C3F; Wed, 29 Sep 2010 09:47:50 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5EEFB400EE; Wed, 29 Sep 2010 10:54:06 -0600 (MDT) Message-ID: <4CA36DE0.1050302@stpeter.im> Date: Wed, 29 Sep 2010 10:48:32 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: tls@ietf.org, pkix@ietf.org, IETF discussion list <ietf@ietf.org>, IETF cert-based identity <certid@ietf.org> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [certid] further discussion of draft-saintandre-tls-server-id-check 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, 29 Sep 2010 16:47:52 -0000 Many thanks to those who reviewed draft-saintandre-tls-server-id-check during IETF Last Call, leading to discussions on a number of lists (TLS WG, SecDir, ietf@ietf.org, etc.). Jeff Hodges and I are currently working through all the discussion threads and will post replies over the next few days. To eliminate cross-posting, we post our replies only to the certid@ietf.org list: https://www.ietf.org/mailman/listinfo/certid If you are interested in continued discussion of this I-D, please subscribe to the certid list so that we can improve the S/N ratio on the lists we've been spamming for the last few weeks. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 29 13:02:55 2010 Return-Path: <stpeter@stpeter.im> 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 B69203A69C4 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 13:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, 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 hYEwGFz8NGQM for <certid@core3.amsl.com>; Wed, 29 Sep 2010 13:02:54 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A11623A6B4E for <certid@ietf.org>; Wed, 29 Sep 2010 13:02:54 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 833BD403DF; Wed, 29 Sep 2010 14:09:10 -0600 (MDT) Message-ID: <4CA39B88.70402@stpeter.im> Date: Wed, 29 Sep 2010 14:03:20 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Henry B. Hotz" <hotz@jpl.nasa.gov> References: <C8B4E80F.EE82%stefan@aaa-sec.com> <4C9A2D12.3020409@stpeter.im> <p0624084ac8bfe10f5b72@[10.20.30.158]> <76232140-6713-416F-8758-8042A82B8857@jpl.nasa.gov> In-Reply-To: <76232140-6713-416F-8758-8042A82B8857@jpl.nasa.gov> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefan Santesson <stefan@aaa-sec.com>, IETF cert-based identity <certid@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: [certid] Why require EKU for certid? 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, 29 Sep 2010 20:02:55 -0000 [trimming tls@ and ietf@ from cc list] On 9/23/10 11:43 AM, Henry B. Hotz wrote: > > On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: > >> At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >>> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>>> General: I would consider stating that server certificates >>>> according to this profile either MUST or SHOULD have the >>>> serverAuth EKU set since it is allways related to the use of >>>> TSL and server authentication. At least it MUST be set when >>>> allowing checks of the CN-ID (see 2.3 below). >>> >>> [..snip..] >> > >> What possible advantage is there to making certificates that do not >> have this flag set be excluded from the practices you are defining? >> That is, if a TLS client gets a certificate from a TLS server that >> the TLS server says is its authentication certificate, why should >> the client care whether or not that flag is set? That flag is an >> assertion from the CA, not from the server who is authenticating. > > > Does this point need discussion? Without checking, I suspect that > 5280 says you obey the EKU, period. OTOH I think Paul raises a valid > point. > > OTOH (again) one could argue that the EKU provides a way to prevent a > stolen cert/key issued to the machine for a different function from > being repurposed to support a fake server. (I'm not convinced this > is significant, but it's something.) > > Absent discussion and consensus, I vote for whatever 5280 says, which > I suppose is what the current silence on the topic equates to. This I-D shall never be taken to override anything in RFC 5280 or any other normatively-referenced specification on which it depends. If folks think we need a blanket statement to that effect, please let us know. Version -10 will have a new section containing an applicability statement, which starts as follows: This document does not supersede the rules for certificate validation provided in [RFC5280]. But we can always add a stronger statement if need be. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 29 13:25:57 2010 Return-Path: <stpeter@stpeter.im> 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 9C5EB3A6D96 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 13:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, 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 dWzAMaJuEjx0 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 13:25:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 5B0953A6D8F for <certid@ietf.org>; Wed, 29 Sep 2010 13:25:56 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 29646403DF; Wed, 29 Sep 2010 14:32:13 -0600 (MDT) Message-ID: <4CA3A0FE.4050503@stpeter.im> Date: Wed, 29 Sep 2010 14:26:38 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: =JeffH <Jeff.Hodges@KingsMountain.com> References: <4CA12756.6070301@KingsMountain.com> In-Reply-To: <4CA12756.6070301@KingsMountain.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Bad certificate handling 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, 29 Sep 2010 20:25:57 -0000 On 9/27/10 5:23 PM, =JeffH wrote: > Matt replied.. >> >> On Fri, 2010-09-24 at 16:01 -0700, =JeffH wrote: >>> > > Given all this, I suggest we change the last part of the last > sentence of >>> > > the "Security Note" quoted above to something like.. >>> > > >>> > > ..., by forcing the user to view the entire > certification path >>> > > and only then allowing the user to choose whether to > accept the >>> > > certificate on a temporary or permanent basis. See > [WSC-UI] for >>> > > further guidance. >>> > > >>> > > ..and leave it at that in -tls-server-id-check. We should also > consider >>> > > making [WSC-UI] a normative reference now that it is at > Recommendation >>> > > maturity level. >>> > >>> > OK. I suggest s/to choose whether //; the point is that the user >>> > accepts the certificate. >>> >>> I tend to think we ought to at least mention the notion that the cert > can be >>> accepted either temporarily or permanently. >> >> And that remains after my proposed edit. If you want to emphasize that >> it's the user's choice, try this: >> >> "...and only then allowing the user to accept the certificate on a >> temporary or permanent basis, at his/her option." >> >> The problem with the current text is that its negation could be that >> someone else does the choosing, when it should be that the certificate >> is not accepted. > > ah, ok, thx, I'd misunderstood your proposed edit, thx for clarification. Based on jhutz's earlier comments, our working copy already has this: ... and only then allowing the user to accept the certificate (on a temporary or permanent basis, at the user's option). That seems to meet the need identified in this thread. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 29 13:31:30 2010 Return-Path: <stpeter@stpeter.im> 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 A25073A6D8F for <certid@core3.amsl.com>; Wed, 29 Sep 2010 13:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 peaC4vXUbVNF for <certid@core3.amsl.com>; Wed, 29 Sep 2010 13:31:28 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 676CE3A6D20 for <certid@ietf.org>; Wed, 29 Sep 2010 13:31:27 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 17B8D403DF; Wed, 29 Sep 2010 14:37:44 -0600 (MDT) Message-ID: <4CA3A249.70601@stpeter.im> Date: Wed, 29 Sep 2010 14:32:09 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: mrex@sap.com References: <201009170521.o8H5LxdZ003712@fs4113.wdf.sap.corp> In-Reply-To: <201009170521.o8H5LxdZ003712@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] DNSSEC-based name canonicalization 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, 29 Sep 2010 20:31:30 -0000 Interesting topic, but I see nothing in this branch of the discussion that necessitates changes to the I-D. Do correct me if I'm wrong. :) On 9/16/10 11:21 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >> On Fri, 2010-09-17 at 00:34 +0200, Martin Rex wrote: >>> Cleanup of my prior message: >>> >>> >>> Matt McCutchen wrote: >>>> >>>> On Thu, 2010-09-16 at 07:27 +0200, Martin Rex wrote: >>>>> Clearly unsafe operations: >>>>> >>>>> - building a reference identifier from the result of a >>>>> DNS CNAME lookup >>>>> >>>>> (the use of DNSSEC does not make this safe) >>>> >>>> Why not? I'm not saying it's good practice, but I don't see an actual >>>> vulnerability. >>> >>> You need two characteristics: >>> >>> (1) _trustworty_ information source for a name transformation >>> (2) _protected_access_ to the information source >>> >>> DNSSEC meets (2) but not (1) >> >> Why not (1)? It should go without saying that by DNSSEC I meant "DNSSEC >> with a set of trustworthy trust anchors that will get us to the desired >> signed zone". From there, the DNS admin has full authority to say what >> certificates a client trying to connect to a host in her zone should >> accept. > > DNS needs to be available, fast, efficient and low-low-low cost. > > The cost of creating and maintaining DNS records with any trustworthyness > that is measurably distinct from zero, with the necessary expertise to > set up and devotion to practise scrutiny for every change to the data > is probably going to far exceed the funding of most, if not all DNS admins. > > Are there already workable procedures and APIs for software to > distinguish "normal" DNSSEC lookup results from "trustworthy" DNSSEC > lookup results with some level of portability? How and how often > would admins/consumers have to update and reconfirm every "trustworthy" > DNSSEC key they keep? > >> >> We could have a record, CERTNAME or something, that specifies the >> hostname for which the certificate should be valid (via keyassure or >> PKIX + server-id-check). I realize now that it would be dangerous to >> reinterpret CNAME for this purpose, just as it is dangerous to >> reinterpret CERT as making an assurance, but that is a separate issue. >> I still wouldn't advise doing it unless we come up with a compelling use >> case. > > DNS domains is a resource that is managed pretty arbitrary on a > first-come first-served basis. It has some loose "a domain is leased > to at most one entity at any single time" provision, that's it. > DNS is vital for the internet, so it needs to remain fast, > efficient and free, and all of that combined makes it hardly > usable to bootstrap an infrastructure of trust, with any meaningful > level of trust. > > The fraction of resources that web browsers accesses through HTTPS, > where the first HTTPS link is served through a page received via > HTTP in a completely untrusted fashion is mindboggling. > Example "ebay". What do you think: how many users that login > through the ebay sign-in page via HTTPS every day, have supplied > the URL of the signin page in a trusted&secure fashion, and > how many open http://www.ebay.<country> and click a link > on that page? > > How about online banking? An internet commerce that cares strongly > about security should serve only one single "301 Moved Permanently" > page with an HTTPS url on port 80, making it difficult to bookmark > anything else than a HTTPS urls to this site. > > "Secure" electronic commerce on the internet is often > like a handful of iron rings that are quickly attached to > each other with tiny rubber bands from the kitchen drawer > in order to give the impression of a chain. Occasionally, > some of these "chains" rip apart by their own weight alone. From Jeff.Hodges@KingsMountain.com Wed Sep 29 14:27:03 2010 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 914BD3A6E17 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 14:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ETLXwHPyElml for <certid@core3.amsl.com>; Wed, 29 Sep 2010 14:27:02 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 320D33A6E12 for <certid@ietf.org>; Wed, 29 Sep 2010 14:27:02 -0700 (PDT) Received: (qmail 31752 invoked by uid 0); 29 Sep 2010 21:27:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 29 Sep 2010 21:27:46 -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:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=H9+VZ51Eb4s63IRsg2bpQTHCG35po96L5DnJpApnVKVl0qk3TFO8lCPZtkvW6gzy41sceN+Ne5nfjvSoM8e6QZ4aMssxfXbjiVBsKnih+3bKFGZSh/ct/IStTirtbz7y; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1P14Bl-00056p-SI for certid@ietf.org; Wed, 29 Sep 2010 15:27:45 -0600 Message-ID: <4CA3AF50.6050101@KingsMountain.com> Date: Wed, 29 Sep 2010 14:27:44 -0700 From: =JeffH <Jeff.Hodges@KingsMountain.com> User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity <certid@ietf.org> 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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, 29 Sep 2010 21:27:03 -0000 I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad certificate handling) and indeed its language needed some semi-major rewriting, which we've done. The entire new section "4.6 Outcome" is below. comments? thanks, =JeffH ### 4.6. Outcome The outcome of the checking procedure is one of the following cases. 4.6.1. Case #1: Match Found If the client has found a presented identifier that matches a reference identifier, matching has succeeded. In this case, the client MUST use the matched reference identifier as the validated identity of the server. 4.6.2. Case #2: No Match Found, Cached Certificate If the client does not find a presented identifier matching any of the reference identifiers, and (a) a human user has previously accepted and cached a certificate for this application service during a previous interaction with the service or (b) a certificate has been cached via configuration settings, then the client MUST verify that the presented certificate matches the cached certificate. If the presented certificate does not match the cached certificate then the client MUST proceed as described under Section 4.6.4. 4.6.3. Case #3: No Match Found, No Cached Certificate If the client does not find a presented identifier matching any of the reference identifiers, and the client has not previously cached a certificate for this application service based on user acceptance or configuration, then the client MUST proceed as described under Section 4.6.4. 4.6.4. Fallback If the client is an interactive client that is directly controlled by a human user, then it SHOULD inform the user of the identity mismatch and automatically terminate the connection with a bad certificate error; this behavior is preferable because it prevents users from inadvertently bypassing security protections in hostile situations. Security Note: Some interactive clients give advanced users the option of proceeding with acceptance and caching of the presented certificate despite an identity mismatch. Although this behavior can be appropriate in certain specialized circumstances, in general it ought to be exposed only to advanced users. Even then it needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the connection and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to accept the certificate (on a temporary or permanent basis, at the user's option). Otherwise, if the client is an automated application not directly controlled by a human user, then it SHOULD terminate the connection with a bad certificate error and log the error appropriately. An automated application MAY provide a configuration setting that disables this behavior, but MUST enable the behavior by default. ### From stpeter@stpeter.im Wed Sep 29 14:37:15 2010 Return-Path: <stpeter@stpeter.im> 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 75CF33A6C43 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 14:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 c0iOe077G17n for <certid@core3.amsl.com>; Wed, 29 Sep 2010 14:37:12 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8B56D3A6AEA for <certid@ietf.org>; Wed, 29 Sep 2010 14:37:09 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 90610403DF; Wed, 29 Sep 2010 15:43:26 -0600 (MDT) Message-ID: <4CA3B1B0.2040106@stpeter.im> Date: Wed, 29 Sep 2010 15:37:52 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Matt McCutchen <matt@mattmccutchen.net> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> <1285450341.1940.79.camel@mattlaptop2.local> In-Reply-To: <1285450341.1940.79.camel@mattlaptop2.local> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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, 29 Sep 2010 21:37:16 -0000 On 9/25/10 3:32 PM, Matt McCutchen wrote: Cutting to the chase... > I propose that section 4.4.4 be changed as follows: > > Old: "...the client MAY as a fallback check for a string whose form > matches that of a fully-qualified DNS domain name in the CN-ID." > > New: "...the client MAY as a fallback check for a string whose form > matches that of a fully-qualified DNS domain name in the CN-ID, provided > that this domain name satisfies any name constraints on the > certification path as defined by [PKIX] section 4.2.1.10." Thank you for proposing text. Given that the server-id-check document is downstream from RFC 5280, it's not clear to me why we need to mention that name constraints apply. I'm especially wondering why this spec would mention name constraints with respect to CN-IDs but not with respect to DNS-IDs, URI-IDs, or SRV-IDs, given that Section 4.2.1.10 of RFC 5280 states in part: The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names. RFC 4985 explicitly mentions name constraints with respect to SRVNames, but that makes sense because it is defining a new name form for the subjectAltName extension of type otherName, which is not mentioned in RFC 3280 / RFC 5280, as mentioned in RFC 5280: The syntax and semantics for name constraints for otherName, ediPartyName, and registeredID are not defined by this specification, however, syntax and semantics for name constraints for other name forms may be specified in other documents. Thus I think this is out of scope for the server-id-check document, but I'm open to being convinced otherwise (and I'm not yet sure whether my co-author agrees with me). Peter -- Peter Saint-Andre https://stpeter.im/ From ietf@augustcellars.com Wed Sep 29 15:10:48 2010 Return-Path: <ietf@augustcellars.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 AD1993A69B7 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Oa3DXXNQHWau for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:10:44 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 476E93A6A29 for <certid@ietf.org>; Wed, 29 Sep 2010 15:10:42 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 554E06A4FE; Wed, 29 Sep 2010 15:11:26 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: "'=JeffH'" <Jeff.Hodges@KingsMountain.com>, "'IETF cert-based identity'" <certid@ietf.org> References: <4CA3AF50.6050101@KingsMountain.com> In-Reply-To: <4CA3AF50.6050101@KingsMountain.com> Date: Wed, 29 Sep 2010 15:19:24 -0700 Message-ID: <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpqtf1DBfzG3HdU1/o9iR7FXwOz5Ns8WLw Content-Language: en-us Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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, 29 Sep 2010 22:10:50 -0000 > -----Original Message----- > From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On Behalf Of > =JeffH > Sent: Wednesday, September 29, 2010 2:28 PM > To: IETF cert-based identity > Subject: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad certificate > handling) and indeed its language needed some semi-major rewriting, which > we've done. The entire new section "4.6 Outcome" is below. > > comments? > > thanks, > > =JeffH > > ### > > 4.6. Outcome > > The outcome of the checking procedure is one of the following cases. > > 4.6.1. Case #1: Match Found > > If the client has found a presented identifier that matches a > reference identifier, matching has succeeded. In this case, the > client MUST use the matched reference identifier as the validated > identity of the server. > > 4.6.2. Case #2: No Match Found, Cached Certificate > > If the client does not find a presented identifier matching any of > the reference identifiers, and (a) a human user has previously > accepted and cached a certificate for this application service during > a previous interaction with the service or (b) a certificate has been > cached via configuration settings, then the client MUST verify that > the presented certificate matches the cached certificate. If the > presented certificate does not match the cached certificate then the > client MUST proceed as described under Section 4.6.4. There was one case in the original text here that I was expecting to be kept. This was the case of the chain of certificates being changed from when it was originally presented. Given the suggestion that the chain is shown for advanced users (see 4.6.4) I am wondering about the fact that we are no longer looking at anything more that the terminal certificate at this point. > > 4.6.3. Case #3: No Match Found, No Cached Certificate > > If the client does not find a presented identifier matching any of > the reference identifiers, and the client has not previously cached a > certificate for this application service based on user acceptance or > configuration, then the client MUST proceed as described under > Section 4.6.4. > > 4.6.4. Fallback > > If the client is an interactive client that is directly controlled by > a human user, then it SHOULD inform the user of the identity mismatch > and automatically terminate the connection with a bad certificate > error; this behavior is preferable because it prevents users from > inadvertently bypassing security protections in hostile situations. > > Security Note: Some interactive clients give advanced users the > option of proceeding with acceptance and caching of the presented > certificate despite an identity mismatch. Although this behavior > can be appropriate in certain specialized circumstances, in > general it ought to be exposed only to advanced users. Even then > it needs to be handled with extreme caution, for example by first > encouraging even an advanced user to terminate the connection and, > if the advanced user chooses to proceed anyway, by forcing the > user to view the entire certification path and only then allowing > the user to accept the certificate (on a temporary or permanent > basis, at the user's option). > > Otherwise, if the client is an automated application not directly > controlled by a human user, then it SHOULD terminate the connection > with a bad certificate error and log the error appropriately. An > automated application MAY provide a configuration setting that > disables this behavior, but MUST enable the behavior by default. I would like to see the MAY and MUST here be lower cased. They are implied by the SHOULD in the preceding sentence and do not need to be re-iterated. > > ### > > > > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid From ietf@augustcellars.com Wed Sep 29 15:12:18 2010 Return-Path: <ietf@augustcellars.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 27CC13A6A9A for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 v3pqWAqxVTh5 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:12:15 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 42A793A6A29 for <certid@ietf.org>; Wed, 29 Sep 2010 15:12:15 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 590646EF7A; Wed, 29 Sep 2010 15:12:59 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: "'Peter Saint-Andre'" <stpeter@stpeter.im>, "'Matt McCutchen'" <matt@mattmccutchen.net> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> <1285450341.1940.79.camel@mattlaptop2.local> <4CA3B1B0.2040106@stpeter.im> In-Reply-To: <4CA3B1B0.2040106@stpeter.im> Date: Wed, 29 Sep 2010 15:20:58 -0700 Message-ID: <006901cb6024$97c85990$c7590cb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE5mp2IHf/sQTeACWXye7dK1f19xwGNyQZRAom+LdyULFeLEA== Content-Language: en-us Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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, 29 Sep 2010 22:12:18 -0000 Peter, It was my understanding of this that the request was that the DNS name constraints be applied to a CN-ID that is being treated as a DN. This would not be standard 5280 behavior. Jim > -----Original Message----- > From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On Behalf Of > Peter Saint-Andre > Sent: Wednesday, September 29, 2010 2:38 PM > To: Matt McCutchen > Cc: certid@ietf.org > Subject: Re: [certid] CN-ID and name constraints > > On 9/25/10 3:32 PM, Matt McCutchen wrote: > > Cutting to the chase... > > > I propose that section 4.4.4 be changed as follows: > > > > Old: "...the client MAY as a fallback check for a string whose form > > matches that of a fully-qualified DNS domain name in the CN-ID." > > > > New: "...the client MAY as a fallback check for a string whose form > > matches that of a fully-qualified DNS domain name in the CN-ID, > > provided that this domain name satisfies any name constraints on the > > certification path as defined by [PKIX] section 4.2.1.10." > > Thank you for proposing text. > > Given that the server-id-check document is downstream from RFC 5280, it's not > clear to me why we need to mention that name constraints apply. > I'm especially wondering why this spec would mention name constraints with > respect to CN-IDs but not with respect to DNS-IDs, URI-IDs, or SRV-IDs, given > that Section 4.2.1.10 of RFC 5280 states in part: > > The name constraints extension, which MUST be used only in a CA > certificate, indicates a name space within which all subject names in > subsequent certificates in a certification path MUST be located. > Restrictions apply to the subject distinguished name and apply to > subject alternative names. > > RFC 4985 explicitly mentions name constraints with respect to SRVNames, but > that makes sense because it is defining a new name form for the > subjectAltName extension of type otherName, which is not mentioned in RFC > 3280 / RFC 5280, as mentioned in RFC 5280: > > The syntax and semantics for name constraints for otherName, > ediPartyName, and registeredID are not defined by this specification, > however, syntax and semantics for name constraints for other name > forms may be specified in other documents. > > Thus I think this is out of scope for the server-id-check document, but I'm open > to being convinced otherwise (and I'm not yet sure whether my co-author > agrees with me). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid From stpeter@stpeter.im Wed Sep 29 15:24:18 2010 Return-Path: <stpeter@stpeter.im> 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 1261E3A69B7 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, 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 NUVH0h48sVm0 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:24:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C14D43A6B34 for <certid@ietf.org>; Wed, 29 Sep 2010 15:24:16 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 05446403DF; Wed, 29 Sep 2010 16:30:33 -0600 (MDT) Message-ID: <4CA3BCBB.1010007@stpeter.im> Date: Wed, 29 Sep 2010 16:24:59 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Paul Hoffman <paul.hoffman@vpnc.org> References: <C8B4E80F.EE82%stefan@aaa-sec.com> <4C9A2D12.3020409@stpeter.im> <p0624084ac8bfe10f5b72@[10.20.30.158]> <76232140-6713-416F-8758-8042A82B8857@jpl.nasa.gov> <4CA39B88.70402@stpeter.im> <p0624084ec8c96bc1768c@[10.20.30.163]> In-Reply-To: <p0624084ec8c96bc1768c@[10.20.30.163]> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Stefan Santesson <stefan@aaa-sec.com>, IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Why require EKU for certid? 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, 29 Sep 2010 22:24:18 -0000 On 9/29/10 4:20 PM, Paul Hoffman wrote: > At 2:03 PM -0600 9/29/10, Peter Saint-Andre wrote: >> [trimming tls@ and ietf@ from cc list] >> >> On 9/23/10 11:43 AM, Henry B. Hotz wrote: >>> >>> On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: >>> >>>> At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >>>>> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>>>>> General: I would consider stating that server certificates >>>>>> according to this profile either MUST or SHOULD have the >>>>>> serverAuth EKU set since it is allways related to the use >>>>>> of TSL and server authentication. At least it MUST be set >>>>>> when allowing checks of the CN-ID (see 2.3 below). >>>>> >>>>> [..snip..] >>>> >>> >>>> What possible advantage is there to making certificates that do >>>> not have this flag set be excluded from the practices you are >>>> defining? That is, if a TLS client gets a certificate from a >>>> TLS server that the TLS server says is its authentication >>>> certificate, why should the client care whether or not that >>>> flag is set? That flag is an assertion from the CA, not from >>>> the server who is authenticating. >>> >>> >>> Does this point need discussion? Without checking, I suspect >>> that 5280 says you obey the EKU, period. OTOH I think Paul >>> raises a valid point. >>> >>> OTOH (again) one could argue that the EKU provides a way to >>> prevent a stolen cert/key issued to the machine for a different >>> function from being repurposed to support a fake server. (I'm >>> not convinced this is significant, but it's something.) >>> >>> Absent discussion and consensus, I vote for whatever 5280 says, >>> which I suppose is what the current silence on the topic equates >>> to. >> >> This I-D shall never be taken to override anything in RFC 5280 or >> any other normatively-referenced specification on which it depends. >> If folks think we need a blanket statement to that effect, please >> let us know. Version -10 will have a new section containing an >> applicability statement, which starts as follows: >> >> This document does not supersede the rules for certificate >> validation provided in [RFC5280]. >> >> But we can always add a stronger statement if need be. > > This misses the point I made when I started this thread. That's because I was replying only to the small item of whether the server-id-check can be taken to override RFC 5280. > Stefan > proposed a change that would require that only certs that included > this EKU be considered, you said you would consider that, I think I said only that Jeff and I hadn't discussed it yet. It's still on our todo list. > and I said > that would be a bad change. Henry's point did not negate or support > my proposal. My sense of the discussion so far is that there's no strong agreement to accept the proposal that Stefan made. Peter -- Peter Saint-Andre https://stpeter.im/ From paul.hoffman@vpnc.org Wed Sep 29 15:25:00 2010 Return-Path: <paul.hoffman@vpnc.org> 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 A05C13A6B34 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.355 X-Spam-Level: X-Spam-Status: No, score=-101.355 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 o1nL6Ao1jfpP for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:24:59 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id D28E83A69B7 for <certid@ietf.org>; Wed, 29 Sep 2010 15:24:59 -0700 (PDT) Received: from [10.20.30.163] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o8TMKtKu085609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2010 15:20:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p0624084ec8c96bc1768c@[10.20.30.163]> In-Reply-To: <4CA39B88.70402@stpeter.im> References: <C8B4E80F.EE82%stefan@aaa-sec.com> <4C9A2D12.3020409@stpeter.im> <p0624084ac8bfe10f5b72@[10.20.30.158]> <76232140-6713-416F-8758-8042A82B8857@jpl.nasa.gov> <4CA39B88.70402@stpeter.im> Date: Wed, 29 Sep 2010 15:20:54 -0700 To: Peter Saint-Andre <stpeter@stpeter.im>, "Henry B. Hotz" <hotz@jpl.nasa.gov> From: Paul Hoffman <paul.hoffman@vpnc.org> Content-Type: text/plain; charset="us-ascii" Cc: Stefan Santesson <stefan@aaa-sec.com>, IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Why require EKU for certid? 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, 29 Sep 2010 22:25:00 -0000 At 2:03 PM -0600 9/29/10, Peter Saint-Andre wrote: >[trimming tls@ and ietf@ from cc list] > >On 9/23/10 11:43 AM, Henry B. Hotz wrote: >> >> On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: >> >>> At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >>>> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>>>> General: I would consider stating that server certificates >>>>> according to this profile either MUST or SHOULD have the >>>>> serverAuth EKU set since it is allways related to the use of >>>>> TSL and server authentication. At least it MUST be set when >>>>> allowing checks of the CN-ID (see 2.3 below). >>>> >>>> [..snip..] >>> >> >>> What possible advantage is there to making certificates that do not >>> have this flag set be excluded from the practices you are defining? >>> That is, if a TLS client gets a certificate from a TLS server that >>> the TLS server says is its authentication certificate, why should >>> the client care whether or not that flag is set? That flag is an >>> assertion from the CA, not from the server who is authenticating. >> >> >> Does this point need discussion? Without checking, I suspect that >> 5280 says you obey the EKU, period. OTOH I think Paul raises a valid >> point. >> >> OTOH (again) one could argue that the EKU provides a way to prevent a >> stolen cert/key issued to the machine for a different function from >> being repurposed to support a fake server. (I'm not convinced this >> is significant, but it's something.) >> >> Absent discussion and consensus, I vote for whatever 5280 says, which >> I suppose is what the current silence on the topic equates to. > >This I-D shall never be taken to override anything in RFC 5280 or any >other normatively-referenced specification on which it depends. If folks >think we need a blanket statement to that effect, please let us know. >Version -10 will have a new section containing an applicability >statement, which starts as follows: > > This document does not supersede the rules for certificate validation > provided in [RFC5280]. > >But we can always add a stronger statement if need be. This misses the point I made when I started this thread. Stefan proposed a change that would require that only certs that included this EKU be considered, you said you would consider that, and I said that would be a bad change. Henry's point did not negate or support my proposal. --Paul Hoffman, Director --VPN Consortium From stpeter@stpeter.im Wed Sep 29 15:40:16 2010 Return-Path: <stpeter@stpeter.im> 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 9980D3A6C24 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 JkZ0ktRQEybs for <certid@core3.amsl.com>; Wed, 29 Sep 2010 15:40:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EEB883A6BD2 for <certid@ietf.org>; Wed, 29 Sep 2010 15:39:27 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C9EFB403DF; Wed, 29 Sep 2010 16:45:06 -0600 (MDT) Message-ID: <4CA3C022.8050202@stpeter.im> Date: Wed, 29 Sep 2010 16:39:30 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jim Schaad <ietf@augustcellars.com> References: <4CA3AF50.6050101@KingsMountain.com> <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> In-Reply-To: <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'IETF cert-based identity' <certid@ietf.org>, '=JeffH' <Jeff.Hodges@KingsMountain.com> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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, 29 Sep 2010 22:40:17 -0000 On 9/29/10 4:19 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On Behalf > Of >> =JeffH >> Sent: Wednesday, September 29, 2010 2:28 PM >> To: IETF cert-based identity >> Subject: [certid] section 4.6 rewrite (aka: Bad certificate handling) >> >> I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad > certificate >> handling) and indeed its language needed some semi-major rewriting, which >> we've done. The entire new section "4.6 Outcome" is below. >> >> comments? >> >> thanks, >> >> =JeffH >> >> ### >> >> 4.6. Outcome >> >> The outcome of the checking procedure is one of the following cases. >> >> 4.6.1. Case #1: Match Found >> >> If the client has found a presented identifier that matches a >> reference identifier, matching has succeeded. In this case, the >> client MUST use the matched reference identifier as the validated >> identity of the server. >> >> 4.6.2. Case #2: No Match Found, Cached Certificate >> >> If the client does not find a presented identifier matching any of >> the reference identifiers, and (a) a human user has previously >> accepted and cached a certificate for this application service during >> a previous interaction with the service or (b) a certificate has been >> cached via configuration settings, then the client MUST verify that >> the presented certificate matches the cached certificate. If the >> presented certificate does not match the cached certificate then the >> client MUST proceed as described under Section 4.6.4. > > There was one case in the original text here that I was expecting to be > kept. This was the case of the chain of certificates being changed from > when it was originally presented. Given the suggestion that the chain is > shown for advanced users (see 4.6.4) I am wondering about the fact that we > are no longer looking at anything more that the terminal certificate at this > point. Yes, that's important. I think this text is a bit confusing because it uses the term "match" for comparing the entire cached certificate against the entire presented certificate, whereas in the rest of the document we use the term "match" for comparing reference identifiers against presented identifiers. Therefore I propose the following adjusted text: If the client does not find a presented identifier matching any of the reference identifiers, and (a) a human user has previously accepted and cached a certificate for this application service during a previous interaction with the service or (b) a certificate has been cached via configuration settings, then the client MUST verify that the presented certificate is the same as the cached certificate, including verification of the entire certification path. If the presented certificate is not the same as the cached certificate then the client MUST proceed as described under Section 4.6.4. >> 4.6.3. Case #3: No Match Found, No Cached Certificate >> >> If the client does not find a presented identifier matching any of >> the reference identifiers, and the client has not previously cached a >> certificate for this application service based on user acceptance or >> configuration, then the client MUST proceed as described under >> Section 4.6.4. >> >> 4.6.4. Fallback >> >> If the client is an interactive client that is directly controlled by >> a human user, then it SHOULD inform the user of the identity mismatch >> and automatically terminate the connection with a bad certificate >> error; this behavior is preferable because it prevents users from >> inadvertently bypassing security protections in hostile situations. >> >> Security Note: Some interactive clients give advanced users the >> option of proceeding with acceptance and caching of the presented >> certificate despite an identity mismatch. Although this behavior >> can be appropriate in certain specialized circumstances, in >> general it ought to be exposed only to advanced users. Even then >> it needs to be handled with extreme caution, for example by first >> encouraging even an advanced user to terminate the connection and, >> if the advanced user chooses to proceed anyway, by forcing the >> user to view the entire certification path and only then allowing >> the user to accept the certificate (on a temporary or permanent >> basis, at the user's option). >> >> Otherwise, if the client is an automated application not directly >> controlled by a human user, then it SHOULD terminate the connection >> with a bad certificate error and log the error appropriately. An >> automated application MAY provide a configuration setting that >> disables this behavior, but MUST enable the behavior by default. > > I would like to see the MAY and MUST here be lower cased. They are implied > by the SHOULD in the preceding sentence and do not need to be re-iterated. I think it might be better to delete the last sentence entirely since it is really an implementation detail (the main point is that the client SHOULD terminate the connection). Peter -- Peter Saint-Andre https://stpeter.im/ From ietf@augustcellars.com Wed Sep 29 16:12:13 2010 Return-Path: <ietf@augustcellars.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 A7EED3A6A39 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 16:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 VjI4EmjtFAg8 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 16:12:05 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 979E33A6835 for <certid@ietf.org>; Wed, 29 Sep 2010 16:12:05 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 856256A456; Wed, 29 Sep 2010 16:12:49 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: "'Peter Saint-Andre'" <stpeter@stpeter.im> References: <4CA3AF50.6050101@KingsMountain.com> <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> <4CA3C022.8050202@stpeter.im> In-Reply-To: <4CA3C022.8050202@stpeter.im> Date: Wed, 29 Sep 2010 16:20:48 -0700 Message-ID: <006a01cb602c$f3dd1150$db9733f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpqtf1DBfzG3HdU1/o9iR7FXwOzwKTMizaAiIBOD6TR1jHIA== Content-Language: en-us Cc: 'IETF cert-based identity' <certid@ietf.org>, '=JeffH' <Jeff.Hodges@KingsMountain.com> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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, 29 Sep 2010 23:12:14 -0000 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Wednesday, September 29, 2010 3:40 PM > To: Jim Schaad > Cc: '=3DJeffH'; 'IETF cert-based identity' > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate = handling) >=20 > On 9/29/10 4:19 PM, Jim Schaad wrote: > > > > > >> -----Original Message----- > >> From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On > >> Behalf > > Of > >> =3DJeffH > >> Sent: Wednesday, September 29, 2010 2:28 PM > >> To: IETF cert-based identity > >> Subject: [certid] section 4.6 rewrite (aka: Bad certificate = handling) > >> > >> I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad > > certificate > >> handling) and indeed its language needed some semi-major rewriting, > >> which we've done. The entire new section "4.6 Outcome" is below. > >> > >> comments? > >> > >> thanks, > >> > >> =3DJeffH > >> > >> ### > >> > >> 4.6. Outcome > >> > >> The outcome of the checking procedure is one of the following = cases. > >> > >> 4.6.1. Case #1: Match Found > >> > >> If the client has found a presented identifier that matches a > >> reference identifier, matching has succeeded. In this case, = the > >> client MUST use the matched reference identifier as the = validated > >> identity of the server. > >> > >> 4.6.2. Case #2: No Match Found, Cached Certificate > >> > >> If the client does not find a presented identifier matching any = of > >> the reference identifiers, and (a) a human user has previously > >> accepted and cached a certificate for this application service = during > >> a previous interaction with the service or (b) a certificate = has been > >> cached via configuration settings, then the client MUST verify = that > >> the presented certificate matches the cached certificate. If = the > >> presented certificate does not match the cached certificate = then the > >> client MUST proceed as described under Section 4.6.4. > > > > There was one case in the original text here that I was expecting to = be > > kept. This was the case of the chain of certificates being changed = from > > when it was originally presented. Given the suggestion that the = chain > > is shown for advanced users (see 4.6.4) I am wondering about the = fact > > that we are no longer looking at anything more that the terminal > > certificate at this point. >=20 > Yes, that's important. >=20 > I think this text is a bit confusing because it uses the term "match" > for comparing the entire cached certificate against the entire = presented > certificate, whereas in the rest of the document we use the term = "match" > for comparing reference identifiers against presented identifiers. >=20 > Therefore I propose the following adjusted text: >=20 > If the client does not find a presented identifier matching any of > the reference identifiers, and (a) a human user has previously > accepted and cached a certificate for this application service = during > a previous interaction with the service or (b) a certificate has = been > cached via configuration settings, then the client MUST verify that > the presented certificate is the same as the cached certificate, > including verification of the entire certification path. If the > presented certificate is not the same as the cached certificate = then > the client MUST proceed as described under Section 4.6.4. >=20 You might change the text to be "cached a certificate with certificate = path" for the text in (a) and (b) This makes it more clear that the = entire certificate path is supposed to be cached. (This is a = potentially harder thing for configuration settings as a certificate = path would be required to be loaded. But making it more explicitly is = probably helpful.) > >> 4.6.3. Case #3: No Match Found, No Cached Certificate > >> > >> If the client does not find a presented identifier matching any = of > >> the reference identifiers, and the client has not previously = cached a > >> certificate for this application service based on user = acceptance or > >> configuration, then the client MUST proceed as described under > >> Section 4.6.4. > >> > >> 4.6.4. Fallback > >> > >> If the client is an interactive client that is directly = controlled by > >> a human user, then it SHOULD inform the user of the identity = mismatch > >> and automatically terminate the connection with a bad = certificate > >> error; this behavior is preferable because it prevents users = from > >> inadvertently bypassing security protections in hostile = situations. > >> > >> Security Note: Some interactive clients give advanced users = the > >> option of proceeding with acceptance and caching of the = presented > >> certificate despite an identity mismatch. Although this = behavior > >> can be appropriate in certain specialized circumstances, in > >> general it ought to be exposed only to advanced users. Even = then > >> it needs to be handled with extreme caution, for example by = first > >> encouraging even an advanced user to terminate the = connection and, > >> if the advanced user chooses to proceed anyway, by forcing = the > >> user to view the entire certification path and only then = allowing > >> the user to accept the certificate (on a temporary or = permanent > >> basis, at the user's option). > >> > >> Otherwise, if the client is an automated application not = directly > >> controlled by a human user, then it SHOULD terminate the = connection > >> with a bad certificate error and log the error appropriately. = An > >> automated application MAY provide a configuration setting that > >> disables this behavior, but MUST enable the behavior by = default. > > > > I would like to see the MAY and MUST here be lower cased. They are > > implied by the SHOULD in the preceding sentence and do not need to = be re- > iterated. >=20 > I think it might be better to delete the last sentence entirely since = it is really an > implementation detail (the main point is that the client SHOULD = terminate the > connection). >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ From stpeter@stpeter.im Wed Sep 29 16:18:45 2010 Return-Path: <stpeter@stpeter.im> 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 F37E83A6C2F for <certid@core3.amsl.com>; Wed, 29 Sep 2010 16:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 F-u4QATor759 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 16:18:43 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4370B3A6C09 for <certid@ietf.org>; Wed, 29 Sep 2010 16:18:43 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A93B340BB9; Wed, 29 Sep 2010 17:25:00 -0600 (MDT) Message-ID: <4CA3C97D.8060809@stpeter.im> Date: Wed, 29 Sep 2010 17:19:25 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jim Schaad <ietf@augustcellars.com> References: <4CA3AF50.6050101@KingsMountain.com> <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> <4CA3C022.8050202@stpeter.im> <006a01cb602c$f3dd1150$db9733f0$@augustcellars.com> In-Reply-To: <006a01cb602c$f3dd1150$db9733f0$@augustcellars.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'IETF cert-based identity' <certid@ietf.org>, '=JeffH' <Jeff.Hodges@KingsMountain.com> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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, 29 Sep 2010 23:18:45 -0000 On 9/29/10 5:20 PM, Jim Schaad wrote: > > >> -----Original Message----- From: Peter Saint-Andre >> [mailto:stpeter@stpeter.im] Sent: Wednesday, September 29, 2010 >> 3:40 PM To: Jim Schaad Cc: '=JeffH'; 'IETF cert-based identity' >> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate >> handling) >> >> On 9/29/10 4:19 PM, Jim Schaad wrote: >>> >>> >>>> -----Original Message----- From: certid-bounces@ietf.org >>>> [mailto:certid-bounces@ietf.org] On Behalf >>> Of >>>> =JeffH Sent: Wednesday, September 29, 2010 2:28 PM To: IETF >>>> cert-based identity Subject: [certid] section 4.6 rewrite (aka: >>>> Bad certificate handling) >>>> >>>> I and PeterSA took a hard look at section "4.6 Outcome" (aka: >>>> Bad >>> certificate >>>> handling) and indeed its language needed some semi-major >>>> rewriting, which we've done. The entire new section "4.6 >>>> Outcome" is below. >>>> >>>> comments? >>>> >>>> thanks, >>>> >>>> =JeffH >>>> >>>> ### >>>> >>>> 4.6. Outcome >>>> >>>> The outcome of the checking procedure is one of the following >>>> cases. >>>> >>>> 4.6.1. Case #1: Match Found >>>> >>>> If the client has found a presented identifier that matches a >>>> reference identifier, matching has succeeded. In this case, >>>> the client MUST use the matched reference identifier as the >>>> validated identity of the server. >>>> >>>> 4.6.2. Case #2: No Match Found, Cached Certificate >>>> >>>> If the client does not find a presented identifier matching any >>>> of the reference identifiers, and (a) a human user has >>>> previously accepted and cached a certificate for this >>>> application service during a previous interaction with the >>>> service or (b) a certificate has been cached via configuration >>>> settings, then the client MUST verify that the presented >>>> certificate matches the cached certificate. If the presented >>>> certificate does not match the cached certificate then the >>>> client MUST proceed as described under Section 4.6.4. >>> >>> There was one case in the original text here that I was expecting >>> to be kept. This was the case of the chain of certificates >>> being changed from when it was originally presented. Given the >>> suggestion that the chain is shown for advanced users (see 4.6.4) >>> I am wondering about the fact that we are no longer looking at >>> anything more that the terminal certificate at this point. >> >> Yes, that's important. >> >> I think this text is a bit confusing because it uses the term >> "match" for comparing the entire cached certificate against the >> entire presented certificate, whereas in the rest of the document >> we use the term "match" for comparing reference identifiers against >> presented identifiers. >> >> Therefore I propose the following adjusted text: >> >> If the client does not find a presented identifier matching any of >> the reference identifiers, and (a) a human user has previously >> accepted and cached a certificate for this application service >> during a previous interaction with the service or (b) a certificate >> has been cached via configuration settings, then the client MUST >> verify that the presented certificate is the same as the cached >> certificate, including verification of the entire certification >> path. If the presented certificate is not the same as the cached >> certificate then the client MUST proceed as described under Section >> 4.6.4. >> > > You might change the text to be "cached a certificate with > certificate path" for the text in (a) and (b) This makes it more > clear that the entire certificate path is supposed to be cached. > (This is a potentially harder thing for configuration settings as a > certificate path would be required to be loaded. But making it more > explicitly is probably helpful.) I'm always in favor of making such things explicit. This will be fixed in the next version -- I now have "certificate (with certificate path)" in multiple locations of the working copy. Peter -- Peter Saint-Andre https://stpeter.im/ From stefan@aaa-sec.com Wed Sep 29 16:19:37 2010 Return-Path: <stefan@aaa-sec.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 E9C893A69DD for <certid@core3.amsl.com>; Wed, 29 Sep 2010 16:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.663 X-Spam-Level: X-Spam-Status: No, score=-102.663 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 JiBoA91KVgIn for <certid@core3.amsl.com>; Wed, 29 Sep 2010 16:19:36 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 501383A6835 for <certid@ietf.org>; Wed, 29 Sep 2010 16:19:35 -0700 (PDT) Received: from s57.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 118CD2E96E6 for <certid@ietf.org>; Thu, 30 Sep 2010 01:20:28 +0200 (CEST) Received: (qmail 15496 invoked from network); 29 Sep 2010 23:20:18 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <stpeter@stpeter.im>; 29 Sep 2010 23:20:18 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 30 Sep 2010 01:20:15 +0200 From: Stefan Santesson <stefan@aaa-sec.com> To: Peter Saint-Andre <stpeter@stpeter.im>, Paul Hoffman <paul.hoffman@vpnc.org> Message-ID: <C8C9964F.F751%stefan@aaa-sec.com> Thread-Topic: [certid] Why require EKU for certid? Thread-Index: ActgLN83fyneejIEL0CCpj4bo4uHrA== In-Reply-To: <4CA3BCBB.1010007@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Why require EKU for certid? 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, 29 Sep 2010 23:19:38 -0000 On 10-09-30 12:24 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote: > On 9/29/10 4:20 PM, Paul Hoffman wrote: >> At 2:03 PM -0600 9/29/10, Peter Saint-Andre wrote: >>> [trimming tls@ and ietf@ from cc list] >>> >>> On 9/23/10 11:43 AM, Henry B. Hotz wrote: >>>> >>>> On Sep 22, 2010, at 9:44 AM, Paul Hoffman wrote: >>>> >>>>> At 10:21 AM -0600 9/22/10, Peter Saint-Andre wrote: >>>>>> On 9/14/10 12:51 AM, Stefan Santesson wrote: >>>>>>> General: I would consider stating that server certificates >>>>>>> according to this profile either MUST or SHOULD have the >>>>>>> serverAuth EKU set since it is allways related to the use >>>>>>> of TSL and server authentication. At least it MUST be set >>>>>>> when allowing checks of the CN-ID (see 2.3 below). >>>>>> >>>>>> [..snip..] >>>>> >>>> >>>>> What possible advantage is there to making certificates that do >>>>> not have this flag set be excluded from the practices you are >>>>> defining? That is, if a TLS client gets a certificate from a >>>>> TLS server that the TLS server says is its authentication >>>>> certificate, why should the client care whether or not that >>>>> flag is set? That flag is an assertion from the CA, not from >>>>> the server who is authenticating. >>>> >>>> >>>> Does this point need discussion? Without checking, I suspect >>>> that 5280 says you obey the EKU, period. OTOH I think Paul >>>> raises a valid point. >>>> >>>> OTOH (again) one could argue that the EKU provides a way to >>>> prevent a stolen cert/key issued to the machine for a different >>>> function from being repurposed to support a fake server. (I'm >>>> not convinced this is significant, but it's something.) >>>> >>>> Absent discussion and consensus, I vote for whatever 5280 says, >>>> which I suppose is what the current silence on the topic equates >>>> to. >>> >>> This I-D shall never be taken to override anything in RFC 5280 or >>> any other normatively-referenced specification on which it depends. >>> If folks think we need a blanket statement to that effect, please >>> let us know. Version -10 will have a new section containing an >>> applicability statement, which starts as follows: >>> >>> This document does not supersede the rules for certificate >>> validation provided in [RFC5280]. >>> >>> But we can always add a stronger statement if need be. >> >> This misses the point I made when I started this thread. > > That's because I was replying only to the small item of whether the > server-id-check can be taken to override RFC 5280. > >> Stefan >> proposed a change that would require that only certs that included >> this EKU be considered, you said you would consider that, > > I think I said only that Jeff and I hadn't discussed it yet. It's still > on our todo list. > >> and I said >> that would be a bad change. Henry's point did not negate or support >> my proposal. > > My sense of the discussion so far is that there's no strong agreement to > accept the proposal that Stefan made. > My point is more that it is good practice to have serverAuth set when the CN attribute is allowed to carry a DN. Absent the serverAuth EKU it is hard to programmatically be sure that the CN actually contains a DNS name. Yes you can probably be pretty sure but there is just a slight chance for problems due to overloaded semantics. ServerAuth provides a much cleaner indication than parsing the CN attribute only. I see potential security problems if a CA allows you to for example set your CN as a friendly name while other attributes such as givenName and SureName are checked against your registered name. The friendly name may be hard to check as it may differ from your registered name (ex Tim Polk). Thus some not so careful implementation may have poor checks and allow you to choose a domain name as your friendly name. This certificate may never be intended to be used for server authentication, but following the rules of the draft this certificate now allows spoofing and you would never detect that. More importantly it has to do with name constraints processing. If you accept the CN attribute as a domain name you need to make sure that it also matches any name constraints set for the dNSName of the path. It is much cleaner again to use the serverAuth as a mechanism for switching in this logic. Absent this check, the domain name may violate name constraints and you would never know. This is the most important point. /Stefan From paul.hoffman@vpnc.org Wed Sep 29 17:12:25 2010 Return-Path: <paul.hoffman@vpnc.org> 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 EC3B43A6974 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 17:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.358 X-Spam-Level: X-Spam-Status: No, score=-101.358 tagged_above=-999 required=5 tests=[AWL=0.688, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 qiuiwnYtIoI1 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 17:12:24 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E09FD3A6AE3 for <certid@ietf.org>; Wed, 29 Sep 2010 17:12:23 -0700 (PDT) Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o8U0D29h090024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2010 17:13:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: <p0624084fc8c98553729e@[10.20.30.163]> In-Reply-To: <C8C9964F.F751%stefan@aaa-sec.com> References: <C8C9964F.F751%stefan@aaa-sec.com> Date: Wed, 29 Sep 2010 17:13:01 -0700 To: Stefan Santesson <stefan@aaa-sec.com> From: Paul Hoffman <paul.hoffman@vpnc.org> Content-Type: text/plain; charset="us-ascii" Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Why require EKU for certid? 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: Thu, 30 Sep 2010 00:12:25 -0000 At 1:20 AM +0200 9/30/10, Stefan Santesson wrote: >My point is more that it is good practice to have serverAuth set when the CN >attribute is allowed to carry a DN. Yes it is. However, that is irrelevant to this document. It would be relevant to a document saying how to create a well-formed server certificate for TLS. >Absent the serverAuth EKU it is hard to programmatically be sure that the CN >actually contains a DNS name. Yes you can probably be pretty sure but there >is just a slight chance for problems due to overloaded semantics. Even if the serverAuth EKU is set, you cannot be sure the CN actually contains a DNS name. The two are orthogonal. >ServerAuth provides a much cleaner indication than parsing the CN attribute >only. I see potential security problems if a CA allows you to for example >set your CN as a friendly name while other attributes such as givenName and >SureName are checked against your registered name. The friendly name may be >hard to check as it may differ from your registered name (ex Tim Polk). >Thus some not so careful implementation may have poor checks and allow you >to choose a domain name as your friendly name. This certificate may never be >intended to be used for server authentication, but following the rules of >the draft this certificate now allows spoofing and you would never detect >that. See both points above. >More importantly it has to do with name constraints processing. If you >accept the CN attribute as a domain name you need to make sure that it also >matches any name constraints set for the dNSName of the path. It is much >cleaner again to use the serverAuth as a mechanism for switching in this >logic. Then there should be a PKIX document saying this. It is not relevant to a document that tells how to match a domain name the client has in its left hand against the identities in the cert it holds in its right hand. >Absent this check, the domain name may violate name constraints and you >would never know. This is the most important point. If the TLS client is doing full certificate path validation, the certificate cannot violate name constraints. That is quite different than what you just said. --Paul Hoffman, Director --VPN Consortium From matt@mattmccutchen.net Wed Sep 29 17:56:05 2010 Return-Path: <matt@mattmccutchen.net> 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 E39523A6AE3 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 17:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] 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 mgztC88n980u for <certid@core3.amsl.com>; Wed, 29 Sep 2010 17:56:04 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id DCCDB3A6BD7 for <certid@ietf.org>; Wed, 29 Sep 2010 17:56:04 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 8E937284071; Wed, 29 Sep 2010 17:56:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=jgfySu2dcLGjyx3iYTxhMEiFifViFM0rosO70v+2GdC ZN4+M4zXhctxSfKT4aRYplp5ItZN/hqoHhnW6F25CG+mdYQCQsVi0o5ByVcX+pZW /KnwdXpebWAs42AWWQTte70q7PubQN4iWkC0Rc3iEdvVrZ8zKmJo/ZHhSR4t/VgA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=xaEO2XzuXMKGfPxVwf1H5qgOsJI=; b=juSZGi+w+2 aFf9Z3mvgUDqyWBThb6s/MA8j3km9HiZ3DFM+hntNBz8mEm6/Zu8QW5RR9s0KNbx XvSFjQeX+KBip2XG2DJfNDdztrqF8xTgrsNcYwrcp1/k2DhWolE8VpRWNKYuzO4Q xyvOQs4WzXSGTcuLF3aElYplY31dth478= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id 4754F28406C; Wed, 29 Sep 2010 17:56:49 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: =JeffH <Jeff.Hodges@KingsMountain.com> In-Reply-To: <4CA3AF50.6050101@KingsMountain.com> References: <4CA3AF50.6050101@KingsMountain.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 29 Sep 2010 20:56:47 -0400 Message-ID: <1285808207.1917.28.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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: Thu, 30 Sep 2010 00:56:06 -0000 On Wed, 2010-09-29 at 14:27 -0700, =JeffH wrote: > I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad certificate > handling) and indeed its language needed some semi-major rewriting, which we've > done. The entire new section "4.6 Outcome" is below. > > comments? The cases of "no cached certificate" and "different cached certificate" could probably be combined into "certificate not cached" to simplify things. I.e.: ### 4.6. Outcome ... 4.6.1. Case #1: Match Found ... 4.6.2. Case #2: No Match Found, Certificate Cached If the client does not find a presented identifier matching any of the reference identifiers, but the presented certificate has been designated as acceptable for this application service (a) by a human user during a previous interaction with the service or (b) via configuration settings, the server identity check succeeds. [XXX: What is the validated identity of the server? Should the cached certificate rather be designated as acceptable for a reference identifier, which can be taken as the identity of the server?] 4.6.3. Case #3: No Match Found, Certificate Not Cached If the client does not find a presented identifier matching any of the reference identifiers and the presented certificate has not been accepted as described in section 4.6.2, then the client MUST NOT consider the certificate to include a validated identity for the application service. Instead, the client MUST proceed as follows. [...] ### -- Matt From matt@mattmccutchen.net Wed Sep 29 18:10:38 2010 Return-Path: <matt@mattmccutchen.net> 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 4A7ED3A6B49 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 18:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] 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 m+Zn9zNKdYEE for <certid@core3.amsl.com>; Wed, 29 Sep 2010 18:10:26 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id A5C793A69AB for <certid@ietf.org>; Wed, 29 Sep 2010 18:10:04 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 740A157806C; Wed, 29 Sep 2010 18:10:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=YeTQ97XzmY2NXS2EmsI+geN17vgeswrWx6mpLb8Xlcz +ZSoIMfn3r03vno3TceoNvW8TWR3AZGCX0QQNW7+Rldm2/eSSZQQbjSGAXy83lwG I5KlBpaWuaDAtAXA77mlJwOvJzYLUCyr7ql3RUGlUMjsiEpuVSnx75gQVhciGW+c = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=864vxqRS7QeRFpnPmCwI6DUOaX0=; b=SKvj429tb4 22Nkc6U8NMab4uWRz9ktxk4NZ44Pv49TFVI5xAApcAZIiW8RVOgpncsc6x/tD6AL LlAm5j+jGTff/LgoXT6J8O6uNquuemBDa4LAAobjISQCc2muoYh5amur+QGtZLsB 4XP+K3tegn7ks1lE+PaeHqpVHmkHetng0= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id 1EBF9578073; Wed, 29 Sep 2010 18:10:49 -0700 (PDT) From: Matt McCutchen <matt@mattmccutchen.net> To: Peter Saint-Andre <stpeter@stpeter.im> In-Reply-To: <4CA3C022.8050202@stpeter.im> References: <4CA3AF50.6050101@KingsMountain.com> <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> <4CA3C022.8050202@stpeter.im> Content-Type: text/plain; charset="UTF-8" Date: Wed, 29 Sep 2010 21:10:48 -0400 Message-ID: <1285809048.1917.42.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: Jim Schaad <ietf@augustcellars.com>, 'IETF cert-based identity' <certid@ietf.org> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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: Thu, 30 Sep 2010 01:10:38 -0000 On Wed, 2010-09-29 at 16:39 -0600, Peter Saint-Andre wrote: > On 9/29/10 4:19 PM, Jim Schaad wrote: > > There was one case in the original text here that I was expecting to be > > kept. This was the case of the chain of certificates being changed from > > when it was originally presented. Given the suggestion that the chain is > > shown for advanced users (see 4.6.4) I am wondering about the fact that we > > are no longer looking at anything more that the terminal certificate at this > > point. > > Yes, that's important. What is the benefit of caching the entire certification path? What attacks does it prevent? Mozilla PSM only caches the end-entity certificate, and if there is a problem with that approach, I would like to know about it. -- Matt From mrex@sap.com Wed Sep 29 19:31:22 2010 Return-Path: <mrex@sap.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 D10FE3A6D69 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 19:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.82 X-Spam-Level: X-Spam-Status: No, score=-9.82 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 U1R1atXGNkIq for <certid@core3.amsl.com>; Wed, 29 Sep 2010 19:31:21 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 21FAB3A6D66 for <certid@ietf.org>; Wed, 29 Sep 2010 19:31:20 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8U2W0mN013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Sep 2010 04:32:01 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009300232.o8U2W0UF010291@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 30 Sep 2010 04:32:00 +0200 (MEST) In-Reply-To: <4CA3C022.8050202@stpeter.im> from "Peter Saint-Andre" at Sep 29, 10 04:39:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: ietf@augustcellars.com, certid@ietf.org, Jeff.Hodges@KingsMountain.com Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Thu, 30 Sep 2010 02:31:22 -0000 Peter Saint-Andre wrote: > > >> 4.6.2. Case #2: No Match Found, Cached Certificate > >> > >> If the client does not find a presented identifier matching any of > >> the reference identifiers, and (a) a human user has previously > >> accepted and cached a certificate for this application service during > >> a previous interaction with the service or (b) a certificate has been > >> cached via configuration settings, then the client MUST verify that > >> the presented certificate matches the cached certificate. If the > >> presented certificate does not match the cached certificate then the > >> client MUST proceed as described under Section 4.6.4. > > > > There was one case in the original text here that I was expecting to be > > kept. This was the case of the chain of certificates being changed from > > when it was originally presented. Given the suggestion that the chain is > > shown for advanced users (see 4.6.4) I am wondering about the fact that we > > are no longer looking at anything more that the terminal certificate at this > > point. > > Yes, that's important. > > I think this text is a bit confusing because it uses the term "match" > for comparing the entire cached certificate against the entire presented > certificate, whereas in the rest of the document we use the term "match" > for comparing reference identifiers against presented identifiers. > > Therefore I propose the following adjusted text: > > If the client does not find a presented identifier matching any of > the reference identifiers, and (a) a human user has previously > accepted and cached a certificate for this application service during > a previous interaction with the service or (b) a certificate has been > cached via configuration settings, then the client MUST verify that > the presented certificate is the same as the cached certificate, > including verification of the entire certification path. If the > presented certificate is not the same as the cached certificate then > the client MUST proceed as described under Section 4.6.4. I do NOT see any reason to cache (and later compare) the entire chain of certificates. It is ONLY the server certificate that matters here. What could be distinguished is what kind of override the user or the application configuration is requesting. Is it only an override for the server-id-check (but otherwise a server certificate that succeeds a regular path validation), or is it an _untrusted_ server certificate, for which no certificate path validation can be performed. If it is only the former, performing regular certificate path validation and revocation checking is sensible. For the latter, a certificate path validation can not be performed. > >> > >> Security Note: Some interactive clients give advanced users the > >> option of proceeding with acceptance and caching of the presented > >> certificate despite an identity mismatch. Although this behavior > >> can be appropriate in certain specialized circumstances, in > >> general it ought to be exposed only to advanced users. Even then > >> it needs to be handled with extreme caution, for example by first > >> encouraging even an advanced user to terminate the connection and, > >> if the advanced user chooses to proceed anyway, by forcing the > >> user to view the entire certification path and only then allowing > >> the user to accept the certificate (on a temporary or permanent > >> basis, at the user's option). Similarily here, "forcing the user to view the entire certification path" does not seem appropriate. It is the server's certificate that matters and which needs to be cached. When there is a lack of trust to the servers certificate (because it is a self-signed cert or issued by some private CA) then the certification path is irrelevant and can not be verified with a regular certificate path validation for "pinned" server certs. > >> > >> Otherwise, if the client is an automated application not directly > >> controlled by a human user, then it SHOULD terminate the connection > >> with a bad certificate error and log the error appropriately. An > >> automated application MAY provide a configuration setting that > >> disables this behavior, but MUST enable the behavior by default. > > > > I would like to see the MAY and MUST here be lower cased. They are implied > > by the SHOULD in the preceding sentence and do not need to be re-iterated. There appears to be a misunderstanding about rfc-2119 terminology (which is not affected by case). compare http://www.ietf.org/mail-archive/web/ietf/current/msg59589.html If the document wants to use the rfc-2119 terminology in lower case typesetting for non-rfc-2119 meaning, it should explicitly say so. Preferably, it should use different words/expressions than "must". -Martin From mrex@sap.com Wed Sep 29 20:23:53 2010 Return-Path: <mrex@sap.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 B82233A6C05 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 20:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.525 X-Spam-Level: X-Spam-Status: No, score=-9.525 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 stwEF+3+u0+W for <certid@core3.amsl.com>; Wed, 29 Sep 2010 20:23:52 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 5FCCE3A6BCC for <certid@ietf.org>; Wed, 29 Sep 2010 20:23:52 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o8U3OZDl002336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Sep 2010 05:24:35 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009300324.o8U3OYBJ013277@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 30 Sep 2010 05:24:34 +0200 (MEST) In-Reply-To: <p0624084fc8c98553729e@[10.20.30.163]> from "Paul Hoffman" at Sep 29, 10 05:13:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: stefan@aaa-sec.com, certid@ietf.org Subject: Re: [certid] Why require EKU for certid? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Thu, 30 Sep 2010 03:23:53 -0000 Paul Hoffman wrote: > > At 1:20 AM +0200 9/30/10, Stefan Santesson wrote: > >My point is more that it is good practice to have serverAuth set when the CN > >attribute is allowed to carry a DN. > > Yes it is. However, that is irrelevant to this document. It would be > relevant to a document saying how to create a well-formed server > certificate for TLS. It is my understanding that the target audience of this document includes CAs, WebServer Admins, Sysadmins and applications on top of TLS ... however it is a little weak in clarifying to which particular audience which particular recommendation/imperative applies. > > >Absent the serverAuth EKU it is hard to programmatically be sure that the CN > >actually contains a DNS name. Yes you can probably be pretty sure but there > >is just a slight chance for problems due to overloaded semantics. > > Even if the serverAuth EKU is set, you cannot be sure the CN actually > contains a DNS name. The two are orthogonal. They are independent, correct. Server endpoint identification has been performed by SSLv3 clients and TLS v1.0 (rfc-2246) clients based on CN-IDs exclusively for many years. rfc-2459 defines an EKU / KeyPurposeId for TLS Servers and TLS clients http://tools.ietf.org/html/rfc2459#page-39 while the server endpoint identification by dNSName SANs instead of CN-IDs appears to be first documented in rfc-2818. Conceptually, every extension that is added to an X.509v3 certificate further constraints its purpose/applicability (compared to not carrying the extension). There are small deviations for the BasicConstraints defined in PKIX, but basically, that's it. So a server cert with the TLS id-kp-serverAuth EKU is "limited" to TLS server auth, not "extended" to it. AFAIK there are also two private OIDs from Netscape and two from Microsoft with the same meaning as id-kp-serverAuth and id-kp-clientAuth. And I would not rely on clients being strict in checking TLS server EKUs... > > >More importantly it has to do with name constraints processing. If you > >accept the CN attribute as a domain name you need to make sure that it also > >matches any name constraints set for the dNSName of the path. It is much > >cleaner again to use the serverAuth as a mechanism for switching in this > >logic. EKUs primarily affect usage scenarios that are born with EKU requirements, rather than SSL&TLS clients and servers, where the EKU situation started as a big mess and the current status is fairly undetermined. > > >Absent this check, the domain name may violate name constraints and you > >would never know. This is the most important point. > > If the TLS client is doing full certificate path validation, the > certificate cannot violate name constraints. That is quite different > than what you just said. As defined by PKIX, name constraints defined for dNSName SANs do not apply to directoryNames such as a certificate subject. Some people are trying to artificially redefine the semantics of name constraints to ensure business models of CAs coming preconfigured as trusted with the software. They're asking TLS clients for a gruesome breach of the PKIX name constraints architecture to "protect" against CAs from evading "dNSName SAN name constraints" imposed by their superiorCAs by issuing server certs without dNSName SANs (and CN-IDs instead, to which dNSName SAN name constraints do no apply). I think it is an extremely bad idea to increase the complexity of CN-ID server-id-check semantics, which have been deprecated 10 years ago, by the order of a magnitude -- in particular in a BCP document, because most of the installed base does not work that way and a huge part of them is quite unlikely to ever adopt such weird CN-ID semantics. -Martin From ietf@augustcellars.com Wed Sep 29 22:17:01 2010 Return-Path: <ietf@augustcellars.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 E54BC3A6D28 for <certid@core3.amsl.com>; Wed, 29 Sep 2010 22:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 QhpppqLF2BeN for <certid@core3.amsl.com>; Wed, 29 Sep 2010 22:17:00 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 8E1833A6C27 for <certid@ietf.org>; Wed, 29 Sep 2010 22:17:00 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 1ECE26EF7C; Wed, 29 Sep 2010 22:17:45 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: "'Matt McCutchen'" <matt@mattmccutchen.net>, "'Peter Saint-Andre'" <stpeter@stpeter.im> References: <4CA3AF50.6050101@KingsMountain.com> <006801cb6024$6049f5a0$20dde0e0$@augustcellars.com> <4CA3C022.8050202@stpeter.im> <1285809048.1917.42.camel@mattlaptop2.local> In-Reply-To: <1285809048.1917.42.camel@mattlaptop2.local> Date: Wed, 29 Sep 2010 22:25:24 -0700 Message-ID: <006b01cb605f$e2a7f9d0$a7f7ed70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpqtf1DBfzG3HdU1/o9iR7FXwOzwKTMizaAiIBOD4CiiY6Z5Mzbmqg Content-Language: en-us Cc: 'IETF cert-based identity' <certid@ietf.org> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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: Thu, 30 Sep 2010 05:17:02 -0000 If there is only one possible certification path then there is no = difference between caching just the EE certificate and caching the = entire chain. However in the event that multiple certificate paths are = possible there may be a difference in behavior. It is possible that you = would trust a specific trust anchor (or intermediate CA) to be more = specific about getting things correct (sooner or later). There may be = differences in extensions which exist in the intermediate certificates = which might lead to slightly different behavior in how the EE = certificates are treated. It is for these reasons that if an explicit = mismatch exists then you might be more or less willing to trust the EE = certificate based on a specific validation path but not on another = validation path. Jim > -----Original Message----- > From: Matt McCutchen [mailto:matt@mattmccutchen.net] > Sent: Wednesday, September 29, 2010 6:11 PM > To: Peter Saint-Andre > Cc: Jim Schaad; 'IETF cert-based identity' > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate = handling) >=20 > On Wed, 2010-09-29 at 16:39 -0600, Peter Saint-Andre wrote: > > On 9/29/10 4:19 PM, Jim Schaad wrote: > > > There was one case in the original text here that I was expecting = to be > > > kept. This was the case of the chain of certificates being = changed from > > > when it was originally presented. Given the suggestion that the > > > chain is shown for advanced users (see 4.6.4) I am wondering about > > > the fact that we are no longer looking at anything more that the > > > terminal certificate at this point. > > > > Yes, that's important. >=20 > What is the benefit of caching the entire certification path? What = attacks does > it prevent? Mozilla PSM only caches the end-entity certificate, and = if there is a > problem with that approach, I would like to know about it. >=20 > -- > Matt From ietf@augustcellars.com Wed Sep 29 22:18:43 2010 Return-Path: <ietf@augustcellars.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 4DFCC3A6B1F for <certid@core3.amsl.com>; Wed, 29 Sep 2010 22:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DzcC14jZM7OJ for <certid@core3.amsl.com>; Wed, 29 Sep 2010 22:18:42 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id B84653A6B7E for <certid@ietf.org>; Wed, 29 Sep 2010 22:18:41 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 91C2F6A41D; Wed, 29 Sep 2010 22:19:26 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: "'Matt McCutchen'" <matt@mattmccutchen.net>, "'=JeffH'" <Jeff.Hodges@KingsMountain.com> References: <4CA3AF50.6050101@KingsMountain.com> <1285808207.1917.28.camel@mattlaptop2.local> In-Reply-To: <1285808207.1917.28.camel@mattlaptop2.local> Date: Wed, 29 Sep 2010 22:27:05 -0700 Message-ID: <006c01cb6060$1f213cf0$5d63b6d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGpqtf1DBfzG3HdU1/o9iR7FXwOzwIyKBCqk1vZBDA= Content-Language: en-us Cc: 'IETF cert-based identity' <certid@ietf.org> Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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: Thu, 30 Sep 2010 05:18:43 -0000 > -----Original Message----- > From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On Behalf Of > Matt McCutchen > Sent: Wednesday, September 29, 2010 5:57 PM > To: =JeffH > Cc: IETF cert-based identity > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > On Wed, 2010-09-29 at 14:27 -0700, =JeffH wrote: > > I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad > > certificate > > handling) and indeed its language needed some semi-major rewriting, > > which we've done. The entire new section "4.6 Outcome" is below. > > > > comments? > > The cases of "no cached certificate" and "different cached certificate" > could probably be combined into "certificate not cached" to simplify things. > I.e.: > > ### > > 4.6. Outcome > ... > 4.6.1. Case #1: Match Found > ... > 4.6.2. Case #2: No Match Found, Certificate Cached > > If the client does not find a presented identifier matching any of the reference > identifiers, but the presented certificate has been designated as acceptable for > this application service (a) by a human user during a previous interaction with > the service or (b) via configuration settings, the server identity check succeeds. > [XXX: What is the validated identity of the server? Should the cached certificate > rather be designated as acceptable for a reference identifier, which can be > taken as the identity of the server?] You cannot take the presented identifier as the identity of the server as it might contain wild cards. > > 4.6.3. Case #3: No Match Found, Certificate Not Cached > > If the client does not find a presented identifier matching any of the reference > identifiers and the presented certificate has not been accepted as described in > section 4.6.2, then the client MUST NOT consider the certificate to include a > validated identity for the application service. Instead, the client MUST proceed > as follows. [...] > > ### > > -- > Matt > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid From stefan@aaa-sec.com Wed Sep 29 23:36:48 2010 Return-Path: <stefan@aaa-sec.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 ED45C3A6D4D for <certid@core3.amsl.com>; Wed, 29 Sep 2010 23:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Wuy4TFemBRYu for <certid@core3.amsl.com>; Wed, 29 Sep 2010 23:36:29 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id 879863A6B5B for <certid@ietf.org>; Wed, 29 Sep 2010 23:36:18 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id BF4EC2D48F1 for <certid@ietf.org>; Thu, 30 Sep 2010 08:37:03 +0200 (CEST) Received: (qmail 36742 invoked from network); 30 Sep 2010 06:37:01 -0000 Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.5]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <paul.hoffman@vpnc.org>; 30 Sep 2010 06:37:01 -0000 User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Thu, 30 Sep 2010 08:36:58 +0200 From: Stefan Santesson <stefan@aaa-sec.com> To: Paul Hoffman <paul.hoffman@vpnc.org> Message-ID: <C8C9FCAA.F771%stefan@aaa-sec.com> Thread-Topic: [certid] Why require EKU for certid? Thread-Index: ActgaeFs+jnNRppEw069h7GuV0BxvA== In-Reply-To: <p0624084fc8c98553729e@[10.20.30.163]> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org> Subject: Re: [certid] Why require EKU for certid? 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: Thu, 30 Sep 2010 06:36:48 -0000 On 10-09-30 2:13 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote: > At 1:20 AM +0200 9/30/10, Stefan Santesson wrote: >> My point is more that it is good practice to have serverAuth set when the CN >> attribute is allowed to carry a DN. > > Yes it is. However, that is irrelevant to this document. It would be relevant > to a document saying how to create a well-formed server certificate for TLS. > >> Absent the serverAuth EKU it is hard to programmatically be sure that the CN >> actually contains a DNS name. Yes you can probably be pretty sure but there >> is just a slight chance for problems due to overloaded semantics. > > Even if the serverAuth EKU is set, you cannot be sure the CN actually contains > a DNS name. The two are orthogonal. > You are correct. But IF you accept the domain name from the CN attribute and the serverAuth, you do at least know that the certificate is issued to a TLS server endpoint. It thus holds the name of a TLS server. >> ServerAuth provides a much cleaner indication than parsing the CN attribute >> only. I see potential security problems if a CA allows you to for example >> set your CN as a friendly name while other attributes such as givenName and >> SureName are checked against your registered name. The friendly name may be >> hard to check as it may differ from your registered name (ex Tim Polk). >> Thus some not so careful implementation may have poor checks and allow you >> to choose a domain name as your friendly name. This certificate may never be >> intended to be used for server authentication, but following the rules of >> the draft this certificate now allows spoofing and you would never detect >> that. > > See both points above. > See point above. You can't possibly mean that the risk of spoofing is the same regardless of whether serverAuth is checked. >> More importantly it has to do with name constraints processing. If you >> accept the CN attribute as a domain name you need to make sure that it also >> matches any name constraints set for the dNSName of the path. It is much >> cleaner again to use the serverAuth as a mechanism for switching in this >> logic. > > Then there should be a PKIX document saying this. It is not relevant to a > document that tells how to match a domain name the client has in its left hand > against the identities in the cert it holds in its right hand. > AFAIK there is no PKIX document supporting the use of CN to carry a domain name. This is a non standard practice. >> Absent this check, the domain name may violate name constraints and you >> would never know. This is the most important point. > > If the TLS client is doing full certificate path validation, the certificate > cannot violate name constraints. That is quite different than what you just > said. > That is just a game with words Paul. Of course the certificate does not violate name constraints. It is the USE of the certificate that violates the name constraints of the path. CA-X in the path has stated "You can only rely on this CA certificate to validate claims about domain names within the example.com namespace" If the end certificate holds the domain name "foo.com" in the CN, But no dNSName SAN, and you accept this claim then you are in fact trusting the CA-X certificate beyond its declared scope. This document is about best current practice right? I'm not an advocate for hopelessly rigid requirements and I do respect legacy. But I think it is reasonable to at least recommend clients to check any domain name against dNSName name constraints regardless of what attribute they pulled that information from. I also think it would be good practice to not blindly accept domain names from any attribute unless you have some indication that it is likely to hold a domain name. A large percentage of installed TLS clients perform these checks, so it is not taken from nowhere. I don't think we can create perfect, but we could limit the risks with reasonable recommendations. /Stefan From stpeter@stpeter.im Thu Sep 30 11:59:07 2010 Return-Path: <stpeter@stpeter.im> 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 787D93A6E3B for <certid@core3.amsl.com>; Thu, 30 Sep 2010 11:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 HVSpDK0H3pez for <certid@core3.amsl.com>; Thu, 30 Sep 2010 11:59:06 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 32E9C3A6E75 for <certid@ietf.org>; Thu, 30 Sep 2010 11:58:22 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5ACD340BB9; Thu, 30 Sep 2010 13:04:46 -0600 (MDT) Message-ID: <4CA4DDFB.2040306@stpeter.im> Date: Thu, 30 Sep 2010 12:59:07 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mrex@sap.com References: <201009300324.o8U3OYBJ013277@fs4113.wdf.sap.corp> In-Reply-To: <201009300324.o8U3OYBJ013277@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: stefan@aaa-sec.com, certid@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: [certid] Why require EKU for certid? 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: Thu, 30 Sep 2010 18:59:07 -0000 On 9/29/10 9:24 PM, Martin Rex wrote: > Paul Hoffman wrote: >> >> At 1:20 AM +0200 9/30/10, Stefan Santesson wrote: >> >>> Absent this check, the domain name may violate name constraints and you >>> would never know. This is the most important point. >> >> If the TLS client is doing full certificate path validation, the >> certificate cannot violate name constraints. That is quite different >> than what you just said. > > As defined by PKIX, name constraints defined for dNSName SANs do not > apply to directoryNames such as a certificate subject. > > Some people are trying to artificially redefine the semantics of > name constraints to ensure business models of CAs coming preconfigured > as trusted with the software. They're asking TLS clients for a gruesome > breach of the PKIX name constraints architecture to "protect" against > CAs from evading "dNSName SAN name constraints" imposed by their > superiorCAs by issuing server certs without dNSName SANs > (and CN-IDs instead, to which dNSName SAN name constraints do no apply). > > I think it is an extremely bad idea to increase the complexity of > CN-ID server-id-check semantics, which have been deprecated 10 years ago, > by the order of a magnitude -- in particular in a BCP document, > because most of the installed base does not work that way and > a huge part of them is quite unlikely to ever adopt such weird > CN-ID semantics. Agreed. As I see it, the Common Name is just a series of characters. Sometimes that series happens to contain one or more instances of the "." character, arrayed in a way that leads people to interpret the series of characters as a DNS domain name. That doesn't mean that it's sensible to take the PKIX name constraints that have been defined for the dNSName SAN and apply those constraints to a series of characters that happens to look like and be interpreted as a DNS domain name. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Sep 30 12:12:21 2010 Return-Path: <stpeter@stpeter.im> 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 ED7E63A6E3B for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 tSs4TTZ7Lxyb for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:12:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 14B243A6E63 for <certid@ietf.org>; Thu, 30 Sep 2010 12:12:15 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C586240BB9; Thu, 30 Sep 2010 13:18:38 -0600 (MDT) Message-ID: <4CA4E13B.7070908@stpeter.im> Date: Thu, 30 Sep 2010 13:12:59 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Stefan Santesson <stefan@aaa-sec.com> References: <C8C9FCAA.F771%stefan@aaa-sec.com> In-Reply-To: <C8C9FCAA.F771%stefan@aaa-sec.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity <certid@ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org> Subject: Re: [certid] Why require EKU for certid? 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: Thu, 30 Sep 2010 19:12:21 -0000 On 9/30/10 12:36 AM, Stefan Santesson wrote: > > > > On 10-09-30 2:13 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote: > >> At 1:20 AM +0200 9/30/10, Stefan Santesson wrote: >>> My point is more that it is good practice to have serverAuth set when the CN >>> attribute is allowed to carry a DN. >> >> Yes it is. However, that is irrelevant to this document. It would be relevant >> to a document saying how to create a well-formed server certificate for TLS. >> >>> Absent the serverAuth EKU it is hard to programmatically be sure that the CN >>> actually contains a DNS name. Yes you can probably be pretty sure but there >>> is just a slight chance for problems due to overloaded semantics. >> >> Even if the serverAuth EKU is set, you cannot be sure the CN actually contains >> a DNS name. The two are orthogonal. > > You are correct. But IF you accept the domain name from the CN attribute and > the serverAuth, you do at least know that the certificate is issued to a TLS > server endpoint. It thus holds the name of a TLS server. Right, you are interpreting the contents of the CN as a domain name. The question is: should the name constraints that apply to dNSName also apply to the contents of the CN (which are conventionally interpreted as a domain name if they have a "." somewhere in the middle)? >>> ServerAuth provides a much cleaner indication than parsing the CN attribute >>> only. I see potential security problems if a CA allows you to for example >>> set your CN as a friendly name while other attributes such as givenName and >>> SureName are checked against your registered name. The friendly name may be >>> hard to check as it may differ from your registered name (ex Tim Polk). >>> Thus some not so careful implementation may have poor checks and allow you >>> to choose a domain name as your friendly name. This certificate may never be >>> intended to be used for server authentication, but following the rules of >>> the draft this certificate now allows spoofing and you would never detect >>> that. >> >> See both points above. >> > See point above. > > You can't possibly mean that the risk of spoofing is the same regardless of > whether serverAuth is checked. > >>> More importantly it has to do with name constraints processing. If you >>> accept the CN attribute as a domain name you need to make sure that it also >>> matches any name constraints set for the dNSName of the path. It is much >>> cleaner again to use the serverAuth as a mechanism for switching in this >>> logic. >> >> Then there should be a PKIX document saying this. It is not relevant to a >> document that tells how to match a domain name the client has in its left hand >> against the identities in the cert it holds in its right hand. >> > > AFAIK there is no PKIX document supporting the use of CN to carry a domain > name. This is a non standard practice. Agreed. >>> Absent this check, the domain name may violate name constraints and you >>> would never know. This is the most important point. >> >> If the TLS client is doing full certificate path validation, the certificate >> cannot violate name constraints. That is quite different than what you just >> said. >> > > That is just a game with words Paul. Of course the certificate does not > violate name constraints. It is the USE of the certificate that violates the > name constraints of the path. > > CA-X in the path has stated "You can only rely on this CA certificate to > validate claims about domain names within the example.com namespace" > > If the end certificate holds the domain name "foo.com" in the CN, But no > dNSName SAN, and you accept this claim then you are in fact trusting the > CA-X certificate beyond its declared scope. > > This document is about best current practice right? > > I'm not an advocate for hopelessly rigid requirements and I do respect > legacy. But I think it is reasonable to at least recommend clients to check > any domain name against dNSName name constraints regardless of what > attribute they pulled that information from. I also think it would be good > practice to not blindly accept domain names from any attribute unless you > have some indication that it is likely to hold a domain name. > > A large percentage of installed TLS clients perform these checks, so it is > not taken from nowhere. > > I don't think we can create perfect, but we could limit the risks with > reasonable recommendations. In current practice, people are treating certain kinds of strings from the CN as domain names. Whether that is *best* current practice is another matter. :) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Sep 30 12:27:38 2010 Return-Path: <stpeter@stpeter.im> 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 8A5A83A6E6E for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 n-J5Z-PUKKzB for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:27:37 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6B3C23A6E6D for <certid@ietf.org>; Thu, 30 Sep 2010 12:27:37 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E4C8740BB9; Thu, 30 Sep 2010 13:34:01 -0600 (MDT) Message-ID: <4CA4E4D6.2020209@stpeter.im> Date: Thu, 30 Sep 2010 13:28:22 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jim Schaad <ietf@augustcellars.com> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> <1285450341.1940.79.camel@mattlaptop2.local> <4CA3B1B0.2040106@stpeter.im> <006901cb6024$97c85990$c7590cb0$@augustcellars.com> In-Reply-To: <006901cb6024$97c85990$c7590cb0$@augustcellars.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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: Thu, 30 Sep 2010 19:27:38 -0000 On 9/29/10 4:20 PM, Jim Schaad wrote: > It was my understanding of this that the request was that the DNS name > constraints be applied to a CN-ID that is being treated as a DN. This would > not be standard 5280 behavior. That's a nice short summary of the issue. It seems to me that defining such behavior might be within scope for an update to RFC 5280, but not for the server-id-check document (since it is by no means intended to update RFC 5280!). Peter -- Peter Saint-Andre https://stpeter.im/ From ietf@augustcellars.com Thu Sep 30 12:48:09 2010 Return-Path: <ietf@augustcellars.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 3350A3A6E80 for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ZOT99X90-w7A for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:48:07 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 228C23A6D2D for <certid@ietf.org>; Thu, 30 Sep 2010 12:48:07 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id 4A04F6EF39; Thu, 30 Sep 2010 12:48:53 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: "'Peter Saint-Andre'" <stpeter@stpeter.im> References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> <1285450341.1940.79.camel@mattlaptop2.local> <4CA3B1B0.2040106@stpeter.im> <006901cb6024$97c85990$c7590cb0$@augustcellars.com> <4CA4E4D6.2020209@stpeter.im> In-Reply-To: <4CA4E4D6.2020209@stpeter.im> Date: Thu, 30 Sep 2010 12:56:36 -0700 Message-ID: <00a201cb60d9$972bc930$c5835b90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE5mp2IHf/sQTeACWXye7dK1f19xwGNyQZRAom+LdwCIxKAuwF2kqUGlBD0PxA= Content-Language: en-us Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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: Thu, 30 Sep 2010 19:48:09 -0000 I would consider this to be an application specific behavior and not = part of the general validity processing that would be part of 5280. If = it was to happen anyplace I think this is where it should be = recommended. I don't however believe that it should necessarily be recommended = anywhere as a practice. jim > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Thursday, September 30, 2010 12:28 PM > To: Jim Schaad > Cc: 'Matt McCutchen'; certid@ietf.org > Subject: Re: [certid] CN-ID and name constraints >=20 > On 9/29/10 4:20 PM, Jim Schaad wrote: >=20 > > It was my understanding of this that the request was that the DNS = name > > constraints be applied to a CN-ID that is being treated as a DN. = This > > would not be standard 5280 behavior. >=20 > That's a nice short summary of the issue. It seems to me that defining = such > behavior might be within scope for an update to RFC 5280, but not for = the > server-id-check document (since it is by no means intended to update = RFC > 5280!). >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ From CWallace@cygnacom.com Thu Sep 30 12:56:01 2010 Return-Path: <CWallace@cygnacom.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 562523A6E67 for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 L7o2wjBTPKjg for <certid@core3.amsl.com>; Thu, 30 Sep 2010 12:55:59 -0700 (PDT) Received: from mail73.messagelabs.com (mail73.messagelabs.com [216.82.249.243]) by core3.amsl.com (Postfix) with SMTP id C4CC93A6E4A for <certid@ietf.org>; Thu, 30 Sep 2010 12:55:58 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-13.tower-73.messagelabs.com!1285876600!96074785!2 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.17] Received: (qmail 1880 invoked from network); 30 Sep 2010 19:56:44 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.17) by server-13.tower-73.messagelabs.com with SMTP; 30 Sep 2010 19:56:44 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 30 Sep 2010 15:52:52 -0400 Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D480112C82E@scygexch1.cygnacom.com> In-Reply-To: <00a201cb60d9$972bc930$c5835b90$@augustcellars.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [certid] CN-ID and name constraints Thread-Index: AQE5mp2IHf/sQTeACWXye7dK1f19xwGNyQZRAom+LdwCIxKAuwF2kqUGlBD0PxD///53EA== References: <201009250309.o8P39Sc7016343@fs4113.wdf.sap.corp> <1285450341.1940.79.camel@mattlaptop2.local><4CA3B1B0.2040106@stpeter.im><006901cb6024$97c85990$c7590cb0$@augustcellars.com><4CA4E4D6.2020209@stpeter.im> <00a201cb60d9$972bc930$c5835b90$@augustcellars.com> From: "Carl Wallace" <CWallace@cygnacom.com> To: "Jim Schaad" <ietf@augustcellars.com>, "Peter Saint-Andre" <stpeter@stpeter.im> Cc: certid@ietf.org Subject: Re: [certid] CN-ID and name constraints 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: Thu, 30 Sep 2010 19:56:01 -0000 > -----Original Message----- > From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On > Behalf Of Jim Schaad > Sent: Thursday, September 30, 2010 3:57 PM > To: 'Peter Saint-Andre' > Cc: certid@ietf.org > Subject: Re: [certid] CN-ID and name constraints >=20 > I would consider this to be an application specific behavior and not > part of the general validity processing that would be part of 5280. If > it was to happen anyplace I think this is where it should be > recommended. As a means of enabling this type of processing, RFC 5280 could be amended to output name constraints state similar to the way policy state is output now. From mrex@sap.com Thu Sep 30 14:14:34 2010 Return-Path: <mrex@sap.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 C21CE3A6B8E for <certid@core3.amsl.com>; Thu, 30 Sep 2010 14:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.831 X-Spam-Level: X-Spam-Status: No, score=-9.831 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 c+fFatG2Ij3B for <certid@core3.amsl.com>; Thu, 30 Sep 2010 14:14:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 8CAD73A6B6B for <certid@ietf.org>; Thu, 30 Sep 2010 14:14:32 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8ULErfC012090 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Sep 2010 23:14:54 +0200 (MEST) From: Martin Rex <mrex@sap.com> Message-Id: <201009302114.o8ULEqQd013861@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Thu, 30 Sep 2010 23:14:52 +0200 (MEST) In-Reply-To: <006b01cb605f$e2a7f9d0$a7f7ed70$@augustcellars.com> from "Jim Schaad" at Sep 29, 10 10:25:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com 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: Thu, 30 Sep 2010 21:14:34 -0000 Jim Schaad wrote: > > If there is only one possible certification path then there is no > difference between caching just the EE certificate and caching the > entire chain. However in the event that multiple certificate paths > are possible there may be a difference in behavior. Nope, not for what is specified in server-id-check. At most, the client would have to memorize along with the server cert whether regular certificate path validation worked for this cached cert. Any changes to the path (above the server cert) will either make the cert path validation fail or be security-irrelevant--entirely without caching and comparing chain certs above the cached/pinned server cert. When the caching/pinning of the server certs is done for untrusted server certs, then the trust relationship is defined only based on the server cert and certificate path validation can not be performed due to a lack of trust, so the chain certs above the server cert are again irrelevant. > > It is possible that you would trust a specific trust anchor (or > intermediate CA) to be more specific about getting things correct > (sooner or later). There may be a slight difference for advanced users, but only at the point where they visualize and confirm the exception, not when doing further connects to the same target and have the server cert cached/pinned. > > There may be differences in extensions which exist in the intermediate > certificates which might lead to slightly different behavior in how the > EE certificates are treated. The existing server-id-check does _not_ specify any matching on chain certs. As described above, changes that affect the outcome of the certificate path validation, the difference in behaviour of the existing code in "fails path validation", "passes path validation" is perfectly sufficient -- as long as the app client memorizes that the cached/pinned server cert originally passed certificate path validation and repeats certificate path validation on future connects. If the client app wants to _entirely_ skip certificate path validation on the pinned/cached server cert, then a changed cert path would not be detected when only the server cert is compared. But I have two observations about this: (a) a malicious server in posession of the original server cert and matching private key can easily send the original cert chain and pass your app clients test, so security-wise, the client does _NOT_ get any security benefit from caching and comparing the entire chain. By not performing a certificate path validation, the client misses cert revocations, and some folks might not like this. Pinning server certs protects you from attackers that manage to get a cert issued from any of the CAs operating under any of your (pre-)trusted roots. Performing certificate path validation even for "pinned" certs protects you from missing revocations. -Martin From ietf@augustcellars.com Thu Sep 30 18:40:49 2010 Return-Path: <ietf@augustcellars.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 4B7FD3A6A59 for <certid@core3.amsl.com>; Thu, 30 Sep 2010 18:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 PvwCCnHARtxT for <certid@core3.amsl.com>; Thu, 30 Sep 2010 18:40:46 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id 3BB2F3A6A76 for <certid@ietf.org>; Thu, 30 Sep 2010 18:40:46 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 9699A6A463; Thu, 30 Sep 2010 18:41:32 -0700 (PDT) From: "Jim Schaad" <ietf@augustcellars.com> To: <mrex@sap.com> References: <006b01cb605f$e2a7f9d0$a7f7ed70$@augustcellars.com> from "Jim Schaad" at Sep 29, 10 10:25:24 pm <201009302114.o8ULEqQd013861@fs4113.wdf.sap.corp> In-Reply-To: <201009302114.o8ULEqQd013861@fs4113.wdf.sap.corp> Date: Thu, 30 Sep 2010 18:49:16 -0700 Message-ID: <00a601cb610a$dc119c60$9434d520$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHpX5v4DItlrruLr6jcOadSCXOmpIyxvhQ Content-Language: en-us Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) 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: Fri, 01 Oct 2010 01:40:49 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Thursday, September 30, 2010 2:15 PM > To: Jim Schaad > Cc: matt@mattmccutchen.net; stpeter@stpeter.im; certid@ietf.org > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > Jim Schaad wrote: > > > > If there is only one possible certification path then there is no > > difference between caching just the EE certificate and caching the > > entire chain. However in the event that multiple certificate paths > > are possible there may be a difference in behavior. > > Nope, not for what is specified in server-id-check. > > At most, the client would have to memorize along with the server cert whether > regular certificate path validation worked for this cached cert. > Any changes to the path (above the server cert) will either make the cert path > validation fail or be security-irrelevant--entirely without caching and > comparing chain certs above the cached/pinned server cert. There is no need to remember that path validation has passed or failed - by definition it has passed or you would never even get here. The document does not "permit" the case of using a certificate if path validation has failed. > > When the caching/pinning of the server certs is done for untrusted server certs, > then the trust relationship is defined only based on the server cert and > certificate path validation can not be performed due to a lack of trust, so the > chain certs above the server cert are again irrelevant. This document makes absolutely no statements about ever doing anything positive with untrusted certificates. If the certificate is untrusted - i.e. fails path validation -- then all bets are off and the document does not apply in any way. After all if you don't trust the certificate why would you believe anything that the certificate says about the identity that is associated with the certificate. This is a complete non-issue for the document. > > > > > It is possible that you would trust a specific trust anchor (or > > intermediate CA) to be more specific about getting things correct > > (sooner or later). > > There may be a slight difference for advanced users, but only at the point > where they visualize and confirm the exception, not when doing further > connects to the same target and have the server cert cached/pinned. And the reason for having this is exactly because the advance user may be looking at the chain of certificates when doing the conformation of the exception. They may make a different decision if a different path is provided for making the decision. > > > > > > There may be differences in extensions which exist in the intermediate > > certificates which might lead to slightly different behavior in how > > the EE certificates are treated. > > The existing server-id-check does _not_ specify any matching on chain certs. > As described above, changes that affect the outcome of the certificate path > validation, the difference in behaviour of the existing code in "fails path > validation", "passes path validation" > is perfectly sufficient -- as long as the app client memorizes that the > cached/pinned server cert originally passed certificate path validation and > repeats certificate path validation on future connects. > > If the client app wants to _entirely_ skip certificate path validation on the > pinned/cached server cert, then a changed cert path would not be detected > when only the server cert is compared. But I have two observations about this: > (a) a malicious server in posession of the original server cert and matching > private key can easily send the original cert chain and pass your app clients > test, so security-wise, the client does _NOT_ get any security benefit from > caching and comparing the entire chain. By not performing a certificate path > validation, the client misses cert revocations, and some folks might not like this. This behavior is not covered in the document. The document assumes in all locations that a successful path validation has been completed on the certificate. > > Pinning server certs protects you from attackers that manage to get a cert > issued from any of the CAs operating under any of your (pre-)trusted roots. > Performing certificate path validation even for "pinned" certs protects you > from missing revocations. Remember this only discussing the case of being unable to complete the logic dealing with comparing the reference and the presented names. This is not dealing any cases where path validation either fails or is not performed. Thus the idea of pinning a certificate that passes (or does not pass validation) is not part of the concepts we are discussing here. > > > > -Martin