From paul.hoffman@vpnc.org Tue Apr 3 16:21:27 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315DE21F8471 for ; Tue, 3 Apr 2012 16:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ug4lWzJh84Vf for ; Tue, 3 Apr 2012 16:21:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6197921F846A for ; Tue, 3 Apr 2012 16:21:26 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q33NLPP8024192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Apr 2012 16:21:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 16:21:24 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [TLS] Definition of SSL proxies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 23:21:27 -0000 In his review of the TLSA protocol, Stephen Farrell asked: "Do we have a = reference for SSL proxies that's not just a product data sheet? Be nice = to add if it exists. (I doubt it'll be an RFC, but I'd bet there's a = paper to be found on the topic.)" I don't know of one; if someone here does, that would be grand. --Paul Hoffman From bhill@paypal-inc.com Tue Apr 3 16:47:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A671D11E80F5 for ; Tue, 3 Apr 2012 16:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yPEqulmDwm6 for ; Tue, 3 Apr 2012 16:47:52 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5E511E8086 for ; Tue, 3 Apr 2012 16:47:52 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=ueWshlOxg4k51n/wE0QHtlUU+RRIPvgMEgiBUFDGl/0kKt+SbZCtVjzG rhG1Nr/0PGY0fbrEj+s6zBdQZ8SG7rGFZiaL1KhOI7NeZIvVlYs90hUDB wHGKW/5DKwnuaxi; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=bhill@paypal-inc.com; q=dns/txt; s=ppinc; t=1333496872; x=1365032872; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2HrCJy21J5fUEePA+vAf7V+C62V2bD5gtb87Nq/xELs=; b=gYrqK8LMJtDBg7L349mXuwRalwp6Wc9eHrFANZrPABpOnPthJ6faA434 Yc6mxn5i5NcjRXl60V3Dih4DhvsKmOob7guUAMiR3HeNeU5JqbQiZDeGf ZJQCvWNU3xgnMUq; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.75,365,1330934400"; d="scan'208";a="6896889" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-005.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 03 Apr 2012 16:47:51 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-005.corp.ebay.com ([fe80::8109:2a37:17ad:e57e%18]) with mapi id 14.01.0339.001; Tue, 3 Apr 2012 17:47:47 -0600 From: "Hill, Brad" To: Paul Hoffman , "tls@ietf.org" Thread-Topic: [TLS] Definition of SSL proxies Thread-Index: AQHNEfCJjLhXUVqNpEWeCmFv2bbQ0JaJw/Bw Date: Tue, 3 Apr 2012 23:47:47 +0000 Message-ID: <370C9BEB4DD6154FA963E2F79ADC6F2E08C987@DEN-EXDDA-S12.corp.ebay.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.245.27.244] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: qpD0My2Q3M7NRzioBgmPsw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Subject: Re: [TLS] Definition of SSL proxies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 23:47:53 -0000 > Stephen Farrell asked: "Do we have a > reference for SSL proxies that's not just a product data sheet? Be nice t= o add > if it exists. (I doubt it'll be an RFC, but I'd bet there's a paper to be= found on > the topic.)" >=20 > I don't know of one; if someone here does, that would be grand. >=20 > --Paul Hoffman >=20 The below, by Jeff Jarmoc at Dell SecureWorks, is the best summary of the l= andscape I've seen: http://www.secureworks.com/research/threats/transitive-trust/ -Brad Hill From paul.hoffman@vpnc.org Wed Apr 4 07:46:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64C921F852C for ; Wed, 4 Apr 2012 07:46:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bR0+HS86EirZ for ; Wed, 4 Apr 2012 07:46:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F921F851A for ; Wed, 4 Apr 2012 07:46:26 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q34EkNSh049880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 4 Apr 2012 07:46:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Apr 2012 07:46:23 -0700 Message-Id: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:46:27 -0000 Greetings again. I am unclear how draft-ietf-tls-oob-pubkey deals with = SPKIs for client authentication. If the client wants to signal that it = is going to use SPKIs for both client and server authentication, does it = include the extension twice with a different value for = ClientOrServerExtension? Or something else? Examples in the doc might be helpful here. --Paul Hoffman= From paul@nohats.ca Thu Apr 5 08:30:47 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77421F86E8 for ; Thu, 5 Apr 2012 08:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpyZvjFdVtuj for ; Thu, 5 Apr 2012 08:30:47 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFBE21F86E5 for ; Thu, 5 Apr 2012 08:30:46 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 13DE28244E; Thu, 5 Apr 2012 11:30:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 0B3438244C; Thu, 5 Apr 2012 11:30:46 -0400 (EDT) Date: Thu, 5 Apr 2012 11:30:46 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> Message-ID: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:30:48 -0000 On Wed, 4 Apr 2012, Paul Hoffman wrote: > Greetings again. I am unclear how draft-ietf-tls-oob-pubkey deals with SPKIs for client authentication. If the client wants to signal that it is going to use SPKIs for both client and server authentication, does it include the extension twice with a different value for ClientOrServerExtension? Or something else? > > Examples in the doc might be helpful here. In an earlier draft, I addressed that with the client equivalent of SNI. That identifier could then be used by the TLS server for an out-of-band check on the client identity (eg via DNSSEC records or otherwise) But the working group thought that was better left out here and addressed seperately, as this draft moved from new TLS extensions to a new cert_type. I'm happy to write this up as a TLS extension draft, if the working group thinks that would be a way to discuss this further. Paul From paul.hoffman@vpnc.org Thu Apr 5 08:41:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72ED621F8598 for ; Thu, 5 Apr 2012 08:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elKtowblVZL7 for ; Thu, 5 Apr 2012 08:41:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D139821F8597 for ; Thu, 5 Apr 2012 08:41:38 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q35FfY0I094301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 08:41:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 5 Apr 2012 08:41:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 15:41:39 -0000 On Apr 5, 2012, at 8:30 AM, Paul Wouters wrote: > On Wed, 4 Apr 2012, Paul Hoffman wrote: >=20 >> Greetings again. I am unclear how draft-ietf-tls-oob-pubkey deals = with SPKIs for client authentication. If the client wants to signal that = it is going to use SPKIs for both client and server authentication, does = it include the extension twice with a different value for = ClientOrServerExtension? Or something else? >>=20 >> Examples in the doc might be helpful here. >=20 > In an earlier draft, I addressed that with the client equivalent of = SNI. > That identifier could then be used by the TLS server for an = out-of-band > check on the client identity (eg via DNSSEC records or otherwise) >=20 > But the working group thought that was better left out here and = addressed > seperately, as this draft moved from new TLS extensions to a new > cert_type. >=20 > I'm happy to write this up as a TLS extension draft, if the working > group thinks that would be a way to discuss this further. I think you misunderstand my question. If the client includes the = *current* cert_type extension from RFC 6091 with a type of RawPublicKey, = what does that mean exactly? RFC 6091 has section 3.5 that says that if = the client gives a cert, it must be the same type that was given in the = extension; your draft is silent on this. I think you need to say either = "cert_type is for the server cert only, which is different than RFC = 6091" or "cert_type applies to both server and client certs, just like = RFC 6091". --Paul Hoffman From turners@ieca.com Mon Apr 9 14:37:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED7921F87F3 for ; Mon, 9 Apr 2012 14:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdTyILQsAi8D for ; Mon, 9 Apr 2012 14:37:12 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.179.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACF921F8780 for ; Mon, 9 Apr 2012 14:37:12 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id A78F02B38C39D; Mon, 9 Apr 2012 16:37:11 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 9A1552B38C37D for ; Mon, 9 Apr 2012 16:37:11 -0500 (CDT) Received: from [71.191.0.197] (port=42017 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SHMGs-0002lA-NW; Mon, 09 Apr 2012 16:37:11 -0500 Message-ID: <4F835685.5060103@ieca.com> Date: Mon, 09 Apr 2012 17:37:09 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Yngve N. Pettersen (Developer Opera Software ASA)" References: <20120306124950.6304.36237.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-71-191-0-197.washdc.east.verizon.net (thunderfish.local) [71.191.0.197]:42017 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:37:13 -0000 Yngve, Here are some comments on the draft (hopefully this will encourage others to also read it): 1. The Abstract contains the following: This document introduces a replacement of the TLS Certificate Status Extension to allow clients to specify and support multiple certificate status methods. I know somebody will get to the word "replacement" and start asking whether this draft should update 6066. I don't think that's the intent you're just defining a new extension so it should just say that: This document defines the TLS Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. 2. Abstract: Expand OCSP and TLS. 3. Abstract: r/Also being introduced/Also defined 4. The RFC editor will move the "requirements language" paragraph to the main body so you might as well do it now. Move it to s1.1. 5. The copy right notice section contains the pre-5378 paragraph, but the draft first appeared after 5378 was published. Is there some bits in here that are copied from 5246 or somewhere else? If not, then you can delete that para. 6. s1: r/Transport Layer Security/Transport Layer Security (TLS) 7. s1: I don't think you need to try to slip in the comparison to other methods. I think it's implied. OLD: The benefits of this extension include a reduced number of roundtrips and network delays for the client to verify the status of the server's certificate using other retrieval methods and a reduced load on the certificate issuer's status response servers, thus solving a problem that can become significant when the issued certificate is presented by a frequently visited server. NEW: The benefits of this extension include a reduced number of roundtrips and network delays for the client to verify the status of the server's certificate and a reduced load on the certificate issuer's status response servers, thus solving a problem that can become significant when the issued certificate is presented by a frequently visited server. 8. s1: wordy ;) OLD: There are two problems with the existing Certificate Status extension as it is currently defined. NEW: There are two problems with the existing Certificate Status extension. 9. s1: Just some tweaking (two whichs read a little odd): OLD: First, it does not provide functionality to request the status information about intermediate CA certificates, which means the client has to request this through other retrieval methods, such as CRLs, which can cause significant delays when the revocation list has to be refreshed. NEW: First, it does not provide functionality to request the status information about intermediate Certification Authority (CA) certificates, which means the client has to request status information through other methods, such as CRLs, thus adding additional delay. 10. s1: r/Certificate Authorities/Certification Authorities X2 11. s1: r/Point[RFC5280]/Point [RFC5280] 12. s1: In the following I think the point is just for client-cached CRLS because most that responders I know about are fed by a CRL. OLD: Given that CRLs, particularly those cached by the client, are frequently less up to date than is possible for an OCSP responder, using OCSP to access up-to-date status information about intermediate CA certificates will be of great benefit to clients. NEW: Given that client-cached CRLs are frequently out of date, using OCSP to access up-to-date status information about intermediate CA certificates will be of great benefit to clients. 13. s1: I guess I'd tweak the following a bit: OLD: The author is aware that the cost of providing this bandwidth just for site certificates has been a concern to some CAs, particularly the smaller ones, and it follows naturally that doubling or tripling this cost could be problematic for the CAs. The author is also aware of at least one case when OCSP requests for a single high-traffic site caused significant network problems for the issuing CA. NEW: CAs should be aware that there is a cost associated with providing bandwidth to support OCSP. There are cases where OCSP requests for a single high-traffic site caused significant network problems for the issuing CA. 14. s1: r/multiple, OCSP mode/multiple-OCSP method 15. s2.1: r/The extension added by this/The extension defined by this 16.: s2.1: Just trying to avoid the questions about whether this draft updates 6066: r/which is updated with this value/which uses the following value 17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is the other status protocol. Should we just add it now? 18. s2.2: Need a normative reference for DER. Use the x680/x690 references from 5246. 19. s2.2: The nonce extension encoding is being fixed. I sure hope it'll get done sooner rather than later. Note that the bis draft does define the encoding as an OCTET STRING so it's aligned. 20. Hmmm should this draft reference draft-ietf-pkix-rfc2560bis instead of RFC 2560? 21. s2.2: r/[RFC2560]) ./[RFC2560]). 22. s2.2: r/that is,/That is, 23. s.2.2: Why the MUST NOT here: The list MAY contain fewer OCSP responses than there were certificates in the Certificate handshake message, but there MUST NOT be more responses than there were certificates in the list spt On 3/6/12 8:01 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > > FYI > > > > ------- Forwarded message ------- > From: internet-drafts@ietf.org > To: yngve@opera.com > Cc: > Subject: New Version Notification for > draft-pettersen-tls-ext-multiple-ocsp-03.txt > Date: Tue, 06 Mar 2012 13:49:50 +0100 > > A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-03.txt has > been successfully submitted by Yngve N. Pettersen and posted to the IETF > repository. > > Filename: draft-pettersen-tls-ext-multiple-ocsp > Revision: 03 > Title: Adding Multiple TLS Certificate Status Extension requests > Creation date: 2012-03-06 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > This document introduces a replacement of the TLS Certificate Status > Extension to allow clients to specify and support multiple > certificate status methods. Also being introduced is a new OCSP- > based method that servers can use to provide status information not > just about the server's own certificate, but also the status of > intermediate certificates in the chain. > > > > > > The IETF Secretariat > > From paul@nohats.ca Tue Apr 10 07:12:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD84921F85A7 for ; Tue, 10 Apr 2012 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bROHI9LEodVZ for ; Tue, 10 Apr 2012 07:12:23 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id C293C21F856A for ; Tue, 10 Apr 2012 07:12:22 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 47B7880116; Tue, 10 Apr 2012 10:12:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 3B11A8001C; Tue, 10 Apr 2012 10:12:17 -0400 (EDT) Date: Tue, 10 Apr 2012 10:12:17 -0400 (EDT) From: Paul Wouters To: Paul Hoffman , "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: Message-ID: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:12:24 -0000 On Thu, 5 Apr 2012, Paul Hoffman wrote: > I think you misunderstand my question. If the client includes the *current* cert_type extension from RFC 6091 with a type of RawPublicKey, what does that mean exactly? RFC 6091 has section 3.5 that says that if the client gives a cert, it must be the same type that was given in the extension; your draft is silent on this. I think you need to say either "cert_type is for the server cert only, which is different than RFC 6091" or "cert_type applies to both server and client certs, just like RFC 6091". When the TLS client contacts the server, it has some idea of who it is contacting for the out of band authentication of the received raw public key. The server has no such idea when it is contact out of the wild, and if it just receives a SPKI without any identifier, then it cannot really know what to do. This is why I suggested the TLS extension equivalent for SNI for the client. So to answer your question, I don't think the current method specified facilitates a server to identify a client by a cert of type SPKI, so it makes no sense currently for the client to send such a cert_type. The client will either have to send a full cert or reject the connection, until we have a proper TLS extension to convey our identity to the server so it can do an out-of-band check on a client cert of type SPKI. Ideally, I would like to avoid this draft from dictating anything, so a possible new draft for such a "client SNI" type TLS extension would not have to update this document. But as there is no way currently for the TLS client to convey its own cert_type is different than then cert_type it requested of the server, I guess we should stick with using the same cert_type symantics as in 6091. That would mean that without a new TLS extension, that TLS servers sending a certificate_request in response to receiveing a cert_type="RawPublicKey" is likely to end in a failed TLS connection, because the server cannot authenticate the client based on the received certificate of type RawPublicKey. If people agree with this approach, I will add such clarifying text to the draft. Paul From paul.hoffman@vpnc.org Tue Apr 10 07:45:43 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3625C11E80CB for ; Tue, 10 Apr 2012 07:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THwpvFnVpVNi for ; Tue, 10 Apr 2012 07:45:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A26211E80B8 for ; Tue, 10 Apr 2012 07:45:42 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AEjfvE083222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 07:45:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 07:45:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 14:45:43 -0000 On Apr 10, 2012, at 7:12 AM, Paul Wouters wrote: > On Thu, 5 Apr 2012, Paul Hoffman wrote: >=20 >> I think you misunderstand my question. If the client includes the = *current* cert_type extension from RFC 6091 with a type of RawPublicKey, = what does that mean exactly? RFC 6091 has section 3.5 that says that if = the client gives a cert, it must be the same type that was given in the = extension; your draft is silent on this. I think you need to say either = "cert_type is for the server cert only, which is different than RFC = 6091" or "cert_type applies to both server and client certs, just like = RFC 6091". >=20 > When the TLS client contacts the server, it has some idea of who it is > contacting for the out of band authentication of the received raw = public > key. The server has no such idea when it is contact out of the wild, = and > if it just receives a SPKI without any identifier, then it cannot = really > know what to do. Sure it can. The same way that the client would have an internal list of = DNS-to-SPKI associations, the server could have an internal list of = ID-to-SPKI associations. > This is why I suggested the TLS extension equivalent for SNI for the > client. Where is this suggested? > So to answer your question, I don't think the current method specified > facilitates a server to identify a client by a cert of type SPKI, so = it > makes no sense currently for the client to send such a cert_type. The > client will either have to send a full cert or reject the connection, > until we have a proper TLS extension to convey our identity to the = server > so it can do an out-of-band check on a client cert of type SPKI. If that is what you believe, it needs to be stated explicitly in the = draft. I'll disagree with it, and let the WG choose. > Ideally, I would like to avoid this draft from dictating anything, so = a > possible new draft for such a "client SNI" type TLS extension would = not > have to update this document. True, but the current draft needs to say how it implements the RFC 6091 = semantics. Leaving it silent will lead to misunderstanding. > But as there is no way currently for the TLS client to convey its own > cert_type is different than then cert_type it requested of the server, = I > guess we should stick with using the same cert_type symantics as in = 6091. Why, yes, you should. :-) > That would mean that without a new TLS extension, that TLS servers = sending > a certificate_request in response to receiveing a = cert_type=3D"RawPublicKey" > is likely to end in a failed TLS connection, because the server cannot > authenticate the client based on the received certificate of type = RawPublicKey. As above, I don't see why that is the case. A server can get client = names and SPKIs out of band just as a client can. > If people agree with this approach, I will add such clarifying text to > the draft. Please add clarifying text regardless, and then we can discuss if we = agree with it. --Paul Hoffman From paul@nohats.ca Tue Apr 10 09:09:30 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE3011E80E8 for ; Tue, 10 Apr 2012 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjwAw-eyny5x for ; Tue, 10 Apr 2012 09:09:30 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3A511E80BE for ; Tue, 10 Apr 2012 09:09:30 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 8C6BE80116; Tue, 10 Apr 2012 12:09:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 81D4C8001C; Tue, 10 Apr 2012 12:09:29 -0400 (EDT) Date: Tue, 10 Apr 2012 12:09:29 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:09:30 -0000 On Tue, 10 Apr 2012, Paul Hoffman wrote: >> When the TLS client contacts the server, it has some idea of who it is >> contacting for the out of band authentication of the received raw public >> key. The server has no such idea when it is contact out of the wild, and >> if it just receives a SPKI without any identifier, then it cannot really >> know what to do. > > Sure it can. The same way that the client would have an internal list of DNS-to-SPKI associations, the server could have an internal list of ID-to-SPKI associations. True. It wouldn't be the best system, but you are right. >> This is why I suggested the TLS extension equivalent for SNI for the >> client. > > Where is this suggested? Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already removed there after discussion with EKR in Quebec City. > True, but the current draft needs to say how it implements the RFC 6091 semantics. Leaving it silent will lead to misunderstanding. > >> But as there is no way currently for the TLS client to convey its own >> cert_type is different than then cert_type it requested of the server, I >> guess we should stick with using the same cert_type symantics as in 6091. > > Why, yes, you should. :-) > >> That would mean that without a new TLS extension, that TLS servers sending >> a certificate_request in response to receiveing a cert_type="RawPublicKey" >> is likely to end in a failed TLS connection, because the server cannot >> authenticate the client based on the received certificate of type RawPublicKey. > > As above, I don't see why that is the case. A server can get client names and SPKIs out of band just as a client can. Yes, it can, but not "as a client can", because the client knows which identity it is going to contact, while the server does not know which identity it is contacted by. > Please add clarifying text regardless, and then we can discuss if we agree with it. Will do. Paul From paul.hoffman@vpnc.org Tue Apr 10 09:25:23 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061D111E8123 for ; Tue, 10 Apr 2012 09:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CC0j2o2VTO9n for ; Tue, 10 Apr 2012 09:25:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 69A9011E8125 for ; Tue, 10 Apr 2012 09:25:21 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3AGPJlX087019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 10 Apr 2012 09:25:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 10 Apr 2012 09:25:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> To: Paul Wouters X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:25:24 -0000 On Apr 10, 2012, at 9:09 AM, Paul Wouters wrote: > On Tue, 10 Apr 2012, Paul Hoffman wrote: >=20 >>> When the TLS client contacts the server, it has some idea of who it = is >>> contacting for the out of band authentication of the received raw = public >>> key. The server has no such idea when it is contact out of the wild, = and >>> if it just receives a SPKI without any identifier, then it cannot = really >>> know what to do. >>=20 >> Sure it can. The same way that the client would have an internal list = of DNS-to-SPKI associations, the server could have an internal list of = ID-to-SPKI associations. >=20 > True. It wouldn't be the best system, but you are right. Many people contend that clients having OOB key associations for servers = is not "the best system" either. I contend they are equivalent. > Yes, it can, but not "as a client can", because the client knows which > identity it is going to contact, while the server does not know which > identity it is contacted by. Errr, this is true for all client authentication; there is no difference = here. --Paul Hoffman From dkg@fifthhorseman.net Tue Apr 10 09:28:16 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8FC11E8128 for ; Tue, 10 Apr 2012 09:28:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO6WYiMzNzAR for ; Tue, 10 Apr 2012 09:28:16 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1332D11E8121 for ; Tue, 10 Apr 2012 09:28:16 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 376F8F979; Tue, 10 Apr 2012 12:28:11 -0400 (EDT) Message-ID: <4F845F96.6070000@fifthhorseman.net> Date: Tue, 10 Apr 2012 12:28:06 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Paul Wouters References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig1C8447DC1023C3AB8F4DA112" Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 16:28:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1C8447DC1023C3AB8F4DA112 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/10/2012 12:09 PM, Paul Wouters wrote: > Yes, it can, but not "as a client can", because the client knows which > identity it is going to contact, while the server does not know which > identity it is contacted by. If a server maintains (for example) a local keyring with identities bound to keys, with a reasonable index on the keys, it should be able to derive the identity from the raw public key directly. is there some scenario where this scheme falls apart? --dkg --------------enig1C8447DC1023C3AB8F4DA112 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJPhF+WXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpr+0P/39MQ/BeMOVDQmxWSHNQgDug g+byt4vsVsoID5NA5uKqDCPHPhBrwVwfzTEYqYSlyUguL5YfpsHMulsfnEX1noJq 2wgIv8YlLhmld1e8Ad+WwarVPH0O2BFO4kvB/VKN/T3AJtleZNUSl2BvHhIz3gzN cr0zijhkeq4PY+EcOw75OUyhbh0CbELZTM/YXhQCMYrjBogB1nOvsv99YYAhaVhB m76F9Z/aCU5P1anu8DMYI1aFEPv+yRKd5OBibZpJp1S+tNHRjQ868puBxX2oeRru zG/2nsOQNmKvU4W9ipa4sDpY2g+ge5K4cPawpQ2DAKVUZa0mu2YIXwFqFOzwcvQI qxZV6RN5E8tjAWdqTE94GOn1T6FJvTBDs5E5C4TtBhd4XuCbh3XUXcPw569h4uzt U193K6YzkQjzKLo5DOJ6tHw7xS3YqzZdUC4bM5Vn4iM4waKnJHv7jawy3tfc18PY YNWSJ+/d0PbmQWUWNq8QVT2PKYrutEv0wfcrS+v+UyDxxDE7dFyM+PL4+Mp8Yc+b DjJoTMK07FWez+03aOLIh42HOvJt/n9DzPkvG+COuUtsIcBwIGmXQ4heCUg9iPEP vg6VEdQQcK0qh06ZKG1m5bhvY/DqW4Q+SQAziZsfw21n/4H+of3ny7DLk/rX/pIH dK24bEukqOa2SmCPrVl0 =3/P4 -----END PGP SIGNATURE----- --------------enig1C8447DC1023C3AB8F4DA112-- From paul@nohats.ca Tue Apr 10 11:07:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA2B11E810A for ; Tue, 10 Apr 2012 11:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xu7NyUjB+Fyc for ; Tue, 10 Apr 2012 11:07:13 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 35E7411E8117 for ; Tue, 10 Apr 2012 11:07:11 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 3B54080116; Tue, 10 Apr 2012 14:07:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 2D53C8001C; Tue, 10 Apr 2012 14:07:11 -0400 (EDT) Date: Tue, 10 Apr 2012 14:07:11 -0400 (EDT) From: Paul Wouters To: Daniel Kahn Gillmor In-Reply-To: <4F845F96.6070000@fifthhorseman.net> Message-ID: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> <4F845F96.6070000@fifthhorseman.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:07:13 -0000 On Tue, 10 Apr 2012, Daniel Kahn Gillmor wrote: > If a server maintains (for example) a local keyring with identities > bound to keys, with a reasonable index on the keys, it should be able to > derive the identity from the raw public key directly. > > is there some scenario where this scheme falls apart? Yes, Opportunistic Encryption. This is where the server accepts crypto from any client that can authenticate, but for that it needs to have some handle on the identity to perform work, such as a FQDN it can look up in DNS(SEC) to get the public key authenticated Paul From paul@nohats.ca Tue Apr 10 11:10:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7216811E8117 for ; Tue, 10 Apr 2012 11:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tsEUDfDSy4i for ; Tue, 10 Apr 2012 11:10:41 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1B11E810A for ; Tue, 10 Apr 2012 11:10:40 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 990BB8011F; Tue, 10 Apr 2012 14:10:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 8C91C8001C; Tue, 10 Apr 2012 14:10:40 -0400 (EDT) Date: Tue, 10 Apr 2012 14:10:40 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:10:41 -0000 On Tue, 10 Apr 2012, Paul Hoffman wrote: >> True. It wouldn't be the best system, but you are right. > > Many people contend that clients having OOB key associations for servers is not "the best system" either. I contend they are equivalent. As I said in another post, it prevents opportunistic encryptio. >> Yes, it can, but not "as a client can", because the client knows which >> identity it is going to contact, while the server does not know which >> identity it is contacted by. > > Errr, this is true for all client authentication; there is no difference here. But in other cases, the client can convey a handle leading to authentication that can suggest a method of out of band lookup. A raw public key tells the server nothing. Can it ask DNS? If so where? Can it ask a CA? If so which? A client name identification mechanism conveys not only a (to be authenticated) name, but can also embed a suggestion for the out of band method for the server to use. Again, compare it to IPsec OE where the FQDN is used to lookup the public IPSECKEY in DNS. Paul From dkg@fifthhorseman.net Tue Apr 10 11:23:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDFB511E810C for ; Tue, 10 Apr 2012 11:23:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l28NmhF7uqwI for ; Tue, 10 Apr 2012 11:23:54 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5380F11E80FD for ; Tue, 10 Apr 2012 11:23:54 -0700 (PDT) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 5470DF979; Tue, 10 Apr 2012 14:23:51 -0400 (EDT) Message-ID: <4F847AB2.800@fifthhorseman.net> Date: Tue, 10 Apr 2012 14:23:46 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Paul Wouters References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> <4F845F96.6070000@fifthhorseman.net> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigF0E494E89F867714E20B8AEF" Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 18:23:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0E494E89F867714E20B8AEF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 04/10/2012 02:07 PM, Paul Wouters wrote: > On Tue, 10 Apr 2012, Daniel Kahn Gillmor wrote: >=20 >> If a server maintains (for example) a local keyring with identities >> bound to keys, with a reasonable index on the keys, it should be able = to >> derive the identity from the raw public key directly. >> >> is there some scenario where this scheme falls apart? >=20 > Yes, Opportunistic Encryption. This is where the server accepts crypto > from any client that can authenticate, but for that it needs to have so= me > handle on the identity to perform work, such as a FQDN it can look up > in DNS(SEC) to get the public key authenticated In the opportunistic encryption case, the server must be willing to accept any key as a client identifier, right? In that case, the application running within the TLS session could add the new key to the data store and associate it with some internal account identifier. No DNS lookup needed, and you end up with the server-side equivalent of TOFU (trust-on-first-use). As you say, it might not be ideal, but it's not unreasonable. --dkg --------------enigF0E494E89F867714E20B8AEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJPhHqyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznprrIP/jlXIl1yrVW/HT7mYJe3KHxT 7x7wVvrfa+Lh5apLVFlYZW0TE3jKXSXTGB45aWdp9gAZpEjLOmdQMEs5JsEh3LfT cxyNhsO7bUib1klHmRcRfD1ZkHPMtJ9zi/rdkFFUM9sAMnGC4f8Rsxz4At5AAKL2 DK5t7lQO8TUlBR+yP8bXY1Msj+95J8+fEc2cIKSEq9FOiJ3q+rYZ6+BpzpETg5vq bKuj3DVEgo9+cljAsskQO3Wz0dfj/QwKgl15q9/G8gUywjLS1ZHZodx6b706I1/X Z16xr7O/eKnLBQUxU9NKsOQ3lhHrcVf5X5sRY5KDRAlOcfemFqok1dbfGljiJT0Y iz9+Wb4fs7UJT0KCPOz4GRhVXmhDbpxTCal6sK7eBTkwoU9zk3wM1Q0dN7ILKPJE 9Jq3BJyip7NqP+17SacORQ+vb60nE9LZrxaP0etZqOcEo7i1rpLFJ5jFSZ2gNqSO esR5MLgAALlNDNc6Y3rbd4hrPyJ8kHmAQpQ+6vEWCjY7gqkfBpNxDRev6XHyNgIZ Oy0kcILZLRN4J2vg0Fu7ACc770T6Rp9WWksrXJ/FiWig4LmXbCEC585pXNwZ/lVG cRwKGJid9hP612G08eYbIXk+Lp+BIOy/b2BFL7VFUwGR0BVfkH/+Rg6ZmkCViI21 nCTkqjSRGyOjLk/y+A3g =yUop -----END PGP SIGNATURE----- --------------enigF0E494E89F867714E20B8AEF-- From frantz@pwpconsult.com Tue Apr 10 14:08:07 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A7A21F868A for ; Tue, 10 Apr 2012 14:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYZxYwd+v+Z8 for ; Tue, 10 Apr 2012 14:08:06 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7809921F8687 for ; Tue, 10 Apr 2012 14:08:05 -0700 (PDT) Received: from [96.238.217.41] (helo=Bill-Frantzs-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1SHiIG-0006K2-HV; Tue, 10 Apr 2012 17:08:04 -0400 Date: Tue, 10 Apr 2012 14:07:59 -0700 From: Bill Frantz To: Paul Wouters X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79055248b8d055011659d2e96c1052792a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 96.238.217.41 Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:08:07 -0000 On 4/10/12 at 7:12, paul@nohats.ca (Paul Wouters) wrote: >So to answer your question, I don't think the current method specified >facilitates a server to identify a client by a cert of type SPKI, so it >makes no sense currently for the client to send such a cert_type. The >client will either have to send a full cert or reject the connection, >until we have a proper TLS extension to convey our identity to the server >so it can do an out-of-band check on a client cert of type SPKI. SPKI certs are designed to allow authorization without=20 identification, like car keys and house keys. If the server is=20 using them in this way, there is no need to identify the client,=20 since possession of the private key associated with the cert is=20 enough to show authorization. What the server should really be interested in is whether the=20 requested action is authorized[1]. If it only has client=20 identification, then it must go through a separate authorization=20 step. Using identification instead of authorization is the path=20 which allows confused deputies[2]. Cheers - Bill [1] For example, see From ABAC to ZBAC: The Evolution of Access=20 Control Models By Alan H. Karp, Harry Haury, and Michael H.=20 Davis =E2=80=93 ISSA member, San Diego, USA Chapter in . [2] N. Hardy, =E2=80=9CThe Confused Deputy: (or why capabilities might=20 have been invented),=E2=80=9D ACM SIGOPS Operating Systems Review,=20 vol. 22, #4 (1988). --------------------------------------------------------------------------- Bill Frantz |"Web security is like medicine - trying to=20 do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | From ekr@rtfm.com Tue Apr 10 14:17:27 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF1F21F8599 for ; Tue, 10 Apr 2012 14:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxfgPQQcX7eP for ; Tue, 10 Apr 2012 14:17:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4521F8598 for ; Tue, 10 Apr 2012 14:17:26 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so207323vcb.31 for ; Tue, 10 Apr 2012 14:17:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=RppnMjQqRE+dlv5+39ufnHCEne0FtuNTGjFh38CwZJU=; b=A7gttQCOTbpfmmqz0kco7+WBYQiFP4dix34s1+Mc+XXBiuWbXb35oLTXlQdLLpnKUG 9Qf1F7/9YR3lhn0W1CLCOyOaJ0h0nk5g/jDJF+9+knnyN31++lpDGFFjpjdBrdjEylwo Q5SbM1LfkPUg4IglHLpXm9bmLU2FZ8TqObLzmHggreweUpf7al0HG6vO7Jbp3OXFXFOp qQ2lVUWxsL6JuE+LG79WDllW4QC9lU/z579uM5gaojU104aSqrPatgVozIV61w9cmhkU BRMCUZmRRhrllLcIlgG50K++DOeIDLyh5IBwATm6bG2fuydsMTwJts7nKgLf0NulxU+m PTOw== Received: by 10.220.57.205 with SMTP id d13mr6498486vch.53.1334092645676; Tue, 10 Apr 2012 14:17:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 10 Apr 2012 14:16:45 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Tue, 10 Apr 2012 14:16:45 -0700 Message-ID: To: Bill Frantz Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmEsDt+kWwqmBZGGYgx/de2cO7UCrzCP5AZoMScHb1iIi2OUR4CnYaMf6vz8ZpcTJY46XPM Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:17:27 -0000 On Tue, Apr 10, 2012 at 2:07 PM, Bill Frantz wrote: > On 4/10/12 at 7:12, paul@nohats.ca (Paul Wouters) wrote: > >> So to answer your question, I don't think the current method specified >> facilitates a server to identify a client by a cert of type SPKI, so it >> makes no sense currently for the client to send such a cert_type. The >> client will either have to send a full cert or reject the connection, >> until we have a proper TLS extension to convey our identity to the serve= r >> so it can do an out-of-band check on a client cert of type SPKI. > > > SPKI certs are designed to allow authorization without identification, li= ke > car keys and house keys. If the server is using them in this way, there i= s > no need to identify the client, since possession of the private key > associated with the cert is enough to show authorization. > > What the server should really be interested in is whether the requested > action is authorized[1]. If it only has client identification, then it mu= st > go through a separate authorization step. Using identification instead of > authorization is the path which allows confused deputies[2]. In this case SPKI means "subject public key info", rather than RFC2693. -Ekr > Cheers - Bill > > [1] For example, see From ABAC to ZBAC: The Evolution of Access Control > Models By Alan H. Karp, Harry Haury, and Michael H. Davis =96 ISSA member= , San > Diego, USA Chapter in > . > > [2] N. Hardy, =93The Confused Deputy: (or why capabilities might have bee= n > invented),=94 ACM SIGOPS Operating Systems Review, vol. 22, #4 (1988). > > -------------------------------------------------------------------------= -- > Bill Frantz =A0 =A0 =A0 =A0|"Web security is like medicine - trying to do= good for > 408-356-8506 =A0 =A0 =A0 |an evolved body of kludges" - Mark Miller > www.pwpconsult.com | > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Tue Apr 10 14:53:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8F611E80B5 for ; Tue, 10 Apr 2012 14:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xw7L3LBmFpN for ; Tue, 10 Apr 2012 14:53:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2B11E8087 for ; Tue, 10 Apr 2012 14:53:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3ALrYAq009511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 Apr 2012 23:53:34 +0200 (MEST) From: Martin Rex Message-Id: <201204102153.q3ALrXKo004423@fs4113.wdf.sap.corp> To: dkg@fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 10 Apr 2012 23:53:33 +0200 (MEST) In-Reply-To: <4F845F96.6070000@fifthhorseman.net> from "Daniel Kahn Gillmor" at Apr 10, 12 12:28:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, tls@ietf.org Subject: Re: [TLS] Client certificate authentication and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 21:53:38 -0000 Daniel Kahn Gillmor wrote: > > Paul Wouters wrote: > > > > Yes, it can, but not "as a client can", because the client knows which > > identity it is going to contact, while the server does not know which > > identity it is contacted by. > > If a server maintains (for example) a local keyring with identities > bound to keys, with a reasonable index on the keys, it should be able to > derive the identity from the raw public key directly. > > is there some scenario where this scheme falls apart? Nope -- this is actually a pretty reasonable and common usage. If you've ever used SSH with public key authentication, it is based _purely_ on the public key. The "name" that appears behind the key in your authorized_keys file is just to facilitate for human beings to tell the keys apart, SSHD itself does *not* care about the name behind the key! (you can change the name in authorized_keys to differ from what the ssh client has in his id_rsa.pub file and authentication will continue to succeed -- as long as the public key matches. -Martin From yngve@opera.com Wed Apr 11 07:20:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B021F858B for ; Wed, 11 Apr 2012 07:20:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7PYylljftLn for ; Wed, 11 Apr 2012 07:20:21 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEA221F8582 for ; Wed, 11 Apr 2012 07:20:21 -0700 (PDT) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3BEKE0k005870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 14:20:16 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Sean Turner" References: <20120306124950.6304.36237.idtracker@ietfa.amsl.com> <4F835685.5060103@ieca.com> Date: Wed, 11 Apr 2012 16:20:14 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <4F835685.5060103@ieca.com> User-Agent: Opera Mail/10.63 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:20:26 -0000 Hello Sean, Thanks for these comments. Adopted most. Comments inline on the rest On Mon, 09 Apr 2012 23:37:09 +0200, Sean Turner wrote: > > > Yngve, > > Here are some comments on the draft (hopefully this will encourage > others to also read it): > 4. The RFC editor will move the "requirements language" paragraph to the > main body so you might as well do it now. Move it to s1.1. The placement of that section is the default used by the xml2rfc template implemented by the XMLmind extension, as part of the "front matter" section of the file. This means that the initial location is determined by the template, and is that way for everyone using that template. non-WG: It might be that the xml2rfc extension developers and the RFC Editor should coordinate? Since the "empty" template already adds several sections, such as the Introduction and IANA sections, moving the note into the introduction section of the template might solve the issue. At present I'll leave it where it is. > 5. The copy right notice section contains the pre-5378 paragraph, but > the draft first appeared after 5378 was published. Is there some bits > in here that are copied from 5246 or somewhere else? If not, then you > can delete that para. The text is based on the relevant RFC 6066 text (taken from the draft), but that RFC is again based on RFC 4366, with only a few differences in that section. RFC 6066 also contain the same pre-5378 licensing language, so I therefore think it is necessary to include it, unless I am told otherwise by those better versed in the licensing rules. > 13. s1: I guess I'd tweak the following a bit: > > OLD: > > The author is aware that the cost of providing this bandwidth > just for site certificates has been a concern to some CAs, > particularly the smaller ones, and it follows naturally that doubling > or tripling this cost could be problematic for the CAs. The author > is also aware of at least one case when OCSP requests for a single > high-traffic site caused significant network problems for the issuing > CA. > > NEW: > > CAs should be aware that there is a cost associated with providing > bandwidth to support OCSP. There are cases where OCSP requests for a > single > high-traffic site caused significant network problems for the issuing > CA. My intention here was to make it clear who the source is. In talks with CAs the bandwidth cost have been a concern for several CAs, particularly the smaller ones. I forgot to mention this during my presentation to the WG, but recent numbers from CAs indicate that about 30% of the OCSP traffic is for intermediate CA cert status requests. There are currently two clients AFAIK, FF and Chrome, that request OCSP for intermediates. Those two make up about 40% of the browser market, so there is at least some caching benefit. I changed the text from The benefit to the issuing CA is less clear, as providing the bandwidth for the OCSP responder can be costly, especially for CAs with many subscriber sites. The author is aware that the cost of providing this bandwidth just for site certificates has been a concern to some CAs, particularly the smaller ones, and it follows naturally that doubling or tripling this cost could be problematic for the CAs. The author is also aware of at least one case when OCSP requests for a single high-traffic site caused significant network problems for the issuing CA. to The benefit to the issuing CA is less clear, as providing the bandwidth for the OCSP responder can be costly, especially for CAs with many high traffic subscriber sites, and this cost is a concern for many CAs. There are cases where OCSP requests for a single high-traffic site caused significant network problems for the issuing CA. How does that look? > 17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is the > other status protocol. Should we just add it now? Could be; I am, however, unfamiliar with SCVP, but if the WG wants it added, and I am provided additional text as a starting point, then I can include it. Adding SCVP will probably require some editorial reorganization of section 2, splitting it into an overall format, an OCSP, and a SVCP subsection. > 18. s2.2: Need a normative reference for DER. Use the x680/x690 > references from 5246. Added. The "misc" citation entry had rather long names, though: CCITT.X680.2002 > 19. s2.2: The nonce extension encoding is being fixed. I sure hope > it'll get done sooner rather than later. Note that the bis draft does > define the encoding as an OCTET STRING so it's aligned. Given performance issues, as a nonce require signing of each response, most responders do not AFAIK enable support for nonces, and while Opera supported it at one time, we have since removed it. In relation to stapling using nonces would almost certainly remove most of the performance benefit. > 20. Hmmm should this draft reference draft-ietf-pkix-rfc2560bis instead > of RFC 2560? Depends on which get finished first. At present I think we should keep them separate, just to be on the safe side. If 2560bis is completed first we can update the reference then. > 21. s2.2: r/[RFC2560]) ./[RFC2560]). > > 22. s2.2: r/that is,/That is, > > 23. s.2.2: Why the MUST NOT here: > > The list MAY > contain fewer OCSP responses than there were certificates in the > Certificate handshake message, but there MUST NOT be more responses > than there were certificates in the list Strictly speaking it does not need to be MUST NOT, but I suspect that in such a case there would be something wrong about the server configuration. AT the very least, the document should define handling of such a case It could be changed to a requirement that the response must only be used to check the corresponding certificate list element, and ignore responses that does not have a corresponding certificate in the list. Requiring the sequence of the lists to match means that if certificate lists that are non-compliant, containing extra or unordered certificates, the client does not have to try to match responses to certificates (an n^2 operation). Thoughts? > spt > > > > On 3/6/12 8:01 AM, Yngve N. Pettersen (Developer Opera Software ASA) > wrote: >> >> FYI >> >> >> >> ------- Forwarded message ------- >> From: internet-drafts@ietf.org >> To: yngve@opera.com >> Cc: >> Subject: New Version Notification for >> draft-pettersen-tls-ext-multiple-ocsp-03.txt >> Date: Tue, 06 Mar 2012 13:49:50 +0100 >> >> A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-03.txt has >> been successfully submitted by Yngve N. Pettersen and posted to the IETF >> repository. >> >> Filename: draft-pettersen-tls-ext-multiple-ocsp >> Revision: 03 >> Title: Adding Multiple TLS Certificate Status Extension requests >> Creation date: 2012-03-06 >> WG ID: Individual Submission >> Number of pages: 9 >> >> Abstract: >> This document introduces a replacement of the TLS Certificate Status >> Extension to allow clients to specify and support multiple >> certificate status methods. Also being introduced is a new OCSP- >> based method that servers can use to provide status information not >> just about the server's own certificate, but also the status of >> intermediate certificates in the chain. >> >> >> >> >> >> The IETF Secretariat >> >> -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From rob.stradling@comodo.com Wed Apr 11 07:41:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32BE11E80C1 for ; Wed, 11 Apr 2012 07:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StRtmz7daabC for ; Wed, 11 Apr 2012 07:41:10 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id A736D11E8080 for ; Wed, 11 Apr 2012 07:41:08 -0700 (PDT) Received: (qmail 17173 invoked from network); 11 Apr 2012 14:41:07 -0000 Received: from ian1.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 11 Apr 2012 14:41:07 -0000 Received: (qmail 2394 invoked by uid 1000); 11 Apr 2012 14:41:07 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Wed, 11 Apr 2012 15:41:07 +0100 Message-ID: <4F859802.6080001@comodo.com> Date: Wed, 11 Apr 2012 15:41:06 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: "Yngve N. Pettersen (Developer Opera Software ASA)" References: <20120306124950.6304.36237.idtracker@ietfa.amsl.com> <4F835685.5060103@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 14:41:10 -0000 On 11/04/12 15:20, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > >> 17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is >> the other status protocol. Should we just add it now? > > Could be; I am, however, unfamiliar with SCVP, but if the WG wants it > added, and I am provided additional text as a starting point, then I can > include it. Adding SCVP will probably require some editorial > reorganization of section 2, splitting it into an overall format, an > OCSP, and a SVCP subsection. Hi Yngve. Would an implementer be permitted to implement the OCSP option but not the SCVP option (or vice versa)? My suggestion: Implementations MUST support the OCSP option, and MAY also support the SCVP option. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From yngve@opera.com Wed Apr 11 08:40:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D7811E807F for ; Wed, 11 Apr 2012 08:40:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldp0oJiNOa6l for ; Wed, 11 Apr 2012 08:40:25 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id DF79B11E8074 for ; Wed, 11 Apr 2012 08:40:24 -0700 (PDT) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3BFeFwN002335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 15:40:16 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Rob Stradling" References: <20120306124950.6304.36237.idtracker@ietfa.amsl.com> <4F835685.5060103@ieca.com> <4F859802.6080001@comodo.com> Date: Wed, 11 Apr 2012 17:40:16 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <4F859802.6080001@comodo.com> User-Agent: Opera Mail/10.63 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 15:40:26 -0000 On Wed, 11 Apr 2012 16:41:06 +0200, Rob Stradling wrote: > On 11/04/12 15:20, Yngve N. Pettersen (Developer Opera Software ASA) > wrote: > >> >>> 17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is >>> the other status protocol. Should we just add it now? >> >> Could be; I am, however, unfamiliar with SCVP, but if the WG wants it >> added, and I am provided additional text as a starting point, then I can >> include it. Adding SCVP will probably require some editorial >> reorganization of section 2, splitting it into an overall format, an >> OCSP, and a SVCP subsection. > > Hi Yngve. Would an implementer be permitted to implement the OCSP > option but not the SCVP option (or vice versa)? In the spec? It should be optional to implement it, so it should be prented as an additional method that may be sent. AFAICT, OpenSSL 1.0.0 does not currently have any support for SCVP. Adding the possibility would, however, improve testing of the extensibility of the extension. > My suggestion: Implementations MUST support the OCSP option, and MAY > also support the SCVP option. Agree. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From ietf@augustcellars.com Wed Apr 11 09:40:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95C511E809A for ; Wed, 11 Apr 2012 09:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srGD36-EnTPX for ; Wed, 11 Apr 2012 09:40:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FD11E8089 for ; Wed, 11 Apr 2012 09:39:59 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 9A4952CA29; Wed, 11 Apr 2012 09:39:59 -0700 (PDT) From: "Jim Schaad" To: "'Paul Wouters'" , "'Paul Hoffman'" References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> In-Reply-To: Date: Wed, 11 Apr 2012 09:38:52 -0700 Message-ID: <01c901cd1801$9cff3fa0$d6fdbee0$@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: AQHXpApgMNflIeoSkabsN3tGQQOqzgJZH9MoAnuMA6sB8B9K2QFNXwaNAthtsHaWKWX5oA== Content-Language: en-us Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 16:40:00 -0000 > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul > Wouters > Sent: Tuesday, April 10, 2012 9:09 AM > To: Paul Hoffman > Cc: tls@ietf.org > Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob- > pubkey > > On Tue, 10 Apr 2012, Paul Hoffman wrote: > > >> When the TLS client contacts the server, it has some idea of who it > >> is contacting for the out of band authentication of the received raw > >> public key. The server has no such idea when it is contact out of the > >> wild, and if it just receives a SPKI without any identifier, then it > >> cannot really know what to do. > > > > Sure it can. The same way that the client would have an internal list of DNS- > to-SPKI associations, the server could have an internal list of ID-to-SPKI > associations. > > True. It wouldn't be the best system, but you are right. > > >> This is why I suggested the TLS extension equivalent for SNI for the > >> client. > > > > Where is this suggested? > > Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already > removed there after discussion with EKR in Quebec City. > If this is really what you want to do, then I would suggest that the document be expanded so that there exists the possibility to include an identifier and/or a public key in the certificate form defined by the oob document. Jim > > > True, but the current draft needs to say how it implements the RFC 6091 > semantics. Leaving it silent will lead to misunderstanding. > > > >> But as there is no way currently for the TLS client to convey its own > >> cert_type is different than then cert_type it requested of the > >> server, I guess we should stick with using the same cert_type symantics as > in 6091. > > > > Why, yes, you should. :-) > > > >> That would mean that without a new TLS extension, that TLS servers > >> sending a certificate_request in response to receiveing a > cert_type="RawPublicKey" > >> is likely to end in a failed TLS connection, because the server > >> cannot authenticate the client based on the received certificate of type > RawPublicKey. > > > > As above, I don't see why that is the case. A server can get client names > and SPKIs out of band just as a client can. > > Yes, it can, but not "as a client can", because the client knows which identity > it is going to contact, while the server does not know which identity it is > contacted by. > > > Please add clarifying text regardless, and then we can discuss if we agree > with it. > > Will do. > > Paul > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ietf@augustcellars.com Wed Apr 11 10:02:16 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410E321F8504 for ; Wed, 11 Apr 2012 10:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RexsIRG8ybaP for ; Wed, 11 Apr 2012 10:02:16 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 15AE921F8503 for ; Wed, 11 Apr 2012 10:02:16 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 93C9B38F04; Wed, 11 Apr 2012 10:02:14 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 11 Apr 2012 10:01:04 -0700 Message-ID: <01d901cd1804$b9257cf0$2b7076d0$@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: Ac0YAd6xQEGjxZdtSlyIW7pm+uB94A== Content-Language: en-us Cc: tls@ietf.org Subject: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:02:16 -0000 There are three models for doing OCSP, as near as I can tell this draft only addresses two of those models. 1. The RP uses a single OCSP server that will issue the OCSP responses for all of the certificates in a chain. 2. The CA directly issues OCSP responses for the certificates that it issues (thus they replace direct CRLs) 3. The CA issues a certificate to the OCSP responder (thus they replace indirect CRLs). The first two are covered as only the certificates in the CA chain and the OCSP responses are needed, however the last model would require that additional certificates and potentially CRLs be transported so that the indirect certificate can be validated as part of processing the OCSP responses. Jim From yngve@opera.com Wed Apr 11 10:36:45 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A221F84EA for ; Wed, 11 Apr 2012 10:36:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkBqNO0gv7Yj for ; Wed, 11 Apr 2012 10:36:44 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 862F821F84CF for ; Wed, 11 Apr 2012 10:36:44 -0700 (PDT) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3BHadT7006053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 17:36:40 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: draft-pettersen-tls-ext-multiple-ocsp@tools.ietf.org, "Jim Schaad" References: <01ca01cd1803$c09b63b0$41d22b10$@augustcellars.com> Date: Wed, 11 Apr 2012 19:36:39 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <01ca01cd1803$c09b63b0$41d22b10$@augustcellars.com> User-Agent: Opera Mail/10.63 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:36:45 -0000 X-List-Received-Date: Wed, 11 Apr 2012 17:36:45 -0000 On Wed, 11 Apr 2012 18:54:10 +0200, Jim Schaad wrote: > There are three models for doing OCSP, as near as I can tell this draft > only > addresses two of those models. > > 1. The RP uses a single OCSP server that will issue the OCSP responses > for > all of the certificates in a chain. > 2. The CA directly issues OCSP responses for the certificates that it > issues (thus they replace direct CRLs) > 3. The CA issues a certificate to the OCSP responder (thus they replace > indirect CRLs). > > The first two are covered as only the certificates in the CA chain and > the > OCSP responses are needed, however the last model would require that > additional certificates and potentially CRLs be transported so that the > indirect certificate can be validated as part of processing the OCSP > responses. How the OCSP responses are retrieved by the server is decided by the server design, and is governed by RFCs 2560 and 5019, and is not really in scope for the document. The most common model will be that the server retrieves them based on the AIA OCSP URL in the certificates, but it is also possible for the server to be configured to download it from a specific responder (or responders) different from what is stated in the certificates. Whether the CA signs the OCSP responses directly, or uses a designated certificate to sign the response (this is handled by the response validation, same as for normal OCSP retrieval) is also IMO out of scope, and it is also governed by RFCs 2560 and 5019. AFAIK revocation is not checked on the designated issuer certificate and there is a recommendation in RFC 5019 about using an extension to disable OCSP checking for that certificate, and not including the CRL or OCSP URLs. While most of that is IMO out of scope, what might be in scope is a recommendation to CAs about whether or not to use designated issuer to sign the responses (although I am inclined to say that this is out of scope, too). At least one major website operator have expressed concern about the responsiveness (from the user experience point of view) of their site if designated issuers are used, since those responses will be much larger than non-designated responses, which might make the handshake hit network limits, requiring an extra delay before the handshake can be completed. While this may be a concern during the first handshake of a session, a well-configured server should be able to keep a session alive for hours or maybe 24 hours, meaning that the extra delay will be rather infrequent (if the session are renegotiated frequently the UX impact might be greater). The present document is about how the client negotiates that the server collects (in a manner not specified) the OCSP responses relevant to the certificates presented by the server, and how they are transferred from the server to the client. Validation of the responses are then handled according to RFC 2560 and RFC 5019,as part of the certificate validation process. It is not different from RFC 6066 in this aspect. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From paul@nohats.ca Wed Apr 11 11:10:17 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B467911E80BA for ; Wed, 11 Apr 2012 11:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.535 X-Spam-Level: X-Spam-Status: No, score=-0.535 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hihUih3kYLl2 for ; Wed, 11 Apr 2012 11:10:17 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 44AE211E808D for ; Wed, 11 Apr 2012 11:10:17 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id B101180335; Wed, 11 Apr 2012 14:10:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id A3DF880331; Wed, 11 Apr 2012 14:10:16 -0400 (EDT) Date: Wed, 11 Apr 2012 14:10:16 -0400 (EDT) From: Paul Wouters To: Jim Schaad In-Reply-To: <01c901cd1801$9cff3fa0$d6fdbee0$@augustcellars.com> Message-ID: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> <01c901cd1801$9cff3fa0$d6fdbee0$@augustcellars.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:10:17 -0000 On Wed, 11 Apr 2012, Jim Schaad wrote: >> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already >> removed there after discussion with EKR in Quebec City. > > If this is really what you want to do, then I would suggest that the > document be expanded so that there exists the possibility to include an > identifier and/or a public key in the certificate form defined by the oob > document. Personall, I strongly prefer not adding more fields to the bare key certificate type, as those people who want to cover client authentication can use full PKIX certs already, and TLS client authentication in the wild seems to be extremely rare. The only two cases I knew are CAcert and Fedora (and for the latter it does not even add security, as I need to identify with another factor anyway (yubikey)) Is there an actual use case where bare keys would be preferable over full PKIX, that also include client auth not based on burned in keys covered by server side SPKI lookups? Paul From mrex@sap.com Wed Apr 11 11:13:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403B311E80B3 for ; Wed, 11 Apr 2012 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u06ijVoEysfP for ; Wed, 11 Apr 2012 11:13:12 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7550B11E808D for ; Wed, 11 Apr 2012 11:13:12 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3BID6aN014285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2012 20:13:06 +0200 (MEST) From: Martin Rex Message-Id: <201204111813.q3BID547012842@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Wed, 11 Apr 2012 20:13:05 +0200 (MEST) In-Reply-To: <01d901cd1804$b9257cf0$2b7076d0$@augustcellars.com> from "Jim Schaad" at Apr 11, 12 10:01:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: draft-pettersen-tls-ext-multiple-ocsp@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:13:13 -0000 Jim Schaad wrote: > > There are three models for doing OCSP, as near as I can tell this draft only > addresses two of those models. > > 1. The RP uses a single OCSP server that will issue the OCSP responses > for all of the certificates in a chain. > 2. The CA directly issues OCSP responses for the certificates that it > issues (thus they replace direct CRLs) > 3. The CA issues a certificate to the OCSP responder (thus they replace > indirect CRLs). > > The first two are covered as only the certificates in the CA chain and the > OCSP responses are needed, however the last model would require that > additional certificates and potentially CRLs be transported so that the > indirect certificate can be validated as part of processing the OCSP > responses. If your above enumeration is supposed to reflect the enumeration from rfc2560 section 4.2.2.2 http://tools.ietf.org/html/rfc2560#section-4.2.2.2 then (1) seems unusable for the purpose of OCSP response stapling within a TLS extension. The "local" within "Matches a local configuration of OCSP signing authority" really refers to the TLS server when acting as RP to obtain the OCSP responses. That "local" may be meaningless even for other hosts of the same site (and in the extreme case, might even be meaningless for a different process on the same host). (3) does _not_ imply an indirection. A CA could issue an OCSP signer cert (as well as a CRL signer cert) as a self-issued non-CA cert. In the OCSP case, if the OCSP signer case, if the OCSP response is not signed by the same CA key(cert) that signed the certificate in question, then that OCSP signer cert ought to be included within the OCSP response (BasicOCSPResponse->certs field), so that the signature validation can be securely performed by the RP. -Martin From ietf@augustcellars.com Wed Apr 11 11:52:15 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C203B21F84B8 for ; Wed, 11 Apr 2012 11:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llv+pt0xRXSp for ; Wed, 11 Apr 2012 11:52:11 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2146221F84AE for ; Wed, 11 Apr 2012 11:52:10 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 681D12C9F4; Wed, 11 Apr 2012 11:52:09 -0700 (PDT) From: "Jim Schaad" To: "'Paul Wouters'" References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> <01c901cd1801$9cff3fa0$d6fdbee0$@augustcellars.com> In-Reply-To: Date: Wed, 11 Apr 2012 11:51:01 -0700 Message-ID: <01ee01cd1814$13741680$3a5c4380$@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: AQHXpApgMNflIeoSkabsN3tGQQOqzgJZH9MoAnuMA6sB8B9K2QFNXwaNAthtsHYCv0m/vAJ5o/a5lf/A8TA= Content-Language: en-us Cc: tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:52:15 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Wednesday, April 11, 2012 11:10 AM > To: Jim Schaad > Cc: tls@ietf.org > Subject: RE: [TLS] Client certificate authentication and draft-ietf-tls-oob- > pubkey > > On Wed, 11 Apr 2012, Jim Schaad wrote: > > >> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already > >> removed there after discussion with EKR in Quebec City. > > > > If this is really what you want to do, then I would suggest that the > > document be expanded so that there exists the possibility to include > > an identifier and/or a public key in the certificate form defined by > > the oob document. > > Personall, I strongly prefer not adding more fields to the bare key certificate > type, as those people who want to cover client authentication can use full > PKIX certs already, and TLS client authentication in the wild seems to be > extremely rare. The only two cases I knew are CAcert and Fedora (and for > the latter it does not even add security, as I need to identify with another > factor anyway (yubikey)) > > Is there an actual use case where bare keys would be preferable over full > PKIX, that also include client auth not based on burned in keys covered by > server side SPKI lookups? Please put me onto the very confused list. In your response to Paul yesterday, you stated that you wanted a TLS extension which did SNI for the client, this is what I was suggesting you put into your structure. I was under the impression that you were arguing that looking up the SPKI at the server was not going to work and that therefore something else was needed. Now you seem to be stating that certificates should be what is used for client authentication. None of this is clear from the current document. And only the case of looking up SPKI would seem to be even possible from the current document. If you state that the certificate structure that is going to be used is the OOB certificate structure then it is going to be the one used by both the client and the server. If you sometimes change this it will make for a very confused server. This means that whatever types of information you need to identify the client to the server for authentication needs to be in this structure definition. If you look at what was done in RFC 6091 - they 1) were very explicit about what the client certificate was and 2) defined a special case for sending an empty PGP certificate slot when the client did not have one available. Jim > > Paul From yngve@opera.com Wed Apr 11 12:15:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2380221F84FE for ; Wed, 11 Apr 2012 12:15:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf-Xn9GCXCGH for ; Wed, 11 Apr 2012 12:15:54 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1F21F8505 for ; Wed, 11 Apr 2012 12:15:53 -0700 (PDT) Received: from acorna.oslo.osa (98.118.34.95.customer.cdi.no [95.34.118.98]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3BJFnln032761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Apr 2012 19:15:50 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: draft-pettersen-tls-ext-multiple-ocsp@tools.ietf.org, "Jim Schaad" References: <01ca01cd1803$c09b63b0$41d22b10$@augustcellars.com> <01e701cd180f$b8fce550$2af6aff0$@augustcellars.com> Date: Wed, 11 Apr 2012 21:15:48 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <01e701cd180f$b8fce550$2af6aff0$@augustcellars.com> User-Agent: Opera Mail/10.63 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 19:15:55 -0000 On Wed, 11 Apr 2012 20:19:52 +0200, Jim Schaad wrote: > > >> -----Original Message----- >> From: Yngve N. Pettersen (Developer Opera Software ASA) >> [mailto:yngve@opera.com] >> Sent: Wednesday, April 11, 2012 10:37 AM >> To: draft-pettersen-tls-ext-multiple-ocsp@tools.ietf.org; Jim Schaad >> Cc: tls@ietf.org >> Subject: Re: draft-pettersen-tls-ext-multiple-ocsp questions >> >> On Wed, 11 Apr 2012 18:54:10 +0200, Jim Schaad >> >> wrote: >> >> > There are three models for doing OCSP, as near as I can tell this >> > draft only addresses two of those models. >> > >> > 1. The RP uses a single OCSP server that will issue the OCSP >> > responses for all of the certificates in a chain. >> > 2. The CA directly issues OCSP responses for the certificates that it >> > issues (thus they replace direct CRLs) 3. The CA issues a certificate >> > to the OCSP responder (thus they replace indirect CRLs). >> > >> > The first two are covered as only the certificates in the CA chain and >> > the OCSP responses are needed, however the last model would require >> > that additional certificates and potentially CRLs be transported so >> > that the indirect certificate can be validated as part of processing >> > the OCSP responses. >> >> How the OCSP responses are retrieved by the server is decided by the > server >> design, and is governed by RFCs 2560 and 5019, and is not really in >> scope > for >> the document. > > I am afraid you have missed my point. What I am looking at is strictly > the > information that needs to be conveyed to the client. > > If a CA setups with an indirect signing certificate then that > certificate is > REQUIRED by the client as part of the OCSP validation information chunk. > Otherwise it would need to do a retrieval on the web for that > certificate in > order to validate the signature on the OCSP response. I suggested that a > CRL MIGHT be needed for the certificate that did the OCSP signing > specifically because I would expect that such a certificate would be > excluded from the OCSP signing and thus a different way of doing the > validation would be required. I would expect a CA to have a CRL that > consisted of JUST OCSP signers as its contents and thus the CRL itself > should be very small. A designated/delegated OCSP responder certificate MUST be issued directly from the CA that issued the certificate that is being validated, and the certificate must be included in the response. See RFC 2560 sec. 2.6 and 4.2.2.2 Since we are assuming that the client is able to build a complete certificate chain based on the certificates sent by the server, if necessary by providing certificates from its own repository or retrieving intermediate CA certs remotely using the AIA Issuer URL in the received certificates, there will be no certificates missing from the chain needed to verify the OCSP response, since the OCSP response is either signed directly by the in-chain CA that issued the certificate, or by a responder using a delegation certificate which was issued by that CA, and which must be included in the response. The only cases for which the validation chain will be broken is if the server's certificate chain cannot be completed, which is a server configuration issue, or if the the delegation certificate either was not included, or was not issued by the CA that issued the certificate, which is a spec violation, and in such a case the client should fail the validation (at least of the response). The OCSP response for a certificate forwarded by the server will (if valid) contain either just the signed response (signed by issuer), or the signed response in combination with the certificate of the responder, which was issued by the CA that issued the certificate. Therefore, all information necessary to check the signature of the response is already available to the client. At present I doubt that any client checks the revocation status of the delegated responder, it is presumed valid and unrevoked (the topic is discussed in RFC 2560 sec. 4.2.2.2.1) . This may or may not be desirable from a security POV, but if so, it is something that the PKIX group should maybe consider as part of the 2560bis work, or perhaps a 5019 successor, not something that should be part of the stapling discussion, since the same issue would be experienced by a client retrieving the responses directly. It is worth noting that (as mentioned) RFC 5019 (which is a light weight profile, meaning that minimum processing overhead is desired) recommends not providing any revocation information in the delegation certificate, but the decision for adding the information is the CA's, and it is the client's decision whether or not to check the revocation information if it is present (which might mean retrieving the CRL or an OCSP response). The server doing the stapling is not involved, and IMO it shouldn't be (if it was, it would have to request that information and then forward it as part of the stapling, which would complicate the protocol structure, as well as the server's control paths). >> >> The most common model will be that the server retrieves them based on >> the >> AIA OCSP URL in the certificates, but it is also possible for the server > to be >> configured to download it from a specific responder (or responders) >> different from what is stated in the certificates. >> >> Whether the CA signs the OCSP responses directly, or uses a designated >> certificate to sign the response (this is handled by the response > validation, >> same as for normal OCSP retrieval) is also IMO out of scope, and it is > also >> governed by RFCs 2560 and 5019. AFAIK revocation is not checked on the >> designated issuer certificate and there is a recommendation in RFC 5019 >> about using an extension to disable OCSP checking for that certificate, > and >> not including the CRL or OCSP URLs. > > Which is a recommendation, but is not a requirement. Thus one could use > a > CRL for OCSP responders (using an OCSP responder for OCSP responders > would > be recursive) and the model does need to be supported by this document. Whether OCSP or CRL is specified for the delegation certificate, and the client want to check it, obtaining that information is IMO outside the scope of this draft as currently envisioned. If desirable, stapling such information should IMO be done by the responder, inside the OCSP response. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From jimsch@augustcellars.com Wed Apr 11 11:21:02 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5D11E80CB for ; Wed, 11 Apr 2012 11:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYlDb1kBUk48 for ; Wed, 11 Apr 2012 11:21:00 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1A57111E80C6 for ; Wed, 11 Apr 2012 11:21:00 -0700 (PDT) Received: from Tobias (unknown [50.34.251.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9EA5938EA5; Wed, 11 Apr 2012 11:20:59 -0700 (PDT) From: "Jim Schaad" To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , References: <01ca01cd1803$c09b63b0$41d22b10$@augustcellars.com> In-Reply-To: Date: Wed, 11 Apr 2012 11:19:52 -0700 Message-ID: <01e701cd180f$b8fce550$2af6aff0$@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: AQKe1zUSV3rdMcRGtOwI0d70k8KQnQJEVMxllOBLnYA= Content-Language: en-us X-Mailman-Approved-At: Wed, 11 Apr 2012 13:09:50 -0700 Cc: tls@ietf.org Subject: Re: [TLS] draft-pettersen-tls-ext-multiple-ocsp questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 18:21:02 -0000 > -----Original Message----- > From: Yngve N. Pettersen (Developer Opera Software ASA) > [mailto:yngve@opera.com] > Sent: Wednesday, April 11, 2012 10:37 AM > To: draft-pettersen-tls-ext-multiple-ocsp@tools.ietf.org; Jim Schaad > Cc: tls@ietf.org > Subject: Re: draft-pettersen-tls-ext-multiple-ocsp questions > > On Wed, 11 Apr 2012 18:54:10 +0200, Jim Schaad > > wrote: > > > There are three models for doing OCSP, as near as I can tell this > > draft only addresses two of those models. > > > > 1. The RP uses a single OCSP server that will issue the OCSP > > responses for all of the certificates in a chain. > > 2. The CA directly issues OCSP responses for the certificates that it > > issues (thus they replace direct CRLs) 3. The CA issues a certificate > > to the OCSP responder (thus they replace indirect CRLs). > > > > The first two are covered as only the certificates in the CA chain and > > the OCSP responses are needed, however the last model would require > > that additional certificates and potentially CRLs be transported so > > that the indirect certificate can be validated as part of processing > > the OCSP responses. > > How the OCSP responses are retrieved by the server is decided by the server > design, and is governed by RFCs 2560 and 5019, and is not really in scope for > the document. I am afraid you have missed my point. What I am looking at is strictly the information that needs to be conveyed to the client. If a CA setups with an indirect signing certificate then that certificate is REQUIRED by the client as part of the OCSP validation information chunk. Otherwise it would need to do a retrieval on the web for that certificate in order to validate the signature on the OCSP response. I suggested that a CRL MIGHT be needed for the certificate that did the OCSP signing specifically because I would expect that such a certificate would be excluded from the OCSP signing and thus a different way of doing the validation would be required. I would expect a CA to have a CRL that consisted of JUST OCSP signers as its contents and thus the CRL itself should be very small. > > The most common model will be that the server retrieves them based on the > AIA OCSP URL in the certificates, but it is also possible for the server to be > configured to download it from a specific responder (or responders) > different from what is stated in the certificates. > > Whether the CA signs the OCSP responses directly, or uses a designated > certificate to sign the response (this is handled by the response validation, > same as for normal OCSP retrieval) is also IMO out of scope, and it is also > governed by RFCs 2560 and 5019. AFAIK revocation is not checked on the > designated issuer certificate and there is a recommendation in RFC 5019 > about using an extension to disable OCSP checking for that certificate, and > not including the CRL or OCSP URLs. Which is a recommendation, but is not a requirement. Thus one could use a CRL for OCSP responders (using an OCSP responder for OCSP responders would be recursive) and the model does need to be supported by this document. Jim > > While most of that is IMO out of scope, what might be in scope is a > recommendation to CAs about whether or not to use designated issuer to > sign the responses (although I am inclined to say that this is out of scope, > too). At least one major website operator have expressed concern about the > responsiveness (from the user experience point of view) of their site if > designated issuers are used, since those responses will be much larger than > non-designated responses, which might make the handshake hit network > limits, requiring an extra delay before the handshake can be completed. > While this may be a concern during the first handshake of a session, a well- > configured server should be able to keep a session alive for hours or maybe > 24 hours, meaning that the extra delay will be rather infrequent (if the > session are renegotiated frequently the UX impact might be greater). > > The present document is about how the client negotiates that the server > collects (in a manner not specified) the OCSP responses relevant to the > certificates presented by the server, and how they are transferred from the > server to the client. Validation of the responses are then handled according > to RFC 2560 and RFC 5019,as part of the certificate validation process. It is not > different from RFC 6066 in this aspect. > > -- > Sincerely, > Yngve N. Pettersen > ********************************************************** > ********** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 > ********************************************************** > ********** From mrex@sap.com Wed Apr 11 14:25:33 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8644D21F84AF for ; Wed, 11 Apr 2012 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alhGT0mOlny7 for ; Wed, 11 Apr 2012 14:25:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AFB9C21F849C for ; Wed, 11 Apr 2012 14:25:29 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3BLPKn7018938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Apr 2012 23:25:25 +0200 (MEST) From: Martin Rex Message-Id: <201204112125.q3BLPJ9D023675@fs4113.wdf.sap.corp> To: paul@nohats.ca (Paul Wouters) Date: Wed, 11 Apr 2012 23:25:19 +0200 (MEST) In-Reply-To: from "Paul Wouters" at Apr 11, 12 02:10:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: ietf@augustcellars.com, tls@ietf.org Subject: Re: [TLS] Client certificate authentication and X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 21:25:33 -0000 Paul Wouters wrote: > >Jim Schaad wrote: >> >>> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already >>> removed there after discussion with EKR in Quebec City. >> >> If this is really what you want to do, then I would suggest that the >> document be expanded so that there exists the possibility to include an >> identifier and/or a public key in the certificate form defined by the oob >> document. > > Personall, I strongly prefer not adding more fields to the bare key > certificate type, That's OK and I don't see a need for that. > > as those people who want to cover client authentication can use > full PKIX certs already, and TLS client authentication in the wild seems > to be extremely rare. I really dislike this answer. What is wrong with plain public keys? It works just fine with SSH. You complained so badly about not wanting to parse X.509 in your client, that I am somewhat appalled to see you suggesting X.509 for client authentication. In our company we've been using SSL client certs for all Intranet systems to which many of our employees need access (Portal, Wikis, Employee self-services scenarios) since 1999, and we've even managed to use it occasionally for stuff that was outsourced (over the internet), because it is so much easier (and more secure) to configure SSL client certs on a WebServer than to newly assign 50.000 passwords each time. If you look around, in many places people can create user accounts with arbitrarily chosen user names, so it really does not matter what name you tag to the key (to make it easier distinguishable for humans), if you tag the keys _at_all_. If you look at the proposal for "Origin-Bound Certificates", they also come with *NO* name that identifies the user, so the concept of recognizing a peer by its public key is really _not_ unusal. > > The only two cases I knew are CAcert and Fedora > (and for the latter it does not even add security, as I need to identify > with another factor anyway (yubikey)) > > Is there an actual use case where bare keys would be preferable over > full PKIX, that also include client auth not based on burned in keys > covered by server side SPKI lookups? Why SPKI lookups? Just have the server map public keys into authorizations, -Martin From wwwrun@rfc-editor.org Thu Apr 12 12:38:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5690921F86D1 for ; Thu, 12 Apr 2012 12:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WIlOV74Rnw8T for ; Thu, 12 Apr 2012 12:38:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BB16721F86CB for ; Thu, 12 Apr 2012 12:38:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2342E6219F; Thu, 12 Apr 2012 12:38:10 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20120412193810.2342E6219F@rfc-editor.org> Date: Thu, 12 Apr 2012 12:38:10 -0700 (PDT) X-Mailman-Approved-At: Thu, 12 Apr 2012 13:13:51 -0700 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:38:51 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3191 -------------------------------------- Type: Editorial Reported by: Martin Rex Section: Meta-Data Original Text ------------- Obsoletes: 3268, 4346, 4366 Updates: 4492 Corrected Text -------------- Updates: 4492 Notes ----- "Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either). "Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066). On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366. "Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2, such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246. 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. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From paul.hoffman@vpnc.org Fri Apr 13 08:02:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A6721F87EF for ; Fri, 13 Apr 2012 08:02:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bgu4S3Okp1QS for ; Fri, 13 Apr 2012 08:02:00 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F171321F87ED for ; Fri, 13 Apr 2012 08:01:59 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3DF1ptP019479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2012 08:01:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20120412193810.2342E6219F@rfc-editor.org> Date: Fri, 13 Apr 2012 08:01:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09A84B45-9963-4C62-B28E-81C44B90DCFB@vpnc.org> References: <20120412193810.2342E6219F@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 15:02:00 -0000 This errata should be rejected because it is not an errata, it is an = objection to the IETF process (how one RFC obsoletes another). It is = definitely an interesting process question, but not one that should be = dealt with through the errata process. On Apr 12, 2012, at 12:38 PM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5246&eid=3D3191 >=20 > -------------------------------------- > Type: Editorial > Reported by: Martin Rex >=20 > Section: Meta-Data >=20 > Original Text > ------------- > Obsoletes: 3268, 4346, 4366 > Updates: 4492 >=20 > Corrected Text > -------------- > Updates: 4492 >=20 > Notes > ----- > "Obsoletes: 4366" is factually incorrect, because it is impossible to = implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec = alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete = HTTP/1.0 either). >=20 > "Obsoletes: 4366" is factually incorrect, because some of the TLS = extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated = by rfc6066). On top of that, in order to implement TLS extensions for = TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the = necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would = be cumbersome to extract from rfc5246 compared to simply using rfc4366. >=20 > "Obsoletes: 3268" is factually incorrect, because 3268 is the document = needed to implement the AES ciphersuites in implementations of TLS = _prior_ to TLSv1.2, > such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for = AES ciphersuites to an existing implementation of TLSv1.0, one would use = TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined = fragments of rfc5246. >=20 > 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.=20 >=20 > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol = Version 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From paul.hoffman@vpnc.org Sat Apr 14 10:44:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AD721F85B9 for ; Sat, 14 Apr 2012 10:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u-AVTBebCIj for ; Sat, 14 Apr 2012 10:44:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B805E21F84EA for ; Sat, 14 Apr 2012 10:43:48 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3EHhkXG059771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 14 Apr 2012 10:43:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 14 Apr 2012 10:43:46 -0700 Message-Id: <02B63809-B70A-43BE-8AA6-0B564EDFA97E@vpnc.org> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [TLS] Update on False Start X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2012 17:44:39 -0000 Not a good sign for TLS changes that require field updates... --Paul Hoffman From n.mavrogiannopoulos@gmail.com Sun Apr 15 02:51:50 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFDF21F8726 for ; Sun, 15 Apr 2012 02:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvYpIpwSe7pc for ; Sun, 15 Apr 2012 02:51:50 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D480321F86D9 for ; Sun, 15 Apr 2012 02:51:49 -0700 (PDT) Received: by eeke51 with SMTP id e51so1114408eek.31 for ; Sun, 15 Apr 2012 02:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=gq1nZWVJLeFQpUPVSGk5FLXUXkZITix9C08Gi5IMxGc=; b=eF/eZaGLIfwwSJ32N1LGdwRQevbUufQTwbcBDZpalQx9yA40Hqrp9dfquk1JMfujXv J4EFgspYyaGSHLdV3N1Dd7M7F3wNijH4ZrG1WUOlYxi+Vta8G+kMAOnaxvxBGvEZv/US ooOiIfpzyFIt4T/1XammIGotixzmA+x89/Ve/3p9/Dz0tbmP4s2R62TJ1bVcNpnSMqi5 eFRzR8pxOqAKVVjWPW80+N0rP1Ucps+0xEWWE7TAnlET188bB+cELyl4kYrttZfYh3fO 3XM75xDbCKmzfZ97NgtOHlEHVf/n9taILnp7e9haj4pAYg3NBe6pvut0LU91uWnGidm4 LjTQ== Received: by 10.213.110.7 with SMTP id l7mr547740ebp.110.1334483508821; Sun, 15 Apr 2012 02:51:48 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id y11sm70156895eem.3.2012.04.15.02.51.47 (version=SSLv3 cipher=OTHER); Sun, 15 Apr 2012 02:51:47 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F8A9A2E.8000508@gnutls.org> Date: Sun, 15 Apr 2012 11:51:42 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Paul Hoffman References: <02B63809-B70A-43BE-8AA6-0B564EDFA97E@vpnc.org> In-Reply-To: <02B63809-B70A-43BE-8AA6-0B564EDFA97E@vpnc.org> X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Update on False Start X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 09:51:50 -0000 On 04/14/2012 07:43 PM, Paul Hoffman wrote: > > Not a good sign for TLS changes that require field updates... I don't know. There might have been other reasons to drop false start. One that I can think of is that the benefits didn't outweigh the costs. The cost is a lower security bar and incompatibility problems. The benefit is improved user experience in a browser. Was such benefit significant with false start? Did pages load faster? I'd expect to have the majority of connections in a browser as resuming sessions, hence improved loading time might not have been the case. Performance improvement figures are missing for such an important extension. regards, Nikos From ynir@checkpoint.com Sun Apr 15 03:39:01 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11B21F870A for ; Sun, 15 Apr 2012 03:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mMclfCtvWgz for ; Sun, 15 Apr 2012 03:39:00 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 03F3A21F86FF for ; Sun, 15 Apr 2012 03:38:59 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3FAcjIC011685; Sun, 15 Apr 2012 13:38:46 +0300 X-CheckPoint: {4F8AB23E-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 15 Apr 2012 13:38:46 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 15 Apr 2012 13:38:43 +0300 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Sun, 15 Apr 2012 13:38:45 +0300 Thread-Topic: [TLS] Update on False Start Thread-Index: Ac0a8+34QRVtdyQoTby/mkZh1pbqpQ== Message-ID: References: <02B63809-B70A-43BE-8AA6-0B564EDFA97E@vpnc.org> <4F8A9A2E.8000508@gnutls.org> In-Reply-To: <4F8A9A2E.8000508@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 116ef9ef18ee4e56a5df3dc9cd38b5614a364d2fbd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Cc: Paul Hoffman , "tls@ietf.org" Subject: Re: [TLS] Update on False Start X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2012 10:39:01 -0000 On Apr 15, 2012, at 12:51 PM, Nikos Mavrogiannopoulos wrote: > On 04/14/2012 07:43 PM, Paul Hoffman wrote: >=20 >> >> Not a good sign for TLS changes that require field updates... >=20 >=20 > I don't know. There might have been other reasons to drop false start. > One that I can think of is that the benefits didn't outweigh the costs. > The cost is a lower security bar and incompatibility problems. They had an explanation in their technical note, about why the security bar= is not lowered. Whether or not we believe that the security argument is va= lid, they believed it. The incompatibility problems were unexpected. I thin= k one of the big reasons that the Internet has moved to "everything over HT= TP(S)" was to escape the middleboxes, because everything that goes over por= ts 80 or 443, and looks somewhat like HTTP or TLS gets through.=20 The middleboxes just became "next generation middleboxes" and now the firew= alls are deep inspecting the TLS connection, and the load balancers try to = improve scale. You can no longer assume that all clients are IE, all server= s are either IIS or Apache with OpenSSL, and the few outliers will have to = adapt. Now there are dozens of implementations our there. > The benefit is improved user experience in a browser. Was such benefit > significant with false start? Did pages load faster? I'd expect to have > the majority of connections in a browser as resuming sessions, hence > improved loading time might not have been the case. Performance > improvement figures are missing for such an important extension. I agree, but note that this was not an extension. It wasn't negotiated. Now= that it's tied to NPN it will be negotiated. A naive implementation of TLS= would work fine. I guess some of the middleboxes had no-so-naive implement= ations. Yoav= From mrex@sap.com Mon Apr 16 09:12:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A8021F8731 for ; Mon, 16 Apr 2012 09:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.061 X-Spam-Level: X-Spam-Status: No, score=-10.061 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTQ6aMqWG9ua for ; Mon, 16 Apr 2012 09:12:48 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3995B21F85B7 for ; Mon, 16 Apr 2012 09:12:48 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3GGCkL0018968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2012 18:12:46 +0200 (MEST) From: Martin Rex Message-Id: <201204161612.q3GGCkjQ000495@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Mon, 16 Apr 2012 18:12:46 +0200 (MEST) In-Reply-To: <09A84B45-9963-4C62-B28E-81C44B90DCFB@vpnc.org> from "Paul Hoffman" at Apr 13, 12 08:01:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:12:49 -0000 Paul Hoffman wrote: > > > http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3191 > > This errata should be rejected because it is not an errata, it is > an objection to the IETF process (how one RFC obsoletes another). You're mistaken, incorrect Meta-Data can be reported as RFC-Errata, see: http://www.ietf.org/iesg/statement/rfc-metadata-errata.html > > It is definitely an interesting process question, but not one that > should be dealt with through the errata process. The condition where the use of Obsoletes: is correct is documented here: http://tools.ietf.org/html/rfc2223#page-12 Obsoletes To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, *> however extensive or brief that new information is; i.e., this *> document can be used alone, without reference to the older *> document. So the meta-data of rfc5246 is definitely factually incorrect, because neither of the stuff that is described by the documents that rfc5246 claims to obsolete can be implemented from rfc5246 ALONE! -Martin From paul.hoffman@vpnc.org Mon Apr 16 09:38:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A3911E80B2 for ; Mon, 16 Apr 2012 09:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yawsJhSzo2hq for ; Mon, 16 Apr 2012 09:38:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF3C11E80AB for ; Mon, 16 Apr 2012 09:38:17 -0700 (PDT) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q3GGcGt4035730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Apr 2012 09:38:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201204161612.q3GGCkjQ000495@fs4113.wdf.sap.corp> Date: Mon, 16 Apr 2012 09:38:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06FB3794-3B92-40AC-937A-5B216A6A529E@vpnc.org> References: <201204161612.q3GGCkjQ000495@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:38:21 -0000 On Apr 16, 2012, at 9:12 AM, Martin Rex wrote: > Paul Hoffman wrote: >>=20 >>> http://www.rfc-editor.org/errata_search.php?rfc=3D5246&eid=3D3191 >>=20 >> This errata should be rejected because it is not an errata, it is >> an objection to the IETF process (how one RFC obsoletes another). >=20 > You're mistaken, incorrect Meta-Data can be reported as RFC-Errata, = see: >=20 > http://www.ietf.org/iesg/statement/rfc-metadata-errata.html Of course. And, if you read that document, you will see what you are = reporting is not a minor errata for meta-data, but a major disagreement = about what "Obsoletes" means. >> It is definitely an interesting process question, but not one that >> should be dealt with through the errata process. >=20 > The condition where the use of Obsoletes: is correct is documented = here: >=20 > http://tools.ietf.org/html/rfc2223#page-12 >=20 > Obsoletes >=20 > To be used to refer to an earlier document that is replaced by > this document. This document contains either revised = information, > or else all of the same information plus some new information, > *> however extensive or brief that new information is; i.e., this > *> document can be used alone, without reference to the older > *> document. >=20 >=20 > So the meta-data of rfc5246 is definitely factually incorrect, > because neither of the stuff that is described by the documents > that rfc5246 claims to obsolete can be implemented from rfc5246 ALONE! I can see your point, and think that the IETF might be using "Obsoletes" = incorrectly in this and many other cases, given the text you quote here. = As I said earlier, that would be an IETF process discussion. That does = not mean you can correct it with an errata, as the document you point to = above clearly says. --Paul Hoffman From mrex@sap.com Mon Apr 16 09:55:36 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5A311E80CA for ; Mon, 16 Apr 2012 09:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb48UmMCcETz for ; Mon, 16 Apr 2012 09:55:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8A86821F86F7 for ; Mon, 16 Apr 2012 09:55:34 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3GGtXMc027317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Apr 2012 18:55:33 +0200 (MEST) From: Martin Rex Message-Id: <201204161655.q3GGtW5Y002995@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Mon, 16 Apr 2012 18:55:32 +0200 (MEST) In-Reply-To: <06FB3794-3B92-40AC-937A-5B216A6A529E@vpnc.org> from "Paul Hoffman" at Apr 16, 12 09:38:15 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 16:55:36 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > Paul Hoffman wrote: > >> > >>> http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3191 > >> > >> This errata should be rejected because it is not an errata, it is > >> an objection to the IETF process (how one RFC obsoletes another). > > > > You're mistaken, incorrect Meta-Data can be reported as RFC-Errata, see: > > > > http://www.ietf.org/iesg/statement/rfc-metadata-errata.html > > Of course. And, if you read that document, you will see what you are > reporting is not a minor errata for meta-data, but a major disagreement > about what "Obsoletes" means. What Obsoletes: means *IS* standardized in rfc2223. The reported errata is actually a minor technical defect. > > >> It is definitely an interesting process question, but not one that > >> should be dealt with through the errata process. > > > > The condition where the use of Obsoletes: is correct is documented here: > > > > http://tools.ietf.org/html/rfc2223#page-12 > > > > Obsoletes > > > > To be used to refer to an earlier document that is replaced by > > this document. This document contains either revised information, > > or else all of the same information plus some new information, > > *> however extensive or brief that new information is; i.e., this > > *> document can be used alone, without reference to the older > > *> document. > > > > > > So the meta-data of rfc5246 is definitely factually incorrect, > > because neither of the stuff that is described by the documents > > that rfc5246 claims to obsolete can be implemented from rfc5246 ALONE! > > I can see your point, and think that the IETF might be using "Obsoletes" > incorrectly in this and many other cases, given the text you quote here. > As I said earlier, that would be an IETF process discussion. That does > not mean you can correct it with an errata, as the document you point > to above clearly says. Actually, the above definition of Obsoletes *DESCRIBES* the current IETF Process. There may be invalid uses of Obsoletes: headers that may be accidental on the part of the authors or of the WG, and a few times that might have even been "political misappropriation". But just because noone reported (or objected) to the incorrect Meta-Information on IETF LC doesn't turn factually incorrect information into facts. But unless the IETF Process is changed, such uses are technical defects that only cause confusion to readers of the affected RFCs. The IETF process to fix document defects is the Errata system. What _you_ might be looking for instead is a Meta-Data to the effect "Successor to Protocol: xxxx" See the correct use of the "Obsoletes:" Meta-Data for the HTTP protocol: rfc1945 HTTP/1.0 rfc2068 HTTP/1.1 rfc2616 HTTP/1.1 Obsoletes: 2068 document rfc2616 truely obsoletes rfc2068, but neither rfc2068 nor rfc2616 obsolete rfc1945. -Martin From n.mavrogiannopoulos@gmail.com Mon Apr 16 23:41:25 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB4121F84FA for ; Mon, 16 Apr 2012 23:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbQKBNTHjjyH for ; Mon, 16 Apr 2012 23:41:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF1E021F84F8 for ; Mon, 16 Apr 2012 23:41:24 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1521851eaa.31 for ; Mon, 16 Apr 2012 23:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=zi/BIkZ2W68prg/E0kq2Qrp8GTTvOlo8+eopvjfxgmk=; b=ub0UKChOabIhjox0/I2KzMOGh+PaPRZ9Pe8v3mRAjxrf7aw4FGz5Dzlvz/+/lXUPRa 4N26MusvKAKCaGOomZoP14rj9l0YNjsD+HThvk9QS+T/Spga+SQiweqs9Y5ryane2QcW dx/30zATysY+ZZ01hI+mk484eqvB+qqSYN/LcpuVOGsj7IJ2gnExB7YKABrn5nc45zsK dC5P/rrTc4DEzxDXSg5d5oFB9FILrdgXhH+GIOaIDzmhumHvzUFi0T7QSZOgs2tjFjHC 2efO94JnlDZuePrVWwRADyTxegnJfawALgcm8ywBgEA0RClSSVZCKNbOYLCkSVo79TFo my9w== Received: by 10.213.17.2 with SMTP id q2mr1059827eba.4.1334644883550; Mon, 16 Apr 2012 23:41:23 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id r44sm98029639eef.2.2012.04.16.23.41.21 (version=SSLv3 cipher=OTHER); Mon, 16 Apr 2012 23:41:22 -0700 (PDT) Message-ID: <4F8D108C.8040701@gmail.com> Date: Tue, 17 Apr 2012 08:41:16 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: tls@ietf.org References: <20120412193810.2342E6219F@rfc-editor.org> In-Reply-To: <20120412193810.2342E6219F@rfc-editor.org> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Apr 2012 10:07:19 -0700 Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 06:41:26 -0000 On 04/12/2012 09:38 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". [...] > -------------------------------------- > Type: Editorial > Reported by: Martin Rex > > Section: Meta-Data > > Original Text > ------------- > Obsoletes: 3268, 4346, 4366 > Updates: 4492 > > Corrected Text > -------------- > Updates: 4492 > > Notes > ----- > "Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either). > "Obsoletes: 4366" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066). On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366. > "Obsoletes: 3268" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2, > such as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246. It looks like a valid report to me. regards, Nikos From ekr@rtfm.com Tue Apr 17 10:18:29 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2AF11E80A3 for ; Tue, 17 Apr 2012 10:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8B-h0xfzqyKJ for ; Tue, 17 Apr 2012 10:18:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CABD511E80C5 for ; Tue, 17 Apr 2012 10:18:24 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so490391vcb.31 for ; Tue, 17 Apr 2012 10:18:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Gq59c7LBhrE7dX0MNsQp2awcLE1QmqV0AP4zRgSRwGA=; b=pjR/I3ugshhT5x9vU547JP+ZqnFZgGHu59WZw7TnAC/8wbQ0jr3YXs4vqpcW+eiAKp QL9nTHay1MqXvhzfhpxOha2tpcfMQoEQ7prMxWA2xGFKAgAma+hasiBvADsrZPgR+Jbl d07AbDKmWQBm2pbtKoKR3W8rQCNBd869akGg+v2/o7MN5Am0TXmlNAxPe+oAWVge+K4c /IVB2WkyTmhuFgAFpMznpX/lYRk4lyRx1T67gVOLLWzfN8mtn08jRmVDzhwG3jy2yCa7 THBljzN8gJYSVfM74iVtMEbmT1w9nEqpR8pXRn/30DkfRNxd7eLKlPeC+IoAa9ZFfAGs CcgA== Received: by 10.220.150.134 with SMTP id y6mr1857845vcv.43.1334683104228; Tue, 17 Apr 2012 10:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 10:17:44 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <20120412193810.2342E6219F@rfc-editor.org> References: <20120412193810.2342E6219F@rfc-editor.org> From: Eric Rescorla Date: Tue, 17 Apr 2012 10:17:44 -0700 Message-ID: To: RFC Errata System Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmfvHjJimIfPrSVeFQ4oC4mPvQ32OCZF1JJOQwfZMJltqEUQTucWJ2Ds7yKOLwLIduVnkDz Cc: tls@ietf.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:18:29 -0000 I don't concur with this report. On Thu, Apr 12, 2012 at 12:38 PM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3191 > > -------------------------------------- > Type: Editorial > Reported by: Martin Rex > > Section: Meta-Data > > Original Text > ------------- > Obsoletes: 3268, 4346, 4366 > Updates: 4492 > > Corrected Text > -------------- > Updates: 4492 > > Notes > ----- > "Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either). > On the other hand, IKEv2 obsoleted IKE. http://tools.ietf.org/html/rfc4306 So I don't this is as clear cut as you suggest. -Ekr From mike-list@pobox.com Tue Apr 17 13:00:30 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C87B21F84FB for ; Tue, 17 Apr 2012 13:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGxghQ1Q0Q17 for ; Tue, 17 Apr 2012 13:00:26 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 08C7D21F84F8 for ; Tue, 17 Apr 2012 13:00:24 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8BE728D6A for ; Tue, 17 Apr 2012 16:00:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=bG/EC/5ewlO3fhS/nsye5+XJR mo=; b=vZqhOVnVasu4VJr3ju8mxPQL3LbB0gQpLqWBWabYV0aVXkt2gKFtXG2JM EZI1MSENUdXsDU3gErjIccuGYCaKqTkGVtmYHoCqkaUUSTUlj517px2JgpgL/rIS MC/RfrXH7ez0P6uyiC/oCG9R2kNpuuvTbytx4WbJPDQRYrbTJs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=PQJ3hpiz22+onNCcDQS XYOGQVH4Dvj7QrpEMdx9pB/zlQoSQ8/ggnKLUIRKGz1t6NSUVAAX+6J5Kl7pJYNK lJJhq9d77qYPQo8Q93bFKX1CNtdDznEf0W1Fe2rRSAgcFaJbp50Cn/llcSsUFj5K XfMvSH3cdiFNrDkqopJ29vyQ= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8562A8D69 for ; Tue, 17 Apr 2012 16:00:22 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 09C978D68 for ; Tue, 17 Apr 2012 16:00:21 -0400 (EDT) Message-ID: <4F8DCBD4.6090104@pobox.com> Date: Tue, 17 Apr 2012 13:00:20 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F6FBD252-88C7-11E1-8993-B1B0728A0A4D-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:00:30 -0000 A lot of people are pushing Google's SPDY protocol to improve web performance; however, it seems to rely on the Next Protocol Negotiation (NPN) extension, which does not appear to have been officially published as an RFC (the -02 draft expired in October 2011). RFC 5246 explains that all TLS extensions have to obtain IETF Consensus to be used on the Internet: This document also uses a registry originally created in [RFC4366]. IANA has updated it to reference this document. The registry and its allocation policy (unchanged from [RFC4366]) is listed below: - TLS ExtensionType Registry: Future values are allocated via IETF Consensus [RFC2434]. [...] NPN also adds a new handshake message to the TLS protocol, completely bypassing the required Standards Action to do so: - TLS HandshakeType Registry: Future values are allocated via Standards Action [RFC2434]. Speeding up the web is certainly not evil, but a large player like Google shouldn't be setting such a bad precedent w.r.t. the IETF process. Mike From n.mavrogiannopoulos@gmail.com Tue Apr 17 13:51:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C39611E80CB for ; Tue, 17 Apr 2012 13:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GcLkkhwQHHz for ; Tue, 17 Apr 2012 13:51:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D13E111E80BD for ; Tue, 17 Apr 2012 13:51:38 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1774721eaa.31 for ; Tue, 17 Apr 2012 13:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=FRdEcV3Efp59HlaRg/QN6vRX7jAJSRsRrky4hM5Bzfk=; b=0GPjuAlCEgjSNwfR9owV4WFmMsIkAcB/w0s4Zyb55s9zf+47nPv++fQYOiyc708PyT rlYm+IMfOim+rx8mwkpJ4vj+g/E6yqOfzy6ZEYKHwhRbMpE66BrppkHObSU2KHZTU3mG z9DrjIo34H3wL97yAiItykJxIhaXy3QJ/H4yGdPi4CnoRS9EmLgzTKWcxUTXrFcaK9OP 0OIdz2jNOWO33xMMTZyFk6gnXxEYUFXeOC5flPChG/PrbUn6+7I1O/TdqXmT+m4EStYo mxWV7EfX7VCaWJOPDTCOCdWKDebZhJwplSBUPRVjRFLj1xKnUXbAlE69ND36P7L9sHmV B+ig== Received: by 10.14.52.133 with SMTP id e5mr2529691eec.127.1334695897983; Tue, 17 Apr 2012 13:51:37 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id q45sm107576958eem.7.2012.04.17.13.51.37 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 13:51:37 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F8DD7D3.4010805@gnutls.org> Date: Tue, 17 Apr 2012 22:51:31 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Michael D'Errico References: <4F8DCBD4.6090104@pobox.com> In-Reply-To: <4F8DCBD4.6090104@pobox.com> X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: TLS Mailing List Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:51:40 -0000 On 04/17/2012 10:00 PM, Michael D'Errico wrote: > A lot of people are pushing Google's SPDY protocol to improve web > performance; > however, it seems to rely on the Next Protocol Negotiation (NPN) extension, > which does not appear to have been officially published as an RFC (the -02 > draft expired in October 2011). I'd also note that the text in the draft isn't sufficient to implement the protocol described. There are no numbers assigned by IANA and fields like padding are not even defined. > NPN also adds a new handshake message to the TLS protocol, completely > bypassing the required Standards Action to do so: Also there is no rationale on why a new handshake message is needed. regards, Nikos From n.mavrogiannopoulos@gmail.com Tue Apr 17 13:53:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0785821F842A for ; Tue, 17 Apr 2012 13:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvUMTqfIReUx for ; Tue, 17 Apr 2012 13:53:45 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60DB511E80BA for ; Tue, 17 Apr 2012 13:53:43 -0700 (PDT) Received: by eeke51 with SMTP id e51so1795278eek.31 for ; Tue, 17 Apr 2012 13:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=0fpKSs1db5pGJCGLzhubu8cI7RRCIEXgYKKK+Yp/WiI=; b=xXjv2089X8ycAdzbelbwxy0RRnCLz2xR8/32Vok/ib/g6Vu9XC8kgB2IRs2pfV7UJf 196ZECRQuxebTev1ig9YD54v0yDDbgwFljqzQ9rpAmRqQiFF2MhHeiy/8YMtXcI0wWQS eTzsta6lg/5qtCS2uGCxqgMlLCmoKjgUOsF4biNupJsH2h5BLGMljvL4bD9cU8zfwFLq cWu4xBrGuM683Z7za8fd7X9jIZta7Z+va07b/EDQqy7seE5mWgmgf6Le9Pklk/U0FzON MlwEROVpH4bCtEHuNN37ZqNUT2qoDaUEW1Ltdf0xxmTW2j5E1bIWVYwv2y4Uxx8lxQJj UJ6Q== Received: by 10.14.127.12 with SMTP id c12mr2486380eei.19.1334696022449; Tue, 17 Apr 2012 13:53:42 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id z47sm107612348een.5.2012.04.17.13.53.41 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 13:53:41 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F8DD855.6020706@gnutls.org> Date: Tue, 17 Apr 2012 22:53:41 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Eric Rescorla References: <20120412193810.2342E6219F@rfc-editor.org> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, RFC Errata System Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:53:51 -0000 On 04/17/2012 07:17 PM, Eric Rescorla wrote: > On the other hand, IKEv2 obsoleted IKE. > http://tools.ietf.org/html/rfc4306 > So I don't this is as clear cut as you suggest. In that case didn't IKEv2 actually made IKE obsolete? It is pretty different than the TLS case where TLS 1.0 is in widespread use several years after it has been marked as obsolete. regards, Nikos From ekr@rtfm.com Tue Apr 17 13:57:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D870121F84A0 for ; Tue, 17 Apr 2012 13:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx942tauw0Y2 for ; Tue, 17 Apr 2012 13:57:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C14B921F845B for ; Tue, 17 Apr 2012 13:57:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5224820vbb.31 for ; Tue, 17 Apr 2012 13:57:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=uCbQ0kFA22kYtas7+jgQwhHAExsIPab4+NiTV2MToFU=; b=hSQLPux8d8i8KXg/stGdSWB1BD9ToBv79gicrztNfNJcfu5QyOx4wWYy6wetO5Hq7L ojFhS7Fm+p53qAVGBtcXVo0/F92G1ZRVnAmgDfFk7KiG/oqpmy0tfHKHSgnzU2RN2Yuu WCwOvaMGxEtB8Exd8BQq5d0cmDKPnR+R7SfHT4WGV1f0Fb1Wl0Q2CAIqppLjmNsmR07e yE/Bo0BfT5G6yX//VkZ18TR+rGuMREnjT+m+u0aZUDB/QOv2ijd8l6S2idR7Uu0fB/JK HDJAmS+AYlEW1ABPxeO1jmaj/HawQHdO22J/OPJpv6wR2ZIUiW4o6PiilxudT3eWOzpv A4LQ== Received: by 10.52.75.105 with SMTP id b9mr6139442vdw.26.1334696226173; Tue, 17 Apr 2012 13:57:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 13:56:26 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <4F8DD855.6020706@gnutls.org> References: <20120412193810.2342E6219F@rfc-editor.org> <4F8DD855.6020706@gnutls.org> From: Eric Rescorla Date: Tue, 17 Apr 2012 16:56:26 -0400 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnE3HLpplxOq7qX+HJh2eZ5fzjHzFNiobUvTeD6RJSq2b9lN6tI6vgtOknqfX59Ay1bUROy Cc: tls@ietf.org, RFC Errata System Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 20:57:11 -0000 On Tue, Apr 17, 2012 at 4:53 PM, Nikos Mavrogiannopoulos wrote: > On 04/17/2012 07:17 PM, Eric Rescorla wrote: > > >> On the other hand, IKEv2 obsoleted IKE. >> http://tools.ietf.org/html/rfc4306 >> So I don't this is as clear cut as you suggest. > > > In that case didn't IKEv2 actually made IKE obsolete? > It is pretty different than the TLS case where > TLS 1.0 is in widespread use several years after it > has been marked as obsolete. I'm not sure I understand what you mean. Those markings are produced at the time the RFC is published, so they're not really contingent on future deployment results, but rather on the IETF's intentions. -Ekr From ynir@checkpoint.com Tue Apr 17 14:22:48 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1672611E80D7 for ; Tue, 17 Apr 2012 14:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.645 X-Spam-Level: X-Spam-Status: No, score=-9.645 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_00=-2.599, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+2jNCC3R+Yl for ; Tue, 17 Apr 2012 14:22:44 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B8BDF11E80B2 for ; Tue, 17 Apr 2012 14:22:43 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3HLMT6D025163; Wed, 18 Apr 2012 00:22:29 +0300 X-CheckPoint: {4F8DEBFA-2-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Apr 2012 00:22:29 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 18 Apr 2012 00:22:27 +0300 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Wed, 18 Apr 2012 00:22:26 +0300 Thread-Topic: [TLS] [Editorial Errata Reported] RFC5246 (3191) Thread-Index: Ac0c4DBHbrdO75KAT4+y4ZnoQVkyzw== Message-ID: <54865061-5F72-421B-8BA4-7444CB7F65E9@checkpoint.com> References: <20120412193810.2342E6219F@rfc-editor.org> <4F8DD855.6020706@gnutls.org> In-Reply-To: <4F8DD855.6020706@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11601ab2d6c27657ba0691759eaf8c95331657758d Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" , RFC Errata System Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 21:22:48 -0000 On Apr 17, 2012, at 11:53 PM, Nikos Mavrogiannopoulos wrote: > On 04/17/2012 07:17 PM, Eric Rescorla wrote: >=20 >=20 >> On the other hand, IKEv2 obsoleted IKE. >> http://tools.ietf.org/html/rfc4306 >> So I don't this is as clear cut as you suggest. >=20 >=20 > In that case didn't IKEv2 actually made IKE obsolete? > It is pretty different than the TLS case where > TLS 1.0 is in widespread use several years after it > has been marked as obsolete. IKEv2 is 7 years old, and IKEv1 is still the rule, while IKEv2 is the excep= tion. It's very similar to TLS 1.1/1.2 vs 1.0, and IPv6 vs v4. Unless there's a good technical reason to keep using the old protocol, such= that it does something that was removed from the new version, I think it's= right that new versions will obsolete older versions. There's no reason to= implement TLS 1.0/1.1 today except for backward compatibility with existin= g systems that are out there. The fact that A obsoletes B does not mean tha= t vendors should delete the code that does B. There is an issue that goes beyond notation, though. When new stuff is defi= ned (like extensions or ciphersuites), it will usually reference the newest= RFC. Usually there will be no problem implementing that same extension or = ciphersuite with TLS 1.1 or 1.0 (or even SSLv3). So the question is, if we = have something new (like SPDY and the NPN extension), does it need to be ti= ed to the latest TLS (1.2 in our case)? You could argue that for SPDY you need a new client and a new server, so yo= u might as well have them do it only over TLS 1.2, but that is not how Goog= le and Mozilla implemented this.=20 Yoav= From mrex@sap.com Tue Apr 17 15:11:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D509021F8494 for ; Tue, 17 Apr 2012 15:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.071 X-Spam-Level: X-Spam-Status: No, score=-10.071 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHUI9BicJrVJ for ; Tue, 17 Apr 2012 15:10:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7868F21F846D for ; Tue, 17 Apr 2012 15:10:59 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3HMAoij010384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 00:10:50 +0200 (MEST) From: Martin Rex Message-Id: <201204172210.q3HMAi0F012680@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 18 Apr 2012 00:10:44 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 17, 12 10:17:44 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:11:03 -0000 Eric Rescorla wrote: > > I don't concur with this report. > > > ----- > > "Obsoletes: 4366" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either). > > > > On the other hand, IKEv2 obsoleted IKE. > http://tools.ietf.org/html/rfc4306 > > So I don't this is as clear cut as you suggest. The instruction given to RFC authors in rfc2223 page 12 about what Obsoletes is _supposed_ to convey is IMHO fairly clear cut. If you want to implement TLSv1.0 (i.e. interoperability with TLS peers using protocol version { 0x03,0x01 }, the use of rfc2246 is essential and unavoidable, because rfc5246 is lacking important information). As it turns out, a few document authors & document shepherds did not pay attention to the definition and purpose of the Obsoletes Header field on Page 12 of rfc2223 "Instructions to RFC Authors" and factually incorrect information got published in headers of some RFCs. Factually incorrect Obsolete headers have created more than one discussion and require the IESG to assess when it is OK and why it might be necessary a to reference RFCs that were marked "Obsolete" normatively -- something which would not be necessary if the RFC authors had used the Obsoletes: correcty, as defined in rfc2223, page-12. But rather than reiterating Epicycles-like theories to describe such exceptions, the engineering solution would be to fix the defect and obviate all of: confusion, complex exceptions and regular discussions about it. -Martin From mrex@sap.com Tue Apr 17 15:34:22 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4A11E80B1 for ; Tue, 17 Apr 2012 15:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.076 X-Spam-Level: X-Spam-Status: No, score=-10.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WQP+5mivonJ for ; Tue, 17 Apr 2012 15:34:22 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8F11E8086 for ; Tue, 17 Apr 2012 15:34:21 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3HMY9Yk011759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 00:34:09 +0200 (MEST) From: Martin Rex Message-Id: <201204172234.q3HMY81B013863@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 18 Apr 2012 00:34:08 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 17, 12 04:56:26 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:34:23 -0000 Eric Rescorla wrote: > > I'm not sure I understand what you mean. Those markings are > produced at the time the RFC is published, so they're not really > contingent on future deployment results, but rather on the > IETF's intentions. The purpose of that Marking is described in a document called rfc2223 "Instructions to RFC Authors". In my ears, your argument sounds somewhat in the direction of: "I have been entirely ignoring the rfc2223 purpose of meta-data and (ab)used the Obsoletes: header to actively promote newer protocol versions and over older protocol versions ... and I want to continue ignoring rfc2223 and (ab)use the Obsoletes: header in that fashion. I do not care how much that (ab)use might confuse other readers of the affected RFCs." ... specifically readers that try to parse RFC meta-data as OFFICIALLY specified by the IETF, i.e. according to rfc2223... (which currently seems to apply to tools/IDNits and the RFC Editor). -Martin From ekr@rtfm.com Tue Apr 17 15:40:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF94311E80B1 for ; Tue, 17 Apr 2012 15:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw7U57pV1+fE for ; Tue, 17 Apr 2012 15:40:20 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C697421F84C8 for ; Tue, 17 Apr 2012 15:40:19 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so721906vcb.31 for ; Tue, 17 Apr 2012 15:40:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=qe4nyM5dUh4ScvnTTukiT3gtfoMG9Y3OL2o8UKN8SGk=; b=n3FMkWtXLSmO38O/UvjAl6O1R/EjmAFDlquIXW3d6dshlihyVKox4UWdu19iaK2Fef XN3KabKVWZvD5qNlfxBGOpMRF2QO2Glu5kQW/sayotN8GfMgKoy/3DACPNpK4grzyIa0 5iZNwsoe72aukBEVMTWhxfQ0mQdGNb+PZutQSv1clWoOzwMH7CA7jLeehFbEfpicxhk9 JG341qLBYQAEoY4munNqUBu7jPW7a2IAahIl69fUpE1JikxDmV+h/gFFwCfiNtphisVG HFX4vAVsJ48UCEw1hJcMYjdl86q4KN6Ij4Rv5DoxpqTaANgqBKXUB2ErxMLm5VtQFG4b aRTA== Received: by 10.52.65.134 with SMTP id x6mr7290707vds.60.1334702419327; Tue, 17 Apr 2012 15:40:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Tue, 17 Apr 2012 15:39:37 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201204172234.q3HMY81B013863@fs4113.wdf.sap.corp> References: <201204172234.q3HMY81B013863@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Tue, 17 Apr 2012 15:39:37 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk2XDrwcgwTg3OVgHxSCgtP0Iu7mNBYryMJSf2WJbbHM2mbAaYX1iE0OvnLY9qUufqJ13K3 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 22:40:21 -0000 On Tue, Apr 17, 2012 at 3:34 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> I'm not sure I understand what you mean. Those markings are >> produced at the time the RFC is published, so they're not really >> contingent on future deployment results, but rather on the >> IETF's intentions. > > The purpose of that Marking is described in a document called > =A0rfc2223 "Instructions to RFC Authors". > > > In my ears, your argument sounds somewhat in the direction of: > > "I have been entirely ignoring the rfc2223 purpose of meta-data and > =A0(ab)used the Obsoletes: header to actively promote newer protocol > =A0versions and over older protocol versions ... and I want to continue > =A0ignoring rfc2223 and (ab)use the Obsoletes: header in that fashion. > =A0I do not care how much that (ab)use might confuse other readers > =A0of the affected RFCs." > > ... specifically readers that try to parse RFC meta-data > as OFFICIALLY specified by the IETF, i.e. according to rfc2223... > (which currently seems to apply to tools/IDNits and the RFC Editor). I can't speak for what it sounds like in your ears, but that's not what I'm saying. -Ekr From mrex@sap.com Tue Apr 17 16:31:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B211E80BD for ; Tue, 17 Apr 2012 16:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.08 X-Spam-Level: X-Spam-Status: No, score=-10.08 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aacIxKHClKJ7 for ; Tue, 17 Apr 2012 16:31:49 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A4FCB11E8086 for ; Tue, 17 Apr 2012 16:31:48 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3HNVadE018022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 01:31:36 +0200 (MEST) From: Martin Rex Message-Id: <201204172331.q3HNVZk6017160@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 18 Apr 2012 01:31:35 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 17, 12 03:39:37 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 23:31:53 -0000 Eric Rescorla wrote: > > On Tue, Apr 17, 2012 at 3:34 PM, Martin Rex wrote: > > Eric Rescorla wrote: > >> > >> I'm not sure I understand what you mean. Those markings are > >> produced at the time the RFC is published, so they're not really > >> contingent on future deployment results, but rather on the > >> IETF's intentions. > > > > The purpose of that Marking is described in a document called > >  rfc2223 "Instructions to RFC Authors". > > > > > > In my ears, your argument sounds somewhat in the direction of: > > > > "I have been entirely ignoring the rfc2223 purpose of meta-data and > >  (ab)used the Obsoletes: header to actively promote newer protocol > >  versions and over older protocol versions ... and I want to continue > >  ignoring rfc2223 and (ab)use the Obsoletes: header in that fashion. > >  I do not care how much that (ab)use might confuse other readers > >  of the affected RFCs." > > > > ... specifically readers that try to parse RFC meta-data > > as OFFICIALLY specified by the IETF, i.e. according to rfc2223... > > (which currently seems to apply to tools/IDNits and the RFC Editor). > > I can't speak for what it sounds like in your ears, but that's not what > I'm saying. But I fail to see any difference between what you're _implying_ and what the message that I'm getting. Please look at the WHOLE section 12 of rfc2223, that defines the two Headers Updates: & Obsoletes and their exact purpose: https://tools.ietf.org/html/rfc2223#section-12 12. Relation to other RFCs Sometimes an RFC adds information on a topic discussed in a previous RFC or completely replaces an earlier RFC. There are two terms used for these cases respectively, Updates and Obsoletes. A document that obsoletes an earlier document can stand on its own. A document that merely updates an earlier document cannot stand on its own; it is something that must be added to or inserted into the previously existing document, and has limited usefulness independently. The terms Supercedes and Replaces are no longer used. Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. Obsoletes To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, however extensive or brief that new information is; i.e., this document can be used alone, without reference to the older document. For example: On the Assigned Numbers RFCs the term Obsoletes should be used since the new document actually incorporate new information (however brief) into the text of existing information and is more up-to-date than the older document, and hence, replaces it and makes it Obsoletes. In lists of RFCs or the RFC-Index (but not on the RFCs themselves) the following may be used with early documents to point to later documents. Obsoleted-by To be used to refer to the newer document(s) that replaces the older document. Updated-by To be used to refer to the newer section(s) which are to be added to the existing, still used, document. Unless rfc-5246 *COMPLETELY*REPLACES* a document listed in Obsoletes: that information is factually wrong. CLEARLY. Should that _not_be_clear_ from rfc2223, then the IETF will need to choose a different language from English to specify standards, because it would make it impossible to write non-ambiguous technical specifications in a language where the above _is_not_clear_. -Martin From mrex@sap.com Tue Apr 17 18:59:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E8111E8086 for ; Tue, 17 Apr 2012 18:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.085 X-Spam-Level: X-Spam-Status: No, score=-10.085 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd3PCLUwY5rm for ; Tue, 17 Apr 2012 18:59:02 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D343521F84B6 for ; Tue, 17 Apr 2012 18:58:54 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3I1wfKp002694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Apr 2012 03:58:41 +0200 (MEST) From: Martin Rex Message-Id: <201204180158.q3I1weQn025522@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Wed, 18 Apr 2012 03:58:40 +0200 (MEST) In-Reply-To: <201204172331.q3HNVZk6017160@fs4113.wdf.sap.corp> from "Martin Rex" at Apr 18, 12 01:31:35 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: Re: [TLS] [Editorial Errata Reported] RFC5246 (3191) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 01:59:06 -0000 Reiterating on the relevant parts of rfc2223 and their meaning. rfc2223 says it is an Instruction from the RFC Editor to RFC authors about EDITORIAL issues (and not about technical issues). Martin Rex wrote: > > https://tools.ietf.org/html/rfc2223#section-12 > > 12. Relation to other RFCs > > Sometimes an RFC adds information on a topic discussed in a previous > RFC or completely replaces an earlier RFC. There are two terms used > for these cases respectively, Updates and Obsoletes. > > [...] > > Obsoletes > > To be used to refer to an earlier document that is replaced by > this document. This document contains either revised information, > or else all of the same information plus some new information, > however extensive or brief that new information is; i.e., this > document can be used alone, without reference to the older > document. There is an editorial reference to "the same or revised information" about the exact same thing, not a technical reference to a new protocol version. This is meant in the sense of SMTP rfc821 -> rfc2821 Internet message format rfc822 -> rfc2822 PKCS#1 rfc2313 -> rfc2437 -> rfc3447 in that the *new* document "completely replaces" the old document, and for independently creating an implementation that is fully interoperable with the installed base, the old document is no longer needed, it has been completely replaced by the new document. IPv4 -> IPv6 is *NOT* an obsoletion in the editorial sense of rfc2223. And while it _would_have_been_ possible (and IMHO valuable) for newer TLS protocol specs to fully include all of the previous procotol versions (greatly facilitating multi-TLS-version implementations), similar to the three examples above, this was _NOT_ done for rfc5246. rfc5246 describes TLSv1.2 exclusively, and among the things it lacks are the TLSv1.0 PRF, the TLSv1.0 ConnectionState, the TLSv1.0 GenericBlockCipher record PDU, the TLSv1.0 CertificateRequest PDU, and probably a few more things beyond the changed digitally-signed struct. If you look at the most recent IESG statement (about moving documents to "historic" status), http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html a guidance was added that sponsoring ADs should describe the intended purpose of any "Obsoletes:" indicater on new documents, which to _me_ looks like a realizatin that too little attention spent on such markers in the past, and since not all RFC author followed the editing guideline provided by the RFC Editor in rfc2223, RFCs might have gotten published with factually incorrect Obsoletes: headers in them. So while fixing the Obsoletes: meta-data on a document is a minor and purely editorial change to that document (and not a technical change), that marker does (per rfc2223 section 12) result in a technical statement about "the old document". The rfc2223 messsage is "The old document has become completely irrelevant to independent creation of interoperable implementations, it has been COMPLETELY REPLACED by the new document." -Martin From nico@cryptonector.com Tue Apr 17 21:20:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7D911E8095 for ; Tue, 17 Apr 2012 21:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0j9oPfEaqdu for ; Tue, 17 Apr 2012 21:20:49 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 33CF011E8076 for ; Tue, 17 Apr 2012 21:20:42 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 5B259286058 for ; Tue, 17 Apr 2012 21:20:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=U0WcssyezgNhW+2k2BPHkCVg4HSYS5ypOBapAptxsG/1 Umk5Vzfk4rCJF26y4e5AEKLhiRWFAjx+9nXFs1D0F3jzgH5drPSoeyrIVjz9Hg8f d17aN6rIgOh6jjtoop0UPu0LfrCzP2yVqD9WD95Y0g5QgrOTFKRbS7cCn1oMGos= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=4XTGEl7hJXKNt/KOYcHgJlvNmms=; b=p3da7ahvJON acCFFuydwoPE3Czz6lp3pRK6wQxGGdF3Alk67QKA4HfpRPfUG1rXDdMxVnQIZQ8v aK2g7ctHptbgRH+Ax7E2Ax/uTd1nK1P+3i+T23DRmJ3JcRzN0ODsNsRIS0rIuxzz z5d3R5ShwNiXXL5/Amu9UIEdGKjFmvkE= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 421DF286057 for ; Tue, 17 Apr 2012 21:20:41 -0700 (PDT) Received: by dady13 with SMTP id y13so12789593dad.27 for ; Tue, 17 Apr 2012 21:20:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr3080211pbb.13.1334722840888; Tue, 17 Apr 2012 21:20:40 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 17 Apr 2012 21:20:40 -0700 (PDT) In-Reply-To: <4F8DCBD4.6090104@pobox.com> References: <4F8DCBD4.6090104@pobox.com> Date: Tue, 17 Apr 2012 23:20:40 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: TLS Mailing List Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 04:20:55 -0000 On Tue, Apr 17, 2012 at 3:00 PM, Michael D'Errico wro= te: > A lot of people are pushing Google's SPDY protocol to improve web > performance; > however, it seems to rely on the Next Protocol Negotiation (NPN) extensio= n, > which does not appear to have been officially published as an RFC (the -0= 2 > draft expired in October 2011). > > RFC 5246 explains that all TLS extensions have to obtain IETF Consensus t= o > be > used on the Internet: > > =C2=A0 This document also uses a registry originally created in [RFC4366]= . > =C2=A0 IANA has updated it to reference this document. =C2=A0The registry= and its > =C2=A0 allocation policy (unchanged from [RFC4366]) is listed below: > > =C2=A0 - =C2=A0TLS ExtensionType Registry: Future values are allocated vi= a IETF > =C2=A0 =C2=A0 =C2=A0Consensus [RFC2434]. =C2=A0[...] > > NPN also adds a new handshake message to the TLS protocol, completely > bypassing > the required Standards Action to do so: > > =C2=A0 - =C2=A0TLS HandshakeType Registry: Future values are allocated vi= a > =C2=A0 =C2=A0 =C2=A0Standards Action [RFC2434]. > > Speeding up the web is certainly not evil, but a large player like Google > shouldn't be setting such a bad precedent w.r.t. the IETF process. I suspect they'd hardly be the first. In fact, it's happened in the context of Kerberos, where we've had some number camping happen. A few things worth pointing out: - There's no IETF standards compliance police. This isn't to say "go ahead and do what you like", rather, that the golden rule applies, and making nice matters, but we're also flexible, and if there's no other way to achieve something than by bending the rules, well, we don't have a police force to make sure you don't, so it does happen. I'm describing reality here. We can minimize camping by having liberal registration rules and protocols that allow for liberal registration rules. E.g., by not creating scarcity artificially; just say no to 8- and 16-bit fields! - The IETF is a volunteer organization, and it's also a sort of gatekeeping organization. If participants don't act in timely ways then they can't gatekeep effectively either. - I can't fault participants for working around the IETF in some cases. In this particular case I think the facts on the ground require some experimenting with real world deployment in order to gain the necessary experience. Specifically it's very hard to tell what will and what won't work as far TLS extensions go without actually trying to deploy them. For a good example see the post-mortem on False Start. Would it have been possible to obtain the necessary experience with TLS concentrators to know whether False Start was feasible *before* progressing the specification to the Standards Track? Almost certainly not. Would it have been possible to publish on the Experimental track first, then promoted to the Standards Track if it proved workable? Not if a registration were needed that required Standards Action! (Sure, the allocation could have been done separately from placing the extension on the Experimental track, but that means more time...) - TLS is extra special. It goes back a long time, it's got a colorful history. TLS (SSL!) specs lacked sufficient detail and review early on. TLS has been deployed in ways that leave the end-to-end model in tatters, specifically: with proxies on both ends, and potentially with more than one proxy on the client side. This makes interop testing harder than for most other protocols. Extending TLS is extra hard. Harder than TCP. - I think one lesson is that the most important protocols we have need detailed, sufficient specifications, and we need regular interop testing and implementors who are willing to fix their implementations. The latter can can be impossible to get in some cases (e.g., in the False Start case, where one implementor no longer has the staff on hand to fix a specific problem). The former can be addressed with review, more process, more timely updates. But the latter? No clue how to address the latter except by having had sufficiently detailed specs and enough interop testing from the get-go. Nico -- From mike-list@pobox.com Tue Apr 17 23:38:50 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EE21F8623 for ; Tue, 17 Apr 2012 23:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9L3UAE36Er6k for ; Tue, 17 Apr 2012 23:38:46 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id BD64021F861D for ; Tue, 17 Apr 2012 23:38:45 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 8C3C4AD6C; Wed, 18 Apr 2012 02:38:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=wp+2DPyNiY8Z o9C+Kf80skCUmso=; b=Aj6ZRAQPzuXHqa9Fj8gVAjkGpOoOnKolxwLEPFoUAeQg qcrG3Wbtka+tFlk9HdLbnCldUs0GFaLnzV7irrtaYWEyl5yXDNpPiZTWuR3seV8u 3iX14sXuTvk36QcYx81r2pxpkh5sQ3uPUYOCGtZMQvShnwRAiyETZHEEX8Cf7e0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=LvIkQb T/9BxQosTetGugjl2y/+dNGS5HrmDssNli7kqwParm/z9MKxYpfhLaqaF30qAxFE hWSMdoLfXXRY/qCW2EwBe03RQSBxUM8EdUr8Q09EN/BhTFDcmdb2u0BNSpZMHQtX odd68yazqkZX3/NgS61nzNuCjomyQahCnceYc= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 823A9AD6B; Wed, 18 Apr 2012 02:38:43 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id A9D2CAD6A; Wed, 18 Apr 2012 02:38:41 -0400 (EDT) Message-ID: <4F8E6170.6070501@pobox.com> Date: Tue, 17 Apr 2012 23:38:40 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <4F8DCBD4.6090104@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2368F794-8921-11E1-9CE0-B1B0728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: TLS Mailing List Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 06:38:51 -0000 I discovered the lack of specs because I went looking for information about how to implement SPDY. At this point there is wide deployment, so we can't do much beyond rubber-stamping what implementations are actually doing[*]. But having the existing behavior documented is very important to make sure implementations are interoperable, as you know. Sure I can sympathize with the need for Google to have experimented and chosen some private values, but now that they're pushing for wider adoption, it is their obligation to get those IANA assignments. Mike * which is a shame since there were valid objections to the way NPN was designed, and it could have been improved with a little effort.... Nico Williams wrote: > On Tue, Apr 17, 2012 at 3:00 PM, Michael D'Errico wrote: >> A lot of people are pushing Google's SPDY protocol to improve web >> performance; >> however, it seems to rely on the Next Protocol Negotiation (NPN) extension, >> which does not appear to have been officially published as an RFC (the -02 >> draft expired in October 2011). >> >> RFC 5246 explains that all TLS extensions have to obtain IETF Consensus to >> be >> used on the Internet: >> >> This document also uses a registry originally created in [RFC4366]. >> IANA has updated it to reference this document. The registry and its >> allocation policy (unchanged from [RFC4366]) is listed below: >> >> - TLS ExtensionType Registry: Future values are allocated via IETF >> Consensus [RFC2434]. [...] >> >> NPN also adds a new handshake message to the TLS protocol, completely >> bypassing >> the required Standards Action to do so: >> >> - TLS HandshakeType Registry: Future values are allocated via >> Standards Action [RFC2434]. >> >> Speeding up the web is certainly not evil, but a large player like Google >> shouldn't be setting such a bad precedent w.r.t. the IETF process. > > I suspect they'd hardly be the first. In fact, it's happened in the > context of Kerberos, where we've had some number camping happen. > > A few things worth pointing out: > > - There's no IETF standards compliance police. This isn't to > say "go ahead and do what you like", rather, that the golden > rule applies, and making nice matters, but we're also flexible, > and if there's no other way to achieve something than by > bending the rules, well, we don't have a police force to make > sure you don't, so it does happen. I'm describing reality here. > > We can minimize camping by having liberal registration rules > and protocols that allow for liberal registration rules. E.g., by > not creating scarcity artificially; just say no to 8- and 16-bit > fields! > > - The IETF is a volunteer organization, and it's also > a sort of gatekeeping organization. If participants don't act in > timely ways then they can't gatekeep effectively either. > > - I can't fault participants for working around the IETF in > some cases. In this particular case I think the facts on the > ground require some experimenting with real world > deployment in order to gain the necessary experience. > Specifically it's very hard to tell what will and what won't > work as far TLS extensions go without actually trying to > deploy them. For a good example see the post-mortem > on False Start. Would it have been possible to obtain the > necessary experience with TLS concentrators to know > whether False Start was feasible *before* progressing > the specification to the Standards Track? Almost > certainly not. Would it have been possible to publish on > the Experimental track first, then promoted to the Standards > Track if it proved workable? Not if a registration were > needed that required Standards Action! (Sure, the allocation > could have been done separately from placing the extension > on the Experimental track, but that means more time...) > > - TLS is extra special. It goes back a long time, it's got a > colorful history. TLS (SSL!) specs lacked sufficient > detail and review early on. TLS has been deployed in ways > that leave the end-to-end model in tatters, specifically: with > proxies on both ends, and potentially with more than one > proxy on the client side. This makes interop testing harder > than for most other protocols. > > Extending TLS is extra hard. Harder than TCP. > > - I think one lesson is that the most important protocols we > have need detailed, sufficient specifications, and we need > regular interop testing and implementors who are willing to > fix their implementations. The latter can can be impossible > to get in some cases (e.g., in the False Start case, where > one implementor no longer has the staff on hand to fix a > specific problem). The former can be addressed with > review, more process, more timely updates. But the latter? > No clue how to address the latter except by having had > sufficiently detailed specs and enough interop testing from > the get-go. > > Nico > -- > > From jsalowey@cisco.com Wed Apr 18 13:42:14 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59F611E8097 for ; Wed, 18 Apr 2012 13:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHO7f-cX+27d for ; Wed, 18 Apr 2012 13:42:10 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE021F83EF for ; Wed, 18 Apr 2012 13:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1457; q=dns/txt; s=iport; t=1334781730; x=1335991330; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tGyqBhVdNJ62ZRhnPiV2UzAXSQdlaXa1/xPSMO4kCPI=; b=CsUY3JDnLwOFBaUv+K5/FprFSqYYx43YJOgdDKYNEkkjiDJDTATQy7/g fqyw7lf4kW8VqSoOBDwhrneujNMbCUR+NLG7+IyH7F75sxJOJ1wb8i9zZ yKe+pdpe+p5Lz0Rh+kO4lwzif7FrdFhYeT3oMK+cKcudBvl/EnpZsXfU7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicGAEQmj0+rRDoI/2dsb2JhbAA6CoMcriWBB4IJAQEBAwEBAQEPASc0CwULCxguJzAGEyKHaAQMmnGgIwSKYIRyYwSIXI0ThXOIXoFpgwc X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="41154052" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 18 Apr 2012 20:42:10 +0000 Received: from [10.33.248.190] ([10.33.248.190]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3IKg8P6002941; Wed, 18 Apr 2012 20:42:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Wed, 18 Apr 2012 13:42:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> <01c901cd1801$9cff3fa0$d6fdbee0$@augustcellars.com> To: Paul Wouters X-Mailer: Apple Mail (2.1084) Cc: Jim Schaad , tls@ietf.org Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:42:15 -0000 Hi Paul, Can you submit an updated draft with the clarification that support for = client auth is only through SPKI lookups? Then we can take the draft to = WGLC. =20 Thanks, Joe =20 On Apr 11, 2012, at 11:10 AM, Paul Wouters wrote: > On Wed, 11 Apr 2012, Jim Schaad wrote: >=20 >>> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already >>> removed there after discussion with EKR in Quebec City. >>=20 >> If this is really what you want to do, then I would suggest that the >> document be expanded so that there exists the possibility to include = an >> identifier and/or a public key in the certificate form defined by the = oob >> document. >=20 > Personall, I strongly prefer not adding more fields to the bare key = certificate > type, as those people who want to cover client authentication can use > full PKIX certs already, and TLS client authentication in the wild = seems > to be extremely rare. The only two cases I knew are CAcert and Fedora > (and for the latter it does not even add security, as I need to = identify > with another factor anyway (yubikey)) >=20 > Is there an actual use case where bare keys would be preferable over > full PKIX, that also include client auth not based on burned in keys > covered by server side SPKI lookups? >=20 > Paul > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ekr@rtfm.com Wed Apr 18 14:03:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D536811E80CF for ; Wed, 18 Apr 2012 14:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAvrIVJp7Pgc for ; Wed, 18 Apr 2012 14:03:02 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7A11E80C0 for ; Wed, 18 Apr 2012 14:03:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6101091vbb.31 for ; Wed, 18 Apr 2012 14:03:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=u77EiqG89RS7mNgMlmHz8OQAGlzcERcdO/tD+xW2xBg=; b=W9r5YLaKdLdMfKr/FoFsX9vfy8n4KSd67/l+0ZKiuWiT9DdRiKDKmx7LVkZfhYYh7x REywAIKLdUSYb7SA3pGUf4qSc5snNiHMLKHwAeYwBqk+5LhOthU0/YVAF4czrP9/3NyD JrjGVtOb0C3qrx//UUIWL3X4GBWIY+jZ/kogmUAUAlxR+VaucvM+inbua/ivk1Ep4yKZ PRA1kCOQNLUYv85Nc146FS0muLg7wjh9Bxayz6VSBT10bfolVy3H60de5n9wH3qcCZfs jwZbDQv+/gdc7UPEO/AHIvpYqOZwW/qtzKTHfjEDAk0HP8mUi+FG0dAWMZya6NY25AxP DQCA== Received: by 10.220.106.144 with SMTP id x16mr1930192vco.63.1334782982192; Wed, 18 Apr 2012 14:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Wed, 18 Apr 2012 14:02:22 -0700 (PDT) X-Originating-IP: [63.245.220.224] From: Eric Rescorla Date: Wed, 18 Apr 2012 17:02:22 -0400 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlJGRFfiNAvglR7wzeVdM+J9rf734ZqJgPYW0wv7Jhoh4yObPJKVGN8B7mCWqdE9Vubf/uZ Subject: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 21:03:07 -0000 WG members, At the meeting in Paris there was broad consensus to adopt Yngve's TLS Multi-Stapling draft (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt). The WG chairs would like to confirm this consensus. Please send any comments by Wednesday April 25. -Ekr [For the chairs] From Jeff.Hodges@KingsMountain.com Wed Apr 18 16:33:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADF21F84AA for ; Wed, 18 Apr 2012 16:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.006 X-Spam-Level: X-Spam-Status: No, score=-99.006 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE2WCzmyCj97 for ; Wed, 18 Apr 2012 16:33:45 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 5346111E808C for ; Wed, 18 Apr 2012 16:33:45 -0700 (PDT) Received: (qmail 22713 invoked by uid 0); 18 Apr 2012 23:33:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 18 Apr 2012 23:33:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Sjc757/VyrPepI7ePwNsNs2bnVtFYxY7BwEXWppI4Us=; b=U3CVGm986PN/Eol822opMmWHQ3hPp6frEk6rQ8N+/RjzUua/FTtP5lZNCfeFwXGJpUiOMfBd7BokJ9gOsBOICxND7POoCpme9+DOmdJsGt7aatT8D6PpYVb2JwEHbOHw; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.216]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SKeNc-0001fS-Oy for tls@ietf.org; Wed, 18 Apr 2012 17:33:44 -0600 Message-ID: <4F8F4F5A.1070300@KingsMountain.com> Date: Wed, 18 Apr 2012 16:33:46 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: IETF TLS WG 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: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 23:33:49 -0000 I support adopting draft-pettersen-tls-ext-multiple-ocsp as a working group item. =JeffH From aerowolf@gmail.com Wed Apr 18 18:06:45 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA011E80AD for ; Wed, 18 Apr 2012 18:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoXWJ8YYbYZA for ; Wed, 18 Apr 2012 18:06:40 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7112911E809D for ; Wed, 18 Apr 2012 18:06:38 -0700 (PDT) Received: by bkuw5 with SMTP id w5so7366651bku.31 for ; Wed, 18 Apr 2012 18:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hxJnsmElDfDXNPm4678EOQOzC6201ADPj4O2URlMa/g=; b=AuonCnxzMsrpvkfnf2vgbYx1LAsarAV7JzqKvRFG5/sJwlsJDPhaQRW2w6P6uUKEou Q2qTh57eD5CotyM8D/Cdt7hJwJHqW+Pc2kDYD+QRC9qLtcj/lJiUlM4F6ZybE1TCFq4w v4uyFoagH26G0BbLUX/ePoE0rJFr1YwfsjWkB+bE/2+ZQ4+JAE87+EeFjDk9Ln9Zpynj /vZWt7BWX3OZcZX+UJyBCAPWF91ZJNisdu2PeD1hYaFiGliTrZSRytGe1ew4DXHHXpsm CTeTgZjRS1RVXvBees5w9GP5qkBBlTPdlrGRYclpKE42nrUGWJFLvgwv3f0+HNaA3fDD 7nHA== MIME-Version: 1.0 Received: by 10.204.156.141 with SMTP id x13mr33204bkw.50.1334797597369; Wed, 18 Apr 2012 18:06:37 -0700 (PDT) Received: by 10.204.17.70 with HTTP; Wed, 18 Apr 2012 18:06:37 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Apr 2012 18:06:37 -0700 Message-ID: From: Kyle Hamilton To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:06:45 -0000 On Wed, Apr 18, 2012 at 2:02 PM, Eric Rescorla wrote: > WG members, > > At the meeting in Paris there was broad consensus to adopt Yngve's > TLS Multi-Stapling draft > (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt). > > The WG chairs would like to confirm this consensus. Please send any > comments by Wednesday April 25. I believe that this is improper for TLS-WG to take up. The problem that multi-stapling is intended to address can be done completely within an X.509 self-signed structure, and derives from PKIX-WG not producing a single coherent standard that client protocols can simply plug in. Trying to work around a PKIX-WG problem in TLS is not going to solve the same types of problems that exist in all other PKIX client protocols. If PKIX-WG could get its collective head out of its... darkness... I'd say push this over there, and force them to come up with a real single atomic credential format that can securely support asserting multiple certificate chains, stapled OCSP responses for ALL certificates in ALL chains, multiple timestamps... basically, TLS has one place to assert one keypair. All we need is a signature chain (or multiple signature chains) to say that someone (an identified X.509 principal, not an X.509 device) actually *gasp* used their own authority to assign a key to a device. That we can't do this is a bug in PKIX, not a bug in TLS. That we can't get multiple certificate status responses in a single structure is a failure of PKIX, not TLS. Working around it in TLS-WG is inefficient, and will not solve the same problem in other PKIX client protocols. Unfortunately, because PKIX-WG can't/won't do anything because everybody's too afraid of changing the status quo, this seems to be the only effective option that presents. I would prefer that it not be handled here, but since the problem in PKIX (which won't change) is exposed by TLS... I (grudgingly) shall support this, with many reservations. -Kyle H From mrex@sap.com Wed Apr 18 18:45:52 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62211E80B0 for ; Wed, 18 Apr 2012 18:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.093 X-Spam-Level: X-Spam-Status: No, score=-10.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAMS8Vqklm8e for ; Wed, 18 Apr 2012 18:45:48 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D075F11E80AD for ; Wed, 18 Apr 2012 18:45:47 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3J1jj36018717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 03:45:45 +0200 (MEST) From: Martin Rex Message-Id: <201204190145.q3J1jff6015899@fs4113.wdf.sap.corp> To: aerowolf@gmail.com (Kyle Hamilton) Date: Thu, 19 Apr 2012 03:45:41 +0200 (MEST) In-Reply-To: from "Kyle Hamilton" at Apr 18, 12 06:06:37 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:45:52 -0000 Kyle Hamilton wrote: > > Eric Rescorla wrote: > > > > At the meeting in Paris there was broad consensus to adopt Yngve's > > TLS Multi-Stapling draft > > (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt). > > > > The WG chairs would like to confirm this consensus. Please send any > > comments by Wednesday April 25. > [quotations rearranged from Kyle's original response] > > I (grudgingly) shall support this, with many reservations. I support adopting the work. > > I believe that this is improper for TLS-WG to take up. The problem > that multi-stapling is intended to address can be done completely > within an X.509 self-signed structure, and derives from PKIX-WG not > producing a single coherent standard that client protocols can simply > plug in. Trying to work around a PKIX-WG problem in TLS is not going > to solve the same types of problems that exist in all other PKIX > client protocols. This was a _known_ characteristic/shortcoming of X.509/PKIX when it was (re-)used by SSLv3 and carried through to TLSv1.0, that revocation checking was designed strictly out-of-band. Originally CRLs, OCSP & SCVP were later defined as alternative mechanisms, but similarly out-of-band. Therefore I consider it INappropriate to blame X.509 for what it is (even though I dislike this property of the X.509 architecture myself). There are huge benefits associated with the multiple OCSP-responses stapling, obviating the RP from additional third-party communication in order to verify the TLS peer's certificate (chain), and protecting the RPs privacy. On top of this, the credential holder is in the best position to ensure an efficiently accessible OCSP responder for his own certificate (chain), efficiently cache OCSP responses for his own cert (chain) and to refresh them out-of-band. > > That we can't do this is a bug in PKIX, not a bug in TLS. That we > can't get multiple certificate status responses in a single structure > is a failure of PKIX, not TLS. Working around it in TLS-WG is > inefficient, and will not solve the same problem in other PKIX client > protocols. Actually, I believe just the opposite. While CRL suffers from a design defect that can result in real world security vulnerability, the OCSP design and the narrow set of acceptable signer certs is a _huge_ improvement over CRLs, without that CRL signer design flaw. -Martin From peter.robinson@rsa.com Wed Apr 18 18:52:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6334911E80AD for ; Wed, 18 Apr 2012 18:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aWRVTpk5gAO for ; Wed, 18 Apr 2012 18:52:35 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7FE21F841C for ; Wed, 18 Apr 2012 18:52:34 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3J1qXgW030898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 18 Apr 2012 21:52:33 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 18 Apr 2012 21:52:20 -0400 Received: from mxhub09.corp.emc.com (mxhub09.corp.emc.com [10.254.92.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3J1qKOf027272 for ; Wed, 18 Apr 2012 21:52:20 -0400 Received: from mx34a.corp.emc.com ([169.254.1.228]) by mxhub09.corp.emc.com ([10.254.92.104]) with mapi; Wed, 18 Apr 2012 21:52:20 -0400 From: To: Date: Wed, 18 Apr 2012 21:52:18 -0400 Thread-Topic: [TLS] Call for acceptance on multi-stapling Thread-Index: Ac0dpr334FRCCtT5TD2uCdsYfEgepwAKEDuw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:52:39 -0000 I support adopting draft-pettersen-tls-ext-multiple-ocsp as a working group= item. ------------------------------------------------ Peter Robinson - peter.robinson@rsa.com Engineering Manager RSA, The Security Division of EMC - http://www.rsa.com/ Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, AUST= RALIA. Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.=20 From nico@cryptonector.com Wed Apr 18 20:01:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7EB11E80B6 for ; Wed, 18 Apr 2012 20:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyRprxK38rO9 for ; Wed, 18 Apr 2012 20:01:51 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8455A11E80B2 for ; Wed, 18 Apr 2012 20:01:51 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by hapkido.dreamhost.com (Postfix) with ESMTP id 93B6C17ABFB for ; Wed, 18 Apr 2012 19:27:10 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 4E507438079 for ; Wed, 18 Apr 2012 19:26:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=w65OLRqBf4Folv6yNZb17Iws13awhuGnQ4TPjfgvfZP2 t9ZsSfN0FHreAHKCzWyA+V2VCrr0uXoh8BordMZfUAKjBtlX58b6YY5F4YGG0JI9 x+CH4zPWGTh2E0eIxZHagy9xKUaisQKEflJ2AZdnGrdciXPq4ZSZCQnxjW9fd+A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Z8hoNqguimt2JPccY0h9tuP1B8U=; b=h2dwrF2NtUC 8zrhZIoirYmaAMmCBEk/uyrfa/JrBqKnuhE73/A6D9BmZy9u58WEh2i0+7D3UcS5 b9VDcI7E5Uc5SA1vViTvdKnSqgRwH62hlBv/EwSqFceiLie6wntxBCO8NL88JLhk W19P7eqXlVhL2fMsEmWahCavvUpLfxMY= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 35A7743806C for ; Wed, 18 Apr 2012 19:26:18 -0700 (PDT) Received: by dady13 with SMTP id y13so14674004dad.27 for ; Wed, 18 Apr 2012 19:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.71 with SMTP id ic7mr1135733pbc.34.1334802377897; Wed, 18 Apr 2012 19:26:17 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 19:26:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Apr 2012 21:26:17 -0500 Message-ID: From: Nico Williams To: Kyle Hamilton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:01:55 -0000 On Wed, Apr 18, 2012 at 8:06 PM, Kyle Hamilton wrote: > I believe that this is improper for TLS-WG to take up. =C2=A0The problem > that multi-stapling is intended to address can be done completely > within an X.509 self-signed structure, and derives from PKIX-WG not > producing a single coherent standard that client protocols can simply > plug in. =C2=A0Trying to work around a PKIX-WG problem in TLS is not goin= g > to solve the same types of problems that exist in all other PKIX > client protocols. Self-signed structure? No. If freshness indication is to be solved via PKIX then it has to be backwards compatible with existing relying parties' certificate validation code. The obvious solution is to have online CAs issuing short-lived certs to systems that posses the corresponding long-lived cert, with the online CAs having different keys from the issuers of the long-lived certs (of course). I'd be quite happy with such a scheme. Much happier than with OCSP response stapling, and much, much happier than with a solution based on self-signed certs that [presumably] hold the real cert and OCSP responses. Nico -- From mrex@sap.com Wed Apr 18 20:21:23 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608F711E8089 for ; Wed, 18 Apr 2012 20:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.096 X-Spam-Level: X-Spam-Status: No, score=-10.096 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lBgBSQXWnaQ for ; Wed, 18 Apr 2012 20:21:22 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id E665E11E8086 for ; Wed, 18 Apr 2012 20:21:21 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3J3LHno005996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 05:21:17 +0200 (MEST) From: Martin Rex Message-Id: <201204190321.q3J3LG35021433@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Thu, 19 Apr 2012 05:21:16 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 18, 12 09:26:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:21:23 -0000 Nico Williams wrote: > > On Wed, Apr 18, 2012 at 8:06 PM, Kyle Hamilton wrote: > > I believe that this is improper for TLS-WG to take up.  The problem > > that multi-stapling is intended to address can be done completely > > within an X.509 self-signed structure, and derives from PKIX-WG not > > producing a single coherent standard that client protocols can simply > > plug in.  Trying to work around a PKIX-WG problem in TLS is not going > > to solve the same types of problems that exist in all other PKIX > > client protocols. > > Self-signed structure? No. If freshness indication is to be solved > via PKIX then it has to be backwards compatible with existing relying > parties' certificate validation code. The obvious solution is to have > online CAs issuing short-lived certs to systems that posses the > corresponding long-lived cert, with the online CAs having different > keys from the issuers of the long-lived certs (of course). > > I'd be quite happy with such a scheme. Much happier than with OCSP > response stapling, and much, much happier than with a solution based > on self-signed certs that [presumably] hold the real cert and OCSP > responses. I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely precludes cert pinning, a scheme that is magnitudes more secure than the existing Alzheimer approach of to identifying servers with zero prior knowledge over and over and over again. -Martin From ekr@rtfm.com Wed Apr 18 20:27:04 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEE611E80B6 for ; Wed, 18 Apr 2012 20:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-mT9F-Gdhfg for ; Wed, 18 Apr 2012 20:27:00 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A81411E80B5 for ; Wed, 18 Apr 2012 20:27:00 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6285006vbb.31 for ; Wed, 18 Apr 2012 20:26:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=khb86hhTDbNUYv4Msc8s9xJWVMnfoD/vfh3gopNsbsU=; b=CCUw9E6uEGiuAR88jvM0Ix4D49HuoM82m6NxYGNxDgo6VtaQZ4Rb0j+pj/oPtuSx29 otLvBmD8S3kyF8QWipD1yVkhs1TtnqV9kGBBcqnRdo205zvKBxmji7okS5vf3Ebzr8/P 0TBzsWR6iB5G7zMqqfeGs7Pl4c8pW4NGYsEKAzYnynhqdM6jo5LwsMu1rDil3tcF/OF5 Fe55BXynlOU87FxjeJMxJ4rkE0hPMhomvisc4YX9lzyx8gD3ysN1x94g8AXTCAeprZO5 3ZSQPKLA/GQayIVQMz0CiXsvLR/VmRxwgyQTAMdO6Jxw1LIBrrAK/oP4zDLGJTG00VxJ opTA== Received: by 10.52.65.134 with SMTP id x6mr198409vds.60.1334806019758; Wed, 18 Apr 2012 20:26:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Wed, 18 Apr 2012 20:26:19 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201204190321.q3J3LG35021433@fs4113.wdf.sap.corp> References: <201204190321.q3J3LG35021433@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 18 Apr 2012 20:26:19 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQms9n6IgsHARZoHDjvv4azGjtNMOIBHQeT6cTlpVHneQIS5ZApXgd8aGwiJgtoyS8vdGF4g Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:27:04 -0000 On Wed, Apr 18, 2012 at 8:21 PM, Martin Rex wrote: > Nico Williams wrote: >> >> On Wed, Apr 18, 2012 at 8:06 PM, Kyle Hamilton wrot= e: >> > I believe that this is improper for TLS-WG to take up. =C2=A0The probl= em >> > that multi-stapling is intended to address can be done completely >> > within an X.509 self-signed structure, and derives from PKIX-WG not >> > producing a single coherent standard that client protocols can simply >> > plug in. =C2=A0Trying to work around a PKIX-WG problem in TLS is not g= oing >> > to solve the same types of problems that exist in all other PKIX >> > client protocols. >> >> Self-signed structure? =A0No. =A0If freshness indication is to be solved >> via PKIX then it has to be backwards compatible with existing relying >> parties' certificate validation code. =A0The obvious solution is to have >> online CAs issuing short-lived certs to systems that posses the >> corresponding long-lived cert, with the online CAs having different >> keys from the issuers of the long-lived certs (of course). >> >> I'd be quite happy with such a scheme. =A0Much happier than with OCSP >> response stapling, and much, much happier than with a solution based >> on self-signed certs that [presumably] hold the real cert and OCSP >> responses. > > I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely > precludes cert pinning, a scheme that is magnitudes more secure than the > existing Alzheimer approach of to identifying servers with zero prior > knowledge over and over and over again. Short-lived certs aren't a problem if you pin by public key, as in: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 -Ekr From nico@cryptonector.com Wed Apr 18 20:38:04 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A6711E807F for ; Wed, 18 Apr 2012 20:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VwxsRFAdlSW for ; Wed, 18 Apr 2012 20:38:00 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 68BD511E8075 for ; Wed, 18 Apr 2012 20:38:00 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 0AE08768061 for ; Wed, 18 Apr 2012 20:38:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=OqZbSWOPXOwcG2MRFA4cRFjBVQcQXA1X0GxOUsrAUgVI OrUhs1B3OJtoEWd029C2jHG60nUbA85+Bx8tarN2h4EKn8DL9R+KSIVYHe2iqJAm az89P7phigywrxaftCsvaR8KUfGrrLxCjqN64qb+whVjNCS0KKVg/+eiaPp0x6o= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Y1ZrDKUhkYiw0xQCYNZ20+zghu4=; b=eDkh5oBzqsr tbu0mUeCcvXTZW3KyudHqgcYA8ycSy9jVbskgjAK6hb8V4dVFLq1EepKDulplurz QmYsw/iVg2rlTgp7hr3LENYA/3sVTIujTm+iBiW1O7dsSe8K6b7jXsGQL/F2OtMb Vphq9SkrN0viiPuEK6MSbiZ4TeH4oMPk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id E631F76805C for ; Wed, 18 Apr 2012 20:37:59 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7653993pbb.31 for ; Wed, 18 Apr 2012 20:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.35 with SMTP id gv3mr1344853pbc.160.1334806679522; Wed, 18 Apr 2012 20:37:59 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 20:37:59 -0700 (PDT) In-Reply-To: <201204190321.q3J3LG35021433@fs4113.wdf.sap.corp> References: <201204190321.q3J3LG35021433@fs4113.wdf.sap.corp> Date: Wed, 18 Apr 2012 22:37:59 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:38:04 -0000 On Wed, Apr 18, 2012 at 10:21 PM, Martin Rex wrote: > Nico Williams wrote: >> I'd be quite happy with such a scheme. =C2=A0Much happier than with OCSP >> response stapling, and much, much happier than with a solution based >> on self-signed certs that [presumably] hold the real cert and OCSP >> responses. > > I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely > precludes cert pinning, a scheme that is magnitudes more secure than the > existing Alzheimer approach of to identifying servers with zero prior > knowledge over and over and over again. Why would it prevent cert pinning? Sure, you couldn't pin a hash of the cert. You'd have to pin one or more of: the subject public key, the subject name and issuer, or both. Nico -- From mrex@sap.com Wed Apr 18 20:56:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A8F21F8447 for ; Wed, 18 Apr 2012 20:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.103 X-Spam-Level: X-Spam-Status: No, score=-10.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQysE1-MTdvj for ; Wed, 18 Apr 2012 20:56:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0177521F8446 for ; Wed, 18 Apr 2012 20:56:33 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3J3uTX8001213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 05:56:29 +0200 (MEST) From: Martin Rex Message-Id: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 19 Apr 2012 05:56:28 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 18, 12 08:26:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:56:38 -0000 Eric Rescorla wrote: > > Martin Rex wrote: > > > > I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely > > precludes cert pinning, a scheme that is magnitudes more secure than the > > existing Alzheimer approach of to identifying servers with zero prior > > knowledge over and over and over again. > > Short-lived certs aren't a problem if you pin by public key, as in: > http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 Credential management operations on the server are quite risky for the availabilty of the server. I doubt that I would ever implement something like that for our server (and refuse to do maintenance/support for such an architecture). If there is some change on the CA that makes the resulting short-lived server certs inacceptable (be it to clients or to responible servers that check credentials before trying to use them) and *ALL* production server depending on the CA will come to a grinding halt. Given how complex PKIX/X.509 is and how crappy the CA software is (boldly issuing certs with invalid or inconsistent content), such a scheme would be IMO screaming for trouble. -Martin From ekr@rtfm.com Wed Apr 18 21:04:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8111E80B3 for ; Wed, 18 Apr 2012 21:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.784 X-Spam-Level: X-Spam-Status: No, score=-102.784 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqOrmxZUj2ZM for ; Wed, 18 Apr 2012 21:04:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0735411E807F for ; Wed, 18 Apr 2012 21:04:37 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1743220vcb.31 for ; Wed, 18 Apr 2012 21:04:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=R19yqjUGouNiPjO9W1YR2fRPTU78hYqKETylUtUKIDU=; b=pVjNaYxVC+iKPb6Qx87G4M/2zEihH9O4A07OkXPowKRjFRSc2b6CLXio2Q5omY2EW2 CEbq6Mbr+FIzOH1fJrUSXKy5koJ6LJD8O49T3LCH3mWA6Wfb6B0u/hyQgG2fGPkDPrNu 7vPMjQyctfrmHa0hKPHH2QEZ5p3KV3UnqJtBTCoA5bvLouyGLJCvedjNhD+wBNjrBAtf 0uZxU3fpMNI6qh6LCXLrJSgBYO0c8EwIxIB9eNpMQgPZzK5kQ5VL+/Jw7K4mDWF5PyIb y8aVnOCEFnE/c1v9oTDmb6gCeBFw/eRpZWGD4ZexiJFrUZ1u86wPn0EyRXmyRPtE7+YF X9zA== Received: by 10.220.57.205 with SMTP id d13mr275013vch.53.1334808277335; Wed, 18 Apr 2012 21:04:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Wed, 18 Apr 2012 21:03:57 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 18 Apr 2012 21:03:57 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl2CYzbFMpJn2I6xMd6Z4QMBrTN7BTAZkmpHxvX+ac205fSMT1WN+U1scPK2lQAvAXLLxm7 Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:04:42 -0000 On Wed, Apr 18, 2012 at 8:56 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> Martin Rex wrote: >> > >> > I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely >> > precludes cert pinning, a scheme that is magnitudes more secure than t= he >> > existing Alzheimer approach of to identifying servers with zero prior >> > knowledge over and over and over again. >> >> Short-lived certs aren't a problem if you pin by public key, as in: >> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 > > Credential management operations on the server are quite > risky for the availabilty of the server. =A0I doubt that I would > ever implement something like that for our server (and refuse > to do maintenance/support for such an architecture). > > If there is some change on the CA that makes the resulting short-lived > server certs inacceptable (be it to clients or to responible servers > that check credentials before trying to use them) and *ALL* production > server depending on the CA will come to a grinding halt. > > Given how complex PKIX/X.509 is and how crappy the CA software is > (boldly issuing certs with invalid or inconsistent content), > such a scheme would be IMO screaming for trouble. What I meant was that it wasn't an issue for cert pinning. Sorry if that wasn't clear from the context. That said, 1. I think you're somewhat overstating the case here: a reasonable server will check rather before the short-lived cert expires, giving you some time to detect errors and correct them. 2. It's not clear to me that this is a significantly worse set of problems than OCSP stapling; for OCSP stapling to work correctly, it has to be hard fail on the client and so bogus OCSP responses will also bring all such production servers to a grinding halt. -Ekr From nico@cryptonector.com Wed Apr 18 21:26:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D9311E80B0 for ; Wed, 18 Apr 2012 21:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kzNqE4sbO2z for ; Wed, 18 Apr 2012 21:26:36 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 75D0A11E8075 for ; Wed, 18 Apr 2012 21:26:36 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 489519406D for ; Wed, 18 Apr 2012 21:26:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=TTuVcz/oUtsUhHn0UP5mV6e69agpBf8R0wg54DmRMibZ G1PEKSidGjE8+uGiPzIUcF1GRLM8dtNXW134OoYZkyeQfdVliV/EQjqJ9czXUXPG F/QqC7/MiT+yYdpC2JDmxGbbHhRItmcSAnNZhpbrKpl5m5Tn4AGMUDGYHzm75EI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=C+HlzAyGEkYVFiV5x3hEM300BSE=; b=DuBnDL2iw4P KfwKtLk70bJYgV7+DOJ9fDKOmoKZjYpH/v6t4qxpM/UFJepnVJVpSQCDqRKczQbX hlP3VuBUBh1GM9lRLy6rUctMbGWA0boJvIT4jTnqEXqh5KFFSTD/86lS7k1u+9jN 6rheMMDy/cVCqMF+9eV7prRDAAhuYVw4= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 2F1089405E for ; Wed, 18 Apr 2012 21:26:36 -0700 (PDT) Received: by dady13 with SMTP id y13so14823937dad.27 for ; Wed, 18 Apr 2012 21:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.35 with SMTP id gv3mr1651573pbc.160.1334809595676; Wed, 18 Apr 2012 21:26:35 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 21:26:35 -0700 (PDT) In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> Date: Wed, 18 Apr 2012 23:26:35 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:26:40 -0000 On Wed, Apr 18, 2012 at 11:03 PM, Eric Rescorla wrote: > On Wed, Apr 18, 2012 at 8:56 PM, Martin Rex wrote: >> Eric Rescorla wrote: >>> >>> Martin Rex wrote: >>> > >>> > I'd be EXTREMELY UNHAPPY with short-lived certs, because it entirely >>> > precludes cert pinning, a scheme that is magnitudes more secure than = the >>> > existing Alzheimer approach of to identifying servers with zero prior >>> > knowledge over and over and over again. >>> >>> Short-lived certs aren't a problem if you pin by public key, as in: >>> http://tools.ietf.org/html/draft-ietf-websec-key-pinning-01 >> >> Credential management operations on the server are quite >> risky for the availabilty of the server. =C2=A0I doubt that I would >> ever implement something like that for our server (and refuse >> to do maintenance/support for such an architecture). >> >> If there is some change on the CA that makes the resulting short-lived >> server certs inacceptable (be it to clients or to responible servers >> that check credentials before trying to use them) and *ALL* production >> server depending on the CA will come to a grinding halt. >> >> Given how complex PKIX/X.509 is and how crappy the CA software is >> (boldly issuing certs with invalid or inconsistent content), >> such a scheme would be IMO screaming for trouble. > > What I meant was that it wasn't an issue for cert pinning. Sorry if > that wasn't clear from the context. > > That said, > 1. I think you're somewhat overstating the case here: a reasonable > server will check rather before the short-lived cert expires, giving > you some time to detect errors and correct them. > > 2. It's not clear to me that this is a significantly worse set of problem= s > than OCSP stapling; for OCSP stapling to work correctly, it has to > be hard fail on the client and so bogus OCSP responses will also > bring all such production servers to a grinding halt. +1. Also, the cert needn't be short-lived so much as fresh (recently issued). Of course, we don't want online CAs issuing long-lived certs, and to make up for their being online we must be prepared to revoke them frequently, which means we still have a headache for cert lifetime trade-off. Still, if OCSP responses need to be fresh within 10 minutes, having short-lived certs live up to 24 hours but be refreshed every ten minutes would probably work well enough. Nico -- From mrex@sap.com Wed Apr 18 21:38:17 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BD121F8460 for ; Wed, 18 Apr 2012 21:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.107 X-Spam-Level: X-Spam-Status: No, score=-10.107 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9wx6eRCfTis for ; Wed, 18 Apr 2012 21:38:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3852221F845F for ; Wed, 18 Apr 2012 21:38:14 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3J4cAvx006259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 06:38:10 +0200 (MEST) From: Martin Rex Message-Id: <201204190438.q3J4c6Nu025658@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 19 Apr 2012 06:38:06 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 18, 12 09:03:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:38:17 -0000 Eric Rescorla wrote: > > Martin Rex wrote: >> >> Credential management operations on the server are quite >> risky for the availabilty of the server.  I doubt that I would >> ever implement something like that for our server (and refuse >> to do maintenance/support for such an architecture). >> >> If there is some change on the CA that makes the resulting short-lived >> server certs inacceptable (be it to clients or to responible servers >> that check credentials before trying to use them) and *ALL* production >> server depending on the CA will come to a grinding halt. >> >> Given how complex PKIX/X.509 is and how crappy the CA software is >> (boldly issuing certs with invalid or inconsistent content), >> such a scheme would be IMO screaming for trouble. > > What I meant was that it wasn't an issue for cert pinning. Sorry if > that wasn't clear from the context. > > That said, > 1. I think you're somewhat overstating the case here: a reasonable > server will check rather before the short-lived cert expires, giving > you some time to detect errors and correct them. 24/7 availability of server admins for each and every important server in a company. That is creating lots of new jobs. But the resulting TCO might make it a hard sell. > > 2. It's not clear to me that this is a significantly worse set of problems > than OCSP stapling; for OCSP stapling to work correctly, it has to > be hard fail on the client and so bogus OCSP responses will also > bring all such production servers to a grinding halt. OCSP stapling has the big advantage that things works pretty much exactly like they do now. Hard fail is not necessary, especially not for the absence of the stapling. The server can get and check the OCSP responses before updating what it inserts as a black box into ServerHelloExtension. And even if something goes wrong on the server with the OCSP response renewal, clients that have a necessity to continue have three options available: - try to obtain OCSP responses themselves - try to work from CRLs instead - do their very own risk management about how old OCSP responses or CRLS they want to tolerate. I would not be surprised if it's more than a magnitude easier to (accidentally) cause a CA cert issuance malfunction than to cause an OCSP server response malfunction by adminstrative action. And while being soft about revocation is not uncommon, being soft about cert expiration would be (and not alternatives possible). If the software components involved in the usage scenarios (CA software, servers, clients) are all from different vendors/suppliers, then allegedly small changes can easily break things that that the changing supplier didn't foresee (or care). *I* would not even dare shipping something that brittle even for a single supplier solution when 24/7 availabilty is important, -Martin From mrex@sap.com Wed Apr 18 21:43:29 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737F711E8089 for ; Wed, 18 Apr 2012 21:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.11 X-Spam-Level: X-Spam-Status: No, score=-10.11 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z22kA6oyPadU for ; Wed, 18 Apr 2012 21:43:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D8D5711E8079 for ; Wed, 18 Apr 2012 21:43:27 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3J4hNbi006840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 06:43:23 +0200 (MEST) From: Martin Rex Message-Id: <201204190443.q3J4hN76026159@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Thu, 19 Apr 2012 06:43:23 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 18, 12 11:26:35 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:43:29 -0000 Nico Williams wrote: > > +1. Also, the cert needn't be short-lived so much as fresh (recently > issued). Of course, we don't want online CAs issuing long-lived > certs, and to make up for their being online we must be prepared to > revoke them frequently, which means we still have a headache for cert > lifetime trade-off. Still, if OCSP responses need to be fresh within > 10 minutes, having short-lived certs live up to 24 hours but be > refreshed every ten minutes would probably work well enough. OCSP Responses fresh within 10 minutes? Sounds like an extreme case of paranoia to me. I likely would not even support such frequent refreshes within our server software, and probably enforce >= 1 hour on that configuration parameter. -Martin From nico@cryptonector.com Wed Apr 18 21:47:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504D821F847B for ; Wed, 18 Apr 2012 21:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pavwuRv9MRVp for ; Wed, 18 Apr 2012 21:47:05 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 06C5721F846A for ; Wed, 18 Apr 2012 21:47:05 -0700 (PDT) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id CB0301E00D for ; Wed, 18 Apr 2012 21:47:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=rZwEqZLbCCMafcS8VkfhdSLxMLr3SkXLl5MyCe+AR7iH Y4TChvXWBsWVJsBEdE2vjTEfx84r5bBefTiae172xPGuS47cky9o6OCC+9eLnpra 885qkt00XotLBeU88G/8CilQNlXX9PakzApPOLnlmQMksDtKYLJpX0glXcWIkLY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=UI3VwjihyNhyaDfv1g2Xb1aL3ns=; b=Z3kq20zp2B+ dsHzq9KFTV/z/Cs+K9AOzNv//lmuE1+mmBBqmQpri3S16FcSJKvjYL3J5dNh4m0N g8I25Gmq9ogQaL3uUUylb9Dku5sWY+Jovjv+XP9zmPSpdVArmGqyD6ieC489Pmuz eryPVQ9RuctcyGbGMXNfW8ITz4ERAtD0= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id BAD051E00C for ; Wed, 18 Apr 2012 21:47:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so7707628pbb.31 for ; Wed, 18 Apr 2012 21:47:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr1901795pbc.97.1334810824377; Wed, 18 Apr 2012 21:47:04 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 21:47:04 -0700 (PDT) In-Reply-To: <201204190438.q3J4c6Nu025658@fs4113.wdf.sap.corp> References: <201204190438.q3J4c6Nu025658@fs4113.wdf.sap.corp> Date: Wed, 18 Apr 2012 23:47:04 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:47:09 -0000 On Wed, Apr 18, 2012 at 11:38 PM, Martin Rex wrote: > OCSP stapling has the big advantage that things works pretty much > exactly like they do now. =C2=A0Hard fail is not necessary, especially If you want revocation to work then you must have some point where you fail hard. Nico -- From nico@cryptonector.com Wed Apr 18 21:50:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C4821F847D for ; Wed, 18 Apr 2012 21:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNDChpTIE5Gc for ; Wed, 18 Apr 2012 21:50:17 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 09F6B21F847B for ; Wed, 18 Apr 2012 21:50:17 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id AF2C7508083 for ; Wed, 18 Apr 2012 21:50:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=cuKwF24KeGlofPSxFLH4ZOv02z09wWQiwxv01tygGvWO sn9BjJzc+I7tj44JZ4gJDTS61Z6bdImOzYOjtY269kqpTAUebf9i8qmQFhWPJ0PR 6S0HqRV4UoJdTGhjtyT6MYXmdWnBOqzje0qHp5LXiMxq62cRkgvHLVEk9Pdx9Xw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=KnG40sooXZD36dKSLY3uweR8wy0=; b=TUwkWaA2j9U rnRiW0W3QChbMW8qhXn5H7ovlHbm77iPLmMr49D222GYzPJ0BXKe3pOKN4LhqnGZ 5AnbpLSFj/AvrsqR/CtakgRhLZY658vjriS4oXAbsEP9gX54nGIsJE0XEu8bdivO AmM6jWdOacexgE1E/zGuRM185YHrrBFc= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 95214508081 for ; Wed, 18 Apr 2012 21:50:16 -0700 (PDT) Received: by dady13 with SMTP id y13so14852798dad.27 for ; Wed, 18 Apr 2012 21:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr1921148pbc.97.1334811016126; Wed, 18 Apr 2012 21:50:16 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 21:50:16 -0700 (PDT) In-Reply-To: <201204190443.q3J4hN76026159@fs4113.wdf.sap.corp> References: <201204190443.q3J4hN76026159@fs4113.wdf.sap.corp> Date: Wed, 18 Apr 2012 23:50:16 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:50:21 -0000 On Wed, Apr 18, 2012 at 11:43 PM, Martin Rex wrote: > Nico Williams wrote: >> +1. =C2=A0Also, the cert needn't be short-lived so much as fresh (recent= ly >> issued). =C2=A0Of course, we don't want online CAs issuing long-lived >> certs, and to make up for their being online we must be prepared to >> revoke them frequently, which means we still have a headache for cert >> lifetime trade-off. =C2=A0Still, if OCSP responses need to be fresh with= in >> 10 minutes, having short-lived certs live up to 24 hours but be >> refreshed every ten minutes would probably work well enough. > > OCSP Responses fresh within 10 minutes? The point was that the ration of lifetime to freshness can be quite large. Whatever the freshness requirement, you can have the lifetime of the credential be a fair be longer. > Sounds like an extreme case of paranoia to me. =C2=A0I likely would not > even support such frequent refreshes within our server software, > and probably enforce >=3D 1 hour on that configuration parameter. In the Kerberos world we typically see *service* ticket lifetimes as short as one hour for plain services and as short as a few minutes for high-value services, with TGTs being renewable for possibly many days. Nico -- From nico@cryptonector.com Wed Apr 18 21:59:27 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B663C21F84D3 for ; Wed, 18 Apr 2012 21:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EddTpgNaUJAT for ; Wed, 18 Apr 2012 21:59:23 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6002321F84C2 for ; Wed, 18 Apr 2012 21:59:23 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 18E662AC059 for ; Wed, 18 Apr 2012 21:59:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=UsgCwzdjGh65ZlAvoFA0F xDmh7gWeUCZgwTVuz+p5K1vabpmLdvmoPPSMvwA7kbh8RH9HezCaCa2/xXi5J1Yr DssEKWeGoHhlN/jgV6egp3pWGNqNN+xu/yEpdqbUtw9FFH4/Ud8+SozxMdhLbmj5 hhEqY9Z9B+8DRUDfZtZCSY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=vQ3YkLGOyFl1nsq6s48x a69H7DQ=; b=SeKHA7ARVz47UsNu1gIrYO1pfzVnWd7IjcJ40qQsR8nCT4GglOOZ 1pZOaXQ4MqDSIR1XmV/n9s8gg1LqpzAC+azIuZJRVPT4aHXTQFbqgcpI/wR0RZCO U8iGKMpscUdS3bUK+TfGfuZ07y5ZRT7wz0gNrtTnxKHwup5UuSJbmcA= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 0038A2AC005 for ; Wed, 18 Apr 2012 21:59:22 -0700 (PDT) Received: by dady13 with SMTP id y13so14863697dad.27 for ; Wed, 18 Apr 2012 21:59:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.218.233 with SMTP id pj9mr2058570pbc.76.1334811562661; Wed, 18 Apr 2012 21:59:22 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 21:59:22 -0700 (PDT) In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> Date: Wed, 18 Apr 2012 23:59:22 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 04:59:27 -0000 OCSP stapling pros: - no changes to CAs Fresh certs from online CAs pros: - no changes to concentrators (except to automate the refreshing of certs and cert chains) - no or minimal changes to relying parties (TLS clients) to insist on freshness OCSP stapling cons: - software/firmware changes required on TLS servers - software changes required on TLS clients - procedures needed to keep OCSP responses fresh Fresh certs from online CAs cons: - changes to CA infrastructure required - procedures needed to keep certs fresh Both should increase the amount of PKIX goop to send similarly (OCSP responses vs. extra certs in the validation chain). Hmmm. I'm not sure yet which is more workable. And then there's the Chrome model of revocation to consider. I think we need to debate this some more. Or at least we need more information. If CAs refuse to go along with the fresh, short-lived certs with online CAs approach then that's that for that approach, but in terms of code (and firmware) to change, this is much better than OCSP stapling. Nico -- From ekr@rtfm.com Wed Apr 18 22:04:34 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82E821F84E4 for ; Wed, 18 Apr 2012 22:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.798 X-Spam-Level: X-Spam-Status: No, score=-102.798 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKRJuLs8ZCR6 for ; Wed, 18 Apr 2012 22:04:34 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1DF921F84E2 for ; Wed, 18 Apr 2012 22:04:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6326057vbb.31 for ; Wed, 18 Apr 2012 22:04:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=uFrJHzhKEKJkLVhjBO+R0uP71JYBRHFjAtYOFasl7ZY=; b=hKDTZlm8b+mBy0DsI9MD7jyg0a1QGVEQTVaST9WxiZK0Cd8qIaVaZK2Pan3xOGUrfA 9F3E0bOllJBYTsOdpnXR37wpzpOKazxguY+p+2C29j2NC8UWzz5Zn5S9WTGJuOmai/VZ /a1Nb1mA9iJ8WOnnxFqf8JUEQWXo0aTVGmRNBw/TpzRrQZBNmyYUCYWGIv92E/TUFmW5 /QCI6GtN2FmnQmhX8YUiSGQl6EiEL9S0Ofs0VttM40AAhdjXJL+9LFGawGABYPVVdVWU rtI3qx9Ke9q9PQNlK1dW4JnHTfAySLS0asg+cE+EJ//MqUjn+CiG67jZO9TA46L/urVF A0qA== Received: by 10.52.69.100 with SMTP id d4mr335384vdu.9.1334811873310; Wed, 18 Apr 2012 22:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Wed, 18 Apr 2012 22:03:53 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 18 Apr 2012 22:03:53 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl39Nup0eUVyi3+15zDJ+PRb2ymDOgOxvdGZPo7kpPvzWJ05Rg6Tlr23IooQcrZ6Hy39Arj Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 05:04:34 -0000 On Wed, Apr 18, 2012 at 9:59 PM, Nico Williams wrot= e: > OCSP stapling pros: > > =A0- no changes to CAs > > Fresh certs from online CAs pros: > > =A0- no changes to concentrators (except to automate the refreshing of > certs and cert chains) > =A0- no or minimal changes to relying parties (TLS clients) to insist on = freshness > > OCSP stapling cons: > > =A0- software/firmware changes required on TLS servers This is required as well for auto-refreshing of short-lived certs, and I believe that both IIS and Apache currently support OCSP stapling. > =A0- software changes required on TLS clients Currently, Chrome at least supports OCSP stapling and there are patches for NSS. It's also not entirely clear that short-lived certs don't cause clients to choke. They shouldn't, but don't and shouldn't aren't always the same. -Ekr From nico@cryptonector.com Wed Apr 18 22:36:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A3411E808A for ; Wed, 18 Apr 2012 22:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL7JvYjszI6O for ; Wed, 18 Apr 2012 22:36:47 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2B57B11E8079 for ; Wed, 18 Apr 2012 22:36:47 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id ABEE69405C for ; Wed, 18 Apr 2012 22:36:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=OlwgkfiDmPI+HIi/bumxuvp2W5awOFSpIPaP4wyR2a8R enm5cUUPBG2YAetVHWHkKn/sBAGb8WtxSycEDuw6Iq/aGpFT7mdbe0vU5NKF3/j1 LOdtkJkEvkPzDWT6Tr1CRxWTEsT7483Z5owcqR57zAGPwgpH5Nci9F1awHY0j64= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=upYAWg6DNhf7fE7WOi9Rh7vIM34=; b=Q/ik4vKnWyi als6sDBK4fjpddL5cdz3R/Dwbn9tDM4HO8AxyPRWmvhQ3IbpWX8flOh/YZwp11rh zt0aXkdTLf+gNIpEi2jPrmUi3mTLRViUAMrFIcisTC1kL0DZjss3XFZd9Vhw0ToL /E/C31+r4aG9+9Gc6Ur7scLx+pd2a660= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 9234E9405E for ; Wed, 18 Apr 2012 22:36:46 -0700 (PDT) Received: by dady13 with SMTP id y13so14911916dad.27 for ; Wed, 18 Apr 2012 22:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.219.200 with SMTP id pq8mr2320313pbc.55.1334813806047; Wed, 18 Apr 2012 22:36:46 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 18 Apr 2012 22:36:46 -0700 (PDT) In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> Date: Thu, 19 Apr 2012 00:36:46 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 05:36:51 -0000 On Thu, Apr 19, 2012 at 12:03 AM, Eric Rescorla wrote: > On Wed, Apr 18, 2012 at 9:59 PM, Nico Williams wr= ote: >> OCSP stapling cons: >> >> =C2=A0- software/firmware changes required on TLS servers > > This is required as well for auto-refreshing of short-lived certs, and Not really: if there are any interfaces suitable for automation you can just automate the periodic installation of new certs. > I believe that both IIS and Apache currently support OCSP stapling. But not this extension, right? >> =C2=A0- software changes required on TLS clients > > Currently, Chrome at least supports OCSP stapling and there are > patches for NSS. It's also not entirely clear that short-lived certs > don't cause clients to choke. They shouldn't, but don't and shouldn't > aren't always the same. With TLS it's like a box of chocolates... (hint: they're all awful). Nico -- From ekr@rtfm.com Thu Apr 19 07:17:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD83521F85C4 for ; Thu, 19 Apr 2012 07:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.81 X-Spam-Level: X-Spam-Status: No, score=-102.81 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48o5kjacU224 for ; Thu, 19 Apr 2012 07:17:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 332C921F85A4 for ; Thu, 19 Apr 2012 07:17:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6654512vbb.31 for ; Thu, 19 Apr 2012 07:17:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=M587PlMul5N/2rO7dZCWCRHr62C5feXEtMdWcWtBT0o=; b=pu4xPIgRMt8xhZUqd+NiWSO5K7I27duNviyUVGEJi66tizaCrr8rItDPa5L4JyvdQ0 gGvUzUwhgGGxQi4xbdOoBIBEAOfFREDjZ+hkRruc4ub58yA3lLwwstrvXV0nI4rGiIW7 eg58xLu8np50BN3ZwGFTZWv9aK7LJO/VbdJH9wuDyeNbMQT7kATnmPo/+uiUm329H1Yu kLzI88rfQlRot3sQl8yAa8i7MgqCmWRG/y7Zii+FHXcNp4jWkPLJKCEN80PjyX5neBwO TuG0YlqVccS8l8IWCb8snf1CvyerccmZFC+akKj4ZRyyofQiqmTwvCQtI2oLlNkcsZ8I GVCQ== Received: by 10.220.153.8 with SMTP id i8mr1184790vcw.73.1334845043627; Thu, 19 Apr 2012 07:17:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 19 Apr 2012 07:16:39 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Thu, 19 Apr 2012 07:16:39 -0700 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnJ3QcduJYKoijdetFF2Z0XxrXu+JCAJRJbjYKtMZxY0C3NXCPq5bF/t+9drDwuLOcvMyxz Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:17:25 -0000 On Wed, Apr 18, 2012 at 10:36 PM, Nico Williams wro= te: > On Thu, Apr 19, 2012 at 12:03 AM, Eric Rescorla wrote: >> On Wed, Apr 18, 2012 at 9:59 PM, Nico Williams w= rote: >>> OCSP stapling cons: >>> >>> =A0- software/firmware changes required on TLS servers >> >> This is required as well for auto-refreshing of short-lived certs, and > > Not really: if there are any interfaces suitable for automation you > can just automate the periodic installation of new certs. You wish. :) I believe that changing a cert in Apache, at least, involves a restart. >> I believe that both IIS and Apache currently support OCSP stapling. > > But not this extension, right? Correct. -Ekr From ryan-ietftls@sleevi.com Thu Apr 19 07:54:18 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BE021F858F for ; Thu, 19 Apr 2012 07:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NygSnnRDsFb for ; Thu, 19 Apr 2012 07:54:18 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id AB65321F846F for ; Thu, 19 Apr 2012 07:54:17 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 55F973B805B; Thu, 19 Apr 2012 07:54:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; q=dns; s= sleevi.com; b=X8MSUDUntsHXj6RslhwZAajKdwrIy2EuhVFDv+Jep+lrJLy0LU qkGhcaPngkAaAvFZqtePzo786SHbscC5eRAaJ6q4SpyXu4ogGo4UYt9nRPyf7G/+ E9Tvnnuo84teFXBaaXHoj7IrORLzBk3x/qfVGUJXZ6eTZQrMsuf0DTNy8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=itOhAywYt0ZcTjIRr9UPi5JnjnY=; b=rH/OkKVmmawPAUOSs faZLP3qqayGpMq4se8QbvJo40sLZpdd8RqT8V9XzM2FDwZHJCvu3w7Cja6kbIxLB v59ThqM7yRAlOHvICRDEZIbzrk7GDtSdh61VLzfhhotM4IxOYzQ3vW1BPl/3jVui vf4kAcXQg8nZlFM8xo/GlrvGj8= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id C9FF83B805C; Thu, 19 Apr 2012 07:54:16 -0700 (PDT) Received: from 216.239.44.25 (proxying for 216.239.44.25) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 19 Apr 2012 07:54:17 -0700 Message-ID: <3ff1f5d08543d03cdf06c955fa38ec82.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Thu, 19 Apr 2012 07:54:17 -0700 From: "Ryan Sleevi" To: "Eric Rescorla" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietftls@sleevi.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:54:18 -0000 > WG members, > > At the meeting in Paris there was broad consensus to adopt Yngve's > TLS Multi-Stapling draft > (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt). > > The WG chairs would like to confirm this consensus. Please send any > comments by Wednesday April 25. > > -Ekr > [For the chairs] I support adopting this as a WG item. From agl@google.com Thu Apr 19 08:01:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7352121F8633 for ; Thu, 19 Apr 2012 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX73n31YlujW for ; Thu, 19 Apr 2012 08:01:10 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E32621F8609 for ; Thu, 19 Apr 2012 08:01:09 -0700 (PDT) Received: by yenm5 with SMTP id m5so5154592yen.31 for ; Thu, 19 Apr 2012 08:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=4dVG8eh8VutCG1K/IZBn3L5J2JOYEIzpxpBRURmELpU=; b=ACd/CeE2GL0t8aMIwBaHBdhaXP8D5ptovVGf4Exd0G8wAvOtmwATE+Xdj6vDimnGjh BABwbMrOfdDtEqW7XfyAHddeeSU0cG1nJqxH3xm/qjki2k1XaPjwYqXS9Ft+or7H0o9/ KpkGY8cvoF0vo+SCay9eZTdFSaVtbRM5ABA88k5Q5U+vWci4coOkKmWrO4TP1dQjisQi hlf9gtFgbHPeGFzFfoyGIDfq+3joFgSVN2n4wqBBODUNNxFlZuiezGNh5aEQ3nKXJ0Tj ZcR+nvT2xghpt8cXNUHvf7bExFIkA6QrGxP62Z0XbCM6SHGQECSKF09XxZ3dBQ4wXAiX kl5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=4dVG8eh8VutCG1K/IZBn3L5J2JOYEIzpxpBRURmELpU=; b=jTDzlnDBwAUS+AW8dr/zsUVToHPohu1uDzywePHviunZq+UwmUxzN8mrrXDAj3VTnG hRuV9zvnjuc3GrkhXBZM2zYK/F9sj30ss9lo+s7xxXN6IuxFk8COBhCgUfkJCvnFUnyb 4CG5p9dtNAMxvcwlwHQ08Tgf019ROp5GtN+s49ZSXtylboz4UtwZF9w80a9vJC8mq+xg s/N6ce2PVTQKX5Jfro1YUmQC8kreHA42RXJPnISaeiD1XhHl6UvcwjCOce343EfHbeZJ oiiLBY5V8mEfWVeOjE2Q/x/Ot2wBlQIMhlimyT+eUauQdQfXkJo+PmrmameRAKhlKLiX CceQ== Received: by 10.50.191.169 with SMTP id gz9mr2577839igc.5.1334847664174; Thu, 19 Apr 2012 08:01:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.191.169 with SMTP id gz9mr2577757igc.5.1334847663470; Thu, 19 Apr 2012 08:01:03 -0700 (PDT) Sender: agl@google.com Received: by 10.231.189.95 with HTTP; Thu, 19 Apr 2012 08:01:03 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Apr 2012 11:01:03 -0400 X-Google-Sender-Auth: oZj6wxz71Shwt65Y1NS1K2VjXrE Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnBeA9pDfQxGnf0xg+6q7HpzZKaYA9U9ke6wQfZLpfZVq7wtzijuXCnPXSl3me6npIvKNDxLgVqPAclQGQr1LHW+mL1a49n3m8xKOY78/K2bZBw7pZDGexl50ACDVwQdz1R2kCr Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:01:10 -0000 On Wed, Apr 18, 2012 at 5:02 PM, Eric Rescorla wrote: > The WG chairs would like to confirm this consensus. Please send any > comments by Wednesday April 25. I support the adoption of this as an item. Cheers AGL From tom@ritter.vg Thu Apr 19 09:56:07 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC40421F85FC for ; Thu, 19 Apr 2012 09:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ouKhVN2jcMe for ; Thu, 19 Apr 2012 09:56:03 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A82E321F85F1 for ; Thu, 19 Apr 2012 09:56:03 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so7988542obb.31 for ; Thu, 19 Apr 2012 09:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D/KnNu2m7v1bKRqLgDwNizspxKsR3nWC/gKxS0WXF3Q=; b=y3F8PH3W3JH7WgU1oll/cD2kGJjrwdRpAGTz/XkS8s5rPJMVhPon2SJIAa3EqWcj5z NihMYlaWPdLeUCwgGPZNBJP9TNiV8QcTNviYqBEyR7RubgtuxA3PKPkIdyGhCbx1qU6W 2rUJcFzfqG6eHfaliPwNqA+8x/em2RUE+cdsg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=D/KnNu2m7v1bKRqLgDwNizspxKsR3nWC/gKxS0WXF3Q=; b=ox1rzJrUbT9buFJ7BcEkwrWQ5EXzwBD2JyOnw/hZfHpx81ypLW+VS/19tyFHmOAq/1 IpnKZBfBWf8ZzPPdf/KVbyy8SmGYlgN04jlGcc3oZ9hviFQOxGbbwg08wV8accBndlgP zERtg38gR7A8jsR3/ADTcZEE3hdnvKUwn/H6zkX3ztiVv5AGdiw5GD1NoJYU8+ABY4V5 uZuA8+6ncp19K+0ksY4XTg0BWNa/94jVdNXBd4dHZUoJ6KVWW7+7qUez4HmFx+toUNTr ZP8LAQV7ct6QRzo3cdTpUoEWyRSjz95HrFy4o0XwFo5gwjeqB5dg1Bxz2i2ZRoFMv/1T 1C3w== Received: by 10.182.72.38 with SMTP id a6mr4047740obv.38.1334854563186; Thu, 19 Apr 2012 09:56:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.116.41 with HTTP; Thu, 19 Apr 2012 09:55:42 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Thu, 19 Apr 2012 12:55:42 -0400 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmf7mdQf0V26XybiB4C06lgYOwQFPgzd/iCib7EtD3GZtt01znszg0UeoqE69nzBfUqwZQf Cc: tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:56:08 -0000 I support adopting this as a WG item. -tom From nico@cryptonector.com Thu Apr 19 09:57:14 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C07921F8603 for ; Thu, 19 Apr 2012 09:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6i3G+xpe9dGy for ; Thu, 19 Apr 2012 09:57:10 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8259021F85FF for ; Thu, 19 Apr 2012 09:57:10 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 34DE2678062 for ; Thu, 19 Apr 2012 09:57:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=PJS0uJQb1VfxknjIRlUDz7JjK7K+HudQwveZKiNrOmul hXLFi1BUeV42S0iGXyTwKgrvwC41xEIcDDLWBqVIkLbsm5RnpApGWCXPddQIRxl+ acXKjlL2FnBULRd9i0P7E7fb3ClI+Gwu38CNFC2NlJJ/S25dne6FWXUmXRcR6H4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=+Vfl+YFoxN1A1kz50giT3vSRmV0=; b=pPu2nEcn9dN E3SG3kQ07f3LFlOJPS8p5CvtJ/YOfGqTFbxexZbRCmGMtlM+eeTKfyee4ffLB0H3 JTpluaGaUtNNT+MAn2niJIFrDwqE9Lp9Rj4P71jngZEyPtHcQ/ZOUYsINVwGamNe 0j0QjwMQuPCd3IyHTpVNjJ3KzZmvoypQ= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 1106A678057 for ; Thu, 19 Apr 2012 09:57:10 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so8424395pbb.31 for ; Thu, 19 Apr 2012 09:57:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.218.233 with SMTP id pj9mr532331pbc.76.1334854629738; Thu, 19 Apr 2012 09:57:09 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 19 Apr 2012 09:57:09 -0700 (PDT) In-Reply-To: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> Date: Thu, 19 Apr 2012 11:57:09 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:57:14 -0000 On Thu, Apr 19, 2012 at 9:16 AM, Eric Rescorla wrote: > On Wed, Apr 18, 2012 at 10:36 PM, Nico Williams w= rote: >> On Thu, Apr 19, 2012 at 12:03 AM, Eric Rescorla wrote: >>> On Wed, Apr 18, 2012 at 9:59 PM, Nico Williams = wrote: >>>> OCSP stapling cons: >>>> >>>> =C2=A0- software/firmware changes required on TLS servers >>> >>> This is required as well for auto-refreshing of short-lived certs, and >> >> Not really: if there are any interfaces suitable for automation you >> can just automate the periodic installation of new certs. > > You wish. :) > > I believe that changing a cert in Apache, at least, involves > a restart. But at least it's possible. And with a server farm and a freshness requirement of, say, a few hours, outages can be avoided altogether. Also, it's not Apache I'm concerned about, but the concentrators. I imagine some may require something like expect scripting to automate server cert replacement (ewww). >>> I believe that both IIS and Apache currently support OCSP stapling. >> >> But not this extension, right? > > Correct. That's important. It's clear that changes to concentrator software/firmware are difficult to effect and deploy. To me that's a big problem with the OCSP stapling proposal. Nico -- From mrex@sap.com Thu Apr 19 12:33:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095F321F8620 for ; Thu, 19 Apr 2012 12:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 938zyFT35+hH for ; Thu, 19 Apr 2012 12:33:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA721F861F for ; Thu, 19 Apr 2012 12:33:42 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3JJXcZW011606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 21:33:38 +0200 (MEST) From: Martin Rex Message-Id: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Thu, 19 Apr 2012 21:33:37 +0200 (MEST) In-Reply-To: from "Nico Williams" at Apr 19, 12 11:57:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 19:33:44 -0000 Nico Williams wrote: > >Eric Rescorla wrote: >> Nico Williams wrote: >>> Eric Rescorla wrote: >>>> Nico Williams wrote: >>>>> OCSP stapling cons: >>>>> >>>>>  - software/firmware changes required on TLS servers >>>> >>>> This is required as well for auto-refreshing of short-lived certs, and >>> >>> Not really: if there are any interfaces suitable for automation you >>> can just automate the periodic installation of new certs. >> >> You wish. :) >> >> I believe that changing a cert in Apache, at least, involves >> a restart. > > But at least it's possible. And with a server farm and a freshness > requirement of, say, a few hours, outages can be avoided altogether. > Also, it's not Apache I'm concerned about, but the concentrators. I > imagine some may require something like expect scripting to automate > server cert replacement (ewww). First of all, the OCSP stapling extension will _not_ preclude that you change your servers to use short-lived certs. But short-lived certs create several additional operational problems, because they expire so often. - on the client: you have to somehow recognize the short-lived certs and distinguish them from normal, long-lived certs and have the client skip traditional revocation-checking, so you would have to augment PKIX with a new attribute for that purpose and then update the entire installed base of TLS clients(!) and CA-Software... rather than just a few servers that will be under premium maintenance anyway if they important. - on the server: the changes necessary on the server to support OCSP stapling is in the ballpark of rfc5746 (renegotiation_info). the actual change to the TLS state machine is much smaller than rfc5746, but the acquisition of the OCSP staple is extra. - the real issue is about the management operation itself on the server. obtaining a new certificate from the CA typically requires mutual authentication, whereas obtaining a fresh OCSP staple can be performed over an insecure channel (followed by a validation that the info is valid). - short-lived certs interfere *badly* with TLS session caching, where clients may end up with factually expired certs after SSL session resumption. > > >>> I believe that both IIS and Apache currently support OCSP stapling. > >> > >> But not this extension, right? > > > > Correct. > > That's important. It's clear that changes to concentrator > software/firmware are difficult to effect and deploy. To me that's a > big problem with the OCSP stapling proposal. This would be a total software logistics goof on the part of the concentrator supplier if that was the case. What use is a ?$$.$$$,- component if the vendor declares itself unable to deploy a change of around 50 lines of code in a software update under maintenance contracts? The usefulness of a specialized concentrator looks somewhat overrated to me (or might be an indicater of non-optimal server software behind it), unless maybe you compare it to an Apache reverse proxy that does not use SSL session resume on the connection to backend servers and also has request pipelining disabled... With a reasonable reverse proxy implementation, which sometimes is included with the server software itself, installed on an x86 or x64 PC, performance should IMHO not be an issue. With newer CPUs that support AES-NI, maybe even less so. Clients that are still limited to 3DES-EDE-CBC are a little harder to serve, but far from unbearable. -Martin From ekr@rtfm.com Thu Apr 19 12:45:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB0D21F86B5 for ; Thu, 19 Apr 2012 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.82 X-Spam-Level: X-Spam-Status: No, score=-102.82 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaQJR-lseL-J for ; Thu, 19 Apr 2012 12:45:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E74B21F86B2 for ; Thu, 19 Apr 2012 12:45:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6920709vbb.31 for ; Thu, 19 Apr 2012 12:45:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=FoKwm6deWxSHrI0UDAs/vMPvy9E1p4aDYCgjV7TbHmg=; b=ox/H2laMEc3ONtIcI1J5I12WWn9tTXo8FRojhpvJu8teUoOmHytjYkj/ber2lXFKzL rxW4YDN4GScGn5mNEDQufKqKZ/Okg1KL6PahH4WCsJkqsygAdAML/dKNSztJG0MFTPe/ FDkoRrErRlJCTet2XEjBwq9USQcezCaOnTxxth5oSa+ynYAl/4tKrse/U31hlZ+RUBoc JOWZqVy56tf4Y6royeFgQf0f1lzr+LRug6RqCjrUzfP7pqKJTMj/VqNu9Ebe6t+gYccv +gXzZGZPpcqU8AHdprP1bhW2+AvYzQDhjywSJclhGpY0AsQHgUZhb+xZrONU05gWhJxu tqKQ== Received: by 10.52.65.134 with SMTP id x6mr1476602vds.60.1334864756071; Thu, 19 Apr 2012 12:45:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 19 Apr 2012 12:45:15 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Thu, 19 Apr 2012 12:45:15 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkxjQQLcukQ9UAxKjrZPhKyLshvb0jKr0DvLPiAUcIMHyUdvx9QoVx/85xYzu2P4mylUAaZ Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 19:45:57 -0000 On Thu, Apr 19, 2012 at 12:33 PM, Martin Rex wrote: > But short-lived certs create several additional operational problems, > because they expire so often. > > =A0- on the client: you have to somehow recognize the short-lived certs a= nd > =A0 distinguish them from normal, long-lived certs and have the client > =A0 skip traditional revocation-checking, so you would have to augment PK= IX > =A0 with a new attribute for that purpose and then update the entire > =A0 installed base of TLS clients(!) and CA-Software... rather than > =A0 just a few servers that will be under premium maintenance anyway > =A0 if they important. This may or may not be an issue. Depends how clients behave if there is merely no revocation information in extensions. > =A0- the real issue is about the management operation itself on the serve= r. > =A0 obtaining a new certificate from the CA typically requires mutual > =A0 authentication, whereas obtaining a fresh OCSP staple can be > =A0 performed over an insecure channel (followed by a validation that > =A0 the info is valid). The assumption behind short-lived certiifcates is that they will be provided over a public channel without authentication, precisely as new OCSP responses can be. Certificates are public information so as long as nothing has changed, you just reissue with the same key. > =A0- short-lived certs interfere *badly* with TLS session caching, > =A0 where clients may end up with factually expired certs after > =A0 SSL session resumption. As far as I can tell, precisely the same situation obtains with respect to the client's opinion of expired OCSP responses. -Ekr From nico@cryptonector.com Thu Apr 19 13:10:07 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420C511E8081 for ; Thu, 19 Apr 2012 13:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18bohCxwLcgu for ; Thu, 19 Apr 2012 13:10:06 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id BD37511E8093 for ; Thu, 19 Apr 2012 13:10:05 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id C47EE508089 for ; Thu, 19 Apr 2012 13:10:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=AZiKQ33WHolnMviIf1VmRfm2cMSfwIGm20Q6A60CQdjI wPqyBefQ6zwnvL1zDhMLSQUZbwBwWtNE3lZUuKkrGhnRJwhF8QUYLH5oBmq0poqy OkJrv58Si4eOyk/UGq2GgM4k5nPUN/5eRHhWPgv1pzkdG8L31mP0aI4hCxOKY8k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=yFNXyWtdODbAuIfkwJnuQH1OjSg=; b=TaDrdKowlcx s12GdLrycdmGvyVUDUaKz1rW1sK7bBHlntLaJn2glK9nWFackswCSy8399sX9rXB 3kgINGgi7Jl42O/bxA+2yl4DDMHK/JKKAW1q1oTRxypDyH0jKA4mYsWhbtO7E+Mj otcLtjrlMjxo5h2/ZBkJa1SfuoOEFKVo= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id AC655508087 for ; Thu, 19 Apr 2012 13:10:04 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so189535pbb.31 for ; Thu, 19 Apr 2012 13:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr6883782pbc.97.1334866204271; Thu, 19 Apr 2012 13:10:04 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 19 Apr 2012 13:10:04 -0700 (PDT) In-Reply-To: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> Date: Thu, 19 Apr 2012 15:10:04 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 20:10:07 -0000 On Thu, Apr 19, 2012 at 2:33 PM, Martin Rex wrote: > Nico Williams wrote: > > First of all, the OCSP stapling extension will _not_ preclude that > you change your servers to use short-lived certs. Neither precludes the other. That's not the question. The questions are: does one, the other, or both solve the problem at hand? and if both do, which is easier to deploy? > But short-lived certs create several additional operational problems, > because they expire so often. No. If clients hard fail when they can't check revocation status of a server cert, then it the operational problem applies to both. If clients prompt when the server cert is expired or the client can't check revocation status then both schemes are still equivalent. If clients neither hard fail nor prompt in one scheme but not the other then that one scheme is useless (this could happen to both schemes). You've not yet demonstrated that one scheme is worse than the other. More importantly, we need to decide when clients (RPs, really) should fail hard. That's critical, no? > =C2=A0- on the client: you have to somehow recognize the short-lived cert= s and > =C2=A0 distinguish them from normal, long-lived certs and have the client > =C2=A0 skip traditional revocation-checking, so you would have to augment= PKIX > =C2=A0 with a new attribute for that purpose and then update the entire > =C2=A0 installed base of TLS clients(!) and CA-Software... rather than > =C2=A0 just a few servers that will be under premium maintenance anyway > =C2=A0 if they important. No, you wouldn't be REQUIRED to "somehow recognize ..." Doing so helps reduce the amount of work the client does -- it's an optimization, and a very good one, yes, but still, only an optimization. A new OCSP wstapling extension, on the other hand, can't be deployed without client-side changes, much more extensive changes than those needed to take advantage of fresh certs! > =C2=A0- on the server: the changes necessary on the server to support OCS= P > =C2=A0 stapling is in the ballpark of rfc5746 (renegotiation_info). > =C2=A0 the actual change to the TLS state machine is much smaller than > =C2=A0 rfc5746, but the acquisition of the OCSP staple is extra. Agreed. But this is critical, no? Server-side changes include changes to concentrators, in some cases to firmware. That's a high barrier. > =C2=A0- the real issue is about the management operation itself on the se= rver. > =C2=A0 obtaining a new certificate from the CA typically requires mutual > =C2=A0 authentication, whereas obtaining a fresh OCSP staple can be > =C2=A0 performed over an insecure channel (followed by a validation that > =C2=A0 the info is valid). See EKR's response, with which I agree entirely. > =C2=A0- short-lived certs interfere *badly* with TLS session caching, > =C2=A0 where clients may end up with factually expired certs after > =C2=A0 SSL session resumption. Depends. I'm arguing for *fresh* certs more than for short-lived certs. Same semantic as for OCSP. We could conceivably be using long-lived certs for this, just refreshed frequently. Nothing wrong with that, eh? >> >>> I believe that both IIS and Apache currently support OCSP stapling. >> >> >> >> But not this extension, right? >> > >> > Correct. >> >> That's important. =C2=A0It's clear that changes to concentrator >> software/firmware are difficult to effect and deploy. =C2=A0To me that's= a >> big problem with the OCSP stapling proposal. > > This would be a total software logistics goof on the part of the > concentrator supplier if that was the case. =C2=A0What use is a > ?$$.$$$,- component if the vendor declares itself unable to > deploy a change of around 50 lines of code in a software update > under maintenance contracts? Well, this: http://www.imperialviolet.org/2012/04/11/falsestart.html leads me to think that concentrator changes are much harder to get than you think. Google clearly worked very hard on False Start and still came up short. And we think that a new OCSP stapling extension will fare better?? Why would that be so?! Now, this is all about optimizing certificate revocation status checking. It's just an optimization. A very good and desirable optimization. We need an optimization in this area. The question is: what's the path of least resistance to getting that optimization deployed? > The usefulness of a specialized concentrator looks somewhat overrated to = me > [...] Me too, but that doesn't change the reality of their being widely deployed. I doubt that reality is going to change anytime soon. Nico -- From geoffk@geoffk.org Thu Apr 19 13:34:19 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6127111E80BE for ; Thu, 19 Apr 2012 13:34: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjREq8dtbzc0 for ; Thu, 19 Apr 2012 13:34:18 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 9F54711E80A3 for ; Thu, 19 Apr 2012 13:34:18 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 5F41B33D106; Thu, 19 Apr 2012 20:34:10 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Eric Rescorla References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> From: Geoffrey Keating Date: 19 Apr 2012 13:34:10 -0700 In-Reply-To: Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 20:34:19 -0000 Eric Rescorla writes: > On Wed, Apr 18, 2012 at 10:36 PM, Nico Williams w= rote: > > On Thu, Apr 19, 2012 at 12:03 AM, Eric Rescorla wrote: > >> On Wed, Apr 18, 2012 at 9:59 PM, Nico Williams = wrote: > >>> OCSP stapling cons: > >>> > >>> =C2=A0- software/firmware changes required on TLS servers > >> > >> This is required as well for auto-refreshing of short-lived certs, and > > > > Not really: if there are any interfaces suitable for automation you > > can just automate the periodic installation of new certs. >=20 > You wish. :) >=20 > I believe that changing a cert in Apache, at least, involves > a restart. You can typically do it using 'apachectl graceful' without an interruption to service, the same as any other Apache configuration change. From tom@ritter.vg Thu Apr 19 13:47:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36A11E80A4 for ; Thu, 19 Apr 2012 13:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqQlpnJFSPK1 for ; Thu, 19 Apr 2012 13:47:02 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7D99021F8693 for ; Thu, 19 Apr 2012 13:47:02 -0700 (PDT) Received: by obbwd20 with SMTP id wd20so8257265obb.31 for ; Thu, 19 Apr 2012 13:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=cu+y71ETUaGbooGl8AK3RC7aUxt3lgelWTa84MOUve8=; b=IRDOFULIQxWrkJl9+Hrp0s7cWFCuSzfvKQtcc8iwsSt0uUE74EkxrlcJBQT23h++xw D8K7bgFTGCo2K8HfJPlzDr8Z77yzlBE8HxKLVzJwO8bFlRkFlEWPuYjURH4DJUmHq9i4 jgE+zIzrn0HmTehXaPZ+ZTtHd6XJigqoomi8A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=cu+y71ETUaGbooGl8AK3RC7aUxt3lgelWTa84MOUve8=; b=SJ8Do+awjWx/TBXO/wict1zKhdArGYr8Jc5h8gkNgk8rh14WSV/3fRVu1Wx/fVmD8T tbYunm5YahDPT8/E18WChe2UYjIgsupnsrZh+nURJ32zc8wo1vYC6MvWH6xCVSouoBg8 deNJ+kUIUts1yuIM5M4750LlcVAWglwOz4wR5wly5qQNqhlPQhf7h1VaHszGL9SeuTEa /Mq7GrktPf5+ZpA7Df+ODRHnStN8aoQDuh2H0tyZKc+V8Y4WTfD+40O3+GoVeDiRiBBq 8k6qF5XJNfCuKO5QCLXb9LCoAUYNqheMN6OQ0PugzS7Kdr6ymTFK64e5a1RkQFD+W5cy vX0A== Received: by 10.182.113.42 with SMTP id iv10mr5254249obb.18.1334868422015; Thu, 19 Apr 2012 13:47:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.116.41 with HTTP; Thu, 19 Apr 2012 13:46:41 -0700 (PDT) In-Reply-To: References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> From: Tom Ritter Date: Thu, 19 Apr 2012 16:46:41 -0400 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmn6P+fResp7S35BINZLd8LD1sG3n7OA7ajWg0dDGo2RheBJI1PERl78wfne19uc21oyQCW Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 20:47:03 -0000 On 19 April 2012 16:10, Nico Williams wrote: > Well, this: http://www.imperialviolet.org/2012/04/11/falsestart.html > leads me to think that concentrator changes are much harder to get > than you think. =A0Google clearly worked very hard on False Start and > still came up short. =A0And we think that a new OCSP stapling extension > will fare better?? =A0Why would that be so?! Browsers: We have worked with CAs for the past year on their OCSP responders, and with websever developers for the past year on their OCSP Stapling Support. We are comfortable enough with OCSP Stapling to run it on our own servers. In x months/1 year we will be enabling OCSP hard fail in our product. BigCo: What does this mean for me? Browser: It means that because your current certificate is not stapled, your users will get slower performance visiting your website, and if there is a network problem or failure on the OCSP responder of your CA, the user cannot reach your site. Also the user's browsing habit is leaked to the CA, although you probably don't care. BigCo: Thanks BigCo: ConcentratorCo, I need OCSP Stapling support, do you provide it? ConcentratorCo: No. ResponsibleConcentratorCo: We do, we do! ConcentratorCo: Shutup. BigCo: Which is more important to us: not spending the money of changing SSL Concentrators or eliminating the possibility that CA's could go down and take down our site? Perhaps I'm being a naive optimist, but I sincerely hope that corporations will vote with their money and show these companies that are _literally_ impeding the adoption of more secure technologies throughout the _entire Internet_ (and not just Stapling, but TLS 1.1 too) that they are not interested in buying from a company that provides less value than their up-to-date competitor. I want to name and shame these companies that are slowing things down. I don't like this current trend of "certain companies do X". Call them out. Journalism is want someone doesn't want you to print, everything else is marketing. If a person takes adequate steps to research the truthfulness of a statement - such as "We sent a TLS ClientHello with a SNI extension to the server, and received an Alert. The same ClientHello sent without the extension did not produce an alert" - you are covered legally. Continuing to cover for these companies that don't interoperate is doing their marketing for them. It's frustrating for participants on this list, embarrassing at how backwards this niche of security is, and it's ridiculous that I can get better information about the Chinese Restaurant around the corner than I can about the company I'm going to pay millions of dollars to help run my secure infrastructure. -tom From mrex@sap.com Thu Apr 19 13:49:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17FD21F8694 for ; Thu, 19 Apr 2012 13:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0QO+C06DXLj for ; Thu, 19 Apr 2012 13:49:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B983921F8693 for ; Thu, 19 Apr 2012 13:48:59 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3JKmtEE021371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 22:48:55 +0200 (MEST) From: Martin Rex Message-Id: <201204192048.q3JKmsmY019775@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 19 Apr 2012 22:48:54 +0200 (MEST) In-Reply-To: from "Eric Rescorla" at Apr 19, 12 12:45:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 20:49:00 -0000 Eric Rescorla wrote: > > >  - the real issue is about the management operation itself on the server. > >   obtaining a new certificate from the CA typically requires mutual > >   authentication, whereas obtaining a fresh OCSP staple can be > >   performed over an insecure channel (followed by a validation that > >   the info is valid). > > The assumption behind short-lived certiifcates is that they will be > provided over a public channel without authentication, precisely > as new OCSP responses can be. Certificates are public information > so as long as nothing has changed, you just reissue with the > same key. Sounds like an additional, brand-new enrollment protocol. > > >  - short-lived certs interfere *badly* with TLS session caching, > >   where clients may end up with factually expired certs after > >   SSL session resumption. > > As far as I can tell, precisely the same situation obtains with > respect to the client's opinion of expired OCSP responses. Hardly. The server cert is an integral part of the session state, whereas the OCSP responses would quite probably be from a seperate OCSP response cache. So when the client processes the ExtendedServerHello, it will stuff any OCSP responses from the existing single-OCSP or the new stapled OCSP response into the global cache and continue, and when processing the server's certificate handshake message, it will check the global cache for acceptably fresh OCSP responses and for all that are missing, expired or insufficiently fresh, the client will, all by himself, decide whether to perform OCSP lookup itself, whether the client considers that his privacy is more important and uses only what he has on hand. A TLS peer will not necessarily perform cert revocation checking during certificate path validation on full handshakes, but instead perform cert revocation checking *AFTER* the TLS handshake and independent of whether the session was resumed or newly established. -Martin From mike-list@pobox.com Thu Apr 19 13:54:14 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43A511E80D3 for ; Thu, 19 Apr 2012 13:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GqQlzcAT-GU for ; Thu, 19 Apr 2012 13:54:12 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 814D811E80CD for ; Thu, 19 Apr 2012 13:54:10 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id D447793B4; Thu, 19 Apr 2012 16:54:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=WUk/pG9VZiL9 H6tMSElKhr40YXk=; b=IJjSlDktDm2Lei5Ywyt3gZoy/Yg5A213+QnnKZTtFypU zUB/moemEDd9SE25ZLn5STu6jIrlTpiSK0LCi0fMIFg5oSdJBMOzrLPmlj1tnSPs OP/QzE96y5aVkAux0C6mpSkkFOIj6oX/Ct9sS9nXEEqJCDU8VgFI7iFTV237+9M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=g8QjGU agwBFbkf20T1lgCmP0ECOkH5ALs2TTnzUQHGyruQ3W0yQvdwAfl/FYvT4NID53u8 1HbUwemvfIilO095T1TG7RUqqAMnkw20CBD1QqydvNN843zwin6QvfTP0u6GHAXC QmfCWqYP+z5J2FJ7EqOCgDnLbmbeqRykqWpYw= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id CAD6E93B3; Thu, 19 Apr 2012 16:54:08 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 0A5F293B1; Thu, 19 Apr 2012 16:54:07 -0400 (EDT) Message-ID: <4F907B6E.3020704@pobox.com> Date: Thu, 19 Apr 2012 13:54:06 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CED469E2-8A61-11E1-94B9-B1B0728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 20:54:14 -0000 Nico Williams wrote: > Well, this: http://www.imperialviolet.org/2012/04/11/falsestart.html > leads me to think that concentrator changes are much harder to get > than you think. Google clearly worked very hard on False Start and > still came up short. And we think that a new OCSP stapling extension > will fare better?? Why would that be so?! False Start was not indicated by an extension, so a client could not know whether the server supported it. Google tried to blacklist known incompatible servers, but they were unable to reliably determine if a server needed to be blacklisted. A concentrator that doesn't implement OCSP stapling will just ignore the extension and proceed normally. Mike From marsh@extendedsubset.com Thu Apr 19 14:05:07 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD7811E8076 for ; Thu, 19 Apr 2012 14:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+26Rn-8k6Yy for ; Thu, 19 Apr 2012 14:05:06 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D321F845E for ; Thu, 19 Apr 2012 14:05:06 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SKyXK-000JL7-77 for tls@ietf.org; Thu, 19 Apr 2012 21:05:06 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 64C4E6067 for ; Thu, 19 Apr 2012 21:05:05 +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: U2FsdGVkX19ARntjR8VY1n/36QHU7tDTKn4ezuiXcTw= Message-ID: <4F8FF6BD.3020401@extendedsubset.com> Date: Thu, 19 Apr 2012 06:27:57 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: TLS Mailing List References: <4F8DCBD4.6090104@pobox.com> <4F8E6170.6070501@pobox.com> In-Reply-To: <4F8E6170.6070501@pobox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 21:05:07 -0000 On 04/18/2012 01:38 AM, Michael D'Errico wrote: > I discovered the lack of specs because I went looking for information > about how to implement SPDY. At this point there is wide deployment, > so we can't do much beyond rubber-stamping what implementations are > actually doing[*]. But having the existing behavior documented is > very important to make sure implementations are interoperable, as you > know. > > Sure I can sympathize with the need for Google to have experimented > and chosen some private values, but now that they're pushing for > wider adoption, it is their obligation to get those IANA > assignments. May 14, 2011 http://tools.ietf.org/id/draft-agl-tls-nextproto-00.txt > 5. IANA Considerations > > This document requires IANA to update its registry of TLS extensions > to assign an entry, referred herein as "next_protocol". > > This document also requires IANA to update its registry of TLS > handshake types to assign an entry, referred herein as > "next_protocol_ann". July 2011 https://technotes.googlecode.com/git/nextprotoneg.html > Implementations > > NPN has been implemented in NSS (patch), TLSLite (patch) and OpenSSL > (included in CVS, patch against 1.0.0d). > > A reference implementation server is running on port 443 of > www.google.com. On the client side, the Chrome web browser enables > NPN by default. Magic values > > For easy reference, this note uses the following magic numbers: > > Next protocol negotiation extension number 13172 > > NextProtocol handshake message number 67 October 3, 2011 https://bugzilla.mozilla.org/show_bug.cgi?id=547312#c9 > NP was an attempt by Paul Hoffman to make NPN more IETF friendly. I > don't believe that it has gone anywhere at all. As far as I know, > there are no implementations of it. > > If the IETF were to standardise an acceptable variant of NPN we > would look to transition over to it. That seems extremely unlikely at > this point. It reads to me like they were trying to do the right thing and the IETF/IANA process failed them. We had this problem with the RI extension too. As a practical matter, developers needed to start interop testing long before the ID was in last call status. It doesn't seem like a good idea to withhold numbers until last call. Those with a credible prospect of deploying and documenting a TLS extension ought to be able to reserve a number from the IANA for development and testing (and possible eventual adoption). Withholding numbers doesn't actually seem to dissuade anyone from developing extensions. It simply results in numbers being de facto allocated in an uncoordinated fashion: From http://hg.mozilla.org/mozilla-central/raw-file/c55ce76c8dac/security/nss/lib/ssl/sslt.h > typedef enum { > ssl_server_name_xtn = 0, > #ifdef NSS_ENABLE_ECC > ssl_elliptic_curves_xtn = 10, > ssl_ec_point_formats_xtn = 11, > #endif > ssl_session_ticket_xtn = 35, > ssl_next_proto_nego_xtn = 13172, > ssl_renegotiation_info_xtn = 0xff01 /* experimental number*/ > } SSLExtensionType; - Marsh From marsh@extendedsubset.com Thu Apr 19 14:31:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBA211E80C6 for ; Thu, 19 Apr 2012 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckPXWvjuv5ZQ for ; Thu, 19 Apr 2012 14:31:40 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5272811E80C5 for ; Thu, 19 Apr 2012 14:31:40 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SKyx1-000HIa-BH; Thu, 19 Apr 2012 21:31:39 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A476B6067; Thu, 19 Apr 2012 21:31:37 +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+e9j61u/oX4b0l06krJugcbOGqBPICJWY= Message-ID: <4F8FFCF5.9030202@extendedsubset.com> Date: Thu, 19 Apr 2012 06:54:29 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael D'Errico References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> <4F907B6E.3020704@pobox.com> In-Reply-To: <4F907B6E.3020704@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, aerowolf@gmail.com, Paul Hoffman Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 21:31:41 -0000 On 04/14/2012 12:43 PM, Paul Hoffman wrote: > > > Not a good sign for TLS changes that require field updates... > > --Paul Hoffman On 04/19/2012 03:54 PM, Michael D'Errico wrote: > Nico Williams wrote: >> Well, this: >> http://www.imperialviolet.org/2012/04/11/falsestart.html leads me >> to think that concentrator changes are much harder to get than you >> think. Google clearly worked very hard on False Start and still >> came up short. And we think that a new OCSP stapling extension >> will fare better?? Why would that be so?! > > False Start was not indicated by an extension, so a client could not > know whether the server supported it. I wonder why they didn't propose an extension to negotiate the use of False Start. Surely that would fix the server intolerance problem. From http://www.imperialviolet.org/2012/04/11/falsestart.html > The `servers' with problems were nearly always SSL terminators. Perhaps they didn't think the WG would adopt it and/or the servers would deploy support for it soon enough? I would love to support a revised version of the proposal http://tools.ietf.org/id/draft-bmoeller-tls-falsestart-00.txt that negotiated via a TLS extension. - Marsh From mrex@sap.com Thu Apr 19 14:52:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5EE11E80D7 for ; Thu, 19 Apr 2012 14:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.118 X-Spam-Level: X-Spam-Status: No, score=-10.118 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGaa0ZJ54bq0 for ; Thu, 19 Apr 2012 14:52:47 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 051AC11E80CF for ; Thu, 19 Apr 2012 14:52:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3JLqeDP026790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Apr 2012 23:52:40 +0200 (MEST) From: Martin Rex Message-Id: <201204192152.q3JLqdfg023250@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 19 Apr 2012 23:52:39 +0200 (MEST) In-Reply-To: <4F8FFCF5.9030202@extendedsubset.com> from "Marsh Ray" at Apr 19, 12 06:54:29 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com, paul.hoffman@vpnc.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 21:52:50 -0000 Marsh Ray wrote: > > I wonder why they didn't propose an extension to negotiate the use of > False Start. Surely that would fix the server intolerance problem. +1 > > Perhaps they didn't think the WG would adopt it and/or the servers would > deploy support for it soon enough? > > I would love to support a revised version of the proposal > http://tools.ietf.org/id/draft-bmoeller-tls-falsestart-00.txt > that negotiated via a TLS extension. +1, but I do not understand what kind of problem the Google proposal has with the RSA key exchange method. The functionality of FalseStart and the RSA key exchange method are completely orthogonal (i.e. unrelated). -Martin From nico@cryptonector.com Thu Apr 19 15:15:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A3911E80CD for ; Thu, 19 Apr 2012 15:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHviCk79pAjt for ; Thu, 19 Apr 2012 15:15:10 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7F99F11E80B8 for ; Thu, 19 Apr 2012 15:15:10 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 4EEAA28606F for ; Thu, 19 Apr 2012 15:15:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=R0OgBQ/njA+C09XiazEQB2jvwPgEeVadSmmEO5nEk7dh hlwHcexQNfNG/k7cKAot4BaT68skTVw9mzjTiixU4B9poPJxIe+cxcUaYMZlCUPL ryPLqqUDuiRn7cwMs2N5o6TXpl0Y4uWgL5FL6aSwfxALuG1/NiSlT9j7jxk5xj8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=sQ446vrgihXMOjVZLcubQXa2KE4=; b=eSKj4xirGuB NZGPpYloO3FRH/H3TtJG+aE+XoaoAdIs5zqlcD4A3VX9g0vakPUma+j39321cf4n LsGesavKv0VsaeCvzgeM9uJHhQfudIUpL/pR9E7ZAoLdKfYM+oWOgA8ExHK/Czqy oO3/yyVTFJN8+ytE37rPAmU6q1/pvSpk= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 35830286058 for ; Thu, 19 Apr 2012 15:15:10 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so299813pbb.31 for ; Thu, 19 Apr 2012 15:15:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.232 with SMTP id ih8mr7608516pbc.118.1334873709889; Thu, 19 Apr 2012 15:15:09 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 19 Apr 2012 15:15:09 -0700 (PDT) In-Reply-To: <4F907B6E.3020704@pobox.com> References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> <4F907B6E.3020704@pobox.com> Date: Thu, 19 Apr 2012 17:15:09 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 22:15:11 -0000 On Thu, Apr 19, 2012 at 3:54 PM, Michael D'Errico wro= te: > Nico Williams wrote: >> Well, this: http://www.imperialviolet.org/2012/04/11/falsestart.html >> leads me to think that concentrator changes are much harder to get >> than you think. =C2=A0Google clearly worked very hard on False Start and >> still came up short. =C2=A0And we think that a new OCSP stapling extensi= on >> will fare better?? =C2=A0Why would that be so?! > > False Start was not indicated by an extension, so a client could not > know whether the server supported it. =C2=A0Google tried to blacklist kno= wn > incompatible servers, but they were unable to reliably determine if a > server needed to be blacklisted. Ahhh, good point. > A concentrator that doesn't implement OCSP stapling will just ignore > the extension and proceed normally. Sure, ok. As long as this is just an optimization that's ok. Nico -- From marsh@extendedsubset.com Thu Apr 19 15:15:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD1F11E80C5 for ; Thu, 19 Apr 2012 15:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v0U4WbdgZ7c for ; Thu, 19 Apr 2012 15:15:36 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0345D11E80BB for ; Thu, 19 Apr 2012 15:15:36 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SKzdX-000Bvp-Hh; Thu, 19 Apr 2012 22:15:35 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB0666067; Thu, 19 Apr 2012 22:15:33 +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+Do2fzG5o8OFGQi+n9CXgBHRUXT1uHRC8= Message-ID: <4F900742.3060004@extendedsubset.com> Date: Thu, 19 Apr 2012 07:38:26 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201204192152.q3JLqdfg023250@fs4113.wdf.sap.corp> In-Reply-To: <201204192152.q3JLqdfg023250@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, aerowolf@gmail.com, paul.hoffman@vpnc.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 22:15:37 -0000 On 04/19/2012 04:52 PM, Martin Rex wrote: > > I do not understand what kind of problem the Google proposal > has with the RSA key exchange method. The functionality of FalseStart > and the RSA key exchange method are completely orthogonal (i.e. unrelated). The thing with FS is that it could allow an active attacker to manipulate the handshake in ways which are not detected by the client until it receives the server's Finished message. But the whole point of FS is that the client sends application data bearing ciphertext before he gets the server's Finished. So in general this would be a recipe for disaster (e.g. rollback attacks), except that certain ciphersuites might be judged "good enough" to use. For example, if the client sends the premaster secret by encrypting it with RSA to a properly-validated server cert, he might feel comfortable transmitting the app data encrypted with AES before knowing whether or not the handshake was manipulated. When using DHE, the Server Key Exchange message ("sent by the server only when the server certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret") would appear to authenticate the handshake to the client. Assuming he validated it before deciding to start falsely. There are other ways this could backfire. For example, if there were any extensions negotiated in the Hello exchange which were necessary for security. Are any extensions like that? I don't know. How about those extensions for the ECDH that "allow a client to negotiate the use of specific curves"? Certainly we'd have to be careful when adding future extensions how they might break in an FS environment. The ciphersuite selection could be faked. The attacker could trick the client into parsing a validly signed ServerRSAParams structure as a ServerDHParams structure, or vice versa. Nate Lawson feels that False Start is dangerous because of downgrade attacks, even allowing a BEAST attack. http://rdist.root.org/2012/02/27/ssl-optimization-and-security-talk/ Still, the prospect of saving half a round trip in latency is quite attractive. - Marsh From agl@google.com Thu Apr 19 15:16:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6658611E80C5 for ; Thu, 19 Apr 2012 15:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9v7BeKeoKhqu for ; Thu, 19 Apr 2012 15:16:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4409F11E80B8 for ; Thu, 19 Apr 2012 15:16:14 -0700 (PDT) Received: by iazz13 with SMTP id z13so15226565iaz.31 for ; Thu, 19 Apr 2012 15:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=NOnRFceBHQzN2lWNguVFm13qlMZNhcStIZv7KhKFqXA=; b=ehPMyg04MdaIS1hiReoWDtE73SXrJ6qE48c4FmnK+kwroIzoNYC9RL5/f7YNzMsVtK VaqXAbKJACNmAYC7d50Zz+OpDDEjPM3YkFdrYiM9BMu9mqq76hSbsn/OL2Pt4s7Gdj2W nhcnrcoC5TF3oQwqdD0rP1g87P5Nj5sIDOiOE0l4R6VtH36OmnSFnFhJiMl0AmK6WmDY 9eJcMYiXNHaffdK04MvWkZPtvJWbrtSXW96OD9zTD7jplY/v6NPCve4zZ4CMOX4V384/ vGV7FxzpkaYjAQwRRZ/aow0sjJH5vwV+QqXJlQs7+OFv3ifviXbQcnaIzcyXW2YMdczk zR0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=NOnRFceBHQzN2lWNguVFm13qlMZNhcStIZv7KhKFqXA=; b=Yt+5ilwAmjTML8RdzcnJC3LTwgrun3ZySvGMbfn8wcS5yCJF3xpr97sPET54wK6vDu X4vafdrE9kyzYsQtki3gJ0L4N3f72Q0Dfyu+TeZNsVrXkgVKaszvi9/mDBC3dT5pZHpO lP0i8UVvT0yA3/dzE8RK1ra3MDIvZVe8rsbju4UBbzoWty0pNmwAV0R2p5HNCRlV6k+r dx//geEF1xxfzNHY9CzTH4t87eVkXgmYwT/CaybUEYyA9rJhqB1LvfnA2j4JUf+4TFqp gV2B41KBmWCJXcqtMc0Ma+XYKW/mYUhhsJ99uwGB1hdu7zrBe5DqqZmsYp61UXG6gT/8 ff5g== Received: by 10.50.186.231 with SMTP id fn7mr3978457igc.15.1334873773948; Thu, 19 Apr 2012 15:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.186.231 with SMTP id fn7mr3978446igc.15.1334873773873; Thu, 19 Apr 2012 15:16:13 -0700 (PDT) Sender: agl@google.com Received: by 10.231.189.95 with HTTP; Thu, 19 Apr 2012 15:16:13 -0700 (PDT) In-Reply-To: <4F8FFCF5.9030202@extendedsubset.com> References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> <4F907B6E.3020704@pobox.com> <4F8FFCF5.9030202@extendedsubset.com> Date: Thu, 19 Apr 2012 18:16:13 -0400 X-Google-Sender-Auth: KwaplXdC_E7hjSgOrgZoyGc9wJA Message-ID: From: Adam Langley To: Marsh Ray Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQndyxQoKoogd6oNbKo/COEsTktYlYCDb52iA9IbRWhwBFDAMkbwBSBx9HHk5r/pPMIyyLOWWlUbKAvK8+v4Gu5WUtdXXtJTBlstrNOa7a61fcwHXjnd3zZwHW2EZo2QJR7+meho Cc: tls@ietf.org, aerowolf@gmail.com, Paul Hoffman Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 22:16:21 -0000 On Thu, Apr 19, 2012 at 7:54 AM, Marsh Ray wrote: > I wonder why they didn't propose an extension to negotiate the use of > False Start. Surely that would fix the server intolerance problem. We wanted to try and speed up everything. Negotiating via an extension significantly limits deployment as servers are rarely updated. The hope was that the fallout would be limited and that we could clean up HTTPS servers to the point where other clients could choose to enable False Start without significant compatibility concerns. That didn't work out I'm afraid. > I would love to support a revised version of the proposal > http://tools.ietf.org/id/draft-bmoeller-tls-falsestart-00.txt > that negotiated via a TLS extension. As of Chrome 20, False Start will be limited to servers supporting NPN and forward secrecy. As that effectively limits it to Google servers I'd be quite happy to respin the draft with an explicit extension number if the WG will take it. (I guess the answer is to propose it and see.) Cheers AGL From nico@cryptonector.com Thu Apr 19 15:17:02 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32DA11E80BB for ; Thu, 19 Apr 2012 15:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqwDQPGULQ5m for ; Thu, 19 Apr 2012 15:17:02 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADE11E80B8 for ; Thu, 19 Apr 2012 15:17:02 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id B9DE8584059 for ; Thu, 19 Apr 2012 15:17:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=qgZicPvHUZDi0NIh0e+7y XonhKREaW1/JuzxvPcBNSbEXB795olkp4RjEO/xD957C0FqUFaPukQdtsFrrzDd8 XPtXQCOBVpX2H6nCFsBE8eamSKUC1/VwpXCkAkp4zjdTPcLnBSenKP2N8I+U5fn2 dkFLPQZFL14TnP0SASQK1c= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=30t8kP09wcP4ND0d2Yty 4I8Q7hs=; b=M+O5ImW2Wo/K6jtGv65yGmzWCzS2t6fEB83f5a11pCa9QD33CmnS dCDMfwehokeWcJLQRQmTQM68LJRCeIo8floviGOta6fvCmOls0E8RDkKiuJH7Bu2 ryG2BxJbIvhEpPgOKF47sXiLeZoTzlVuSPG9gnRiwIVVNsgotiMTuM8= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id A13D5584057 for ; Thu, 19 Apr 2012 15:17:01 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so301335pbb.31 for ; Thu, 19 Apr 2012 15:17:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.71 with SMTP id ic7mr7742972pbc.34.1334873821346; Thu, 19 Apr 2012 15:17:01 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 19 Apr 2012 15:17:01 -0700 (PDT) In-Reply-To: <4F8FFCF5.9030202@extendedsubset.com> References: <201204191933.q3JJXbw4015580@fs4113.wdf.sap.corp> <4F907B6E.3020704@pobox.com> <4F8FFCF5.9030202@extendedsubset.com> Date: Thu, 19 Apr 2012 17:17:01 -0500 Message-ID: From: Nico Williams To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org, aerowolf@gmail.com, Paul Hoffman Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 22:17:03 -0000 On Thu, Apr 19, 2012 at 6:54 AM, Marsh Ray wrote: > Perhaps they didn't think the WG would adopt it and/or the servers would > deploy support for it soon enough? Dunno. Suppose it'd worked? Then it would have been wonderful that it requires no server changes. So that's my guess: Google was hoping to have an optimization that works instantly with no changes required on servers. > I would love to support a revised version of the proposal > http://tools.ietf.org/id/draft-bmoeller-tls-falsestart-00.txt > that negotiated via a TLS extension. Agreed. Nico -- From nico@cryptonector.com Thu Apr 19 15:30:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133FA11E80CE for ; Thu, 19 Apr 2012 15:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfqyolQQOuKt for ; Thu, 19 Apr 2012 15:30:24 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5836811E80C1 for ; Thu, 19 Apr 2012 15:30:24 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id BEB4ABC042 for ; Thu, 19 Apr 2012 15:30:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=hpU3mv97+cGfur7P4H/Jg mE7zUiw4/DvXRpi1J3e7bybUww9nr52truq7aOW6xlw4ANPdtxMUxiSxzIaNj4fX lylVZ5T6zLJ9mTCqORB63C6snLYzcJQ+cJjpWu4hJf6K5Gim51ZOTg8vQvligxz6 JTDkXQeK10F1xQ6o2okgBs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=xzYjUg79JCZFGxH7sgSo Vw/0nvI=; b=jbFNncE9MfzMWa6JwGRFzle/ltXipBngwgZjWNtxK5TNZuSY4T2R ml9d2nxvDMaCCOjIydeTq1RBLakhb25/BuUUhZECZDhir6+trciQB0XNK3nSvd7M vXmIYItPqyrogx/22ggNFMYXD1fibSaxzo+OB03sYjQOMZ3v548/m3I= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id AD672BC005 for ; Thu, 19 Apr 2012 15:30:23 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so311897pbb.31 for ; Thu, 19 Apr 2012 15:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.232 with SMTP id ih8mr7692489pbc.118.1334874618330; Thu, 19 Apr 2012 15:30:18 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 19 Apr 2012 15:30:18 -0700 (PDT) In-Reply-To: <4F8FF6BD.3020401@extendedsubset.com> References: <4F8DCBD4.6090104@pobox.com> <4F8E6170.6070501@pobox.com> <4F8FF6BD.3020401@extendedsubset.com> Date: Thu, 19 Apr 2012 17:30:18 -0500 Message-ID: From: Nico Williams To: Marsh Ray Content-Type: text/plain; charset=UTF-8 Cc: TLS Mailing List Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 22:30:26 -0000 On Thu, Apr 19, 2012 at 6:27 AM, Marsh Ray wrote: > It reads to me like they were trying to do the right thing and the IETF/IANA > process failed them. Not IANA. The IETF failed them. > We had this problem with the RI extension too. As a practical matter, > developers needed to start interop testing long before the ID was in last > call status. This has happened quite a bit in other areas too (e.g., the IKEv2 NAT-T extensions, IIIRC). Part of the problem is that during development the protocol is still fluid and you don't want code to get deployed that later fails to interop when the final protocol ends up differing from an earlier version. For non-scarce namespaces the solution is to just make allocations liberally. And for scarce ones? I think we could use a standard policy that requires, say, just WG chair and AD approval -- something less that IESG Approval, more than FCFS, something akin to Expert Review but requiring wider consensus yet being light-weight. The problem is that we can't require WG consensus or WG chair approval for allocations because WGs are not stable -- we'd need a method for updating which WG's chairs (if any applicable WG remains) need to approve. Ditto ADs, as it's possible to have the IESG re-organized. But IESG Approval is a bit heavy-duty, I think (maybe I'm wrong about that). > Withholding numbers doesn't actually seem to dissuade anyone from developing > extensions. It simply results in numbers being de facto allocated in an > uncoordinated fashion: Bingo. But I don't think this is just a matter of the IETF being too conservative in selecting allocation policies for registries. That's only part of it. The other part is that we need an allocation policy that is lightweight yet faster/simpler than Expert Review and also requiring approval by an authority that can confirm the existence of consensus for the allocation. The bodies that would provide that confirmation are ephemeral. Nico -- From mrex@sap.com Thu Apr 19 16:04:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4170C11E8083 for ; Thu, 19 Apr 2012 16:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.121 X-Spam-Level: X-Spam-Status: No, score=-10.121 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6tpU4Wk584p for ; Thu, 19 Apr 2012 16:04:54 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0952E11E8081 for ; Thu, 19 Apr 2012 16:04:53 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3JN4nOI011454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 01:04:49 +0200 (MEST) From: Martin Rex Message-Id: <201204192304.q3JN4mJ4027348@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 20 Apr 2012 01:04:48 +0200 (MEST) In-Reply-To: <4F900742.3060004@extendedsubset.com> from "Marsh Ray" at Apr 19, 12 07:38:26 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, aerowolf@gmail.com, tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:04:55 -0000 Marsh Ray wrote: > > On 04/19/2012 04:52 PM, Martin Rex wrote: > > > > I do not understand what kind of problem the Google proposal > > has with the RSA key exchange method. The functionality of FalseStart > > and the RSA key exchange method are completely orthogonal (i.e. unrelated). > > The thing with FS is that it could allow an active attacker to > manipulate the handshake in ways which are not detected by the client > until it receives the server's Finished message. But the whole point of > FS is that the client sends application data bearing ciphertext before > he gets the server's Finished. > > So in general this would be a recipe for disaster (e.g. rollback > attacks), except that certain ciphersuites might be judged "good enough" > to use. For example, if the client sends the premaster secret by > encrypting it with RSA to a properly-validated server cert, he might > feel comfortable transmitting the app data encrypted with AES before > knowing whether or not the handshake was manipulated. > > When using DHE, the Server Key Exchange message ("sent by the server > only when the server certificate message (if sent) does not contain > enough data to allow the client to exchange a premaster secret") would > appear to authenticate the handshake to the client. Assuming he > validated it before deciding to start falsely. I fail to understand what protection DHE provides over RSA. http://tools.ietf.org/html/rfc5246#page-52 struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ }; } ServerKeyExchange; The digital signature in the ServerKeyExchange handshake message IMO provides none such protection. The client_random is under full control of the attacker, the server_random is unpredictable by the client and whether the KeyExchange is performed with signed ServerDHParams or the public RSA key from the server cert is orthogonal to FalseStart. Maybe the client does not want to use FalseStart if the encryption strength of the server-selected cipher suite is poor, but since there is nothing in DHE ServerKeyExchange that would protect TLS extensions or the ciphersuite, I don't see a rationale why DHE is OK and RSA not. > > There are other ways this could backfire. For example, if there were any > extensions negotiated in the Hello exchange which were necessary for > security. Are any extensions like that? I don't know. How about those > extensions for the ECDH that "allow a client to negotiate the use of > specific curves"? Certainly we'd have to be careful when adding future > extensions how they might break in an FS environment. FalseStart only makes sense in an environment, where the confidentiality protection applied to application data that is optimistically sent ahead of the handshake completion is deemed adequately strong to not be susceptible to brute force decryption or iterative guessing. But that depends on the PRF (which depends on the TLS protocol version), the symmetric cipher strength and the strength of the key exchange algorithm in general, but not on whether the latter is DHE vs RSA. > > Still, the prospect of saving half a round trip in latency is quite > attractive. It's half a round trip in the handshake tokens, and either nothing or a full round-trip on the initial communication overhead. For HTTP/1.x, where the client sends the request, there is *NO* saving on the abbreviated handshake (aka session resume). Unless either the server's or the client's tls session management is significantly screwed, or majority of elements on the pages are completely scattered all over different servers, the performance benefit will be in the noise. On reasonably configured, high-load servers I see full handshake : resumes 98 : 2 if TLS session caching _works_. And if session caching doesn't work, I see the CPU cores getting maxed out, so that the saved roundtrip latency on the full handshake is more than compensated by the CPU contention... -Martin From mrex@sap.com Thu Apr 19 16:10:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA83711E80BE for ; Thu, 19 Apr 2012 16:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbKcd1Uki3Zj for ; Thu, 19 Apr 2012 16:10:39 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED0121F8484 for ; Thu, 19 Apr 2012 16:10:32 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3JNAR4H004038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 01:10:27 +0200 (MEST) From: Martin Rex Message-Id: <201204192310.q3JNAQ5q027525@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 20 Apr 2012 01:10:26 +0200 (MEST) In-Reply-To: <201204192304.q3JN4mJ4027348@fs4113.wdf.sap.corp> from "Martin Rex" at Apr 20, 12 01:04:48 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:10:50 -0000 Typo on the full handshake : session resumes. 2 : 98 Sorry, -Martin Martin Rex wrote: > > Marsh Ray wrote: > > > > On 04/19/2012 04:52 PM, Martin Rex wrote: > > > > > > I do not understand what kind of problem the Google proposal > > > has with the RSA key exchange method. The functionality of FalseStart > > > and the RSA key exchange method are completely orthogonal (i.e. unrelated). > > > > The thing with FS is that it could allow an active attacker to > > manipulate the handshake in ways which are not detected by the client > > until it receives the server's Finished message. But the whole point of > > FS is that the client sends application data bearing ciphertext before > > he gets the server's Finished. > > > > So in general this would be a recipe for disaster (e.g. rollback > > attacks), except that certain ciphersuites might be judged "good enough" > > to use. For example, if the client sends the premaster secret by > > encrypting it with RSA to a properly-validated server cert, he might > > feel comfortable transmitting the app data encrypted with AES before > > knowing whether or not the handshake was manipulated. > > > > When using DHE, the Server Key Exchange message ("sent by the server > > only when the server certificate message (if sent) does not contain > > enough data to allow the client to exchange a premaster secret") would > > appear to authenticate the handshake to the client. Assuming he > > validated it before deciding to start falsely. > > I fail to understand what protection DHE provides over RSA. > > http://tools.ietf.org/html/rfc5246#page-52 > > struct { > select (KeyExchangeAlgorithm) { > case dh_anon: > ServerDHParams params; > case dhe_dss: > case dhe_rsa: > ServerDHParams params; > digitally-signed struct { > opaque client_random[32]; > opaque server_random[32]; > ServerDHParams params; > } signed_params; > case rsa: > case dh_dss: > case dh_rsa: > struct {} ; > /* message is omitted for rsa, dh_dss, and dh_rsa */ > /* may be extended, e.g., for ECDH -- see [TLSECC] */ > }; > } ServerKeyExchange; > > The digital signature in the ServerKeyExchange handshake message > IMO provides none such protection. > > The client_random is under full control of the attacker, the server_random > is unpredictable by the client and whether the KeyExchange is performed > with signed ServerDHParams or the public RSA key from the server cert > is orthogonal to FalseStart. > > Maybe the client does not want to use FalseStart if the encryption > strength of the server-selected cipher suite is poor, but since there > is nothing in DHE ServerKeyExchange that would protect TLS extensions > or the ciphersuite, I don't see a rationale why DHE is OK and RSA not. > > > > > > There are other ways this could backfire. For example, if there were any > > extensions negotiated in the Hello exchange which were necessary for > > security. Are any extensions like that? I don't know. How about those > > extensions for the ECDH that "allow a client to negotiate the use of > > specific curves"? Certainly we'd have to be careful when adding future > > extensions how they might break in an FS environment. > > > FalseStart only makes sense in an environment, where the confidentiality > protection applied to application data that is optimistically sent > ahead of the handshake completion is deemed adequately strong to > not be susceptible to brute force decryption or iterative guessing. > > But that depends on the PRF (which depends on the TLS protocol > version), the symmetric cipher strength and the strength of the > key exchange algorithm in general, but not on whether the latter > is DHE vs RSA. > > > > > > Still, the prospect of saving half a round trip in latency is quite > > attractive. > > It's half a round trip in the handshake tokens, and either nothing or a > full round-trip on the initial communication overhead. > > For HTTP/1.x, where the client sends the request, there is *NO* saving > on the abbreviated handshake (aka session resume). > > Unless either the server's or the client's tls session management is > significantly screwed, or majority of elements on the pages are completely > scattered all over different servers, the performance benefit will be > in the noise. On reasonably configured, high-load servers I see > > full handshake : resumes > > 98 : 2 > > if TLS session caching _works_. > > And if session caching doesn't work, I see the CPU cores getting maxed out, > so that the saved roundtrip latency on the full handshake is more > than compensated by the CPU contention... > > > -Martin > From ekr@rtfm.com Thu Apr 19 16:15:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2B221F845A for ; Thu, 19 Apr 2012 16:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.83 X-Spam-Level: X-Spam-Status: No, score=-102.83 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcwUKb3mAkYS for ; Thu, 19 Apr 2012 16:15:19 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 953D921F855B for ; Thu, 19 Apr 2012 16:15:19 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7054913vbb.31 for ; Thu, 19 Apr 2012 16:15:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=/U8IWSO1ossW3rc3fLhZwqk2MhSrcGp/BstwpC7FQO4=; b=mFG9uawAiJ5coaJkc0jPpnkp94WHpwZasu6FjC3e3ZsVvJVeBYcN3EqEsZFg9tYZOx jERpRxdBazbxeV9ZuBHvLnDjGgeBK6flU21ZfLgNCAFFh/QMB3H5e6C/07EG5mArz89M ciLPd1SesDzLSVrHih31b+LrwZULzplQb3CmoAYMX40VUp8aC2JY3yVXQIeyAjANFLVP OjSx1aUeB3IIXPK5BviENIHy6Mo3KBmNxtimx5qltHR3ySMI+bfJAWCoXRoNi+yqLcCJ yEvL3gPWWYoGiZSsAY4GcE4AUKH3qsfN6uHbf3qKe/+Q2emaIzsaVY04N7L3sEDVXZLk 52Gg== Received: by 10.52.65.134 with SMTP id x6mr1861031vds.60.1334877318894; Thu, 19 Apr 2012 16:15:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 19 Apr 2012 16:14:38 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4F8FF6BD.3020401@extendedsubset.com> References: <4F8DCBD4.6090104@pobox.com> <4F8E6170.6070501@pobox.com> <4F8FF6BD.3020401@extendedsubset.com> From: Eric Rescorla Date: Thu, 19 Apr 2012 16:14:38 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmockaVKq35HFUQbjQiwzWyRNWCPUW1b0fc+bjb6quUagX9VJAvNQt36mNlhdAp1M3Rbu2d Cc: TLS Mailing List Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:15:20 -0000 On Thu, Apr 19, 2012 at 4:27 AM, Marsh Ray wrote: > On 04/18/2012 01:38 AM, Michael D'Errico wrote: > It doesn't seem like a good idea to withhold numbers until last call. Those > with a credible prospect of deploying and documenting a TLS extension ought > to be able to reserve a number from the IANA for development and testing > (and possible eventual adoption). I don't see what "last call" has to do with it. This document has no formal IETF status of any kind. I don't have a problem with pre-allocating numbers for WG drafts, but that is not in fact the case here. Note that one of the code points being used here is a "handshake_type", which is allocated out of a 8-bit space. There are good reasons not to have this space FCFS. -Ekr From agl@google.com Thu Apr 19 16:20:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614F421F858B for ; Thu, 19 Apr 2012 16:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVPR-te0G0aP for ; Thu, 19 Apr 2012 16:20:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5905621F858A for ; Thu, 19 Apr 2012 16:20:43 -0700 (PDT) Received: by iazz13 with SMTP id z13so15296919iaz.31 for ; Thu, 19 Apr 2012 16:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=l1LHRIuvkSAU2+EHMY0V20ACVkLfon0DrSD+cZ+MN2E=; b=oQA7PcKqC5L2JuGtPUQedQtRG91+nCwKUWHlTrN71cswEMyMmX+RN/aDV5PHDitmmp 8JynkkDSNEspSsG49nsgARX/y0qxI2fzooGjFlTS8Sv+50DPcRgkF4bEzxsWA5vHFTzB lPVe+3TDVCntZ+yVFR5bqVwqnGwNBpu6e1p2ZYg2ztA6tv2RBFqIzT/o0i1g9sVKbOpH 5fwhzA8aus6irQROZNNcgu9Xb4fs2vpkeH3/5WfvbMiQzHukSOsL8qPoNmF8d1A2eBNf mnyJK4pPwnmYGqTguYxI1Pk88VtkeIhVK8+jT0CwY2lIY5Ehenemn4/pYu4ztnz/QkgO Dhuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=l1LHRIuvkSAU2+EHMY0V20ACVkLfon0DrSD+cZ+MN2E=; b=N7PmA5iZwOmtEwwPIYIT9Ky+uS578JXL8qEHHtlas1zDxOi2+g5wh3hek2w56oen+7 0f4l3EI/Wcxpzy1EqdjcvbhCDoqWV8AJA/3fvRIgUjH8VFutSwCzOt+I9EiE7i79ip+2 14MfvP0iyjEkt3Be4LLF57K9xBtu94lUqxMOnsKU8Y6Z8KqKcbqVJ2K9NX2kuAsQfgzb YMyC2O3QL0lvCINRBJpeUBRv1feJLbSH2ZzOxjFsm1rQFXPKApWz4tHgKitfDlPLTDks kIcB/wfBNjXzD98i/NYLeOQ5I6oARojZmC9UuZWvKtT+CSTmnyi+krVrdTGZRH36svN8 ZlKQ== Received: by 10.50.186.231 with SMTP id fn7mr4074620igc.15.1334877643058; Thu, 19 Apr 2012 16:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.186.231 with SMTP id fn7mr4074609igc.15.1334877642980; Thu, 19 Apr 2012 16:20:42 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Thu, 19 Apr 2012 16:20:42 -0700 (PDT) In-Reply-To: <201204192310.q3JNAQ5q027525@fs4113.wdf.sap.corp> References: <201204192304.q3JN4mJ4027348@fs4113.wdf.sap.corp> <201204192310.q3JNAQ5q027525@fs4113.wdf.sap.corp> Date: Thu, 19 Apr 2012 19:20:42 -0400 Message-ID: From: Adam Langley To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkpcccFqT/1V1ECfkqKf7Durf6WO7Pn2plPLQwEkPX++lfPXvqhhgosGnL+9FhkSg+2rPkAs2yJCFMg9xUhb1wJ3xvzrbSvbj/JNocZvMYq7ayTIMtk3s2uQhbNZWbPr3YuRZLg Cc: paul.hoffman@vpnc.org, aerowolf@gmail.com, tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:20:44 -0000 On Thu, Apr 19, 2012 at 7:10 PM, Martin Rex wrote: > Typo on the =C2=A0full handshake : session resumes. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 = =C2=A0 =C2=A0 =C2=A0: =C2=A0 =C2=A098 DHE/ECDHE makes a difference because, otherwise, an attacker can make the client send data in a non-forward secure fashion by playing with the handshake. (I don't believe that the signature in the ServerKeyExchange signs anything useful in this situation.) To the other point, your resumption rates are a lot better than mine :) None the less, as a client, browsers frequently hit sites without session resumption information. Either because it's a site that we've never visited before, or because resumption information is only kept in memory and browsers get restarted quite often. The extra RTT to the server (without False Start) delays the fetch of the initial HTML. That HTML frequently references blocking resources on another HTTPS server, which, in turn, do the same thing. It's not uncommon to go 3, 4 or even 5 layers deep with this. So we end taking 3, 4, or 5 extra RTTs due to the full handshakes. That's why it's so attractive to remove round trips. Also keep in mind that our biggest transport security problem is that most sites don't use TLS at all and part of the reason is because of the additional latency. So there's always complex tradeoffs between speed and security in this domain. Cheers AGL From ekr@rtfm.com Thu Apr 19 16:21:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8A21F858F for ; Thu, 19 Apr 2012 16:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.838 X-Spam-Level: X-Spam-Status: No, score=-102.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWeeUw6ZWGAj for ; Thu, 19 Apr 2012 16:21:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B47F21F858A for ; Thu, 19 Apr 2012 16:21:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7057930vbb.31 for ; Thu, 19 Apr 2012 16:21:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=urXcH76M2ml0j7/qtFRve4jZovdRzE6aW8obAUJw3go=; b=mk8cPLsJPkSzSRJVLW+UqVKBpYy52D/LzmQiriG3kt+gS8cDsrm/u9IYsDzzarTnbE B6Y0SLgHFJLDTf6sjWf1cw6G1A9GtJcE1uZ5dwCZQJe2Tc9mibSJfUo+nHzVrXVos/BF qUcos/0zVji9a0WGk1jocJ4JKacDp/16fAavh5AhfUyfWrnwNnb6mgbclBrMOnMnV4TM T+u3/L2dRHiP/alq4/2EmgvypVNkhdJ4hT7AT5TJPjVK8zBLQ2WB+D2u+ApPcH1I1CCk WT6ymjLb1SlFq8I+lMh0lWypRWe9dZOcie10etjojtsbIV/FF32N29R/gY0r/tUHSX6v o9Kw== Received: by 10.52.75.105 with SMTP id b9mr1927060vdw.26.1334877679830; Thu, 19 Apr 2012 16:21:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.19.233 with HTTP; Thu, 19 Apr 2012 16:20:38 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <201204192048.q3JKmsmY019775@fs4113.wdf.sap.corp> References: <201204192048.q3JKmsmY019775@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Thu, 19 Apr 2012 16:20:38 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnOLpzzd6+LAx+tSHy3g4Mw6csBKgGXIyMrVJjeZ3KbVpiOXZaM78dQsH/XO5hkYVEb+IY5 Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 23:21:21 -0000 On Thu, Apr 19, 2012 at 1:48 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> > =A0- the real issue is about the management operation itself on the se= rver. >> > =A0 obtaining a new certificate from the CA typically requires mutual >> > =A0 authentication, whereas obtaining a fresh OCSP staple can be >> > =A0 performed over an insecure channel (followed by a validation that >> > =A0 the info is valid). >> >> The assumption behind short-lived certiifcates is that they will be >> provided over a public channel without authentication, precisely >> as new OCSP responses can be. Certificates are public information >> so as long as nothing has changed, you just reissue with the >> same key. > > Sounds like an additional, brand-new enrollment protocol. There's no additional enrollment involved. You just HTTP fetch the certificate from a specified location in the cert. -Ekr From marsh@extendedsubset.com Thu Apr 19 18:37:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0E321F860D for ; Thu, 19 Apr 2012 18:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gcvzUmC05wA for ; Thu, 19 Apr 2012 18:37:38 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC0621F8611 for ; Thu, 19 Apr 2012 18:37:38 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SL2n3-000243-NX; Fri, 20 Apr 2012 01:37:37 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B52046067; Fri, 20 Apr 2012 01:37:35 +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: U2FsdGVkX18gbcFKsBelV03iGDsAJmxq7b/Z7vPIcBk= Message-ID: <4F901608.3000201@extendedsubset.com> Date: Thu, 19 Apr 2012 08:41:28 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201204192304.q3JN4mJ4027348@fs4113.wdf.sap.corp> In-Reply-To: <201204192304.q3JN4mJ4027348@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, aerowolf@gmail.com, paul.hoffman@vpnc.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 01:37:39 -0000 On 04/19/2012 06:04 PM, Martin Rex wrote: > > I fail to understand what protection DHE provides over RSA. > > http://tools.ietf.org/html/rfc5246#page-52 > > struct { > select (KeyExchangeAlgorithm) { > case dh_anon: > ServerDHParams params; > case dhe_dss: > case dhe_rsa: > ServerDHParams params; > digitally-signed struct { > opaque client_random[32]; > opaque server_random[32]; > ServerDHParams params; > } signed_params; > case rsa: > case dh_dss: > case dh_rsa: > struct {} ; > /* message is omitted for rsa, dh_dss, and dh_rsa */ > /* may be extended, e.g., for ECDH -- see [TLSECC] */ > }; > } ServerKeyExchange; > > The digital signature in the ServerKeyExchange handshake message > IMO provides none such protection. Yes, you're right. I was misremembering. Probably thinking of the Certificate Verify message, but of course that's in the other direction. > The client_random is under full control of the attacker, the server_random > is unpredictable by the client Well, interestingly, the client_random and server_random actually are signed along with the DH params. So at least the client can verify those values. I don't know why they didn't just sign over a hash of all handshake messages to that point like in Cert Verify. A design decision from back when there was only one protocol version supporting DHE at all and no extensions to worry about. > FalseStart only makes sense in an environment, where the confidentiality > protection applied to application data that is optimistically sent > ahead of the handshake completion is deemed adequately strong to > not be susceptible to brute force decryption or iterative guessing. I think we should remember too that it's always the client's choice whether or not to start falsely. Even if it were a negotiated protocol feature it wouldn't commit the client to anything in advance, it only relaxes a sequencing constraint. It also seems to require an API change: application code needs to hand the TLS stack some data in advance of a successful handshake result. Apps need to opt-in consciously. I usually object to this line of reasoning, but it seems like the worst case is it turns out to be an exploitable browser bug of the sort that requires a MitM, less attractive to attackers than the drive-by exploitable sort of bug patched every week or two. So if a few closely-maintained client apps like browser vendors want to opt-in to it, that sounds like an honest risk-reward decision. - Marsh From ekr@rtfm.com Thu Apr 19 19:10:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5011E809D for ; Thu, 19 Apr 2012 19:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.203 X-Spam-Level: X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-G7fOw6dthG for ; Thu, 19 Apr 2012 19:10:45 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9211E8097 for ; Thu, 19 Apr 2012 19:10:45 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so480315pbb.31 for ; Thu, 19 Apr 2012 19:10:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=dPAPFhpJwDz/7MoF4SGygbrvekmKYEhGXgv6FXr8fTA=; b=nG/Q8mzbjMfKsav6lCzvzQjmAsFcktOXB2vlCNBEFEc1ALDsku+PMAGe74gV3K571e hvwT7KuLGcPhZ+fhs61a16KMzuhXLVb1OAR6ZfF0MQOCf9lY4usXlq7BgZf6i53PfZAb EC4+38uxrm1g19gH4wZg84dnO0iwZD1VqVGonfdYbTJ4j8sA8rxWQfLq8nUT6733pmVj f3/EzRc4jFpmKGxfKUuxLIV6isbAr9eAxciwUMNxIvnYHI0M9/SmJdWDIRGRBy8ngbV4 x3zZFFsVmgLjQGdYWSTssEgPTYHVxGFr3uwO0GFVeRQAhFvYusYPtHrTEK5Awl7f4J6U 3ilg== Received: by 10.68.229.73 with SMTP id so9mr3154041pbc.163.1334887845550; Thu, 19 Apr 2012 19:10:45 -0700 (PDT) Received: from [10.81.194.12] (mobile-166-205-137-118.mycingular.net. [166.205.137.118]) by mx.google.com with ESMTPS id uf3sm3852115pbc.67.2012.04.19.19.10.43 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 Apr 2012 19:10:44 -0700 (PDT) References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B176) From: Eric Rescorla Date: Thu, 19 Apr 2012 19:10:41 -0700 To: Geoffrey Keating X-Gm-Message-State: ALoCoQnW3lD9K32HSdmYyIRG7mN9GejraDWP6pYAoA6F3pxwNLZJcZWSwq62nOHwjEJ2VMrNOe6n Cc: "tls@ietf.org" , "aerowolf@gmail.com" Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:10:46 -0000 Good news. Thanks On Apr 19, 2012, at 13:34, Geoffrey Keating wrote: > Eric Rescorla writes: >=20 >> On Wed, Apr 18, 2012 at 10:36 PM, Nico Williams w= rote: >>> On Thu, Apr 19, 2012 at 12:03 AM, Eric Rescorla wrote: >>>> On Wed, Apr 18, 2012 at 9:59 PM, Nico Williams w= rote: >>>>> OCSP stapling cons: >>>>>=20 >>>>> - software/firmware changes required on TLS servers >>>>=20 >>>> This is required as well for auto-refreshing of short-lived certs, and >>>=20 >>> Not really: if there are any interfaces suitable for automation you >>> can just automate the periodic installation of new certs. >>=20 >> You wish. :) >>=20 >> I believe that changing a cert in Apache, at least, involves >> a restart. >=20 > You can typically do it using 'apachectl graceful' without an > interruption to service, the same as any other Apache configuration > change. From marsh@extendedsubset.com Thu Apr 19 19:28:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA72821E801A for ; Thu, 19 Apr 2012 19:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB4xmKwUIry9 for ; Thu, 19 Apr 2012 19:28:13 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3F57321E800F for ; Thu, 19 Apr 2012 19:28:13 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SL3a0-0000NC-S9; Fri, 20 Apr 2012 02:28:12 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A4FAD6067; Fri, 20 Apr 2012 02:28:11 +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: U2FsdGVkX18/v9G9D7tuKZUpTdn1zutOpntaY2QeF3E= Message-ID: <4F9021E4.80802@extendedsubset.com> Date: Thu, 19 Apr 2012 09:32:04 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Eric Rescorla References: <4F8DCBD4.6090104@pobox.com> <4F8E6170.6070501@pobox.com> <4F8FF6BD.3020401@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: TLS Mailing List Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:28:14 -0000 On 04/19/2012 06:14 PM, Eric Rescorla wrote: > On Thu, Apr 19, 2012 at 4:27 AM, Marsh Ray wrote: >> On 04/18/2012 01:38 AM, Michael D'Errico wrote: >> It doesn't seem like a good idea to withhold numbers until last call. Those >> with a credible prospect of deploying and documenting a TLS extension ought >> to be able to reserve a number from the IANA for development and testing >> (and possible eventual adoption). > > I don't see what "last call" has to do with it. My understanding from the RFC 5746 process was that 'In Last Call' status was the usual requirement to get an assignment. I think I got that impression from someone who was not particularly involved in [TLS] though. > This document has no formal > IETF status of any kind. I don't have a problem with pre-allocating numbers > for WG drafts, but that is not in fact the case here. I'd say that there's no set-in-stone policy against numbers for work-in-progress drafts is good news. I don't know what exactly happened to make them believe that pursuing an RFC for False Start was a lost cause. > Note that one of the code points being used here is a "handshake_type", > which is allocated out of a 8-bit space. There are good reasons not to > have this space FCFS. Certainly these things need to be managed carefully. However, in the 2.5 years or so I've been following [TLS] I think I've seen maybe 2 or 3 proposals that involved a new handshake record type. If by some strange (i.e., poorly coordinated) circumstances we ended up running low on free code points, we could easily assign one to indicate the presence of additional field at the beginning of the handshake data. As it stands today a large percentage of web browsers will be using TLS extension type 13172 and handshake record type 67 for a specific purpose. Somebody ought to write this down somewhere, it might as well be the IANA. - Marsh From mrex@sap.com Thu Apr 19 19:49:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053F11E80AC for ; Thu, 19 Apr 2012 19:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.126 X-Spam-Level: X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9WFk8K9QMdZ for ; Thu, 19 Apr 2012 19:49:08 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE111E80AA for ; Thu, 19 Apr 2012 19:49:08 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3K2musP023889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 04:49:01 +0200 (MEST) From: Martin Rex Message-Id: <201204200248.q3K2mt8O010155@fs4113.wdf.sap.corp> To: geoffk@geoffk.org (Geoffrey Keating) Date: Fri, 20 Apr 2012 04:48:55 +0200 (MEST) In-Reply-To: from "Geoffrey Keating" at Apr 19, 12 01:34:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:49:09 -0000 Geoffrey Keating wrote: > > Eric Rescorla writes: >> >> Nico Williams wrote: >>> >>> Not really: if there are any interfaces suitable for automation you >>> can just automate the periodic installation of new certs. >> >> You wish. :) >> >> I believe that changing a cert in Apache, at least, involves >> a restart. > > You can typically do it using 'apachectl graceful' without an > interruption to service, the same as any other Apache configuration > change. What is possible probably depends very much on the type of Server you're using. Does that work with Tomcat as well? Our server does all connection management, TLS and the HTTP-protocol processing within one multi-threaded process. I added the capability to update credentials and trust anchors gracefully and transparently for the caller ~5 years ago, to get rid of the process restart. -Martin From mrex@sap.com Thu Apr 19 20:21:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222AC11E8091 for ; Thu, 19 Apr 2012 20:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.128 X-Spam-Level: X-Spam-Status: No, score=-10.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PczUdJuFeR98 for ; Thu, 19 Apr 2012 20:21:38 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 468DC11E80E5 for ; Thu, 19 Apr 2012 20:21:38 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3K3LU1S004490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 05:21:35 +0200 (MEST) From: Martin Rex Message-Id: <201204200321.q3K3LUEw011927@fs4113.wdf.sap.corp> To: agl@google.com (Adam Langley) Date: Fri, 20 Apr 2012 05:21:30 +0200 (MEST) In-Reply-To: from "Adam Langley" at Apr 19, 12 07:20:42 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, aerowolf@gmail.com, tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 03:21:39 -0000 Adam Langley wrote: > > On Thu, Apr 19, 2012 at 7:10 PM, Martin Rex wrote: > > Typo on the  full handshake : session resumes. > > 2  :  98 > > DHE/ECDHE makes a difference because, otherwise, an attacker can make > the client send data in a non-forward secure fashion by playing with > the handshake. (I don't believe that the signature in the > ServerKeyExchange signs anything useful in this situation.) I'm lost. traffic protection keys will be newly derived in the same fashion from the premaster secret for both, DHE/ECDHE and RSA by using the PRF. > > To the other point, your resumption rates are a lot better than mine :) If yours are worse than 4:96, then I strongly suspect problems with your (or your clients) TLS session caching. The 2:98 was measured on a big server (24 core) of a customer 6 years ago who was facing significant load problems for two days every month when a few million customers were trying to pick up their online billing information. The problem was due to a bug in the session caching of our OEM TLS implementation when it reached the session cache limit and purged the wrong session when adding to and already full cache, resulting in a 98% full TLS handshakes and maxing out the CPUs. By raising the default session cache size and lowering the time-based expiration to 30min. the ratio reverse (98% resumes) and the CPU load of the server dropped to the 10-20% range. The impact of dysfunctional session caching is going to become much worse with 2048-bit instead of 1024-bit RSA keys, because of the 6-fold increase in processing times for RSA crypto operations. > > None the less, as a client, browsers frequently hit sites without > session resumption information. Either because it's a site that we've > never visited before, or because resumption information is only kept > in memory and browsers get restarted quite often. > > The extra RTT to the server (without False Start) delays the fetch of > the initial HTML. That HTML frequently references blocking resources > on another HTTPS server, which, in turn, do the same thing. It's not > uncommon to go 3, 4 or even 5 layers deep with this. So we end taking > 3, 4, or 5 extra RTTs due to the full handshakes. False can not possibly save on TLS session resumes with HTTP/1.x, so I'm inclined to believe that your figures are be the result of serious TLS session caching problems; and fixing those problems would result in significantly higher improvement than FalseStart could achieve. -Martin From mrex@sap.com Thu Apr 19 20:48:01 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60B621F85F0 for ; Thu, 19 Apr 2012 20:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.83 X-Spam-Level: X-Spam-Status: No, score=-9.83 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkNaAUjaBrdw for ; Thu, 19 Apr 2012 20:48:01 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id EE98E21F85EF for ; Thu, 19 Apr 2012 20:48:00 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3K3lwad029199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 05:47:58 +0200 (MEST) From: Martin Rex Message-Id: <201204200347.q3K3lweh013469@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Fri, 20 Apr 2012 05:47:58 +0200 (MEST) In-Reply-To: <4F9021E4.80802@extendedsubset.com> from "Marsh Ray" at Apr 19, 12 09:32:04 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] SPDY / NPN X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 03:48:01 -0000 Marsh Ray wrote: > > > This document has no formal > > IETF status of any kind. I don't have a problem with pre-allocating numbers > > for WG drafts, but that is not in fact the case here. > > I'd say that there's no set-in-stone policy against numbers for > work-in-progress drafts is good news. The RFC that creates the IANA registry (usually the one that creates the protocol in question) also defines the allocation policy for registry values. Often, the available number range is partitioned into areas with different allocation policies. See the TLS registries here (textual): [1] http://www.iana.org/assignments/tls-parameters/tls-parameters.txt [2] http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.txt and the allocation policies that the creator of the registry can choose from: [3] http://tools.ietf.org/html/bcp26#section-4.1 Handshake messages are defined in [1], allocation policy "Standards Action". Extension types are defined in [2], allocation policy "IETF Consensus" The issue with too strict rules is that it may simply get ignored, and code points be "kidnapped". So overly strict rules can result in an near complete loss of control over people&ideas whose time has come. "It's easier to ask forgiveness than it is to get permission." -Martin From n.mavrogiannopoulos@gmail.com Fri Apr 20 00:53:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365821F871E for ; Fri, 20 Apr 2012 00:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2s46u2Zlluo for ; Fri, 20 Apr 2012 00:53:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6624F21F8718 for ; Fri, 20 Apr 2012 00:53:40 -0700 (PDT) Received: by eeke51 with SMTP id e51so2526987eek.31 for ; Fri, 20 Apr 2012 00:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=hSJg47CwJltnKdTIHuUnS4xY0+xrMWTjSHHwRylM0AY=; b=jF7EoXOwqrL/JNrxcyH4sDGXjLFkpG1YoSafG0ZKvpzps1K9PsYmdNEOCuHdpniH5J ur7YTK+hoAzRD0IER+zcjKlNCBuj+/ki+UKahmiZn6RuDYNQlux5DwwGkXJjtdUnV5iV u/mGKGGudih75EKIdReXUjx9GjTXgM71RQvUoBS+iaWCkJUNS5gqw1xH/YS0eMrqWEGy HgFM0wMi/Frpak5TKQ+Oooj19ld5IHMKal5HwnyAX4wQoU7m4NWMMSeUwfKQsYbNMyNO Z7KdqBq5/+XTFz1cu+dyAwOITW9A2TCuTuqWRwBOHcpf9h4MzCv00Kapdsb7MBBT/tM4 FPig== Received: by 10.213.6.198 with SMTP id a6mr422342eba.79.1334908419511; Fri, 20 Apr 2012 00:53:39 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id n55sm22353475eef.6.2012.04.20.00.53.38 (version=SSLv3 cipher=OTHER); Fri, 20 Apr 2012 00:53:38 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F9115FC.1060702@gnutls.org> Date: Fri, 20 Apr 2012 09:53:32 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: Marsh Ray References: <201204192152.q3JLqdfg023250@fs4113.wdf.sap.corp> <4F900742.3060004@extendedsubset.com> In-Reply-To: <4F900742.3060004@extendedsubset.com> X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, aerowolf@gmail.com, paul.hoffman@vpnc.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 07:53:41 -0000 On 04/19/2012 02:38 PM, Marsh Ray wrote: > There are other ways this could backfire. For example, if there were any > extensions negotiated in the Hello exchange which were necessary for > security. Are any extensions like that? I don't know. How about those > extensions for the ECDH that "allow a client to negotiate the use of > specific curves"? Certainly we'd have to be careful when adding future > extensions how they might break in an FS environment. > The ciphersuite selection could be faked. The attacker could trick the > client into parsing a validly signed ServerRSAParams structure as a > ServerDHParams structure, or vice versa. Nice that you bring this up. I am working on attack involving ServerDHParams and ServerECDHParams, and from what I have so far a man in the middle attack is possible (with significant effort at attacker's part though). regards, Nikos From agl@google.com Fri Apr 20 09:34:08 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF3F21F867A for ; Fri, 20 Apr 2012 09:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+XT1DzrbVO5 for ; Fri, 20 Apr 2012 09:34:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 46F1321F8669 for ; Fri, 20 Apr 2012 09:34:07 -0700 (PDT) Received: by yhkk25 with SMTP id k25so6064559yhk.31 for ; Fri, 20 Apr 2012 09:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=/WsNp0GEas3iurDbmWOu6a/dTzP+FMFHkSw8TXGnGps=; b=eQI8ePIHw327JvleRANLaFW/+PTHsSN9L5e59tS3lhLAmEMqXXzkbZKl+q0UEiAUzL puXfxcSGPw7Ix/BjPEwZKgGWYlrG4HUj6C7kv35BErtTdDx6tekTOChcK9dtZMmPF+we 13Uz9XvKZ/azTK19B116/O7DK6E2X9t0b07EIIU9h31MAbKIlcI/wPR6/Hu18CUVcXZG E1VV5FDbUGw+YkaWZ2qK6mT7gLjRx/n3NVkyNDlmiQrrj/cUY0SPS7UT55EJcwcEoPbp zJZgrkhgnrqhPK3wj428Mczz4aWaxzXYtAttJbidBo9QnK941C+dIBqbxq/mqFNtqlrP yX8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=/WsNp0GEas3iurDbmWOu6a/dTzP+FMFHkSw8TXGnGps=; b=HsGfvhyXj0OQXxYAug8CoknX9T0nCdeXtwCf8Xsle/NQ4omZGDq+eb3Cb2CSJPY5WM Nl3WVGO4S4ZDmvI6uneZcKYWU8E0WQeYUV3ibVD9gafvS7nnKkrdyKrVyiQPVBlTWIZo PbZ76s3+Yawjg/NSN5Up8dgDjLDMxUP02TczNZgAnR/tfKZ6Cmmja6gn38wsLZh7X2Gc Vvd7odWlEtI2+/WM9vUQSyC2aJqG36y+Sdffdvfy5WsGQ0Y6AlwXCHUwNDGvqZ4x9wTJ rra4phvTA6bFCmwzsncheQJYdO/LL0OHYQfS9P3XVnVhHEM5cZklaBfpyH4y9JVLT1Jw M5OQ== Received: by 10.50.186.231 with SMTP id fn7mr7050577igc.15.1334939646427; Fri, 20 Apr 2012 09:34:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.186.231 with SMTP id fn7mr7050555igc.15.1334939646233; Fri, 20 Apr 2012 09:34:06 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Fri, 20 Apr 2012 09:34:06 -0700 (PDT) In-Reply-To: <201204200321.q3K3LUEw011927@fs4113.wdf.sap.corp> References: <201204200321.q3K3LUEw011927@fs4113.wdf.sap.corp> Date: Fri, 20 Apr 2012 12:34:06 -0400 Message-ID: From: Adam Langley To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnHcH7IyNgkj7tBFVm9z3+3WgbdJWKHQKtIhHL75ayztreFwK9QLyhvIXChdMvyuGVvYJvzYycZYxKXNPKLMdrq3qS3MxZ1I02TiYhjMIKdsQBsXgZvmxE9uu10SKUE+vZVZ2rd Cc: paul.hoffman@vpnc.org, aerowolf@gmail.com, tls@ietf.org Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 16:34:08 -0000 On Thu, Apr 19, 2012 at 11:21 PM, Martin Rex wrote: > I'm lost. =C2=A0traffic protection keys will be newly derived in the > same fashion from the premaster secret for both, DHE/ECDHE and RSA > by using the PRF. If the client is willing to False Start with an RSA ciphersuite then it'll be encrypting the premaster secret to a fixed public key (the one in the server's certificate) and sending data protected by that encryption. Therefore that data isn't forward secure because I can break into the real server and steal its private key from its disk. Many TLS servers don't do forward secrecy anyway, so there's no loss there and one could make a fair argument that the attack is unrealistic. None the less, that's the thinking behind the requirement. > False can not possibly save on TLS session resumes with HTTP/1.x, > so I'm inclined to believe that your figures are be the result > of serious TLS session caching problems; and fixing those problems would > result in significantly higher improvement than FalseStart could achieve. Of course we have significant resumption problems; this is the Internet :) With my server-side hat on, we do everything we can but clients a) don't do session resumption or b) restart quite often and flush their caches. But if we assume that only competent clients will be doing False Start anyway, we can discount a) as an advantage, certainly. With my client-side hat on, many servers don't do session resumption right. It's obscure and most administrators probably don't even know that it exists. Fixing the world isn't something that I have the power to do, so a client-side, unilateral change that can get us the same effect is still very useful. Cheers AGL From Andrei.Popov@microsoft.com Fri Apr 20 10:22:12 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885CE21F84CD for ; Fri, 20 Apr 2012 10:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjF8z6u4mV48 for ; Fri, 20 Apr 2012 10:22:11 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7254221F84C9 for ; Fri, 20 Apr 2012 10:22:11 -0700 (PDT) Received: from mail100-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 17:22:10 +0000 Received: from mail100-va3 (localhost [127.0.0.1]) by mail100-va3-R.bigfish.com (Postfix) with ESMTP id 449FC2073C for ; Fri, 20 Apr 2012 17:22:10 +0000 (UTC) X-SpamScore: -14 X-BigFish: VS-14(zz1432N98dK148cMzz1202hzz8275bhz2fh2a8h683h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail100-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Andrei.Popov@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail100-va3 (localhost.localdomain [127.0.0.1]) by mail100-va3 (MessageSwitch) id 1334942516104439_12563; Fri, 20 Apr 2012 17:21:56 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.251]) by mail100-va3.bigfish.com (Postfix) with ESMTP id 08ECA4C0394 for ; Fri, 20 Apr 2012 17:21:56 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 17:21:54 +0000 Received: from CH1EHSOBE002.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.283.4; Fri, 20 Apr 2012 17:21:38 +0000 Received: from mail209-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Fri, 20 Apr 2012 17:20:38 +0000 Received: from mail209-ch1 (localhost [127.0.0.1]) by mail209-ch1-R.bigfish.com (Postfix) with ESMTP id 9C698200676 for ; Fri, 20 Apr 2012 17:20:38 +0000 (UTC) Received: from mail209-ch1 (localhost.localdomain [127.0.0.1]) by mail209-ch1 (MessageSwitch) id 1334942437895817_22290; Fri, 20 Apr 2012 17:20:37 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.243]) by mail209-ch1.bigfish.com (Postfix) with ESMTP id D585C1C00B1 for ; Fri, 20 Apr 2012 17:20:37 +0000 (UTC) Received: from SN2PRD0310HT001.namprd03.prod.outlook.com (157.56.234.5) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 20 Apr 2012 17:20:37 +0000 Received: from SN2PRD0310MB395.namprd03.prod.outlook.com ([169.254.1.53]) by SN2PRD0310HT001.namprd03.prod.outlook.com ([10.255.112.36]) with mapi id 14.16.0143.004; Fri, 20 Apr 2012 17:20:34 +0000 From: Andrei Popov To: "tls@ietf.org" Thread-Topic: Re: [TLS] What's the right version number in the PreMasterSecret for renegotiation Thread-Index: Ac0fGUr6yQDr3A7+TEevg+HGinImqQ== Date: Fri, 20 Apr 2012 17:20:34 +0000 Message-ID: <7A41E0C9581F8346A6883D6254E78490095BE64A@SN2PRD0310MB395.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.174.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PRD0310HT001.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Fri, 20 Apr 2012 10:27:11 -0700 Subject: Re: [TLS] What's the right version number in the PreMasterSecret for renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 17:25:10 -0000 Coming back to this thread, we are investigating the possible interoperabil= ity and RFC compliance issues in Microsoft's SSL/TLS implementation. Thanks for bringing this to our attention, Andrei Popov, Microsoft On Tue, 10 Aug 2010 at 16:02:42 -0700, Michael D'Errico wrote: > The problematic handshake is: > > ---->ClientHello v1.1----> (ask for an abbreviated handshake) > <---ServerHello V1.1<--- (not resumable, new session) > ... > --->PreMasterSecret (v1.2)---> (**) > > The version encoded within the PreMasterSecret is not the version > that was used in the ClientHello. That's a violation of the spec. > > The fact that the client does actually support version 1.2 is > immaterial. A server is not expected to have logic that keeps track > of the highest version the client has ever offered in the past. From mike-list@pobox.com Fri Apr 20 11:42:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8010421F85E7 for ; Fri, 20 Apr 2012 11:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3nPB9Y6AVaD for ; Fri, 20 Apr 2012 11:42:50 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8968B21F85C4 for ; Fri, 20 Apr 2012 11:42:50 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A785884A0; Fri, 20 Apr 2012 14:42:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=KvbVLGxg8ud4 3FSxpoiMMuxHtjw=; b=ppU3tAH1lWyUJjSrEIOcZ4CO7f3aKH/eJl2VF/BCEqtz L/x9BUNq6+lsmoN2O84jC2hDBQRHLj8Pnrn3dCMOK/KVSP1h81xmWbTI5uWItTtV qDzkBt5l/0OQAtlJulCtyIljIT8zvLcXSpEka1HCxLggYxE6khNY57O+RDTdS8E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=euZVW9 77AzGFdOE7xJs4J/duE52RmGEMD+R0PBILJ4BtKLbsuy4WRz6F1ILPjWrMS7gI+a ky6xnxzyBa94u0XcMW20EklVdq0kA5ASIwfOuRB0Lb+TsqWD2ixo2kIC8usIya1J GF85R6CTxdfvhqxisDAWdhi9Prrg2z/oazIBY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id A0F0B849F; Fri, 20 Apr 2012 14:42:49 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 0E8E2849E; Fri, 20 Apr 2012 14:42:48 -0400 (EDT) Message-ID: <4F91AE27.4010803@pobox.com> Date: Fri, 20 Apr 2012 11:42:47 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Andrei Popov References: <7A41E0C9581F8346A6883D6254E78490095BE64A@SN2PRD0310MB395.namprd03.prod.outlook.com> In-Reply-To: <7A41E0C9581F8346A6883D6254E78490095BE64A@SN2PRD0310MB395.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: A0E308C4-8B18-11E1-BE94-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: "tls@ietf.org" Subject: Re: [TLS] What's the right version number in the PreMasterSecret for renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 18:42:51 -0000 While it would be good for clients to do this correctly, I've seen many people argue that checking the version embedded inside an RSA premaster secret serves no purpose other than to cause more failed handshakes. Version rollback protection is redundant since the Finished messages also catch tampering. So, yes, please fix any problems you find w.r.t. encoding the version in the RSA premaster secret, but also consider turning off checking in your servers (or make it configurable, disabled by default). Mike Andrei Popov wrote: > Coming back to this thread, we are investigating the possible interoperability and RFC compliance issues in Microsoft's SSL/TLS implementation. > > Thanks for bringing this to our attention, > > Andrei Popov, > Microsoft > > On Tue, 10 Aug 2010 at 16:02:42 -0700, Michael D'Errico wrote: >> The problematic handshake is: >> >> ---->ClientHello v1.1----> (ask for an abbreviated handshake) >> <---ServerHello V1.1<--- (not resumable, new session) >> ... >> --->PreMasterSecret (v1.2)---> (**) >> >> The version encoded within the PreMasterSecret is not the version >> that was used in the ClientHello. That's a violation of the spec. >> >> The fact that the client does actually support version 1.2 is >> immaterial. A server is not expected to have logic that keeps track >> of the highest version the client has ever offered in the past. From code@funwithsoftware.org Fri Apr 20 17:29:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B875711E809A for ; Fri, 20 Apr 2012 17:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tROi4+cqJMv9 for ; Fri, 20 Apr 2012 17:29:55 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id D0FBD11E8095 for ; Fri, 20 Apr 2012 17:29:54 -0700 (PDT) Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.48]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id B3B18A7035A for ; Fri, 20 Apr 2012 20:29:53 -0400 (EDT) Received: (qmail 14090 invoked from network); 21 Apr 2012 00:29:53 -0000 Received: by simscan 1.4.0 ppid: 17908, pid: 28603, t: 1.4488s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 21 Apr 2012 00:29:51 -0000 Message-Id: <25D04C83-1FE6-4569-9B5E-9F9D2391D9B8@funwithsoftware.org> From: Patrick Pelletier To: tls@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 20 Apr 2012 17:29:49 -0700 References: X-Mailer: Apple Mail (2.936) Subject: [TLS] protocol registry issues (was SPDY / NPN) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 00:29:55 -0000 Martin Rex wrote: > The issue with too strict rules is that it may simply get ignored, > and code points be "kidnapped". So overly strict rules can result > in an near complete loss of control over people&ideas whose time has > come. > > "It's easier to ask forgiveness than it is to get permission." It seems that ssh has a better way to handle this "experimental deployment" phase, since it uses strings, and allows domain-qualified private names. (RFC 4250, section 4.6.1) What about an extension that would allow TLS to do a similar thing? The extension would be sent by the client, and would declare its interpretation of "Private Use" numbers, by associating each number with a string. (Which would have the "foo@example.com" format of ssh private names.) Then, if the server understood this extension, it would simply use the Private Use numbers that the client proposed. Once IANA allocates a number, the client can use the IANA-allocated number in its list of number/string pairs, instead of a Private Use number, so that it can interoperate both with servers that support this "number to string" extension but don't yet know about the new IANA number, and also with servers that do know about the IANA- allocated number, but don't support the "number to string" extension. Once enough servers know about the IANA-allocated number, the clients can stop listing it in their "number to string" list, to save space. This would work for any registry which has a "private use" range, which from a quick look at the IANA registry, looks like: TLS Certificate Types, TLS ClientCertificateType Identifiers, TLS Cipher Suites, EC Named Curves, EC Point Formats, EC Curve Types, TLS Supplemental Data Formats, TLS UserMappingTypes, TLS SignatureAlgorithms, TLS HashAlgorithms, TLS Authorization Data Formats, and TLS Compression Method Identifiers. There are some registries which don't have "private use" areas, so IANA would need to allocate a "private use" range in order to use them with this extension. That would include: TLS ContentTypes, TLS Alerts, TLS HandshakeTypes, Heartbeat Message Types, Heartbeat Modes, and ExtensionTypes. It seems like this would be an easy way to avoid the "kidnapping"/"number camping" problem. --Patrick From mrex@sap.com Mon Apr 23 14:21:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E5811E8087 for ; Mon, 23 Apr 2012 14:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.383 X-Spam-Level: X-Spam-Status: No, score=-9.383 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEO2wdh3IHLm for ; Mon, 23 Apr 2012 14:21:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1E19F11E8072 for ; Mon, 23 Apr 2012 14:21:26 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3NLL5pB009602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Apr 2012 23:21:05 +0200 (MEST) From: Martin Rex Message-Id: <201204232121.q3NLL4wq024994@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 23 Apr 2012 23:21:04 +0200 (MEST) In-Reply-To: <4F9115FC.1060702@gnutls.org> from "Nikos Mavrogiannopoulos" at Apr 20, 12 09:53:32 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: paul.hoffman@vpnc.org, tls@ietf.org, aerowolf@gmail.com Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 21:21:28 -0000 Nikos Mavrogiannopoulos wrote: > > Marsh Ray wrote: >> >> There are other ways this could backfire. For example, if there were any >> extensions negotiated in the Hello exchange which were necessary for >> security. Are any extensions like that? I don't know. How about those >> extensions for the ECDH that "allow a client to negotiate the use of >> specific curves"? Certainly we'd have to be careful when adding future >> extensions how they might break in an FS environment. >> The ciphersuite selection could be faked. The attacker could trick the >> client into parsing a validly signed ServerRSAParams structure as a >> ServerDHParams structure, or vice versa. > > Nice that you bring this up. I am working on attack involving > ServerDHParams and ServerECDHParams, and from what I have so far a > man in the middle attack is possible (with significant effort at > attacker's part though). Looking at the TLS full handshake: http://tools.ietf.org/html/rfc5246#page-36 How about changing the ServerKeyExchange handshake message to produce a digital signature over the handshake message hash up to that point, i.e. ClientHello+ServerHello+opt. ServerCertificate instead of only ClientRandom+ServerRandum, plus the server key parameters as usual? -Martin From jmdesp@free.fr Tue Apr 24 07:31:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C7E21F8828 for ; Tue, 24 Apr 2012 07:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynFZCbXJQRqC for ; Tue, 24 Apr 2012 07:31:52 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id E3F6921F8829 for ; Tue, 24 Apr 2012 07:31:50 -0700 (PDT) Received: from [172.30.24.38] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) (Authenticated sender: jmdesp) by smtp4-g21.free.fr (Postfix) with ESMTPA id 838574C81B0; Tue, 24 Apr 2012 16:31:42 +0200 (CEST) Message-ID: <4F96B94B.8050900@free.fr> Date: Tue, 24 Apr 2012 16:31:39 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120322 Firefox/12.0 SeaMonkey/2.9 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:31:53 -0000 Eric Rescorla a écrit : > It's also not entirely clear that short-lived certs > don't cause clients to choke. They shouldn't, but don't and shouldn't > aren't always the same. They make time synchronization problems at lot more acute. This can be interpreted as "causing them to choke", I'd expect the scale of the problem to be larger than the one with false start. From nico@cryptonector.com Tue Apr 24 07:39:29 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0221F87F7 for ; Tue, 24 Apr 2012 07:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKWe3kW1sl8d for ; Tue, 24 Apr 2012 07:39:29 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C20F221F87B4 for ; Tue, 24 Apr 2012 07:39:25 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 661B621DE7E for ; Tue, 24 Apr 2012 07:39:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=VQHUnnc2AjzOIBG1sD1Ne6cag2JEcCEIZH7ptwcOhEa5 M8GiqEKFIN9413QLOaFknUXBxOAT0uH2xbfMg8rDHdhS2TzidCh46f0GqZ0sy6j3 BnHFecBtUlwlDWKiTpzSPNUBppswiMXcIBxi+F7W/gk1F1V3FeG6GPaS7VChPDU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=TelU1m47gSNqmcJ/ZcO9ubE8tgk=; b=Yx/ujDyZUIr +qXAioHXz57QAd9UUw44elR7/tSMnhISB+dEOymofdz9Ad/kFFEFcdq8xfGTlV0W YQq5VR2CEbi5y+cXKV2VrJNoLL/GHwatpJym7MOG6IxSAfuw0a3jibnoVu5ZVYsg t38IjWxbJcGusHT1RCgSTjj92MG6trjE= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 4766821DE6A for ; Tue, 24 Apr 2012 07:39:25 -0700 (PDT) Received: by dady13 with SMTP id y13so1352956dad.27 for ; Tue, 24 Apr 2012 07:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.130.130 with SMTP id oe2mr4208445pbb.160.1335278364818; Tue, 24 Apr 2012 07:39:24 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 24 Apr 2012 07:39:24 -0700 (PDT) In-Reply-To: <4F96B94B.8050900@free.fr> References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> <4F96B94B.8050900@free.fr> Date: Tue, 24 Apr 2012 09:39:24 -0500 Message-ID: From: Nico Williams To: Jean-Marc Desperrier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:39:29 -0000 On Tue, Apr 24, 2012 at 9:31 AM, Jean-Marc Desperrier wrot= e: > Eric Rescorla a =C3=A9crit : > >> It's also not entirely clear that short-lived certs >> don't cause clients to choke. They shouldn't, but don't and shouldn't >> aren't always the same. > > > They make time synchronization problems at lot more acute. > This can be interpreted as "causing them to choke", I'd expect the scale = of > the problem to be larger than the one with false start. They don't have to be short-lived, just fresh. From jmdesp@free.fr Tue Apr 24 07:59:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A9721F8855 for ; Tue, 24 Apr 2012 07:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEPncyxYDhek for ; Tue, 24 Apr 2012 07:59:08 -0700 (PDT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF021F87F4 for ; Tue, 24 Apr 2012 07:59:06 -0700 (PDT) Received: from [172.30.24.38] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) (Authenticated sender: jmdesp) by smtp4-g21.free.fr (Postfix) with ESMTPA id 740444C81AA; Tue, 24 Apr 2012 16:59:00 +0200 (CEST) Message-ID: <4F96BFB1.1040209@free.fr> Date: Tue, 24 Apr 2012 16:58:57 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120322 Firefox/12.0 SeaMonkey/2.9 MIME-Version: 1.0 To: Eric Rescorla , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 14:59:09 -0000 Eric Rescorla a écrit : > WG members, > > At the meeting in Paris there was broad consensus to adopt Yngve's > TLS Multi-Stapling draft > (http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt). > > The WG chairs would like to confirm this consensus. Please send any > comments by Wednesday April 25. I support this as a working group item. I also think the proposal would gain from allowing the OCSPResponseList to contain ARLs (authority revocation list) and not only OCSP token. In my opinion, the cost is not big for the implementation, and they are real use cases, but this I mean a *lot* of deployed PKI that do not implement OCSP for intermediate certificates, but have an ARL available that is the same size, or smaller, than an OCSP token would be. On another hand, I believe the ResponderID thing is not worth the effort. In RFC2560, option 1 of 4.2.2.2 (locally configured responder) only works in a mutually agreed private context. Option 2 and 3 (responder same as CA, responder with the id-ad-ocspSigning EKU) are the only one that work in a public context (and for example are mandated in the Mozilla policy) and they do not need this ResponderID thing. Only option 1 would use it, when there's an ambiguity about which responder this specific client trusts, but then outside of multi-status there would be no way to get the same functionality with RFC2560. So, including it seems to me to be implementation pain for extremely small and specific advantage. From ynir@checkpoint.com Tue Apr 24 11:14:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE1D21F87C1 for ; Tue, 24 Apr 2012 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lxnrwmVPkob for ; Tue, 24 Apr 2012 11:14:48 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E477821F87AE for ; Tue, 24 Apr 2012 11:14:47 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3OIEfXX004621; Tue, 24 Apr 2012 21:14:41 +0300 X-CheckPoint: {4F96FA12-1-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Apr 2012 21:14:39 +0300 From: Yoav Nir To: Nico Williams Date: Tue, 24 Apr 2012 21:14:42 +0300 Thread-Topic: [TLS] Call for acceptance on multi-stapling Thread-Index: Ac0iRhyCyIMU1X2EQmiNOn8i76KGiQ== Message-ID: References: <201204190356.q3J3uSbT023588@fs4113.wdf.sap.corp> <4F96B94B.8050900@free.fr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 115a0d4ea8f21e26f37151a9adce3c8943c1f5770a Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Call for acceptance on multi-stapling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 18:14:49 -0000 Hi Nico On Apr 24, 2012, at 5:39 PM, Nico Williams wrote: > On Tue, Apr 24, 2012 at 9:31 AM, Jean-Marc Desperrier wr= ote: >> Eric Rescorla a =E9crit : >>=20 >>> It's also not entirely clear that short-lived certs >>> don't cause clients to choke. They shouldn't, but don't and shouldn't >>> aren't always the same. >>=20 >>=20 >> They make time synchronization problems at lot more acute. >> This can be interpreted as "causing them to choke", I'd expect the scale= of >> the problem to be larger than the one with false start. >=20 > They don't have to be short-lived, just fresh. I don't understand the distinction. If a relying party (in our case, the br= owser) requires that certificates are at most 24 hours old (presumably calc= ulated by subtracting the current time from the notBefore field), what diff= erence does it make if the notAfter field is 5 years in the future? Yoav From agl@google.com Tue Apr 24 13:56:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364DD21F8631 for ; Tue, 24 Apr 2012 13:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXPSJY3aeh94 for ; Tue, 24 Apr 2012 13:56:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 868A321F85F8 for ; Tue, 24 Apr 2012 13:56:43 -0700 (PDT) Received: by yhkk25 with SMTP id k25so888179yhk.31 for ; Tue, 24 Apr 2012 13:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record; bh=zn8BY8CqrkNSom/Y/BcsYcMHR9baNSMysWUAQdcRNro=; b=ABv0z/6Uy9YtgCqbVhOyYZ5vI5bxI05H7rEo+LSnfXS43RlNELYlFbYaX86LdgPLxp KwdMTaj9j4/LBVzYaROcTBzMtn96HrJfHQWsFfMIYvwbuIRTrEY6n+YvfrvKL17yFOMe 370AbrlwIDyBw0bunxzrVE3Z2hWuRFp2JcNAb6hYDAQLcoCd88rlxU3lFPLMmZtAmUAO sNBWXDAmuQJgcSMH89QEog4WKKAZu7INVh8Mn24GLpXt/oX+1lOERsnoyincHq0zasf8 Xj+IqQvpSv+mHnBxy9TMjK60z15/KkH3REoQqxkYCAdG0Xi6LPPEX2TAU6JWV9NJMcsM MxSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-system-of-record:x-gm-message-state; bh=zn8BY8CqrkNSom/Y/BcsYcMHR9baNSMysWUAQdcRNro=; b=QpULQaLgrY8+JzB73SKUSB0ZLIbjuQRyhI6V3osg89Bq4E/ZVrXwIIzkllDZJP5+/w MrPSWRns0zbiSwbDWZwIFIZE203cSJ7YXlJpk89E5RB8LbJi/EE4oWRBz7QKBE9vYRqW NYw0DKdYB9HGMFMQmfeJavarJBadAfSd5ee3flwlCVmGtJcw8azss1/XkYjQz0Q3tAyy 9w8AqygV69PI4rrpekzx8hvaCxP/MoagAOA1feMYJUXCsjGudwmW4hTIdaIjxdlu5Oek IsjEhkeWoh63A9Aa2nRnGRzQ20o7duALfqxsTIEKpyK1tHbjVcLWtuULb1e9Abg6C8T/ lGAQ== Received: by 10.50.185.232 with SMTP id ff8mr51687igc.5.1335301002671; Tue, 24 Apr 2012 13:56:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.185.232 with SMTP id ff8mr51682igc.5.1335301002603; Tue, 24 Apr 2012 13:56:42 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Tue, 24 Apr 2012 13:56:42 -0700 (PDT) Date: Tue, 24 Apr 2012 16:56:42 -0400 Message-ID: From: Adam Langley To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkjfuzUJXZbmDYU9eTJ4cSljOEQtHNzWS2sq48h+7oNevUcHahkPnm1PjR6JdlXpRlr5mGmAtsXMdLruhU2xZUfCFQ0eCB2bMd6TBL9v8fVzb1rWM9mUUzWXpCpt5S1Rr4FnVfn Subject: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:56:44 -0000 With httpbis active, several people have suggested that it's time to make another pass at making NPN a little more formal. Previous drafts have omitted some details so that the more important aspects were clearer. Paul Hoffman also made a valiant attempt [2] at making it more "IETF friendly" to see whether that would get anywhere. In contrast, the current draft [1] is complete and sufficient to produce an interoperable implementation with what's running on www.google.com. Perforce, it includes the current extension and handshake message numbers. I understand that using these numbers without permission has upset some people. However, we stand up, evaluate and tear down TLS work at a rate far in excess of what the WG could usefully process. Standardising every experiment before testing it would waste RFCs and allocations, not to mention years. Therefore the extension and handshake numbers were randomly generated. NPN is included in several TLS implementations and used quite regularly on the Internet and I would like the TLS WG to consider its adoption. Cheers AGL [1] https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-03 [2] https://tools.ietf.org/html/draft-agl-tls-nextproto-00 From ynir@checkpoint.com Wed Apr 25 05:05:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCA21F878E for ; Wed, 25 Apr 2012 05:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o1iini72ACO for ; Wed, 25 Apr 2012 05:05:02 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5A15521F8789 for ; Wed, 25 Apr 2012 05:05:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q3PC4woB027710; Wed, 25 Apr 2012 15:04:58 +0300 X-CheckPoint: {4F97F4E1-1-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Apr 2012 15:04:57 +0300 From: Yoav Nir To: Adam Langley Date: Wed, 25 Apr 2012 15:05:00 +0300 Thread-Topic: [TLS] Next Protocol Negotiation 03 Thread-Index: Ac0i26FCxqAF/3ftSgG0pjdgL6DEWw== Message-ID: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11c47f6cb40e40d02ab74ed013f2e1c3861382bc16 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 12:05:03 -0000 Hi Adam I support the adoption of NPN. However, I would like to get a statement from Google, that if the output fr= om the working group is different from what is running on Google's servers = (and Chrome and Firefox) right now, those servers and clients will change t= o match the standard. Otherwise, we are going to have one of two outcomes: - the TLS working group rubber-stamps Google's proposal, perhaps decoratin= g it with some nice security considerations. - the TLS working group creates a different standard, and implementers can= choose between the Google NPN and the IETF NPN, and more that likely, impl= ement both. At HTTPBIS in Paris There was such a statement about SPDY. Can you make one= about NPN? I can think of two things that might prove contentious: 1. Using the extension and handshake numbers. I would hope that IANA assig= ns those numbers rather than forcing a transition period, but that should n= ot be a problem as both clients update without asking the user, and the ser= vers are under your control. So it's not a problem either way. 2. Some may consider the use of a new handshake message as superfluous. Yo= u could have the client advertise that it supports http/1.1 and spdy/2.0, a= nd then the server chooses one in the ServerHello. The downside is that an = eavesdropper can then know what the protocol inside the TLS connection is. = I don't know if the benefit of hiding that information is worth a new handh= sake message, which also changes the state machine. Yoav On Apr 24, 2012, at 11:56 PM, Adam Langley wrote: > With httpbis active, several people have suggested that it's time to > make another pass at making NPN a little more formal. >=20 > Previous drafts have omitted some details so that the more important > aspects were clearer. Paul Hoffman also made a valiant attempt [2] at > making it more "IETF friendly" to see whether that would get anywhere. >=20 > In contrast, the current draft [1] is complete and sufficient to > produce an interoperable implementation with what's running on > www.google.com. >=20 > Perforce, it includes the current extension and handshake message > numbers. I understand that using these numbers without permission has > upset some people. However, we stand up, evaluate and tear down TLS > work at a rate far in excess of what the WG could usefully process. > Standardising every experiment before testing it would waste RFCs and > allocations, not to mention years. Therefore the extension and > handshake numbers were randomly generated. >=20 > NPN is included in several TLS implementations and used quite > regularly on the Internet and I would like the TLS WG to consider its > adoption. From lloyd@randombit.net Wed Apr 25 05:18:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0900621F873B for ; Wed, 25 Apr 2012 05:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akhjU4NFDrwh for ; Wed, 25 Apr 2012 05:18:45 -0700 (PDT) Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8443521F8736 for ; Wed, 25 Apr 2012 05:18:45 -0700 (PDT) Received: by chihiro.randombit.net (Postfix, from userid 1000) id 86F051249481; Wed, 25 Apr 2012 08:18:44 -0400 (EDT) Date: Wed, 25 Apr 2012 08:18:44 -0400 From: Jack Lloyd To: tls@ietf.org Message-ID: <20120425121844.GE9472@randombit.net> Mail-Followup-To: tls@ietf.org References: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 12:18:46 -0000 On Wed, Apr 25, 2012 at 03:05:00PM +0300, Yoav Nir wrote: > 1. Using the extension and handshake numbers. I would hope that IANA > assigns those numbers rather than forcing a transition period, but > that should not be a problem as both clients update without asking > the user, and the servers are under your control. So it's not a > problem either way. This seems to be assuming the only users for NPN are Firefox and Chrome on the clients and Google's servers, but given that NPN is already included in OpenSSL 1.0.1 and there seems to be substantial interest in SPDY on the server side, it seems implausible that this would still be true by the time the WG produced a modified NPN extension. -Jack From agl@google.com Wed Apr 25 06:09:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D30721F872E for ; Wed, 25 Apr 2012 06:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDIc-mX90ISR for ; Wed, 25 Apr 2012 06:09:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14821F872D for ; Wed, 25 Apr 2012 06:09:25 -0700 (PDT) Received: by iazz13 with SMTP id z13so83345iaz.31 for ; Wed, 25 Apr 2012 06:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=qE4i38l9ynFVMSbfc1r8kzgWuHJnJdcKiKOaKe9rh+U=; b=l/1XIyAB9UHSiz/4P3HXKBm69CvrXcxbnXh2VKLrVuAtB6fvC8RJ1KDPAlT+ULIihU uOLen8tDQtJjtCvmM+kVgsSvLufN51GdIObLWaUHADZwLXIkIVExxoyEkoyyxly0cGkS LLjPpIxi8V0Ej2JaVvSgQjZmc6o0bFpnldxNxHjhxNW48i8igMXV22LbBew8MwMix8TT Le6epuIDBp7LWUTp7O9UNz+QoaaJkTX7Iy6Sig9w24vbCX+c98slHVp0nfgP8WUPuSqU jEZcFd0V9GwTJJxxqMGGQPq7O/KWtqn+RE90ecCpSSN/Jbe+4JMJXe6yOPeseu+HXyUF XPGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=qE4i38l9ynFVMSbfc1r8kzgWuHJnJdcKiKOaKe9rh+U=; b=Xj6il99YjfhU6hUgoiLGpqZDoHQfxdhi0OM4qu8BT49Do6uV6FHx67dSc9BzGjQ5zS 9nC7e9Tfi/U4aktgVXykUus7MwTp3dR7leDHLNvX69OK4rk4w6wK+K1hQCUPR8f4Yf97 U1FJRlHGvMu0DZnPiXeuYjW5kPlOxUBCBTsYm9/inyE1+fkdZVBufKoQF53N7PSvzBnG Uf+r8vbG3KVSg32TjXaifUN29QuhcAAhOkSYXOMl6MKvWPUJp7TthUav6lXCDlWyPWl4 aXVmpzbqqOHXC4E8/H/7WxMHl8P05IX0hOSC3kRQz3rNF8ElD7kW1dx2WY2v5nxqKbt0 Md/Q== Received: by 10.50.181.196 with SMTP id dy4mr14382456igc.5.1335359364539; Wed, 25 Apr 2012 06:09:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.181.196 with SMTP id dy4mr14382438igc.5.1335359364390; Wed, 25 Apr 2012 06:09:24 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Wed, 25 Apr 2012 06:09:24 -0700 (PDT) In-Reply-To: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> References: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> Date: Wed, 25 Apr 2012 09:09:24 -0400 Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQmB7WVbOpcyg3QUkz4p/93tdbvUgZHUmA3vijy1t2hkdmVF7yFu37EM1i7eZjgxEnARJj1Ll8ECqyE/GggzRWagm7Q9j3dcfPA9CPeu7vMaKbcYnj6TEQJH+w+YvaAeIZF3qEpm Cc: "tls@ietf.org" Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:09:26 -0000 On Wed, Apr 25, 2012 at 8:05 AM, Yoav Nir wrote: > However, I would like to get a statement from Google, that if the output = from the working group is different from what is running on Google's server= s (and Chrome and Firefox) right now, those servers and clients will change= to match the standard. Otherwise, we are going to have one of two outcomes= : I will have to check around before making a statement on behalf of Google, but my personal inclination would be to adopt the result of the WG. If the result differed, then Chrome/Firefox may support both during the transition, which could be several years. (Google is not the only large site using SPDY.) > =C2=A01. Using the extension and handshake numbers. I feel that the process around magic numbers is flawed and forcing a renumbering would be an unfortunate amount of effort to serve very abstract goals. None the less, I don't think that renumbering would be a deal breaker. > =C2=A02. Some may consider the use of a new handshake message as superflu= ous. We reached the point where we have to deploy over TLS with NPN, in part, because of middleware interference. TLS's cryptography has been a fairly effective barrier that has held the line below the transport layer for the most part. (MITM proxies are the significant exception.) Other protocols that lack cryptography (notably HTTP) are now effectively frozen in place by buggy middleware in all directions. Given this history, an NPN that allows middleware to 'filter' would seem to be a short term solution at best. We're also looking at other extensions, for example encrypted client certs[1] (which have been suggested by others too), that also involve encrypted handshake messages. So that state machine change may be be useful for a range of needs. [1] http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 Cheers AGL From internet-drafts@ietf.org Wed Apr 25 06:19:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA8A21F876C; Wed, 25 Apr 2012 06:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPDD4YcrilZw; Wed, 25 Apr 2012 06:19:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC35521F86FA; Wed, 25 Apr 2012 06:19:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120425131948.30136.35436.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 06:19:48 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:19:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : TLS Out-of-Band Public Key Validation Author(s) : Paul Wouters John Gilmore Samuel Weiler Tero Kivinen Hannes Tschofenig Filename : draft-ietf-tls-oob-pubkey-03.txt Pages : 10 Date : 2012-04-25 This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. Currently, TLS authentication can only occur via X.509-based Public Key Infrastructure (PKI) or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative public key validation methods. One such alternative public key valiation method is offered by the DNS-Based Authentication of Named Entities (DANE) together with DNS Security. Another alternative is to utilize pre-configured keys, as is the case with sensors and other embedded devices. The usage of raw public keys, instead of X.509-based certificates, leads to a smaller code footprint. The support for raw public keys is introduced into TLS via a new non- PKIX certificate type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ From paul@nohats.ca Wed Apr 25 06:22:04 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3414421F8634 for ; Wed, 25 Apr 2012 06:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVH-74UcIXcf for ; Wed, 25 Apr 2012 06:22:03 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id BCB6121F863E for ; Wed, 25 Apr 2012 06:22:01 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id C5B338036B; Wed, 25 Apr 2012 09:22:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id B17ED80358 for ; Wed, 25 Apr 2012 09:22:00 -0400 (EDT) Date: Wed, 25 Apr 2012 09:22:00 -0400 (EDT) From: Paul Wouters To: tls@ietf.org Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-03.txt (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 13:22:04 -0000 The only change between the -02 and the -03 draft is the addition of: 3.5. Client authentication Client authentication by the TLS server is supported only through authentication of the received client SubjectPublicKeyInfo via an out-of-band method Paul A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ From n.mavrogiannopoulos@gmail.com Wed Apr 25 08:16:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E33421F8656 for ; Wed, 25 Apr 2012 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S2uLzDjZ9yR for ; Wed, 25 Apr 2012 08:16:04 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BC76821F864D for ; Wed, 25 Apr 2012 08:16:03 -0700 (PDT) Received: by eeke51 with SMTP id e51so349081eek.31 for ; Wed, 25 Apr 2012 08:16:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=gyWeNp77oOY6haY4BElIwk+5IzCc1quX/MMBMGJcWLU=; b=cBAZp23b7v7mDBbSQsma7W00nvCERPOGkX6Nh34NmmFFYOfy+mEsLLS531MxN5/g9N 6MEyueBm6utgAdcbl6UaO3XWuBNiXkybQ5peHWv1CEK3xwU2PuADnWwuivn5mxWxDJsO r5yM238jsaZLNQ0+tvfoLiYbRFbKYDCPcGoS+tpgubsmdv4hNpTecNm+qTkwXCEF9cTO jH9sG3kQ0WN1rLguHQ/9sXwPz5bVRXqh0MwKGjZ71wc9NzSJb2PXl19jyw2VWk5kF28N 7wt/n29HolOFS8Z3Z0QgzRODyUoLUogkNMwC/pzbLeT5lz0M5za6LoJ28ZJfUnFvqiFd gAxw== Received: by 10.213.17.5 with SMTP id q5mr304896eba.242.1335366962769; Wed, 25 Apr 2012 08:16:02 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id m42sm105016133eef.0.2012.04.25.08.15.58 (version=SSLv3 cipher=OTHER); Wed, 25 Apr 2012 08:16:00 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F981528.9010903@gnutls.org> Date: Wed, 25 Apr 2012 17:15:52 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120329 Icedove/10.0.3 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:16:05 -0000 On 04/24/2012 10:56 PM, Adam Langley wrote: > Perforce, it includes the current extension and handshake message > numbers. I understand that using these numbers without permission has > upset some people. However, we stand up, evaluate and tear down TLS > work at a rate far in excess of what the WG could usefully process. > Standardising every experiment before testing it would waste RFCs and > allocations, not to mention years. Therefore the extension and > handshake numbers were randomly generated. Some comments on the current draft. It is quite a complex negotiation. My understanding is, that instead of having a simple: ClientHello: I want protocols A, or B. ServerHello: Let's talk A. We have ClientHello: I want to negotiate a protocol ServerHello: I have A or B. ... Client NPN message: Let's talk A. That's really different from any other negotiation in TLS. I understand that you might want to hide the protocol that they are actually talking, but is this the way to do it? Say that B is TOR. Wouldn't a middleware terminate the connection anyway if the server supports tor? So that complication doesn't really buy privacy or protection against middlewares. I'd suggest that you define NPN using the simple ClientHello/ServerHello methods, and then for privacy add a new extension NegotiatePrivate or so that would exchange after Client ChangeCipherSpec: ClientPrivateExtensions: client_hello_extension_list<0..2^16-1>; and after the server Changecipherspec: ServerPrivateExtensions: server_hello_extension_list<0..2^16-1>; and this format is not NPN specific. Any extension can be negotiated like that. regards, Nikos From marsh@extendedsubset.com Wed Apr 25 08:58:22 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B8821F875E for ; Wed, 25 Apr 2012 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svD5-0lkNQJe for ; Wed, 25 Apr 2012 08:58:22 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2947021F86A2 for ; Wed, 25 Apr 2012 08:58:22 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SN4bl-000GcY-Ki; Wed, 25 Apr 2012 15:58:21 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A42726081; Wed, 25 Apr 2012 15:58:20 +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: U2FsdGVkX19VfpqCjJtRZWJfqNDKGEj/cDMuNM1IH0M= Message-ID: <4F981F1B.3020101@extendedsubset.com> Date: Wed, 25 Apr 2012 10:58:19 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Adam Langley References: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:58:22 -0000 On 04/25/2012 08:09 AM, Adam Langley wrote: > > We're also looking at other extensions, for example encrypted client > certs[1] (which have been suggested by others too), that also involve > encrypted handshake messages. So that state machine change may be be > useful for a range of needs. So if we are going to change the state machine in a generally more useful way, why not make the change more general? I.e., instead of > struct { > opaque selected_protocol<0..255>; > opaque padding<0..255>; > } NextProtocol; We could define something closely analogous to a Hello message extension area, records sent immediately after the CCS in their respective directions: struct { Extension extensions<0..2^16-1>; } ClientAdditionalExtensions; struct { Extension extensions<0..2^16-1>; } ServerAdditionalExtensions; thus re-using the definition of 'Extension' from RFC 5246. The use of these ClientServerAdditionalExtensions record could be negotiated with (what else?) a new extension. We could call it the AdditionalExtensionsNegotiationExtension, but maybe there's a better name. I envision this extension could be sent on the Client Hello and replied to on the Server Hello if this feature is negotiated. We could define this Client Hello extension to be empty, or it might be useful to have it list the ExtensionTypes for which the actual data will be sent in the CAE and those for which the reply is required to be sent in the SAE record after the CCS. The extension sent in reply on the Server Hello reply would indicate the feature was negotiated successfully. It could list the ExtensionTypes for which the use of was negotiated successfully, but the actual reply payload will be found in the SAE after the CCS. There are considerations for resumed handshakes because the server CCS comes before the client CCS. But there are already such considerations: "Most current TLS extensions are relevant only when a session is initiated: when an older session is resumed, the server does not process these extensions in Client Hello, and does not include them in Server Hello. However, some extensions may specify different behavior during session resumption." [RFC5246] This would enable implementors to take the pain of modifying their state machines once while also enabling other extensions to benefit from the privacy enhancement. Thus, the definition of next_protocol remains nearly the same, except that it is now the "extension data" field of a proper next_protocol_negotiation type extension. We'd have to decide which (if any) of the currently defined extension types should be considered incompatible with this new feature, but it seems like most would transition smoothly. Few current extensions seem to affect handshake messages between the Hellos and the CCS. Nor does it seem likely that many will specify different behavior during session resumption." - Marsh From marsh@extendedsubset.com Wed Apr 25 09:09:56 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9943A21F87D5 for ; Wed, 25 Apr 2012 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.154 X-Spam-Level: X-Spam-Status: No, score=-2.154 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ27AkFby9xn for ; Wed, 25 Apr 2012 09:09:56 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id F3DC121F87D3 for ; Wed, 25 Apr 2012 09:09:55 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SN4mx-0006aF-Iw; Wed, 25 Apr 2012 16:09:55 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 20E816081; Wed, 25 Apr 2012 16:09: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: U2FsdGVkX18TaoepDTLWHBYUHAf0+gaJHcf7xxbx86Y= Message-ID: <4F9821D0.5050805@extendedsubset.com> Date: Wed, 25 Apr 2012 11:09:52 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4F981528.9010903@gnutls.org> In-Reply-To: <4F981528.9010903@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:09:56 -0000 On 04/25/2012 10:15 AM, Nikos Mavrogiannopoulos wrote: > > Say that B is TOR. Wouldn't a middleware terminate the connection anyway > if the server supports tor? So that complication doesn't > really buy privacy or protection against middlewares. Tor is actively engaged in a fascinating tit-for-tat contest with protocol censors. In fact, they are developing methods precisely to make it impractical for unauthorized middleboxen to actually determine "if the server supports Tor". It's an evolving situation and I expect it will continue to evolve faster than, say, IETF protocols. :-) So I don't think it's a useful indicator of the effectiveness of any proposed TLS protocol features. - Marsh From agl@google.com Wed Apr 25 09:40:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6741221F87DF for ; Wed, 25 Apr 2012 09:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoxIXLTaP060 for ; Wed, 25 Apr 2012 09:40:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF221F87BF for ; Wed, 25 Apr 2012 09:40:40 -0700 (PDT) Received: by iazz13 with SMTP id z13so342338iaz.31 for ; Wed, 25 Apr 2012 09:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=0cS/oXBpWzjW7LaXcY3NWi+7yFgKY1Fdco0lZHUlKsc=; b=Ud/T8mAygNqlL6TD5mzIBcCOluRakIiIteXEKtPmz7QRWPEHmmmWX/gm7CxFUWn/Ya fEQGh+Y8rmBZJlY3eOxQXGWhJBjkzM6nN+KoW4oeIG/sC90B0TLKFkRSyihg6TXsv/Sy fsPQX/ATgb86oFuYODt+5/cOmSUDAlG4Oq6/1YquZ/RVEJbS4TuRI4BUrVKf8V+tJqYa aPfAD1bsh6Z2R1stnYFGoh0tZFtca3x35Hhdwe3Iz2t2uR97Wx6f3VJG6L9dUDLa/AX/ Lm6Xg2wJWDk9scL2juUGAVXOaOXNeDFgEqrdoLGOjPUFNbiQqzLDhsx0ZdA/zBRpFbAP dEFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=0cS/oXBpWzjW7LaXcY3NWi+7yFgKY1Fdco0lZHUlKsc=; b=ROD7FpPX4qXxUAomOJF04jYLpN3mNrIslFbqTJJ/YNubG6zGbHz/hF5TJ0mKPofRG1 Jz3zN33QNUycfQRohMLliSvE90hc158PrbVZxRI+t3HvW4qCF2MZcRP1p+FwZI+tqNMv w58MaCFtQ2wOaqKgLAVlLBN4IVuvxh77/0hOmj7OQKd0UiaoIZK3hEMbZiioZE2fbUIT hq4b/iWZt0gjmcU0EjntA5p5ACmlP0Mmcnb2skSGMmnXsL52uG9hWLN4Lg6L8nwZu+ev NAOcC6EOKuPHMkBt7iRvRRhCjgr5+tquesqyGLnEWMf9+qOCo7T4f5l7iOH0+5OFYsL0 Ewxw== Received: by 10.50.191.169 with SMTP id gz9mr3443652igc.5.1335372040480; Wed, 25 Apr 2012 09:40:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.191.169 with SMTP id gz9mr3443628igc.5.1335372040302; Wed, 25 Apr 2012 09:40:40 -0700 (PDT) Sender: agl@google.com Received: by 10.231.189.95 with HTTP; Wed, 25 Apr 2012 09:40:40 -0700 (PDT) In-Reply-To: <4F981528.9010903@gnutls.org> References: <4F981528.9010903@gnutls.org> Date: Wed, 25 Apr 2012 12:40:40 -0400 X-Google-Sender-Auth: nYOXH5NFbquYQom8JAOMc5Yl5e0 Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlKPoEtSh9T7GUVeZdVi8kYI8h8BR/BBcayJfF/+AHbwM544denvhihjrVNTiEOu6wuLtdCnAhZmx0kBcpxVsPxaXHfp/KdkWHL1ddNhgZnNXPwCrzvtNN9F4IDwt4CVvGgUlEr Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:40:41 -0000 On Wed, Apr 25, 2012 at 11:15 AM, Nikos Mavrogiannopoulos wrote: > Say that B is TOR. Wouldn't a middleware terminate the connection anyway > if the server supports tor? So that complication doesn't > really buy privacy or protection against middlewares. The idea would be that the server doesn't advertise Tor, or any other possibly suspect protocol. Rather the client would simply select "tor" as the protocol. The fact that the server advertises is unfortunate, but necessary to avoid an extra round trip. I'd rather see NPN in the clear as a standard ClientHello/ServerHello negotiation then take an extra round trip. Cheers AGL From mike-list@pobox.com Wed Apr 25 09:42:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C1F21F8697 for ; Wed, 25 Apr 2012 09:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55N7v4KBJuri for ; Wed, 25 Apr 2012 09:42:40 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 74EBB21F8693 for ; Wed, 25 Apr 2012 09:42:40 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7139B9505; Wed, 25 Apr 2012 12:42:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=RFVzQqrZKbaU k9ZBz6UffiLyuCU=; b=UpRRELT1bz5NzpIZSHOJkPu1a+FQX+rjnQzu2ajxtJdv F4gXqMbPj9bRE/ToELINOawQDl/IMUjF0nwDdJa5CNIhsjk2ak7JAcIpJUa/zNG4 2pekZwXMgCn4m+mVq/4k2WBBQOOXtYWtOKbOk4+HMGjRoA+tAxQYpZAfekodDDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=kYZju0 OSgI3SSBPNbXj2r5fGVJpXKaUsaMbILPne2gw8Un0nxt4LivmXmIkhCfXk1sUlzj MloHFc52+kAtBvtY5UHxt3e51IJZEopEpNeGCTNLbqvKbgj6kSQWVp194L5Ll/hn UOvBjqDztcAsz+f4/CL1TR09ghTBS3iU8nbIY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5297994FB; Wed, 25 Apr 2012 12:42:38 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 43C4794FA; Wed, 25 Apr 2012 12:42:37 -0400 (EDT) Message-ID: <4F982973.1010804@pobox.com> Date: Wed, 25 Apr 2012 09:42:27 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4F981528.9010903@gnutls.org> In-Reply-To: <4F981528.9010903@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: AA649BB6-8EF5-11E1-B783-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:42:41 -0000 Nikos Mavrogiannopoulos wrote: > > My understanding is, that instead of having a simple: > ClientHello: I want protocols A, or B. > ServerHello: Let's talk A. > > We have > ClientHello: I want to negotiate a protocol > ServerHello: I have A or B. > ... > Client NPN message: Let's talk A. > > That's really different from any other negotiation in TLS. > I understand that you might want to hide the protocol that > they are actually talking, but is this the way to do it? Hiding the protocol is problematic if the server wants to use the NextProtocol as part of its certificate selection process. It would need to be in the ClientHello extension. Also, if we're going to go down the road of sending Handshake messages after ChangeCipherSpec (NPN, concealed client cert), then I'd suggest that there should be no order imposed on these messages; otherwise the state machine logic could get unwieldy quickly, not to mention the difficulty in writing the specs. Further, we should not create another registry of protocol names (the Google Tech Note lists "http/1.1", "spdy/1", and "spdy/2" as being in use). Please leverage the existing IANA list of well-known services for this (so we don't need to duplicate definitions for "smtp", "imap4", etc.), along with the standard "x-" prefix for anything experimental like SPDY ("x-google-spdy-2" as an example). Mike From nico@cryptonector.com Wed Apr 25 09:51:22 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00A821F863F for ; Wed, 25 Apr 2012 09:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUCKfhk0ZuYt for ; Wed, 25 Apr 2012 09:51:22 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id ED2FE21F8611 for ; Wed, 25 Apr 2012 09:51:15 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 7758F598058 for ; Wed, 25 Apr 2012 09:51:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=eTsbYzRkADqGlkjWfCorE7zWDJ8gqw9bcxIlRTNeYJ7J Tq/2pj0U6doUJAxgSkDnJ9PlVaJzKZr797go2OJg1VDHHI7nxg8Vk+TDW8LjYGFU 478y/TKcTSNosYRswqcs0ixOO+ebuMS13CCmRZZBzuOwjVLD0O0mR0Hffiedvvw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=YSY8vFUFk1DfEmSt2tLi3zQB/uA=; b=tTomiPGyzfy Kp9E6Hc3FFrvNAGm5aCVobgOskTIl6bzmX3Pl97NGEvbVZ654Kly619I7RBGYVD5 kZqV0U7RiElaudJNgCIs6fSt8O3+FxNrOkkRpblZvUKLC1wOkP769kMADM9rEIP2 X85XvB0CuVZucqnlUE6kshRZCvVTwWsI= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 5BEF4598057 for ; Wed, 25 Apr 2012 09:51:15 -0700 (PDT) Received: by dady13 with SMTP id y13so547101dad.27 for ; Wed, 25 Apr 2012 09:51:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.34 with SMTP id or2mr1699906pbb.118.1335372674889; Wed, 25 Apr 2012 09:51:14 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 25 Apr 2012 09:51:14 -0700 (PDT) In-Reply-To: <4F982973.1010804@pobox.com> References: <4F981528.9010903@gnutls.org> <4F982973.1010804@pobox.com> Date: Wed, 25 Apr 2012 11:51:14 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:51:23 -0000 On Wed, Apr 25, 2012 at 11:42 AM, Michael D'Errico wr= ote: > Further, we should not create another registry of protocol > names (the Google Tech Note lists "http/1.1", "spdy/1", and > "spdy/2" as being in use). =C2=A0Please leverage the existing IANA > list of well-known services for this (so we don't need to > duplicate definitions for "smtp", "imap4", etc.), along with > the standard "x-" prefix for anything experimental like SPDY > ("x-google-spdy-2" as an example). I disagree. First, TCP port numbers are a scarce resource, and one thing we should have learned by now is that creating scarce resources =3D=3D creating problems. Second, the chances are that the set of TCP port number services and NPN protocols will not be one be a subset of the other. Why waste a port number (or add an alias to one) if it will never be used? Third, why the heck should anyone have to register their service protocol names? That only ever made sense in the context of a scarce resource (port numbers). I'm with those who want SSHv2-style extension naming (i.e., name@domain). It's worked great for SSHv2. (The one major extensibility issue for SSv2 has been its initial handshake, which is not easily extensible, and the one reserved field in it has not been implemented consistently, so it's useless in that regard, which has led to some degree of signalling through fake algorithm identifiers.) Nico -- From agl@google.com Wed Apr 25 09:53:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8377721F8764 for ; Wed, 25 Apr 2012 09:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.822 X-Spam-Level: X-Spam-Status: No, score=-102.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPYUK72hsXKN for ; Wed, 25 Apr 2012 09:53:55 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0FE121F875E for ; Wed, 25 Apr 2012 09:53:54 -0700 (PDT) Received: by iazz13 with SMTP id z13so359863iaz.31 for ; Wed, 25 Apr 2012 09:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=QnWaWWuCMe4VtLPfkM8bp3kXKz2PpPvJh3SVPOxoC8k=; b=SJ4BWZa3BT262yiNJz58pW/6gDpzIkxP7nOnA/sw0v3Ftl4MTH7n/Epzb/dsMJivXM DvCe3j+tDf4BIOJtJdqMtdoM83StCocL1RTq/FgRrQp5BgaS6DC6K/T7Pu5GeaMQUGTf 5yXbnhV/KkytWLCtXoFv69tffGNll0/+Exd+/t6LePB2gK8wKdzGguumwUDBdNoAYrFI J3xboGW9ov4apyTQjOo1xPagwQW5CUSSXpuCqQARom01kmWE2tileuTia2e/ViHdh9IX Utyk3jx25Srksa9/lVOcpR3BdlK4lRN8cis6KqK540yA0GJEG/5i053+0S9ttwQIHSaM j7XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=QnWaWWuCMe4VtLPfkM8bp3kXKz2PpPvJh3SVPOxoC8k=; b=OzV5GX0+HCpo+quvjSIYh3CqlRtTUsPHEuwMwNNU2H47PLsviL621kyCtHLYld2XNt RQaGP9wdYUIHbIRcw4cRyydTCoj1fOv473rKPWlrI0tSX4fgCaERmC65EoFVke/lvihh O4Wq2S0MBqWfIuugRuwPQ5XVBClZBOCkODoiOxjJ6EyhgfbXA8L6WrXWHBPECG1mnjzs RN9jhd8tUyDW0FJle5XR+P91bJ/HxRJUAXn3EBEt67Icnn1N9W1/K9h8vj80gZYIecjJ M5MuEpqQ+wycNZ37gjCsoqWEaKZ/X9HEbZNhPjXV04IUk7RQRAYR1irjOXR18rd3WT+q v4qw== Received: by 10.50.185.232 with SMTP id ff8mr3604582igc.5.1335372834625; Wed, 25 Apr 2012 09:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.185.232 with SMTP id ff8mr3604573igc.5.1335372834500; Wed, 25 Apr 2012 09:53:54 -0700 (PDT) Received: by 10.231.189.95 with HTTP; Wed, 25 Apr 2012 09:53:54 -0700 (PDT) In-Reply-To: <4F981F1B.3020101@extendedsubset.com> References: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> <4F981F1B.3020101@extendedsubset.com> Date: Wed, 25 Apr 2012 12:53:54 -0400 Message-ID: From: Adam Langley To: Marsh Ray Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnHufu+B1RtQu75CojFk7pMNYsxmgUOHbdH0ptIK6lZVCZ0dVtxITAICezt7Jmf+T5Q9BgON1cyrqruZ5gczdIk/AXTfQqfrcYbhKGp4ExMWXQmZB6YzLZcQtslrbHOYY3Psmg5 Cc: "tls@ietf.org" Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:53:55 -0000 On Wed, Apr 25, 2012 at 11:58 AM, Marsh Ray wrote: > We could define something closely analogous to a Hello message extension > area, records sent immediately after the CCS in their respective directions: This would appear to be very close to to what Nikos suggested. But this is important an important point: > There are considerations for resumed handshakes because the server CCS comes > before the client CCS. If NPN were a property of the session, then we wouldn't have to burn an extra round trip when negotiating encrypted extensions with an resumed handshake. It still precludes False Start, but I'm not adverse to making NPN a property of the session - it just makes the code a little more complex. Cheers AGL From stpeter@stpeter.im Wed Apr 25 09:57:12 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DD321F87A1 for ; Wed, 25 Apr 2012 09:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhqxKD2ROsil for ; Wed, 25 Apr 2012 09:57:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0841221F87A0 for ; Wed, 25 Apr 2012 09:57:12 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 74E0D40058; Wed, 25 Apr 2012 11:11:47 -0600 (MDT) Message-ID: <4F982CE6.9090507@stpeter.im> Date: Wed, 25 Apr 2012 10:57:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Michael D'Errico References: <4F981528.9010903@gnutls.org> <4F982973.1010804@pobox.com> In-Reply-To: <4F982973.1010804@pobox.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:57:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/25/12 10:42 AM, Michael D'Errico wrote: > Further, we should not create another registry of protocol names > (the Google Tech Note lists "http/1.1", "spdy/1", and "spdy/2" as > being in use). Please leverage the existing IANA list of > well-known services for this (so we don't need to duplicate > definitions for "smtp", "imap4", etc.), along with the standard > "x-" prefix for anything experimental like SPDY ("x-google-spdy-2" > as an example). Folks in the security area might think differently, but over in the applications area we're working to deprecate the "x-" prefix: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/ In fact it's on tomorrow's IESG telechat, so poke the Security ADs right now if you have concerns. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+YLOYACgkQNL8k5A2w/vw/BgCg3diQJ5QdtVA1MOQV+JMxZUmT L+EAn0/G3OgFszo1tXXlg8Tq5MwNGsGT =BOio -----END PGP SIGNATURE----- From turners@ieca.com Wed Apr 25 10:26:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E7721F85F9 for ; Wed, 25 Apr 2012 10:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtS3PV6xhEsg for ; Wed, 25 Apr 2012 10:26:19 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.160.2]) by ietfa.amsl.com (Postfix) with ESMTP id A57DC21F8603 for ; Wed, 25 Apr 2012 10:26:19 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 2C839418FFC77; Wed, 25 Apr 2012 12:26:19 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id BEBA6418FFB85 for ; Wed, 25 Apr 2012 12:26:18 -0500 (CDT) Received: from [96.231.123.106] (port=41062 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SN5ys-0007HK-Ga for tls@ietf.org; Wed, 25 Apr 2012 12:26:18 -0500 Message-ID: <4F9833B9.9030303@ieca.com> Date: Wed, 25 Apr 2012 13:26:17 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-123-106.washdc.east.verizon.net (thunderfish.local) [96.231.123.106]:41062 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] test (please ignore) EOM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:26:20 -0000 From mike-list@pobox.com Wed Apr 25 11:12:16 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B4421F882D for ; Wed, 25 Apr 2012 11:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y1IXM0lIlFd for ; Wed, 25 Apr 2012 11:12:15 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 23DF521F87FE for ; Wed, 25 Apr 2012 11:12:15 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 858DE9CFC; Wed, 25 Apr 2012 14:12:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=ajW5OHbimjqK 295Sfh29fsgWgX8=; b=gslAPyZIw3mkugbvhK7zKZGXxQyuU210ebdZN6y+P2I4 MfAZ2r4g54t7wA+WDC/yPEM9IM3xUUvv2xJrRZbqhnDBL59w19NxOhiK3vRctQ5K BNyRBl+1BHqdLwaB55yvKwbAhvxr+PAradsO2JLHbwDL095VMae8KADsqG3GTC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Sz3xcc EpD31hDOA+GujEFGa/eRYzlQjJk7ySn5b/m+6Okq9oduN5vto0ma4A0F7pHcIVpC 41NPHAQ3PG7Cwd+jFK7BRy/aX+zASHKhmKlZJDLeZW9t/+B1HksQwI3HHCTGHNKm YCPSXIMNhV3U9ZXRdIehEfzK4cWXgJbxrDDEM= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7E3A39CFB; Wed, 25 Apr 2012 14:12:14 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 9B5DA9CFA; Wed, 25 Apr 2012 14:12:13 -0400 (EDT) Message-ID: <4F983E7C.1050704@pobox.com> Date: Wed, 25 Apr 2012 11:12:12 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <4F981528.9010903@gnutls.org> <4F982973.1010804@pobox.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 2F0213A6-8F02-11E1-B77E-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:12:16 -0000 I think you misunderstood what I meant. I don't want to use port numbers, but rather the service names such as "smtp" and "imap" which have already been registered with IANA. No need to create a duplicate registry for use in TLS NPN. I am unfamiliar with SSH at the protocol level, so was unaware of its extension naming. Would "spdy/2@google.com" be an example of how to name non-IANA things? Looks good to me. Mike Nico Williams wrote: > On Wed, Apr 25, 2012 at 11:42 AM, Michael D'Errico wrote: >> Further, we should not create another registry of protocol >> names (the Google Tech Note lists "http/1.1", "spdy/1", and >> "spdy/2" as being in use). Please leverage the existing IANA >> list of well-known services for this (so we don't need to >> duplicate definitions for "smtp", "imap4", etc.), along with >> the standard "x-" prefix for anything experimental like SPDY >> ("x-google-spdy-2" as an example). > > I disagree. First, TCP port numbers are a scarce resource, and one > thing we should have learned by now is that creating scarce resources > == creating problems. Second, the chances are that the set of TCP > port number services and NPN protocols will not be one be a subset of > the other. Why waste a port number (or add an alias to one) if it > will never be used? Third, why the heck should anyone have to > register their service protocol names? That only ever made sense in > the context of a scarce resource (port numbers). > > I'm with those who want SSHv2-style extension naming (i.e., > name@domain). It's worked great for SSHv2. (The one major > extensibility issue for SSv2 has been its initial handshake, which is > not easily extensible, and the one reserved field in it has not been > implemented consistently, so it's useless in that regard, which has > led to some degree of signalling through fake algorithm identifiers.) > > Nico From nico@cryptonector.com Wed Apr 25 11:29:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E4B21F88D6 for ; Wed, 25 Apr 2012 11:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtPKZtNhqhA2 for ; Wed, 25 Apr 2012 11:29:58 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6B621F88D5 for ; Wed, 25 Apr 2012 11:29:58 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3E7E367406A for ; Wed, 25 Apr 2012 11:29:58 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 1288F674060 for ; Wed, 25 Apr 2012 11:29:57 -0700 (PDT) Received: by dady13 with SMTP id y13so713889dad.27 for ; Wed, 25 Apr 2012 11:29:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.34 with SMTP id or2mr2356407pbb.118.1335378597206; Wed, 25 Apr 2012 11:29:57 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 25 Apr 2012 11:29:57 -0700 (PDT) In-Reply-To: <4F983E7C.1050704@pobox.com> References: <4F981528.9010903@gnutls.org> <4F982973.1010804@pobox.com> <4F983E7C.1050704@pobox.com> Date: Wed, 25 Apr 2012 13:29:57 -0500 Message-ID: From: Nico Williams To: "Michael D'Errico" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:29:59 -0000 On Wed, Apr 25, 2012 at 1:12 PM, Michael D'Errico wro= te: > I think you misunderstood what I meant. =C2=A0I don't want to use > port numbers, but rather the service names such as "smtp" and > "imap" which have already been registered with IANA. =C2=A0No need > to create a duplicate registry for use in TLS NPN. Right, but those names got with port numbers... > I am unfamiliar with SSH at the protocol level, so was unaware > of its extension naming. =C2=A0Would "spdy/2@google.com" be an > example of how to name non-IANA things? =C2=A0Looks good to me. Yes, that. Works great! Nico -- From agl@google.com Wed Apr 25 11:40:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3E221F88B0 for ; Wed, 25 Apr 2012 11:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.163 X-Spam-Level: X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9rlgfssSuMQ for ; Wed, 25 Apr 2012 11:40:20 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9BF21F87BF for ; Wed, 25 Apr 2012 11:40:20 -0700 (PDT) Received: by ghbg16 with SMTP id g16so453666ghb.31 for ; Wed, 25 Apr 2012 11:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=I1AQvjDgJ4H5v9d5nIxOX2rMi8GM4FoV93/Qa8NQ9P4=; b=Sz70WKce0yT3BznXPXqZCgIPqMIxy5cFLK8boadOaHmTo8v9iSyV32YsDBM+Uq4soe cZsyzrzP0zlGXD+55zRkzuAjPHcE9yg8nHl53yEv6qnvD4G8BrycEvtkPSLjf9mfn7fA KXovSNz6aic4OtWjYJc/HjNXJAHMmYXufjls7qVy8YayMf7Mm93uWpa6foo1LFSaf/wx EauxqN59fD9nHjiZps/3ORxSSyIR1Kv6VkKRMzo9QP46eBbE1mhyuJYSdAs4Mb0LoR9c xf5jXMCf0ulBJXgM5+UH+AHT1FxlLam8rL02mEI1B81jWSrDfsPirSmZos1RLFDKXAwO MuZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=I1AQvjDgJ4H5v9d5nIxOX2rMi8GM4FoV93/Qa8NQ9P4=; b=Z6dtnySmpJQ7Yw4H9qP1R/YYdLwcL4ohcHF7HkSTkk3zd0arCXq2WzgXeeeEhUXXId cQEgFXKAENUCNcYjuPMSmhKtEc63yrRl9Gk+lJmdkHGRNtuUqZ59PrZWOu//TtOX2oyG p9XsQAGuPHowrrk3DQPiu6uiSAiCh4KrKKkEEVvgUnRoSBRgT5Ussrrwe2ZRXVCpOy2y IEHS51uqseIi1Iu/gdnu0fNwiQDCnbHb0FKQiVi3bLADUzbUNhL2BTDYJgDPAXLEZ133 GedxVFwMkyLvZ5cKtvZXpQf9PzgVhesICbpU7psmAE6W9brmnkJAz76A71M3PYIj1uyC t4eg== Received: by 10.50.237.101 with SMTP id vb5mr15836036igc.15.1335379219334; Wed, 25 Apr 2012 11:40:19 -0700 (PDT) Received: by 10.50.237.101 with SMTP id vb5mr15836029igc.15.1335379219215; Wed, 25 Apr 2012 11:40:19 -0700 (PDT) From: Adam Langley In-Reply-To: References: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> <20120425121844.GE9472@randombit.net> <4F981528.9010903@gnutls.org> <4F981571.9060100@gnutls.org> <4F981F1B.3020101@extendedsubset.com> <4F9821D0.5050805@extendedsubset.com> <4F982973.1010804@pobox.com> <4F982CE6.9090507@stpeter.im> <4F983E7C.1050704@pobox.com> MIME-Version: 1.0 Date: Wed, 25 Apr 2012 11:40:17 -0700 (PDT) Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=14dae934083b00766e04be853434 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlJXhRLMRAqQwOjPTH4G+Xg+QoA8eVC5GMu2AQbjjjZyYR11vKWIX0n/x1TA1DgqNuncDGvAiHoJw7WzFLBlQDrgDfFQ6W2rlOckBpLxjHwZGbKtzdCITCb/3eyYCieYS0e6uDd Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 18:40:21 -0000 --14dae934083b00766e04be853434 Content-Type: text/plain; charset=UTF-8 On Wed Apr 25 14:29:57 GMT-400 2012, Nico Williams wrote: > Yes, that. Works great! > Rather, I think it would be "spdy@google.com/2". None the less, I'm perfectly happy with that if it avoids extra IANA work. Cheers AGL --14dae934083b00766e04be853434 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed Apr 25 14:29:57 GMT-400 2012, Nico Williams <nico@cryptonector.com> wrote:=C2=A0

Yes, that. Works great!

Rather, I think it would b= e "spdy@google.com/2". N= one the less, I'm perfectly happy with that if it avoids extra IANA wor= k.


Cheers

AGL
--14dae934083b00766e04be853434-- From nico@cryptonector.com Wed Apr 25 12:20:48 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F01121F85C4 for ; Wed, 25 Apr 2012 12:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sty2oqpY2jPw for ; Wed, 25 Apr 2012 12:20:47 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C610921F891C for ; Wed, 25 Apr 2012 12:20:45 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 91563678062 for ; Wed, 25 Apr 2012 12:20:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=fSeLuxfikZBr34BaAfOOR 2v6E5Q5oQmkQCnTHyeNIQndQ2pMNuCBfpmt8fYxMBQNLxizF6+Z8UkqMrhkSMMek SJaflr6vvfggfOn0M7lVOXHgQS4O/uhu0dVUELlcTth9j1cd0oy/56q/cGiBVRzg GrXyrcpANFajkHMi+gajUk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=J+kakSiICwZci9E4Wlaz mhTse0o=; b=xfypzojuhUN7eKs5C8BzFPJ4T4MvmFjAl9PE+riwBQnZfjF+r13w qe+EpFtKvTgXXiZi6m2gtEBlnQzb1mIw7ozO4Us4pkOyEWBAGXuCbeCTnh0qjxtv fFR9li1gwf6+K5/wk30gZCWI460XMNljrmVRBaZyimrqu8blbSqtIc4= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 6CDE2678057 for ; Wed, 25 Apr 2012 12:20:45 -0700 (PDT) Received: by pbbrp16 with SMTP id rp16so1869727pbb.31 for ; Wed, 25 Apr 2012 12:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.130.130 with SMTP id oe2mr9087950pbb.160.1335381645062; Wed, 25 Apr 2012 12:20:45 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 25 Apr 2012 12:20:44 -0700 (PDT) In-Reply-To: References: <13435052-1245-4C37-A0D0-C5CBFFB1FE75@checkpoint.com> <20120425121844.GE9472@randombit.net> <4F981528.9010903@gnutls.org> <4F981571.9060100@gnutls.org> <4F981F1B.3020101@extendedsubset.com> <4F9821D0.5050805@extendedsubset.com> <4F982973.1010804@pobox.com> <4F982CE6.9090507@stpeter.im> <4F983E7C.1050704@pobox.com> Date: Wed, 25 Apr 2012 14:20:44 -0500 Message-ID: From: Nico Williams To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:20:48 -0000 On Wed, Apr 25, 2012 at 1:40 PM, Adam Langley wrote: > On Wed Apr 25 14:29:57 GMT-400 2012, Nico Williams > wrote: >> >> Yes, that. Works great! > > Rather, I think it would be "spdy@google.com/2". None the less, I'm > perfectly happy with that if it avoids extra IANA work. In SSHv2 the rule is @, so it'd have to be spdy2@google.com, or some such. But tonce we've agreed to the principle, the exact form of the identifier is much less important. I don't mind if we went with @[/], or better yet: tag URIs (RFC4151) (name@domain is slightly less verbose, but whatever). Nico -- From marsh@extendedsubset.com Wed Apr 25 12:32:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18B421F88FE for ; Wed, 25 Apr 2012 12:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDQJ7Nqw38UK for ; Wed, 25 Apr 2012 12:32:55 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 47B0B21F88DF for ; Wed, 25 Apr 2012 12:32:55 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SN7xN-000CR0-2x; Wed, 25 Apr 2012 19:32:53 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B27BA6081; Wed, 25 Apr 2012 19:32:51 +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: U2FsdGVkX19AO6ldfygyFOwzMUgP00vq8viBo9Yop2s= Message-ID: <4F985162.7040405@extendedsubset.com> Date: Wed, 25 Apr 2012 14:32:50 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Adam Langley References: <4F981528.9010903@gnutls.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:32:55 -0000 On 04/25/2012 11:40 AM, Adam Langley wrote: > > The idea would be that the server doesn't advertise Tor, or any other > possibly suspect protocol. Rather the client would simply select "tor" > as the protocol. > > The fact that the server advertises is unfortunate, but necessary to > avoid an extra round trip. I'd rather see NPN in the clear as a > standard ClientHello/ServerHello negotiation then take an extra round > trip. I don't speak for the Tor project, but I don't think this design is going to meet anyone's requirements for serious censorship resistance. Nevertheless, giving some privacy to the significant bits of the handshake in a way that is more latency-friendly than full renegotiation is very appealing. It seems likely to enable new and interesting applications, SPDY is just one good example. Unfortunately, we must keep in mind that anything sent before receiving the other endpoint's Finished message is going to raise similar considerations as False Start. The security guarantees provided to this data are somewhat squishy, as they tend to depend on all sorts of not-yet-fully authenticated details of the in-progress negotiation. As we saw with ServerKeyExchange DHE_RSA/ECDH, even the future introduction of new key exchanges and cipher suites can change these properties. In the case of something like NP(N), a MitM might utilize a downgrade attack which allows him to decrypt the client's NP record (possibly offline). This could break the handshake, but clients are so eager to retry the user might not even notice. So maybe any facility for "privately" negotiating handshake extensions ought to be held to a clear standard lest we invite disaster, namely, it should provide the same security guarantees as are provided to application data. - Marsh From mike-list@pobox.com Wed Apr 25 12:58:02 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187BF21F88F0 for ; Wed, 25 Apr 2012 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT-ErTuw5m8x for ; Wed, 25 Apr 2012 12:58:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 698A821F87C5 for ; Wed, 25 Apr 2012 12:58:01 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C98D0972A; Wed, 25 Apr 2012 15:58:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=WRZ9kGAgrp8l dq5Ri6rJCDRwaMM=; b=OvHsNMJs0bPGTzUe3vT7VtpJxgpLm8v++SIbXIPWiMiz feCmXHH5UJ7gerU7XEKXMP8GAXxLg3S1Wuslhe7fNy0ePB5V1o3YgT4fgQUkCzt5 JYGf8XDYHA2B/JZEMy5UiIJs2C0nJmvQWJU7uZcEYuRhUEaOepqmPxGp7lQuFGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ZINSm1 IOgHjiUxfz2SJjQ+TrFDdqOnDsRz/Kcz2zowqAFQVOrm9g3A49j0b+7IieuTT0/Z PAond9P+ikpbWC1YpMtmPQqSqG/Awzmpf9GOhOtwEE1RTcTg7F0oPN2IUi99xi2e bornFaN0vEfuw13dd/BO9DD0pKHTe69Kr1VgY= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id C16F69729; Wed, 25 Apr 2012 15:58:00 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 12CDE9728; Wed, 25 Apr 2012 15:57:59 -0400 (EDT) Message-ID: <4F985747.1020707@pobox.com> Date: Wed, 25 Apr 2012 12:57:59 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Adam Langley References: <4F981528.9010903@gnutls.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: F5C85672-8F10-11E1-B471-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 19:58:02 -0000 Adam Langley wrote: > > The fact that the server advertises is unfortunate, but necessary to > avoid an extra round trip. I'd rather see NPN in the clear as a > standard ClientHello/ServerHello negotiation then take an extra round > trip. I think we can accommodate both "styles" of NPN with one extension: A) If the client sends an empty ExtensionData, then behave the way it is currently defined by the Technical Note. B) Otherwise if the client sends a list of protocol strings in its ExtensionData, then the server chooses the first one it supports and responds with it. C) Sending an empty list would have to be defined as either an error (server responds with a fatal alert) or to be the same as (A). Mike From mike-list@pobox.com Wed Apr 25 13:31:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1D21F8829 for ; Wed, 25 Apr 2012 13:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoAGqhhX+Kqn for ; Wed, 25 Apr 2012 13:31:20 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0621F8828 for ; Wed, 25 Apr 2012 13:31:19 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 7F77C9A3F for ; Wed, 25 Apr 2012 16:31:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type; s=sasl; bh=0biM zxzW1gs5m4vQyh0oogjhSbw=; b=gCYTSw98KATbZh1r56tQ9uGX17YcsFVVPVqq Ubz3xfJY/h66AbEfikxtS996uOPz/YEJGUVGnqUY+AZYav68JM+gC62t92v7MFiP L/n+zql+6f1Wqi3zCK+CRWJT+ZrHz2IDvx5hGLRxKYPvurQplEHqjPdB5epGNz2o s6WLsic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type; q=dns; s=sasl; b=ACu ucKHdBgV5gEeJTNVeOn+gb5S7qw+Ep3fP1jd0j006pbhKvDf7pcdggiftXTdO1wM wjgSMfeg4Pj6cD1OSCiQWZIhqansdVvGObyPYoGWsDutH3IgAi1GWuphcJYRVWaI J6Pup0uFGK9W5N9Qg2m5Vng8UhPlJtr7h9sp3AN4= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 78E5F9A38 for ; Wed, 25 Apr 2012 16:31:19 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id C9DE19A37 for ; Wed, 25 Apr 2012 16:31:18 -0400 (EDT) Message-ID: <4F985F15.90807@pobox.com> Date: Wed, 25 Apr 2012 13:31:17 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: TLS Mailing List Content-Type: multipart/mixed; boundary="------------050103010003050201000006" X-Pobox-Relay-ID: 9D04E3CA-8F15-11E1-B609-8BEB728A0A4D-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] [Fwd: Re: What's the right version number in the PreMasterSecret for renegotiation] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:31:21 -0000 This is a multi-part message in MIME format. --------------050103010003050201000006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nasko asked that I forward this message to the list. Apologies if you've already received it. Mike --------------050103010003050201000006 Content-Type: message/rfc822; name="Re: [TLS] What's the right version number in the PreMasterSecret for renegotiation.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [TLS] What's the right version number in the PreMasterSe"; filename*1="cret for renegotiation.eml" X-Account-Key: account1 X-Mozilla-Keys: Return-Path: Received: from murder ([unix socket]) (authenticated user=38729857@mailstore.pobox.com bits=0) by b-pb-mailstore-quonix (Cyrus v2.2.13) with LMTPA; Wed, 25 Apr 2012 11:30:45 -0400 X-Sieve: CMU Sieve 2.2 Received: from sienna.pobox.com (sienna.pobox.com [74.115.168.43]) by mailstore.pobox.com (Postfix) with ESMTP id 608AAF914 for <38729857@mailstore.pobox.com>; Wed, 25 Apr 2012 11:30:45 -0400 (EDT) Received: from sienna.pobox.com (localhost [127.0.0.1]) by sienna.pobox.com (Postfix) with ESMTP id DC4DA200212 for <38729857@mailstore.pobox.com>; Wed, 25 Apr 2012 11:30:44 -0400 (EDT) Delivered-To: mike-list@pobox.com X-Pobox-Orig-Sender: X-Pobox-Delivery-ID: 9E61EADA-8EEB-11E1-90F7-D46845A40134-38729857!sienna.pobox.com x-pobox-client-address: 205.205.221.4 x-pobox-client-name: mail231.csoft.net Received: from mail231.csoft.net (mail231.csoft.net [205.205.221.4]) by sienna.pobox.com (Postfix) with ESMTP id 5A614200599 for ; Wed, 25 Apr 2012 11:29:41 -0400 (EDT) Received: by mail231.csoft.net (Postfix, from userid 1021) id 8B74D241A35D; Wed, 25 Apr 2012 11:29:35 -0400 (EDT) Date: Wed, 25 Apr 2012 11:29:35 -0400 From: Nasko Oskov To: Michael D'Errico Cc: Andrei Popov , "tls@ietf.org" Subject: Re: [TLS] What's the right version number in the PreMasterSecret for renegotiation Message-ID: <20120425152935.GJ5543@netsekure.org> References: <7A41E0C9581F8346A6883D6254E78490095BE64A@SN2PRD0310MB395.namprd03.prod.outlook.com> <4F91AE27.4010803@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F91AE27.4010803@pobox.com> User-Agent: Mutt/1.4.2.3i X-ICG-Account-ID: 38729857 On Fri, Apr 20, 2012 at 11:42:47AM -0700, Michael D'Errico wrote: > While it would be good for clients to do this correctly, I've seen > many people argue that checking the version embedded inside an RSA > premaster secret serves no purpose other than to cause more failed > handshakes. Version rollback protection is redundant since the > Finished messages also catch tampering. I'm with Michael on this. I've discussed this privately with a few people few months ago and the consensus seems to be that from security perspective it is not needed anymore with one caveat - no SSLv2 fallback allowed. The premaster version check was added to prevent the downgrade to SSLv2, so if SSLv2 is disabled, there is very little use of the value in current TLS implementations. > So, yes, please fix any problems you find w.r.t. encoding the version > in the RSA premaster secret, but also consider turning off checking > in your servers (or make it configurable, disabled by default). It is best to be configurable, with the default off. -- Nasko Oskov "A hacker does for love what others would not do for money." --------------050103010003050201000006-- From jsalowey@cisco.com Wed Apr 25 17:36:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5894711E8091 for ; Wed, 25 Apr 2012 17:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsiE-+ZX1paW for ; Wed, 25 Apr 2012 17:36:05 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB611E8076 for ; Wed, 25 Apr 2012 17:36:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=183; q=dns/txt; s=iport; t=1335400565; x=1336610165; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=a4gtoEUmWjmHisFCUZR4DSwQBt99aSHtIh4KzXLVd/M=; b=awKiRgtO2m70ssJalsLI+LIuqZuekVJfa2sO7y2SUQXW6Pmbacu/uGEm UYFMOwfOwR7Cue1Nj5LZGJt6sF/vPhlIy8W4U8CVYECPMxkdMwG5cX1jF uXM68Dzu7h0v7SSTbg+uRtsLlnwk1WaTbGceHYi8CpiH73gVXKvXdKVZu Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYFAKWXmE+rRDoG/2dsb2JhbABFgx2uL4EHgiIBCh2CModsmgyBKKAXjTuCQmMEiGONGIV0iGGBaYMJ X-IronPort-AV: E=Sophos;i="4.75,484,1330905600"; d="scan'208";a="39620154" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 26 Apr 2012 00:36:05 +0000 Received: from [10.33.248.250] ([10.33.248.250]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3Q0a4X0017738 for ; Thu, 26 Apr 2012 00:36:05 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Apr 2012 17:35:55 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 00:36:06 -0000 This is an announcement of working group last call for = draft-ietf-tls-oob-pubkey-03.txt. Please complete reviews and send = comments to the TLS list by Friday May 18, 2012. =20 From simon@josefsson.org Thu Apr 26 01:23:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5521F87A4 for ; Thu, 26 Apr 2012 01:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.817 X-Spam-Level: X-Spam-Status: No, score=-99.817 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhvcNf+tplP2 for ; Thu, 26 Apr 2012 01:23:03 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id DC22B21F84CE for ; Thu, 26 Apr 2012 01:23:02 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3Q8Mri0025020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Apr 2012 10:22:55 +0200 From: Simon Josefsson To: tls@ietf.org References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120426:jsalowey@cisco.com::Ny43+TtLXSTX+iRJ:6YaG X-Hashcash: 1:22:120426:tls@ietf.org::tzOrAcKjJPqMBnO7:DesM Date: Thu, 26 Apr 2012 10:22:53 +0200 In-Reply-To: (Joe Salowey's message of "Wed, 25 Apr 2012 17:35:55 -0700") Message-ID: <87pqauq4v6.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:23:03 -0000 I generally support the idea behind this document, and the document looks in reasonable good shape. Please find my review comments below. Major concerns: 1) Section 3.1 and 3.2 more or less duplicate section 3.1 and 3.2 of RFC 6091. Wouldn't it be better to describe the RawPublicKey CertificateType alone, rather than duplicating the entire CertificateType extension? There is a risk that this document says something different than RFC 6091, which ought to be the canonical place for the definition of the "cert_type" extension. If this document moves forward, we'll effectively have two specifications of the "cert_type" extension. The IANA registry points at RFC 6091. This seems bad from a standards process point of view. My suggestion is to normatively reference RFC 60961 (and call out that in the LC announcement) and specify the RawPublicKey "cert_type" extension only. 2) The "Security Considerations" says that the main challenge with raw public keys over keys in X.509/OpenPGP is how to associate the public key with a specific entity. However, I believe the problem is larger than that, and there is a similar challenge for several other forms of metadata about a public key. It is not only the identity of a key that can have significant impact on system security. Other kind of metadata (for example "do not use this public key after the year 2015") can be critical for secure deployments. I suggest to add a final paragraph to discuss this. Minor concerns: 1) Currently, TLS authentication can only occur via X.509-based Public Key Infrastructure (PKI) or OpenPGP certificates. By specifying a Replace 'TLS authentication' with 'TLS public-key authentication', as TLS supports several non-X509/OpenPGP forms of authentication. 2) One such alternative public key valiation method is offered by the ^ typo 3) The support for raw public keys is introduced into TLS via a new non- PKIX certificate type. I suggest to drop 'non-PKIX'. It is non-OpenPGP too, but neither is relevant. The document define a new certificate type, period. 4) to-server communication. As part of the manufacturing process, the embeded device may be configured with the address and the public key of a dedicated CoAP server, as well as a public key for the client ^^^^^^^^^^ itself. The usage of X.509-based PKIX certificates [PKIX] may not Shouldn't that be 'private key'? Or at least 'public and private key'. 5) Section 3: the certificate payloads only contain the SubjectPublicKeyInfo There should be a reference to [PKIX] here, since SubjectPublicKeyInfo is defined there and it is important to be able to find that definition. /Simon From marsh@extendedsubset.com Thu Apr 26 10:12:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725AA21F8594 for ; Thu, 26 Apr 2012 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.334, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecBtFayKYBdh for ; Thu, 26 Apr 2012 10:12:32 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id E0DC721F8593 for ; Thu, 26 Apr 2012 10:12:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1SNSF5-0006Og-9c for tls@ietf.org; Thu, 26 Apr 2012 17:12:31 +0000 Received: from [172.16.2.4] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9409767A3 for ; Thu, 26 Apr 2012 17:12:30 +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+wIXRANWSs2wC7U6aLiud0dcJn9oaTuC4= Message-ID: <4F9981FC.4000205@extendedsubset.com> Date: Thu, 26 Apr 2012 12:12:28 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <4F981528.9010903@gnutls.org> <4F985162.7040405@extendedsubset.com> In-Reply-To: <4F985162.7040405@extendedsubset.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:12:32 -0000 On 04/25/2012 02:32 PM, Marsh Ray wrote: > > I don't speak for the Tor project, but I don't think this design is > going to meet anyone's requirements for serious censorship resistance. > > Nevertheless, giving some privacy to the significant bits of the > handshake in a way that is more latency-friendly than full renegotiation > is very appealing. It seems likely to enable new and interesting > applications, SPDY is just one good example. Just an update, I've made contact with the Tor project. As heavy users of TLS, they are interested in the direction the protocol evolves. They may also have some useful input here on this issue of privacy of handshake records. - Marsh From mrex@sap.com Thu Apr 26 10:21:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A7E21F8638 for ; Thu, 26 Apr 2012 10:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rVapf4MxuOS for ; Thu, 26 Apr 2012 10:21:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B90E621F8622 for ; Thu, 26 Apr 2012 10:21:04 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q3QHL0E6024661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Apr 2012 19:21:01 +0200 (MEST) From: Martin Rex Message-Id: <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> To: marsh@extendedsubset.com (Marsh Ray) Date: Thu, 26 Apr 2012 19:21:00 +0200 (MEST) In-Reply-To: <4F9981FC.4000205@extendedsubset.com> from "Marsh Ray" at Apr 26, 12 12:12:28 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:21:05 -0000 Marsh Ray wrote: > > On 04/25/2012 02:32 PM, Marsh Ray wrote: > > > > I don't speak for the Tor project, but I don't think this design is > > going to meet anyone's requirements for serious censorship resistance. > > > > Nevertheless, giving some privacy to the significant bits of the > > handshake in a way that is more latency-friendly than full renegotiation > > is very appealing. It seems likely to enable new and interesting > > applications, SPDY is just one good example. > > Just an update, I've made contact with the Tor project. As heavy users > of TLS, they are interested in the direction the protocol evolves. They > may also have some useful input here on this issue of privacy of > handshake records. http://tools.ietf.org/html/rfc4680 describes two additional generic handshake messages in the cleartext part of the TLS handshake. Maybe we should define something similar for the encrypted part of the handshake, so that we don't have to add new handshake messages for every new feature? -Martin From agl@google.com Thu Apr 26 10:29:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C739721F86B6 for ; Thu, 26 Apr 2012 10:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6beGkRHjwpm for ; Thu, 26 Apr 2012 10:29:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44D6721F86B7 for ; Thu, 26 Apr 2012 10:29:40 -0700 (PDT) Received: by iazz13 with SMTP id z13so2269085iaz.31 for ; Thu, 26 Apr 2012 10:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=jqS2mwCqW+2W1UmsEmtlT8B4uewrbTFioFwZP+FCybc=; b=P1Um9z/QbNkZviawmjY6k+2YpGEvSEEY7WRSjPoHaVBP0i0RON65DudDbhrhjwJASe tx0LfCcvkTtqTY/3CxIBPImSDjMrS8rR1f05Fj0sfemp29roXQRLEHbEZZsfr0Xs9A3X Q1bxRjB1Jy96CYJmQ5k12qGNGezrtlGJPOamiNJn6MBhjFXud6XrVJigxhh5M7JAD7VQ HvAhrPAPyckY0/dNqVPn7is6ReY/e+bJV6KooJhg+pezGFznuIDYwUfEfByIuSBX9jVb gZnVUrobZQ5OW+RBC06naRWNK+lmg+2HmXciNIY/HmzcqBry10NwXbZFa6lt/aoxbsG7 ePqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=jqS2mwCqW+2W1UmsEmtlT8B4uewrbTFioFwZP+FCybc=; b=PjTSj5y3Yp/moGzQyf7RbQWNAJ/cKhkyXxlesJiKtj1nd8YcaXU5p1vyJtxVv+IBRM T3JvVrkeltcfiqaouRsiXwTJwYfs4lKJZQ7gdkcyuahlL0KSPPO3NVnYMLCyKyxviQGG nUUwRHBx5oIHiLgzT0PLvP2HXlsbZ2qW3ieKM7y32u3nQliYMxGimJrccI4t6r3yOvwg wgaueACBbl5mYNncOrQADK3wpda1nTtaJsBiXwwUqidBl1BT60Lf2AINjCglqR7izDNX GntSfehPn9oVOxn1UYaTQPxy1IAeaVaePCpFyGMntxGy99ddd7t9D9YKg0sFrs05uvI6 3xDg== Received: by 10.50.186.231 with SMTP id fn7mr8166811igc.15.1335461379827; Thu, 26 Apr 2012 10:29:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.186.231 with SMTP id fn7mr8166800igc.15.1335461379723; Thu, 26 Apr 2012 10:29:39 -0700 (PDT) Sender: agl@google.com Received: by 10.231.189.95 with HTTP; Thu, 26 Apr 2012 10:29:39 -0700 (PDT) In-Reply-To: <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> Date: Thu, 26 Apr 2012 13:29:39 -0400 X-Google-Sender-Auth: 5nO4bxN1oXX8npiU-KD6iOVnipk Message-ID: From: Adam Langley To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnVmTwud2DtXh9lTYhRGDi0CLbuSlow5RR+wCkayACdKnN4MVlSVPf23aajT4JftMLCLJgwZGJ5DhQ5RIhScUR8LFhwojpjU5b5mxL+Hpez14QXSihhkDn5hGDq/JLsZGjydRnp Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:29:40 -0000 On Thu, Apr 26, 2012 at 1:21 PM, Martin Rex wrote: > Maybe we should define something similar for the encrypted part of > the handshake, so that we don't have to add new handshake messages > for every new feature? Indeed, folks seem to be leaning towards wanting more generic support for extensions under encryption. Having a "client offers, server selects" extension exchange after the ChangeCipherSpecs is perfectly possible, although at the cost of precluding False Starting a full handshake. False Start isn't a real TLS feature of course, but we're currently pondering how much we want to be able to support it, and how much we want NPN under encryption. Also, if there's a generic "secure" extension exchange after the CCS, it has the same concerns as False Start. i.e. an attacker can perform a downgrade attack on it. For False Start we say that if the ciphersuite isn't strong enough, we simply won't do it. But having a TLS feature switch on and off like that seems untenable. So, in short, "still thinking". Cheers AGL From paul@nohats.ca Thu Apr 26 10:57:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E591F21E809F for ; Thu, 26 Apr 2012 10:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlS2oPiwImfr for ; Thu, 26 Apr 2012 10:57:46 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id E650221E808D for ; Thu, 26 Apr 2012 10:57:45 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 926E68036B; Thu, 26 Apr 2012 13:57:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 8641F8032E; Thu, 26 Apr 2012 13:57:44 -0400 (EDT) Date: Thu, 26 Apr 2012 13:57:44 -0400 (EDT) From: Paul Wouters To: Simon Josefsson In-Reply-To: <87pqauq4v6.fsf@latte.josefsson.org> Message-ID: References: <87pqauq4v6.fsf@latte.josefsson.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-oob-pubkey-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 17:57:47 -0000 On Thu, 26 Apr 2012, Simon Josefsson wrote: > Major concerns: > > 1) Section 3.1 and 3.2 more or less duplicate section 3.1 and 3.2 of RFC > 6091. Wouldn't it be better to describe the RawPublicKey > CertificateType alone, rather than duplicating the entire > CertificateType extension? I think you are right. This was originally done because it started as a new TLS extension, and then also covered what has now been moved to cached-objects. > 2) The "Security Considerations" says that the main challenge with raw > public keys over keys in X.509/OpenPGP is how to associate the public > key with a specific entity. However, I believe the problem is larger > than that, and there is a similar challenge for several other forms of > metadata about a public key. It is not only the identity of a key that > can have significant impact on system security. Other kind of metadata > (for example "do not use this public key after the year 2015") can be > critical for secure deployments. I suggest to add a final paragraph to > discuss this. Sounds reasonable. Will do. > Minor concerns: All fixed as per your suggestions. Paul From desnacked@riseup.net Thu Apr 26 19:57:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95FF11E8079 for ; Thu, 26 Apr 2012 19:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbY79vrBq0fp for ; Thu, 26 Apr 2012 19:57:44 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA311E8072 for ; Thu, 26 Apr 2012 19:57:44 -0700 (PDT) Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id F1D625B3E0 for ; Thu, 26 Apr 2012 19:57:43 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: desnacked@riseup.net) with ESMTPSA id 0DBBE9BD From: George Kadianakis To: tls@ietf.org User-Agent: Microsoft Outlook Express 6.00.2900.5843 Date: Fri, 27 Apr 2012 04:57:04 +0200 Message-ID: <87aa1xg9vj.fsf@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.97.3 at mx1 X-Virus-Status: Clean Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 02:57:45 -0000 Adam Langley wrote: > On Thu, Apr 26, 2012 at 1:21 PM, Martin Rex wrote: > > Maybe we should define something similar for the encrypted part of > > the handshake, so that we don't have to add new handshake messages > > for every new feature? > > Indeed, folks seem to be leaning towards wanting more generic support > for extensions under encryption. Having a "client offers, server > selects" extension exchange after the ChangeCipherSpecs is perfectly > possible, although at the cost of precluding False Starting a full > handshake. False Start isn't a real TLS feature of course, but we're > currently pondering how much we want to be able to support it, and how > much we want NPN under encryption. > > Also, if there's a generic "secure" extension exchange after the CCS, > it has the same concerns as False Start. i.e. an attacker can perform > a downgrade attack on it. For False Start we say that if the > ciphersuite isn't strong enough, we simply won't do it. But having a > TLS feature switch on and off like that seems untenable. > > So, in short, "still thinking". > > > Cheers > > AGL Minimizing the unnecessary unencrypted information in TLS seems like a wise idea, and post-CCS TLS extensions is a good first step in that direction. Defining the use cases and the threat model of post-CCS extensions is probably a useful thing to do at this point. For example, thinking about use cases, there are TLS extensions that can't be placed post-CCS, like the ECC extensions or SessionTicket, since they concern the SSL key exchange. At the same time, TLS extensions like server_name, RI or NPN make sense post-CCS. With regards to the threat model, post-CCS extensions should probably share the exact same threat model as pre-CCS extensions, since they both happen before the Finished record (for example, putting application data on them is not a good idea). Talking about threat models, the "client offers, server selects" model might be susceptible to brute-force extension enumeration attacks, and if 'secret TLS extensions' are considered useful, the protocol should be designed appropriately. Getting a bit funkier (since the state machine is a-changing these days) maybe it makes sense to add a post-auth post-Finished phase to TLS, so that "supplemental data" can be exchanged without the fear of an MITM. PS: Sorry for screwing up the threading; I am not subscribed to the list and the ML web archive does not expose Message-IDs. From tom@ritter.vg Fri Apr 27 07:53:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12621F86B4 for ; Fri, 27 Apr 2012 07:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkQLEQK1IVXf for ; Fri, 27 Apr 2012 07:53:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 753C321F86AF for ; Fri, 27 Apr 2012 07:53:54 -0700 (PDT) Received: by yhkk25 with SMTP id k25so499845yhk.31 for ; Fri, 27 Apr 2012 07:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Z9Vaql0Z+8U5S3dy8Zx+Gs8dXYZMp0cN/3MkvyPUiSQ=; b=GtRWl3LYH12rubpD+sBUpcplk82oZojb1+m6Pt2GrTlusBgA5uKTT1qtBpzIKu9Uea Obidcvi+Fj3yZ+qiVjw1j/p49YshO8nBGBTUzR0XsN3tmMIAKSkvWH/4lf0e/cItdLQT Rp5Vlb9dqOlX8AxcpkdSoFf4xDVOjDbo/yGjY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=Z9Vaql0Z+8U5S3dy8Zx+Gs8dXYZMp0cN/3MkvyPUiSQ=; b=glvW47pbghqzZLxjbgJdvY2GLwYP64cbCQfQbeOOzeKlw/FBdMpzaJwx1DAGh53KPA JrO90PWEjmUSkWHMF39nfHp7BcTJg7N4qxfaMOhkK9u7aF9oqu0hAZ+qOpP5a6eXonS4 m6QSdvZPQm+W6rcJ4ryf4zfOpeBoCkCt0cuMpKrSgbj/hYo1BVPW10H7alpyu21ZSczH fFtGAIagKb5no43auZ3YlLC6ypNfRmWo/sQHmlot9jDnLbICmo8AHXJkXRh5PAuB4RBZ HRl/1BQciME4AstwEDPW6MVQ9gJlFQs/74xHxKmEGe4heb2DhopogLFdyQ3Sr0dyybZh UGLg== Received: by 10.60.24.9 with SMTP id q9mr7018901oef.4.1335538433804; Fri, 27 Apr 2012 07:53:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.150.41 with HTTP; Fri, 27 Apr 2012 07:53:33 -0700 (PDT) In-Reply-To: References: <4F9981FC.4000205@extendedsubset.com> <201204261721.q3QHL0lA014062@fs4113.wdf.sap.corp> From: Tom Ritter Date: Fri, 27 Apr 2012 10:53:33 -0400 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQniMdxNR0aTT9MdyCErH1WVKPtu8tWdWa2z7Qwk23Tu0EmoWZrAqhbNMgF1RkhnGclW0cpg Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:53:55 -0000 > Defining the use cases and the threat model of post-CCS extensions is > probably a useful thing to do at this point. > ... > With regards to the threat model, post-CCS extensions should probably > share the exact same threat model as pre-CCS extensions, since they > both happen before the Finished record (for example, putting > application data on them is not a good idea). > ... > Getting a bit funkier (since the state machine is a-changing these > days) maybe it makes sense to add a post-auth post-Finished phase to > TLS, so that "supplemental data" can be exchanged without the fear of > an MITM. I think I'm in the minority here, but I tend to distinguish passive and active attacks significantly, and into different threat models. We've seen evidence of widescale passive 'attacks'/taps on the government level, and more commonly on the corporate level - the evidence indicates that passive taps are pervasive, orders of magnitude more common than the active attacks we've seen in Syria, Iran, and corporate environments. Post-CCS extensions are good against passive attacks, but not active ones. This was discussed at length a little bit ago when talking about Encrypted Client certificates where the threat model moved (from my perception) from preventing passive observation to preventing an active attempt to learn the client's identity by altering the handshake detectably. There's potentially two state machine changes here. Post-CCS, Pre-Finish - where the tradeoff of performance is better than resistance from active attacks: perhaps SNI. And Post-Finish for things that should resist active attacks: such as encrypted client certificates. -tom From desnacked@riseup.net Thu Apr 26 19:51:12 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4DD21F85BE for ; Thu, 26 Apr 2012 19:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIB0Gaic8kql for ; Thu, 26 Apr 2012 19:51:11 -0700 (PDT) Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5E08921F85BB for ; Thu, 26 Apr 2012 19:51:11 -0700 (PDT) Received: from fruiteater.riseup.net (fruiteater-pn.riseup.net [10.0.1.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id E26DA5B1E5 for ; Thu, 26 Apr 2012 19:51:10 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: desnacked@riseup.net) with ESMTPSA id 022CF9B5 From: George Kadianakis To: tls@ietf.org User-Agent: Microsoft Outlook Express 6.00.2900.5843 Date: Fri, 27 Apr 2012 04:50:33 +0200 Message-ID: <87ehr9ga6e.fsf@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.97.3 at mx1 X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 27 Apr 2012 09:17:06 -0700 Subject: Re: [TLS] Next Protocol Negotiation 03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 02:54:27 -0000 Adam Langley wrote: > On Thu, Apr 26, 2012 at 1:21 PM, Martin Rex wrote: > > Maybe we should define something similar for the encrypted part of > > the handshake, so that we don't have to add new handshake messages > > for every new feature? > > Indeed, folks seem to be leaning towards wanting more generic support > for extensions under encryption. Having a "client offers, server > selects" extension exchange after the ChangeCipherSpecs is perfectly > possible, although at the cost of precluding False Starting a full > handshake. False Start isn't a real TLS feature of course, but we're > currently pondering how much we want to be able to support it, and how > much we want NPN under encryption. > > Also, if there's a generic "secure" extension exchange after the CCS, > it has the same concerns as False Start. i.e. an attacker can perform > a downgrade attack on it. For False Start we say that if the > ciphersuite isn't strong enough, we simply won't do it. But having a > TLS feature switch on and off like that seems untenable. > > So, in short, "still thinking". > > > Cheers > > AGL Minimizing the unnecessary unencrypted information in TLS seems like a wise idea, and post-CCS TLS extensions is a good first step in that direction. Defining the use cases and the threat model of post-CCS extensions is probably a useful thing to do at this point. For example, thinking about use cases, there are TLS extensions that can't be placed post-CCS, like the ECC extensions or SessionTicket, since they concern the SSL key exchange. At the same time, TLS extensions like server_name, RI or NPN make sense post-CCS. With regards to the threat model, post-CCS extensions should probably share the exact same threat model as pre-CCS extensions, since they both happen before the Finished record (for example, putting application data on them is not a good idea). Talking about threat models, the "client offers, server selects" model might be susceptible to brute-force extension enumeration attacks, and if 'secret TLS extensions' are considered useful, the protocol should be designed appropriately. Getting a bit funkier (since the state machine is a-changing these days) maybe it makes sense to add a post-auth post-Finished phase to TLS, so that "supplemental data" can be exchanged without the fear of an MITM. PS: Sorry for screwing up the threading; I am not subscribed to the list and the ML web archive does not expose Message-IDs. From henry.story@bblfish.net Mon Apr 30 09:47:04 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0017C21F87A3 for ; Mon, 30 Apr 2012 09:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCRUdz4d-aBv for ; Mon, 30 Apr 2012 09:47:03 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF36521F8796 for ; Mon, 30 Apr 2012 09:47:02 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2411549bku.31 for ; Mon, 30 Apr 2012 09:47:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer:x-gm-message-state; bh=tTut4x8HqdlpmERLeLclRrT+MOl074eVy4yYgDGn7ds=; b=F5PjoWU6DwWxZJALV40/eaw2wMNmOuW5JSt93VNE4475LCvir2AHLZDTj/ddRnxhc7 gVlZltyl9m8lioHBW+o9lXmGd9/y2rQJo6rZKudAvwLXUbOU00p+sNB3U+ciJRmxam+c E2skM6BOp5Uf9OEMaoPCcEAmODLNVo+ryM0ls4j3GPzdrxG2rmOEuXD2o9Sr9ge+WXwl VLqn7Jfc4aheqjwlLqhIAAgZd9R7HZLFngIr/7HKUf8f84+r5DtAsvk/hBOuWjjyRll9 ZUVDZlSJMj6wPKBkScXG1ZPcvNI4C4od3rYWmPi5bofHpRbiCkZhXS5q+F1V4m8Z0qUJ sMLQ== Received: by 10.204.155.154 with SMTP id s26mr634876bkw.129.1335804421678; Mon, 30 Apr 2012 09:47:01 -0700 (PDT) Received: from [172.23.42.56] (p5DDBB8B5.dip.t-dialin.net. [93.219.184.181]) by mx.google.com with ESMTPS id n17sm21076640bkw.5.2012.04.30.09.46.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 09:47:00 -0700 (PDT) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2012 18:46:57 +0200 Message-Id: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> To: "tls@ietf.org List" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkNo2vdc65ydl4HtUPDTLiLlwemvvwOTs4PcOjVHD0ET4ZZZKVlG6sUBG3agZf/8elTGvB+ Cc: public-webid Subject: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 16:47:04 -0000 TLS currently helps one know that when opens a connection to a service = (domain:port pair) one is actually connected to the machine that officially owns that = domain. It does not give one the big picture of what kind of entity one is actually = connected to: ie. it does not answer the following questions: - is this a legal entity? - which country is it based in (or which legal framework is it = responsible to) - who are the owners - what kind of organisation is it? (individual, bank, commerce, school, = university, charity...) In a recent talk I gave at the European Identity conference in Biel, = Switzerland, I looked=20 at how this extra information could be made available by using WebID and = Linked Data, published by official entities in ways that gave those documents legal weight. = This would not be technically very difficult to do, but would provide huge benefits to the web. It = could increase trust=20 in the way people use the web, and it could enable commerce in a much = broader way that hitherto found on the web. I put this presentation up on my blog with the title "WebID and = Commerce"=20 http://bblfish.net/blog/2012/04/30/ WebID is just the art of tying TLS into the linked data world, which is = the framework that has been developed under the guidance of Tim Berners Lee. So it brings = two worlds together, which is why I am cross posting here. It seems like an idea with a lot = of potential. Henry Social Web Architect http://bblfish.net/ From mrex@sap.com Mon Apr 30 10:16:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C97A21F87FA for ; Mon, 30 Apr 2012 10:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.127 X-Spam-Level: X-Spam-Status: No, score=-10.127 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA7DLkLtLu8o for ; Mon, 30 Apr 2012 10:16:50 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB19E21F8802 for ; Mon, 30 Apr 2012 10:16:49 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q3UHGl9f024199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Apr 2012 19:16:47 +0200 (MEST) From: Martin Rex Message-Id: <201204301716.q3UHGkwW019079@fs4113.wdf.sap.corp> To: henry.story@bblfish.net (Henry Story) Date: Mon, 30 Apr 2012 19:16:46 +0200 (MEST) In-Reply-To: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> from "Henry Story" at Apr 30, 12 06:46:57 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, public-webid@w3.org Subject: Re: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:16:51 -0000 Henry Story wrote: > > TLS currently helps one know that when opens a connection to a service > (domain:port pair) one is actually connected to the machine that > officially owns that domain. That sounds backwards from what it is. A DNS domain owner can obtain TLS server certificates for hosts in his domain. So when a TLS server shows a cert with a DNS Name in it that chains to one of the RootCAs known in the TLS X.509 PKI as known by common web browsers, then one assumes that this cert was obtained by someone who could demonstrate to the relevant CA to be an admin for that DNS domain. For domain validated (DV) certs, the ability to receive the DNS admins EMail is all that is verified. Nowadays, DV-certs seem not to contain any other data in subject and subject alt name about the cert requestor besides the DNS hostname for which the cert was requested. > > It does not give one the big picture of > what kind of entity one is actually connected to: > ie. it does not answer the following questions: > > - is this a legal entity? > - which country is it based in (or which legal framework is it responsible to) > - who are the owners > - what kind of organisation is it? > (individual, bank, commerce, school, university, charity...) That information is completely irrelavant to TLS and to the existing server endpoint identification schemes on top of TLS (rfc2818,rfc6125). The CABForum has defined schemes to verify additional attributes about certificate requestors, which can be places as verified/vetted attributes in "organzation verified" (OV) and "extended validation" (EV) certs, but these come at a signficant extra cost, and that extra information is only meaningful to human beings. > > In a recent talk I gave at the European Identity conference in Biel, > Switzerland, I looked at how this extra information could be made > available by using WebID and Linked Data, published by official entities > in ways that gave those documents legal weight. This would not be > technically very difficult to do, but would provide huge benefits > to the web. While OV- and EV-certs may provide additional benefits to users who actually verify these attributes, the information is irrelevant for "the web". > > It could increase trust in the way people use the web, > and it could enable commerce in a much broader way that hitherto > found on the web. "The Web" is glued together with URLs, which distinguish places _only_ by DNS Names, nothing else. An URL does not distinguish ACME bank from ACME fireworks, and there is no rule which of them was first to register a particular DNS domain name. So IMHO, the only way you could "increase (percieved) trust in the web" would be to significantly deceive users about the underlying technology. -Martin From nico@cryptonector.com Mon Apr 30 10:31:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2F721F8855 for ; Mon, 30 Apr 2012 10:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQxQHwkUNWO5 for ; Mon, 30 Apr 2012 10:31:25 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D426621F8848 for ; Mon, 30 Apr 2012 10:31:25 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 708C92AC059 for ; Mon, 30 Apr 2012 10:31:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=D4If+jlaIpf1pe7nRQj2oO5V7grg88sIeFW7YJqtyEPy 16kRuRQm37KcdMYpC5KXXAR/AMVRlGoL4FK0T4dhaD+9Gx/y3j/1Ybwyp+DrLtr5 XePXOVA2qRjuGdYUeHyKtMvhJwjqNjXRRBQneAXcWVKNwrL1d+JaHUIoBcxJrIk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=DgsovsFy6GqD2apjHA18R/LuuLc=; b=n7uKhLJ+b6g I9Pc/YE73Kesw6OvVmx7zn9r5+y9ycYZNzCXFomqupX7u1LrT2irsyXdQgAopyno yJ5hoPdy8VmQL7iFy2zRn9n8be0Bmd0o43/t2cKkqZy9FgA+ofN9+ZUApm9dJJg9 NbmCOL/a4afGJVq+qPYv3iLFLlzL+1TA= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 4DE132AC072 for ; Mon, 30 Apr 2012 10:31:24 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so764060pbc.31 for ; Mon, 30 Apr 2012 10:31:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.225.170 with SMTP id rl10mr47745975pbc.76.1335807084447; Mon, 30 Apr 2012 10:31:24 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Mon, 30 Apr 2012 10:31:24 -0700 (PDT) In-Reply-To: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> Date: Mon, 30 Apr 2012 12:31:24 -0500 Message-ID: From: Nico Williams To: Henry Story Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org List" , public-webid Subject: Re: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:31:28 -0000 On Mon, Apr 30, 2012 at 11:46 AM, Henry Story wro= te: > TLS currently helps one know that when opens a connection to a service (d= omain:port pair) > one is actually connected to the machine that officially owns that domain= . It does not > give one the big picture of what kind of entity one is actually connected= to: > ie. it does not answer the following questions: > > =C2=A0- is this a legal entity? > =C2=A0- which country is it based in (or which legal framework is it resp= onsible to) > =C2=A0- who are the owners > =C2=A0- what kind of organisation is it? (individual, bank, commerce, sch= ool, university, charity...) There are not things I've cared much about in the brick and mortar world because those things are implied. It's... difficult to put up a fake bank, with fake tellers, advertisement, and so on. Not so difficult to put up or hack hole-in-the-wall ATMs, but then I don't use hole-in-the-wall ATMs. In the off-line world this approach pervades. Now, it is true that I care about track records (e.g., when making investments), but I've never asked "who are the owners?", except for small restaurants/shops that I like and where knowing the owners is social benefit. I've also not asked "is this a legal entity". Maybe I'm just naive? When I see a doctor I see diplomas on their office walls, but I don't go double checking them. And so on. In the on-line world some of these questions are more interesting, but only because trust is harder to establish. And anyways, we don't get answers to these questions on-line, not most users anyways. The trick is to get domain names to reflect the same things that brick and mortar sites do. > In a recent talk I gave at the European Identity conference in Biel, Swit= zerland, I looked > at how this extra information could be made available by using WebID and = Linked Data, published > by official entities in ways that gave those documents legal weight. This= would not be technically > very difficult to do, but would provide huge benefits to the web. It coul= d increase trust > in the way people use the web, and it could enable commerce in a much bro= ader way that hitherto > found on the web. No matter what we're still talking about how to establish trust. That's the hard part. How do I trust that such and such corporation owns some website? I have to know who is making that statement, and for that I must authenticate them, and I've to decide if they can make that statement authoritatively, and whether I trust them (even if I can authenticate them). Assuming the TLS server PKI works then you're right, this is simple to add as a *protocol*. Though you'd still need to get someone to do the vouching: it won't be governments, since there are some many ones that are authoritative at some level that users could not really authorize them to make these statements, so it has to be some commercial operation, or a national-level agency. That sounds so difficult to pull off, and likely to provide so little value that I don't think it can happen. But on a smaller scale it could happen, and, indeed, it does already. What I have in mind is federations of like companies. Sites like Amazon, eBay, and Yahoo! already have, effectively, federations of vendors. I'd like to see a federation of banks. Nico -- From henry.story@bblfish.net Mon Apr 30 10:36:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE52D21E8047 for ; Mon, 30 Apr 2012 10:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01yyaDOhtlbd for ; Mon, 30 Apr 2012 10:36:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9929A21E8048 for ; Mon, 30 Apr 2012 10:35:57 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2447048bku.31 for ; Mon, 30 Apr 2012 10:35:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=QL+NhSLmGYIGv8rSjN/PWlosYXDKxjTGzI/u2iCEXlc=; b=RAXSPrRYJkQXOGC6PBgskphjUU6zbBzKIJnI7+IrtO+dFCqswfc0Dk/pQchqOeeH2f xOm6rYv9N3hQW2W/5gTRYGZ/vcECcfnWqwfdKiQTacgn9C3Zawggrrt5RqwpzTI0cDhw YC/Oy1URXpUj3rZT+ARAqnOr+IvegJrpDH4ReLWw2m4WlzQ/ovA+Wtspb0YqjgiDdKb7 CgBBnn1rmNGHsBoNn8skE0me0WCqC59C18u5r6Sm8AAPX7g3KxWJGqFcF8VLTNDabaub E2s+8zP5pv9zsSzdpub/YTZj4CJw16HxMNbc1LHUUeTOFGMRq8wQYsCI/cTBXDTqdWn4 pTiQ== Received: by 10.204.155.147 with SMTP id s19mr1401828bkw.140.1335807356462; Mon, 30 Apr 2012 10:35:56 -0700 (PDT) Received: from [172.23.42.56] (p5DDBB8B5.dip.t-dialin.net. [93.219.184.181]) by mx.google.com with ESMTPS id z14sm28146059bky.15.2012.04.30.10.35.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 10:35:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <201204301716.q3UHGkwW019079@fs4113.wdf.sap.corp> Date: Mon, 30 Apr 2012 19:35:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <451221D8-4087-4687-9954-7FE78A6100F4@bblfish.net> References: <201204301716.q3UHGkwW019079@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmkqiktY/oQayVooywGN7sYloLZUEWnTKbDpaU4eOlYPWlM6JT0B7qv3izpedSj3fTaXPSO Cc: tls@ietf.org, public-webid@w3.org Subject: Re: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 17:36:01 -0000 Martin, seeing the speed at which you responded I don't think you took the time to look at the presentation. It may be worth doing that, as it presents some technology that opens up many new possibilities you may not be aware of. The proposal furthermore works with TLS not against it: it builds on TLS directly to build something that I think you will find very interesting. :-) But let me answer your points below to hopefully answer misgivings. On 30 Apr 2012, at 19:16, Martin Rex wrote: > Henry Story wrote: >>=20 >> TLS currently helps one know that when opens a connection to a = service >> (domain:port pair) one is actually connected to the machine that >> officially owns that domain. >=20 > That sounds backwards from what it is. >=20 > A DNS domain owner can obtain TLS server certificates for hosts in > his domain. So when a TLS server shows a cert with a DNS Name in it > that chains to one of the RootCAs known in the TLS X.509 PKI as known > by common web browsers, then one assumes that this cert was obtained > by someone who could demonstrate to the relevant CA to be an admin > for that DNS domain. >=20 > For domain validated (DV) certs, the ability to receive the DNS admins > EMail is all that is verified. Nowadays, DV-certs seem not to contain > any other data in subject and subject alt name about the cert = requestor > besides the DNS hostname for which the cert was requested. Well TLS at that level still only guarantees that you connected to the=20= machine. Not the context of who owns the machine and how it fits into=20 the policitical/economic/legal context. Ie. it does not answer the=20 questions I put below: >>=20 >> It does not give one the big picture of >> what kind of entity one is actually connected to: >> ie. it does not answer the following questions: >>=20 >> - is this a legal entity? >> - which country is it based in (or which legal framework is it = responsible to) >> - who are the owners >> - what kind of organisation is it? >> (individual, bank, commerce, school, university, charity...) >=20 >=20 > That information is completely irrelavant to TLS and to the existing > server endpoint identification schemes on top of TLS = (rfc2818,rfc6125). >=20 > The CABForum has defined schemes to verify additional attributes about > certificate requestors, which can be places as verified/vetted = attributes > in "organzation verified" (OV) and "extended validation" (EV) certs, > but these come at a signficant extra cost, and that extra information = is > only meaningful to human beings. The idea is not to put this information in the certificates at all, but to place a URI in the SAN and IAN fields that allow that entity to be tied into what for lack of a better word I called the institutional web. >=20 >=20 >>=20 >> In a recent talk I gave at the European Identity conference in Biel, >> Switzerland, I looked at how this extra information could be made >> available by using WebID and Linked Data, published by official = entities >> in ways that gave those documents legal weight. This would not be >> technically very difficult to do, but would provide huge benefits >> to the web. >=20 > While OV- and EV-certs may provide additional benefits to users who > actually verify these attributes, the information is irrelevant for = "the web". I am not speaking of adding this information the way EV certs do it: = into the certificate. >=20 >=20 >>=20 >> It could increase trust in the way people use the web, >> and it could enable commerce in a much broader way that hitherto >> found on the web. >=20 > "The Web" is glued together with URLs, which distinguish places > _only_ by DNS Names, nothing else. An URL does not distinguish > ACME bank from ACME fireworks, and there is no rule which of them > was first to register a particular DNS domain name. yes, but the web can by basing itself on TLS and soon DNS-SEC and DANE create a network of linked data that can be used to create the trust that is missing at the TLS layer. In this scenario this is not a flaw of TLS, but rather something that can be build on top and WITH TLS. If this is correct it should help guide the future development of TLS=20 and other IETF security protocols. >=20 > So IMHO, the only way you could "increase (percieved) trust in the = web" > would be to significantly deceive users about the underlying = technology. I sincerely believe this not to be the case. I think it is worth looking at this proposal with an open mind. There are two worlds that I am = trying to get to work together: TLS and LinkedData. There is much that they can do together, if we can get both communities to understand each other. Hope this helps, Henry >=20 > -Martin >=20 Social Web Architect http://bblfish.net/ From henry.story@bblfish.net Mon Apr 30 12:24:14 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4A421F8883 for ; Mon, 30 Apr 2012 12:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRRI+1VWYz5s for ; Mon, 30 Apr 2012 12:24:14 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9492721F8869 for ; Mon, 30 Apr 2012 12:24:13 -0700 (PDT) Received: by bkuw5 with SMTP id w5so2525259bku.31 for ; Mon, 30 Apr 2012 12:24:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=W8K+DVSoi2oK3oMVt+Y01Lgqj2oguyxwe+Uz4P+b3zE=; b=I3mv0skYRszkDKcJ22bQl32FS0wn7KqiZUwcsQTlED8CZwQs6BtWQONigSA8pnT/HZ F1flBwqCCrBM3J3ncIRkRLDCr7ekGoGWqjNdyP3Qt7FJId/QujXirnAa8W1JAxBMhJoz irjP+QDIKqph22+kUXgFO+aQMCe9yaSPhe8syquPgU0pO4aRh5wRflbpCB+nzTXyHzXv girFtbSqJJEpFoezSLVIdwOkpOSvz6fZHAyYhy0NYhhWwhd9ECSj6K+m8dwglb6JGM8K frr3n6xfq0Swn+80VIFAmtwz6qPJiOsIe3qH5AAEJugBCSC0jHY8+k87ipQJAzIVEmll O+0A== Received: by 10.204.132.77 with SMTP id a13mr3593909bkt.76.1335813852509; Mon, 30 Apr 2012 12:24:12 -0700 (PDT) Received: from [172.23.42.56] (p5DDBB8B5.dip.t-dialin.net. [93.219.184.181]) by mx.google.com with ESMTPS id v2sm28576692bkw.16.2012.04.30.12.24.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 12:24:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Mon, 30 Apr 2012 21:24:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07B7828B-DF75-446E-AF6E-6A16BD9F9146@bblfish.net> References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> To: Nico Williams X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm5wDYjNkjoP9zKtC7SZTZMCCF0PmGAeJGh7SMSiJxEXjytrPigyfhHZVgaUACJDIJ3XH8z Cc: "tls@ietf.org List" , public-webid Subject: Re: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:24:15 -0000 On 30 Apr 2012, at 19:31, Nico Williams wrote: > On Mon, Apr 30, 2012 at 11:46 AM, Henry Story = wrote: >> TLS currently helps one know that when opens a connection to a = service (domain:port pair) >> one is actually connected to the machine that officially owns that = domain. It does not >> give one the big picture of what kind of entity one is actually = connected to: >> ie. it does not answer the following questions: >>=20 >> - is this a legal entity? >> - which country is it based in (or which legal framework is it = responsible to) >> - who are the owners >> - what kind of organisation is it? (individual, bank, commerce, = school, university, charity...) >=20 > There are not things I've cared much about in the brick and mortar > world because those things are implied. It's... difficult to put up a > fake bank, with fake tellers, advertisement, and so on. Not so > difficult to put up or hack hole-in-the-wall ATMs, but then I don't > use hole-in-the-wall ATMs. In the off-line world this approach > pervades. Now, it is true that I care about track records (e.g., when > making investments), but I've never asked "who are the owners?", > except for small restaurants/shops that I like and where knowing the > owners is social benefit. I've also not asked "is this a legal > entity". Maybe I'm just naive? When I see a doctor I see diplomas on > their office walls, but I don't go double checking them. And so on. exactly. That may have been a better way to introduce the subject in the presentation! > In the on-line world some of these questions are more interesting, but > only because trust is harder to establish. And anyways, we don't get > answers to these questions on-line, not most users anyways. The trick > is to get domain names to reflect the same things that brick and > mortar sites do. yes, but a domain name can be reached by clicking a page that is not behind https, and so a man in the middle attack could have changed the originating link, even if it came from a trusted source. Also with people typing in urls it is easy to make a spelling mistake that a clever domain hacker could have bought. Finally there are many online businesses that are perhaps very reliable - a small swiss watch maker=20 for example - which don't have the marketing power to make us all = remember their name. The linked data web could help here. Browsers could use the background=20= "institution web" graph to help users identify the site they are on. If browsers don't do that other companies could provide widgets or browser plugins to fill the gap. >=20 >> In a recent talk I gave at the European Identity conference in Biel, = Switzerland, I looked >> at how this extra information could be made available by using WebID = and Linked Data, published >> by official entities in ways that gave those documents legal weight. = This would not be technically >> very difficult to do, but would provide huge benefits to the web. It = could increase trust >> in the way people use the web, and it could enable commerce in a much = broader way that hitherto >> found on the web. >=20 > No matter what we're still talking about how to establish trust. > That's the hard part. How do I trust that such and such corporation > owns some website? I have to know who is making that statement, and > for that I must authenticate them, and I've to decide if they can make > that statement authoritatively, and whether I trust them (even if I > can authenticate them). yes. All businesses tend to be registered somewhere: be it either with = the local authority, or with some tax office, or with the stock exchange,... >=20 > Assuming the TLS server PKI works then you're right, this is simple to > add as a *protocol*. Though you'd still need to get someone to do the > vouching: it won't be governments, since there are some many ones that > are authoritative at some level that users could not really authorize > them to make these statements, so it has to be some commercial > operation, or a national-level agency. yes. > That sounds so difficult to pull off, and likely to provide so little > value that I don't think it can happen. I think the value is quite big in fact, and it would not be that = difficult to do technically. Getting all of these institutions to coordinate would be more difficult to do I agree, and one would have to start somewhere = where the value and the will is there: perhaps the stock exchanges or banks. In my presentation I illustrate the idea with banks. How it gets going = in actual fact is of course wide open. It would be something one could run=20= some fruitful test cases to see what is required. >=20 > But on a smaller scale it could happen, and, indeed, it does already. > What I have in mind is federations of like companies. Sites like > Amazon, eBay, and Yahoo! already have, effectively, federations of > vendors. I'd like to see a federation of banks. Yes. That's the example I used. In Switzerland it was suggested that companies such as Swatch that have a lot of resellers that are always changing might also have a need for something like this. This is why=20 I think that attacking this from both the social networking side and the more formal institutional side is useful. The institutional side helps people see how trust can work in a distributed manner - it always has. It is just that we tend to think of governments as central agencies, whereas in reality they are distributed: each state is a peer in the = social network of states. I'd be happy to work with some organisations that are interested in = trying this out. Henry >=20 > Nico > -- Social Web Architect http://bblfish.net/ From nico@cryptonector.com Mon Apr 30 12:57:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD87621F867B for ; Mon, 30 Apr 2012 12:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[AWL=-0.983, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZBuOu-mB90M for ; Mon, 30 Apr 2012 12:57:54 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 1351B21F867A for ; Mon, 30 Apr 2012 12:57:54 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 93CAD10049 for ; Mon, 30 Apr 2012 12:57:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=f+RgL6+84FIr7LesZxKziNlhVrYedwik3OxWo0XmfVe1 iWpaVDlBvQTS1P1XctH1gbZXaJFS6Fc2ddm/Wkw64LwRbhsKsDmnenVOlW8uTtGW WbkqXRmBnfNSPd0AXLFzgGmDNzOYa5nALAjPLQVmJPEe24wZJebuxOFPunEN8A8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=oMWY2HlVpqk4G4u75AWnYpRS25k=; b=aIaw9eQoRvP K9klWi8pdxbX7pOwmuAP3tIMz3M3RNsaIXw6yj+80/2QKwH2i8P7P+yaEHRI43a7 8/gHQzOHcckp2qM9FDi8b20ingBYKE5Y5wNzWkfpsdDWufFsRHZH5mPpVwj52Hsx ZpOUWtR+2pZAP8KoPqERR5n4bjMqNFkQ= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 7B98310060 for ; Mon, 30 Apr 2012 12:57:53 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so890960pbc.31 for ; Mon, 30 Apr 2012 12:57:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.221.10 with SMTP id qa10mr50386393pbc.139.1335815873175; Mon, 30 Apr 2012 12:57:53 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Mon, 30 Apr 2012 12:57:52 -0700 (PDT) In-Reply-To: <07B7828B-DF75-446E-AF6E-6A16BD9F9146@bblfish.net> References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> <07B7828B-DF75-446E-AF6E-6A16BD9F9146@bblfish.net> Date: Mon, 30 Apr 2012 14:57:52 -0500 Message-ID: From: Nico Williams To: Henry Story Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org List" , public-webid Subject: Re: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:57:54 -0000 On Mon, Apr 30, 2012 at 2:24 PM, Henry Story wrot= e: > On 30 Apr 2012, at 19:31, Nico Williams wrote: >> In the on-line world some of these questions are more interesting, but >> only because trust is harder to establish. =C2=A0And anyways, we don't g= et >> answers to these questions on-line, not most users anyways. =C2=A0The tr= ick >> is to get domain names to reflect the same things that brick and >> mortar sites do. > > yes, but a domain name can be reached by clicking a page that is not > behind https, and so a man in the middle attack could have changed > the originating link, even if it came from a trusted source. Also > [...] That problem doesn't go away. We can't just use HTTPS (no matter how much some people insist that we should only use HTTPS). DNSSEC wouldn't help either since usign HTTP (no S) means that there can always be an MITM in TCP. The only solution here is to train users to know when to insist on HTTPS, and the UIs really have to not suck (as long as we allow HTTP_no_S for some things this will be a problem). >> No matter what we're still talking about how to establish trust. >> That's the hard part. =C2=A0How do I trust that such and such corporatio= n >> owns some website? =C2=A0I have to know who is making that statement, an= d >> for that I must authenticate them, and I've to decide if they can make >> that statement authoritatively, and whether I trust them (even if I >> can authenticate them). > > yes. All businesses tend to be registered somewhere: be it either with th= e > local authority, or with some tax office, or with the stock exchange,... I'm not sure that's true. In the U.S. in some/many?/most? states it's possible to start a sole proprietorship without having to first register anywhere -- sure, these are going to be small businesses, and they will eventually have to pay taxes and therefore register, but even then, there's too many governments you'd have to go check to find out about random companies, at least in the U.S. Who's going to do it? I can't think of a random web customer caring to check the tax records of a sole proprietorship or corporation, or caring to know immediately that someone else has checked. >> Assuming the TLS server PKI works then you're right, this is simple to >> add as a *protocol*. =C2=A0Though you'd still need to get someone to do = the >> vouching: it won't be governments, since there are some many ones that >> are authoritative at some level that users could not really authorize >> them to make these statements, so it has to be some commercial >> operation, or a national-level agency. > > yes. > >> That sounds so difficult to pull off, and likely to provide so little >> value that I don't think it can happen. > > I think the value is quite big in fact, and it would not be that difficul= t > to do technically. Getting all of these institutions to coordinate would > be more difficult to do I agree, and one would have to start somewhere wh= ere > the value and the will is there: perhaps the stock exchanges or banks. Again, protocol-wise: trivial, but business-wise: very much non-trivial. "Not that difficult to do technically" is not enough, and you do have to be careful what you mean by "technically", because to me this is "technically" quite difficult when we include anything other than "protocol details" in "technically". >> But on a smaller scale it could happen, and, indeed, it does already. >> What I have in mind is federations of like companies. =C2=A0Sites like >> Amazon, eBay, and Yahoo! already have, effectively, federations of >> vendors. =C2=A0I'd like to see a federation of banks. > > Yes. That's the example I used. In Switzerland it was suggested that > companies such as Swatch that have a lot of resellers that are always > changing might also have a need for something like this. This is why > I think that attacking this from both the social networking side and the > more formal institutional side is useful. The institutional side helps > people see how trust can work in a distributed manner - it always has. > It is just that we tend to think of governments as central agencies, > whereas in reality they are distributed: each state is a peer in the soci= al > network of states. Governments are too distributed to help with this problem, unless we could get all these governments (or at least the ones that matter, or enough that the ones that do can be the ones that end up mattering) to have all these databases online. That's a political problem. Political processes can be very slow -- much slower than IETF processes. Watch out. My conception of federations sidesteps that problem. And as I said: it's already happening on some scale. With respect to banks... the business model there looks significantly different than Amazon's/eBay's/Yahoo!'s -- the latter act as a directory/middleman to the vendors, while there should be no middleman when it comes to banking, and people do not purchase banking products/services from random banks as often as they do trinkets from random vendors, which limits the usefulness of a directory of banks. So I'm not sure what we can do there. Basically I'm skeptical. For my money the certificate transparency proposal is our best bet in the short-term. Longer-term, if there's any way to bring user authentication mechanisms that can do mutual authentication into the web, then that will help enormously when it comes to banking, but I think there's a lot of barriers to improving user authentication on the web. We'll see. (That reminds me, I should write something up for HTTPbis.) Nico -- From geoffk@geoffk.org Mon Apr 30 20:03:16 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D0D21E80BA for ; Mon, 30 Apr 2012 20:03:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUzNTGaTZ0-I for ; Mon, 30 Apr 2012 20:03:15 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3D21E80A4 for ; Mon, 30 Apr 2012 20:03:15 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 14A4933D063; Tue, 1 May 2012 03:03:15 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Henry Story References: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> From: Geoffrey Keating Date: 30 Apr 2012 20:03:14 -0700 In-Reply-To: <37860D94-8750-40F9-9388-07057B4E6ECD@bblfish.net> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "tls@ietf.org List" , public-webid Subject: Re: [TLS] Fixing TLS Trust X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 03:03:16 -0000 Henry Story writes: > TLS currently helps one know that when opens a connection to a > service (domain:port pair) one is actually connected to the machine > that officially owns that domain. It does not give one the big > picture of what kind of entity one is actually connected to: ie. it > does not answer the following questions: > > - is this a legal entity? > - which country is it based in (or which legal framework is it responsible to) > - who are the owners > - what kind of organisation is it? (individual, bank, commerce, school, university, charity...) Isn't this mostly covered by EV certificates? - The 'is this a legal entity' part is answered with 'yes'. - The country/legal framework part is the jurisdictionOfIncorporationCountryName field and similar. - It doesn't describe the owners, but of course that information could change between the time the connection is opened and the packets reach the other end; except in the case where a certificate is issued to a sole proprietor, in which case that individual is named in the certificate. In the case of a company it does provide sufficient information to track down the company and find its owners if they are publicly available. - The kind of organisation is covered by the businessCategory field. The presentation seemed interesting.