From yngve@opera.com Tue Jul 3 09:37: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 D1A5E21F8786 for ; Tue, 3 Jul 2012 09:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05] 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 BjDEZ-9rwfGw for ; Tue, 3 Jul 2012 09:37:28 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16521F86D3 for ; Tue, 3 Jul 2012 09:37:27 -0700 (PDT) Received: from acorna.invalid.invalid (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 q63GbWH8031306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Jul 2012 16:37:33 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: <20120703074954.1553.31285.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2012 18:37:36 +0200 To: "tls@ietf.org" 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: <20120703074954.1553.31285.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/11.64 (Win32) Subject: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.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: Tue, 03 Jul 2012 16:37:28 -0000 Hello all, In light of the recent discussion about using SCSVs to protect against version rollbacks, I decided to write up my own proposal, which is already used in Opera. This method uses the Renego Information (RI) extension as an indication that the server is version and extension intolerant, and require the client to only connect to the server using its highest supported TLS version and extensions when the RI extension is encountered, if necessary restarting the connection to do so. This approach should, according to my testing, work with more than 99.86% of Renego patched servers, using just one connection to establish the connection. Currently, 70% of servers are Renego patched. With respect to the steps in the procedure, under normal conditions the client will be able to establish a connection on the first try with 95% of servers that are not patched for Renego, for the remaining servers (about 1.5% of all servers), one or more attempts using older protocol versions will be needed. If implemented, this method will naturally be obsoleted when clients change to only accept connections with Renego patched servers and remove/disable all code for performing version rollbacks. ------- Forwarded message ------- Subject: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt Date: Tue, 03 Jul 2012 09:49:54 +0200 A new version of I-D, draft-pettersen-tls-version-rollback-removal-00.txt has been successfully submitted by Yngve N. Pettersen and posted to the IETF repository. Filename: draft-pettersen-tls-version-rollback-removal Revision: 00 Title: Managing and removing automatic version rollback in TLS Clients Creation date: 2012-07-03 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-pettersen-tls-version-rollback-removal-00.txt Status: http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal Htmlized: http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-00 Abstract: Ever since vendors started deploying TLS 1.0 clients, these clients have had to handle server implementations that do not tolerate the TLS version supported by the client, usually by automatically signaling an older supported version instead. Such version rollbacks represent a potential security hazard, if the older version should become vulnerable to attacks. The same history repeated when TLS Extensions were introduced, as some servers would not negotiate with clients that sent these protocol extensions, forcing clients to reduce protocol functionality in order to maintain interoperability. This document outlines a procedure to help clients decide when they may use version rollback to maintain interoperability with legacy servers, under what conditions the clients should not allow version rollbacks, such as when the server has indicated support for the TLS Renegotiation Information extension. The intention of this procedure is to limit the use of automatic version rollback to legacy servers and eventually eliminate its use. -- 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 Tue Jul 3 18:30: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 6A92E21F86C2 for ; Tue, 3 Jul 2012 18:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[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 LpYXPfQXIaI4 for ; Tue, 3 Jul 2012 18:30:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A33FD21F8627 for ; Tue, 3 Jul 2012 18:30:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q641UD94005615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jul 2012 03:30:13 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen (Developer Opera Software ASA)" Date: Wed, 4 Jul 2012 03:30:13 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120704013013.154FD1A13A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt 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, 04 Jul 2012 01:30:07 -0000 If there is anything worth considering that it would be an approach which has (a) the highest possible likelyhood to succees the TLS handshake -- which pretty much means extension-less ClientHello with ClientHello.ClientVersion either {3,0} or {3,1} (b) and simultaneously succeding that very same initial handshake with the highest common protocol version supported by both peers -- which pretty much means that the client must convey his highest supported version through a cipher suite value and that the updated server will ignore/override ClientHello.client_version when it detects the SCSV-based version negotiation. This will on the very first handshake even when the client does not cache information about the server's capabilities, and it will work without incuring failed TLS handshakes--an approach that for some software stacks would require each and every application to implement a reconnect fallback. -Martin From yngve@opera.com Wed Jul 4 01:07: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 392B021F870A for ; Wed, 4 Jul 2012 01:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.263, 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 7RQz1NYd8Wf6 for ; Wed, 4 Jul 2012 01:07:26 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45721F8808 for ; Wed, 4 Jul 2012 01:07:25 -0700 (PDT) Received: from acorna.invalid.invalid (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 q6487VuX027495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2012 08:07:32 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <20120704013013.154FD1A13A@ld9781.wdf.sap.corp> Date: Wed, 04 Jul 2012 10:07:37 +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: <20120704013013.154FD1A13A@ld9781.wdf.sap.corp> User-Agent: Opera Mail/11.64 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.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, 04 Jul 2012 08:07:27 -0000 On Wed, 04 Jul 2012 03:30:13 +0200, Martin Rex wrote: > If there is anything worth considering that it would be an > approach which has > > (a) the highest possible likelyhood to succees the TLS handshake > -- which pretty much means extension-less ClientHello with > ClientHello.ClientVersion either {3,0} or {3,1} > > (b) and simultaneously succeding that very same initial handshake > with the highest common protocol version supported by both peers > -- which pretty much means that the client must convey his highest > supported version through a cipher suite value and that the > updated server will ignore/override ClientHello.client_version > when it detects the SCSV-based version negotiation. > > This will on the very first handshake even when the client does not > cache information about the server's capabilities, and it will work > without incuring failed TLS handshakes--an approach that for some > software stacks would require each and every application to implement > a reconnect fallback. An extension-less Client Hello would not be able to provide some of the information we will need to send to the server, even if the content in the extensions was frozen by a specification. Two examples: Server Name Indication and any new extensions that are added. A frozen extension set would require new SCSVs every time it was updated, or for every combination that one might want to use., which is rather impractical IMO. This means that a Client Hello with extension are needed for any new functionality we want to add, which means one have to deal with extension intolerant servers. According to my research, my approach will currently work on the first connection (Max version, TLS 1.2, plus extensions) for 98.5% of servers out there. That number is steadily increasing, 6 months ago it was 98.35%. Most of the rest are extension intolerant for some, or all TLS 1.0 - 1.2 versions, some (1.5% of the group) are just version intolerant, and will require one or more extra connections to complete a handshake, and would also require this for an SCSV scenario with extensions. 94% of them are not Renego patched. I doubt that using an SCSV to indicate highest version will remove the need to do version rollbacks for servers that does not support the SCSV, or in case of a downgrade attack being attempted. Also, using the SCSV method would not result in the version rollback method ever being retired. I also suspect that any server that is not being updated to fix the Renego issue will not be updated to support the SCSV method. My proposal have the benefit of leveraging an existing protocol feature, adapts an already existing negotiating sequence in web browser clients, works on first connection for most servers, even when the client signals TLS 1.2 and extensions, and does not require updating servers with a new feature once they are patched for Renego, and it automatically becomes redundant and can be removed when all servers support Renego and clients require it. -- 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 Thu Jul 5 00:39: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 383D121F8598 for ; Thu, 5 Jul 2012 00:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HRG+-LAtUMxS for ; Thu, 5 Jul 2012 00:39:03 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id BA57121F8594 for ; Thu, 5 Jul 2012 00:39:01 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q657dB3E016852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 5 Jul 2012 09:39:11 +0200 (MEST) In-Reply-To: To: "Yngve N. Pettersen (Developer Opera Software ASA)" Date: Thu, 5 Jul 2012 09:39:11 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20120705073911.0BC4C1A082@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-00.txt 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, 05 Jul 2012 07:39:04 -0000 Personally, I consider going through a handshake failure an no-go for standardization, and would rather like to see a slight (fully optional and fully backwards-compatible) protocol modification to support a succcessul TLS handshake with the most desirable common characteristics, ZERO extra crypto overhead and a further reduction of failed TLS handshakes on the internet. Although retrying a TLS handshake with different characteristics after a TLS handshake failure may be an option for some implementations and some types of clients (in particular with Browsers), there are applications and environments, where this option simply does not exist. One other possibility to avoid waste of crypto cycles and a handshake failure would be to specify&standardize an SCSV that can be used to restart the handshake. Wasn't something like this done for the Server-Gated Crypto hacks in SSL3? So a client could start with a "conservative" extension-less SSLv3 ClientHello and include that SCSV, and a server who supports a higher version number than offered in ClientHello.client_version and/or supporting extensions that would acctually affect the characteristics of the resulting handshake, could return a ServerHello with that SCSV as the "common cihper suite", (and maybe a ServerHelloExtension describing features that can be safely used and may have been avoided by a conservative client (potentially including things like DHE cipher suites because of the small subgroup goof of some servers), an upon receiving a ServerHello with that SCSV, the client would simply restart the handshake with a full-blown ClientHello carrying all the features that the client supports and may want to offer. For proposed session resumes, the client would then already have the info about what the server supports in the TLS session cache, so there would be no overhead for handshakes with proposed TLS session resumes (even when the server perform occasional full handshakes, as long as it returns a TLS session id, so that this feature remains transparent/invisible to client applications. SNI might become a useful feature in a few years. Today there is still a significant number of clients which does not support SNI, and the interop problem that would result from an SNI prerequisite is at least a magnitude larger than TLS version intolerance and TLS extension intolerance problems. -Martin From Johannes.Merkle@secunet.com Fri Jul 6 01:43: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 3E6CB21F86D1 for ; Fri, 6 Jul 2012 01:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlHPIlUHB-N3 for ; Fri, 6 Jul 2012 01:43:24 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0452321F86D5 for ; Fri, 6 Jul 2012 01:43:23 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 6B65B1A008F; Fri, 6 Jul 2012 10:43:38 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 578C51A008E; Fri, 6 Jul 2012 10:43:34 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jul 2012 10:43:27 +0200 Message-ID: <4FF6A52F.1030308@secunet.com> Date: Fri, 06 Jul 2012 10:43:27 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2012 08:43:28.0041 (UTC) FILETIME=[69E17990:01CD5B53] Subject: [TLS] Using ECC Brainpool curves with TLS 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, 06 Jul 2012 08:43:25 -0000 Hello all, in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile, support for these ECC Brainpool Curves has been included in some crypto libraries as openssl (recently) and crypto++. However, in order to use the Brainpool Curves with TSL (for authentication and/or key agreement), still some specifications and IANA registry updates are needed. Therefore, an RFC specifying the usage of the ECC Brainpool Curves with TLS has to be written. In order to go forward with this, we would like to discuss some questions and potential issues. We would appreciate any feedback on the following. [Question 1] According to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be shepherded by the TLS WG. Therefore, our first and most important question is: Is the WG willing to shepherd this RFC? [Question 2] What category will be preferred for this RFC, Standards Track or Informational RFC? [Question 3] Actually, we also plan to prepare analogous specifications for IKE, so an option may be to write a common RFC for TLS and IKE analogously to RFC 5114. Would this be a good idea, in particular as this would imply shepherding by two WGs, or would it be better to prepare separate RFCs for IKE and TLS? [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one being the "quadratic twist" of the other having the same algebraic structure (and hence, security level), but one of them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the implementation we propose to register IANA values (for EC Named Curve) for both curves for each bit length. Of course, this doubles the number of number assignments. Does anyone consider this a problem? [Question 5] No IANA registries are required for DTLS. However, authors have to specify whether new identifiers for TLS are suitable for DTLS as well. This should be done for the ECC Brainpool curves. Any comments on this? Johannes -- Johannes Merkle secunet Security Networks AG johannes.merkle@secunet.com www.secunet.com From douglas@stebila.ca Fri Jul 6 04: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 B914821F878B for ; Fri, 6 Jul 2012 04:31:28 -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 cnZ4SuuMjOdA for ; Fri, 6 Jul 2012 04:31:28 -0700 (PDT) Received: from smtp113.iad.emailsrvr.com (smtp113.iad.emailsrvr.com [207.97.245.113]) by ietfa.amsl.com (Postfix) with ESMTP id 128F221F8787 for ; Fri, 6 Jul 2012 04:31:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp41.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id CB04A290156; Fri, 6 Jul 2012 07:31:43 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp41.relay.iad1a.emailsrvr.com (Authenticated sender: douglas-AT-stebila.ca) with ESMTPSA id B308929041E; Fri, 6 Jul 2012 07:31:42 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Douglas Stebila In-Reply-To: <4FF6A52F.1030308@secunet.com> Date: Fri, 6 Jul 2012 21:31:37 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF6A52F.1030308@secunet.com> To: Johannes Merkle X-Mailer: Apple Mail (2.1278) Cc: "tls@ietf.org" Subject: Re: [TLS] Using ECC Brainpool curves with TLS 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, 06 Jul 2012 11:31:28 -0000 On 2012-Jul-6, at 6:43 PM, Johannes Merkle wrote: > [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, = 256, 320, 384, 512 two curves are defined, one > being the "quadratic twist" of the other having the same algebraic = structure (and hence, security level), but one of > them allows particular efficient arithmetic. In order to leave the = choice of the curve for a given bit length to the > implementation we propose to register IANA values (for EC Named Curve) = for both curves for each bit length. Of course, > this doubles the number of number assignments. Does anyone consider = this a problem? One alternative would be to use an extension, similar to the Supported = Points Format Extension, to indicate whether to use the twisted form or = the original form. Or in fact define the twisted form as just another = ECPointFormat. But you could also ask the question: if the quadratic twist is more = efficient, will anyone ever use the untwisted version? If not, then = perhaps you could just standardize the twisted version alone, reducing = the number of combinations to be tested and supported. Douglas= From internet-drafts@ietf.org Sun Jul 8 07:07:58 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 4230421F85EF; Sun, 8 Jul 2012 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 XrIti3NTyKNh; Sun, 8 Jul 2012 07:07:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BDF21F8547; Sun, 8 Jul 2012 07:07:55 -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.30p2 Message-ID: <20120708140755.16513.71464.idtracker@ietfa.amsl.com> Date: Sun, 08 Jul 2012 07:07:55 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-01.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: Sun, 08 Jul 2012 14:07:58 -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 Group of= the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-01.txt Pages : 10 Date : 2012-07-08 Abstract: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method that a server can use to provide status information (i.e., based on the Online Certificate Status Protocol and Server-Based Certificate Validation Protocol) not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-ex= tension-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yngve@opera.com Sun Jul 8 07:19: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 ACE4021F8611 for ; Sun, 8 Jul 2012 07:19:09 -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 KniQI-NXqreV for ; Sun, 8 Jul 2012 07:19:08 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7F48521F860B for ; Sun, 8 Jul 2012 07:19:08 -0700 (PDT) Received: from acorna.invalid.invalid (226.70.202.84.customer.cdi.no [84.202.70.226]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q68EJS50028511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 8 Jul 2012 14:19:29 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <20120708140755.16513.71464.idtracker@ietfa.amsl.com> Date: Sun, 08 Jul 2012 16:19:26 +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: <20120708140755.16513.71464.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-01.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: Sun, 08 Jul 2012 14:19:09 -0000 Hi, The main change in this version is the addition of an SCVP based status method. Could readers that are familiar with SCVP please review those parts of the document? On Sun, 08 Jul 2012 16:07:55 +0200, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > Title : The TLS Multiple Certificate Status Request Extension > Author(s) : Yngve N. Pettersen > Filename : draft-ietf-tls-multiple-cert-status-extension-01.txt > Pages : 10 > Date : 2012-07-08 > > Abstract: > This document defines the Transport Layer Security (TLS) Certificate > Status Version 2 Extension to allow clients to specify and support > multiple certificate status methods. Also defined is a new method > that a server can use to provide status information (i.e., based on > the Online Certificate Status Protocol and Server-Based Certificate > Validation Protocol) not just about the server's own certificate, but > also the status of intermediate certificates in the chain. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-multiple-cert-status-extension-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- 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 Johannes.Merkle@secunet.com Mon Jul 9 10:20:35 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 8455C11E816C for ; Mon, 9 Jul 2012 10:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZy8NtqWdSlc for ; Mon, 9 Jul 2012 10:20:34 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 75EEE11E816D for ; Mon, 9 Jul 2012 10:20:34 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id A80731A0079; Mon, 9 Jul 2012 19:20:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 316211A0075; Mon, 9 Jul 2012 19:20:56 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jul 2012 19:20:55 +0200 Message-ID: <4FFB12F6.1020609@secunet.com> Date: Mon, 09 Jul 2012 19:20:54 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Douglas Stebila References: <4FF6A52F.1030308@secunet.com> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2012 17:20:55.0126 (UTC) FILETIME=[329FEF60:01CD5DF7] Cc: "tls@ietf.org" Subject: Re: [TLS] Using ECC Brainpool curves with TLS 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 Jul 2012 17:20:35 -0000 Douglas, >> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one >> being the "quadratic twist" of the other having the same algebraic structure (and hence, security level), but one of >> them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the >> implementation we propose to register IANA values (for EC Named Curve) for both curves for each bit length. Of course, >> this doubles the number of number assignments. Does anyone consider this a problem? > > One alternative would be to use an extension, similar to the Supported Points Format Extension, to indicate whether to use the twisted form or the original form. Or in fact define the twisted form as just another ECPointFormat. > An extension would work, but although these curves are isomorphic (mathematically equivalent), there parameters and arithmetic are different. So my feeling is that they should not be assigned to the same curve values. A point format is even less suitable as this has nothing to do with EC point representation. We have approx 65000 assignments left. So the question is if saving 7 numbers is worth defining extra syntax and semantics. My personal opinion is that it is not. > But you could also ask the question: if the quadratic twist is more efficient, will anyone ever use the untwisted version? If not, then perhaps you could just standardize the twisted version alone, reducing the number of combinations to be tested and supported. The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations, we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the quadratic twist. Johannes -- Johannes Merkle secunet Security Networks AG johannes.merkle@secunet.com www.secunet.com From jsalowey@cisco.com Tue Jul 10 22:12: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 6E18B11E80FF for ; Tue, 10 Jul 2012 22:12:28 -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 EYxNK+QanuvP for ; Tue, 10 Jul 2012 22:12:28 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id CA98611E80FC for ; Tue, 10 Jul 2012 22:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=277; q=dns/txt; s=iport; t=1341983577; x=1343193177; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7Qwt/SVs//FhJyh7OrdCu3+EOYFH8e8Xs4Q/i09k4uI=; b=PvlamsdaPTylAMQPBvEHCCp/9gH6uAMas5RBuDwtvC+keDjZE2CKrK3D zmaBlp37MyHmxr4FmX02WElihYHyBh8cQZw8SISXm8K74nh3j9804CkNw Q7Zv+OlL5RI1w/2NpIPWYAHjZba11ROQQzHE5qryRbiASXTT1y25x5BCd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACAK/U+tJV2Z/2dsb2JhbABFt3+BB4InEgEnUQE+QicENYdrnAaBKKAbi1SEemADlTaOH4Fmgl+BVg X-IronPort-AV: E=Sophos;i="4.77,564,1336348800"; d="scan'208";a="100656029" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 11 Jul 2012 05:12:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6B5Cv4w023236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Jul 2012 05:12:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 00:12:56 -0500 From: "Joseph Salowey (jsalowey)" To: "tls@ietf.org" Thread-Topic: TLS meeting at IETF 84 Thread-Index: AQHNXyPUrQcpbbSdQ0WpPgYgC8Pz6Q== Date: Wed, 11 Jul 2012 05:12:29 +0000 Message-ID: <892A08E7-A4D7-4EE4-A7EE-8D262E22BAC2@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19032.004 x-tm-as-result: No--25.623300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5B90A3250F6EB44D95EC0B47A2672668@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS meeting at IETF 84 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 Jul 2012 05:12:28 -0000 The TLS meeting has been scheduled for Tuesday, Morning Session II 1030-113= 0. If you have something you would like to present please let the chairs k= now. We have limited time so priority will be given to items related to wo= rking group tasks. =20 Cheers, Joe= From hannes.tschofenig@gmx.net Wed Jul 11 03:56: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 9D9FD21F867D for ; Wed, 11 Jul 2012 03:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 D2SKcFYKVyJf for ; Wed, 11 Jul 2012 03:56:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1E79821F8674 for ; Wed, 11 Jul 2012 03:56:11 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2012 10:56:41 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp012) with SMTP; 11 Jul 2012 12:56:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19qCX4BnD9qpUOf9cGMWfMvFVcsHr4OwLNxvuWFo8 zYulA7wNHfV70k From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2012 13:56:40 +0300 Message-Id: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 10:56:21 -0000 Hi all,=20 draft-ietf-tls-oob-pubkey 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. Here is the latest draft:=20 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 I would be great to get your feedback on an open issue that concerns the = semantic of the exchange. I believe there are three use cases we would = like to support with this work. Below, I provide high level message = exchanges to explain those:=20 I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) client_hello,=20 raw-public-key-indicator=3D"Server, when you send me your raw public = key? I support this out-of-band key validation using DANE." -> <- server_hello, raw-public-key=3D"OK. The certificate = structure below contains my raw public key.", certificate, // with raw public key inside=20= server_key_exchange, server_hello_done client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data II) Client and Server use Raw Public Keys (the smart object use case - CORE working group) client_hello,=20 raw-public-key=3D"Server, please send me your raw public key and I will = then send you mine. Are you OK processing my raw public key for client = authentication?" -> <- server_hello, raw-public-key=3D"Below you find my raw = public key and please send me your raw public key for client=20 = authentication", certificate, // raw public key server_key_exchange, certificate_request, server_hello_done certificate, // with client's raw public key client_key_exchange, certificate_verify, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data II) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello,=20 raw-public-key=3D"I would like to use my raw public key for client = authentication with OAuth. I also process X.509 for server-side = authentication." -> <- server_hello, raw-public-key=3D"Please send me your raw = public key. I use X.509 for server-side authentication", certificate, // with X.509 cert. server_key_exchange, certificate_request, server_hello_done certificate, // with client's raw public key client_key_exchange, certificate_verify, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data -------- QUESTION: Are these all the message exchanges we need? Are there some = problems with the exchanges?=20 Ciao Hannes From ekr@rtfm.com Wed Jul 11 07:21: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 DEFE821F86B9 for ; Wed, 11 Jul 2012 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.787 X-Spam-Level: X-Spam-Status: No, score=-102.787 tagged_above=-999 required=5 tests=[AWL=0.190, 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 Tj9wYWuri6KQ for ; Wed, 11 Jul 2012 07:21:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA9221F86A7 for ; Wed, 11 Jul 2012 07:21:36 -0700 (PDT) Received: by vcqp1 with SMTP id p1so843470vcq.31 for ; Wed, 11 Jul 2012 07:22: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=knDT4zsNumTp4w6b4mOIVlQ+EARJIhryStKjHtRc/LE=; b=e5rveGQaO1rPFZBwMslgvFmYX2lCjd75UYvN/7fp69jb04e/4STqLFLKC/yqO3fOmT Pf/aBoWg11OOWXF/ixurtaZJKaq47AQSOumfhWn0X9gIeeQotm+wPrKCijrGI5UH8UM1 4fBCZVl9WDqxPaLYKb+AcpnosOoLixYj6VztZYHLvbXncVXuXYssYsGfjYNPXjHUdT2r Uo9XimDUrKxeLbIck9qtZw7QQGZl7/fhAkXkuqNKuGc6ygB3t6UQ2mZIuMJAf6xf1xMc KmstDKqYEGKrXaVyHo0e3VOmU4hO4gScgMM7cGigDUmapbi8/g364I3kuYVZ7ESJN53Q SJMg== Received: by 10.220.153.198 with SMTP id l6mr23136896vcw.2.1342016526233; Wed, 11 Jul 2012 07:22:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 11 Jul 2012 07:21:25 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> From: Eric Rescorla Date: Wed, 11 Jul 2012 07:21:25 -0700 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk41kgTKh04t+QLs0VxZDc9pGCEEiOb3kC/Zb/eT6u1/cmXwsI8sqlF4nG3+ruskr1IYURK Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 14:21:38 -0000 On Wed, Jul 11, 2012 at 3:56 AM, Hannes Tschofenig wrote: > Hi all, > > draft-ietf-tls-oob-pubkey 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. > > Here is the latest draft: > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 > > I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: It might help if you desscribe the actual open issue. > I) Server uses Raw Public Keys (client authentication happens at some other layer) > (the DANE use case) > > client_hello, > raw-public-key-indicator="Server, when you send me your raw public key? Is your suggestion that this is indicating ":I would not support X.509? > I support this out-of-band key validation using DANE." -> Wait, who said anything about indicating DANE here? The agreed upon indication was "I would support a public key", nothing about DANE. > <- server_hello, > raw-public-key="OK. The certificate structure below contains my raw public key.", > certificate, // with raw public key inside > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) > > client_hello, > raw-public-key="Server, please send me your raw public key and I will then send you mine. Are you OK processing my raw public key for client authentication?" -> This is not a semantic associated with the client. In TLS the server requests client auth. At most the client could say "I could send you a raw public key for auth if you asked for it" > <- server_hello, > raw-public-key="Below you find my raw public key and please send me your raw public key for client > authentication", > certificate, // raw public key > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) > > client_hello, > raw-public-key="I would like to use my raw public key for client authentication with OAuth. I also process X.509 for server-side authentication." -> As above. > <- server_hello, > raw-public-key="Please send me your raw public key. This is in certreq, no? > I use X.509 for server-side authentication", Why would this need an indication? > certificate, // with X.509 cert. > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > -------- > > QUESTION: Are these all the message exchanges we need? Are there some problems with the exchanges? > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From n.mavrogiannopoulos@gmail.com Wed Jul 11 08:16: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 E385C21F867A for ; Wed, 11 Jul 2012 08:16:11 -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 br4CwwLKbRje for ; Wed, 11 Jul 2012 08:16:11 -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 C0D2721F8679 for ; Wed, 11 Jul 2012 08:16:07 -0700 (PDT) Received: by eekd4 with SMTP id d4so466436eek.31 for ; Wed, 11 Jul 2012 08:16:37 -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=GNCF1gfrKZYUMH2OopZXy4EZjlbjV5D62sFAWMBEJMU=; b=U8tiNyat1jnCQIDa5ynoBaM1HcoLU1UxMORsivjU5dy98jRJBg6I0kbTsgwjokIvqn KI7ld+4cx+pBx6vpZlsvjE1FmuhJ/hmPrgFwRah/loMP01ESzZ4gGPKKi/57P2G5A3QV aWXDWMtE5K3jd55GrKI5QbVCEQVKm+DffsB+3EGgi0V7IVSNOvKmmBYk4pfBK/TbPH6p UXkovwVooVTTD6EQHj8JPlruL51RV2LE2NJo9wCzpUecNEh+Rv/eiUGZ0BmBAC0qZesn 7lczn7eJ572TTb7XmQMO3ahUw7dEei+uDsJors3jz4TcjlUi2+Bhlmz57O2iNP0i3X/g SsJA== Received: by 10.14.119.3 with SMTP id m3mr11630444eeh.204.1342019797804; Wed, 11 Jul 2012 08:16:37 -0700 (PDT) Received: from [10.100.2.17] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id y54sm6720185eef.10.2012.07.11.08.16.36 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 08:16:36 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FFD98D4.1090000@gnutls.org> Date: Wed, 11 Jul 2012 17:16:36 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> In-Reply-To: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 15:16:12 -0000 On 07/11/2012 12:56 PM, Hannes Tschofenig wrote: > Hi all, > > draft-ietf-tls-oob-pubkey 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. > > Here is the latest draft: > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 > > I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: > I) Server uses Raw Public Keys (client authentication happens at some other layer) If you don't need a client certificate or public key, you don't send a certificate request. > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) Your draft already covers that case. > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) (server X.509 certificate, client raw public key) I see two options. 1. You overload the ClientCertificateType of the certificate request with a raw_rsa_sign that does what you intend. 2. You create a new extension that modifies the format of the certificate request to include an explicit certificate format. regards, Nikos From hannes.tschofenig@gmx.net Wed Jul 11 08:57: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 C4AEB11E8091 for ; Wed, 11 Jul 2012 08:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 WWdHBnpW-17q for ; Wed, 11 Jul 2012 08:57:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A6C4B11E8085 for ; Wed, 11 Jul 2012 08:57:21 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2012 15:57:50 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp002) with SMTP; 11 Jul 2012 17:57:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yfEkf9ZIy0I2cVQl15ZgyHsrqyeh55NcLMYJ1Rf jO73HsrI1UnRvQ Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Wed, 11 Jul 2012 18:57:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> To: Eric Rescorla X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 15:57:22 -0000 Hi Ekr,=20 thanks for your quick response.=20 When we started the work we just copied the functionality from RFC 6091 = and that RFC defined a new "cert_type" extension.=20 As it turns out RFC 6091 didn't IMHO clearly specify the semantic of the = value in the cert type. There are various scenarios, as described below.=20 For example, when a client sends a cert_type=3D"raw-key, x509" does this = mean it can raw public keys for client authentication and it is OK to = receive an X.509 for server authentication? Does it want to receive also = a raw public key from the server when the server supports it?=20 >=20 >> I) Server uses Raw Public Keys (client authentication happens at some = other layer) >> (the DANE use case) >>=20 >> client_hello, >> raw-public-key-indicator=3D"Server, when you send me your raw public = key? >=20 > Is your suggestion that this is indicating ":I would not support = X.509? There has to be a way to indicate what is supported. The rest is not = supported.=20 >=20 >=20 >> I support this out-of-band key validation using DANE." -> >=20 > Wait, who said anything about indicating DANE here? The agreed upon > indication was > "I would support a public key", nothing about DANE. >=20 >=20 What happens if the client supports raw public keys but does not support = the out-of-band validation using DNSSEC?=20 While I wasn't really suggesting to provide the way to say "I want to = use DANE" I see problems for interoperability here.=20 >=20 >> <- server_hello, >> raw-public-key=3D"OK. The certificate = structure below contains my raw public key.", >> certificate, // with raw public key = inside >> server_key_exchange, >> server_hello_done >>=20 >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >>=20 >> II) Client and Server use Raw Public Keys >> (the smart object use case - CORE working group) >>=20 >> client_hello, >> raw-public-key=3D"Server, please send me your raw public key and I = will then send you mine. Are you OK processing my raw public key for = client authentication?" -> >=20 > This is not a semantic associated with the client. In TLS the server > requests client auth. At most the client could say "I could > send you a raw public key for auth if you asked for it" The important thing here is the indication that both the server and the = client are able to process and accept raw public keys.=20 >=20 >=20 >> <- server_hello, >> raw-public-key=3D"Below you find my raw = public key and please send me your raw public key for client >> = authentication", >> certificate, // raw public key >> server_key_exchange, >> certificate_request, >> server_hello_done >>=20 >> certificate, // with client's raw public key >> client_key_exchange, >> certificate_verify, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >>=20 >> II) Hybrid Scenario >> (the OAuth Holder-of-the-Key Use case) >>=20 >> client_hello, >> raw-public-key=3D"I would like to use my raw public key for client = authentication with OAuth. I also process X.509 for server-side = authentication." -> >=20 > As above. >=20 >=20 >> <- server_hello, >> raw-public-key=3D"Please send me your = raw public key. >=20 > This is in certreq, no? I should have rather written. The certreq is asking for your raw public = key since you said you support raw public keys (but you have may other = certificate types).=20 >=20 >=20 >> I use X.509 for server-side authentication", >=20 > Why would this need an indication? I believe the problem is that we have to provide a way for the client to = figure out what is in the certificate extension. In the raw public key = case we only dump the SubjectPublicKeyInfo structure into the = Certificate payload.=20 We make it easier for the client to parse the content of the structure.=20= Right?=20 >=20 >> certificate, // with X.509 cert. >> server_key_exchange, >> certificate_request, >> server_hello_done >>=20 >> certificate, // with client's raw public key >> client_key_exchange, >> certificate_verify, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >> -------- >>=20 >> QUESTION: Are these all the message exchanges we need? Are there some = problems with the exchanges? >>=20 Ciao Hannes From ekr@rtfm.com Wed Jul 11 09:06: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 8FD5811E810F for ; Wed, 11 Jul 2012 09:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=0.177, 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 rKtsYS7Ln-pm for ; Wed, 11 Jul 2012 09:06:29 -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 7ABF511E8110 for ; Wed, 11 Jul 2012 09:06:26 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so937062vbb.31 for ; Wed, 11 Jul 2012 09:06:57 -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=OOu9HCnvFS89ZB2ibeUjYtXn/8x7YhhChYaLRCCNgD0=; b=iWyWfaI/egtyfATbOJkhri/zcilze/5LW2+VrekrdK5JnNyh3/STtueD2tZqWVe7bI 1hOYkAKs3tWpfkuVJUEdNVVZoIvCp6Df1LhkiR+x359hIVYrnkkHoU67BaHDXcOLjEfM QVZZwsobQfUe2Yo6hJwhSUW4u00kaxnNaQJEWVQVinHYjnTS02gUszkwRNHXuDxM0rFL tMzoKXlJ/fXR1i1hKYYLF/FiZTb79R85Cune+PRK2lms4rZSQAkxBXoZLeecx0PmoN3u LE2BOEqwU42wzXtqWCV7FGPv3224yPF+wOGKvVQ60vy3G4WNKpP3tEJneBQCKyj1LLYF s1jg== Received: by 10.52.100.229 with SMTP id fb5mr19945063vdb.102.1342022816922; Wed, 11 Jul 2012 09:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Wed, 11 Jul 2012 09:06:16 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> From: Eric Rescorla Date: Wed, 11 Jul 2012 09:06:16 -0700 Message-ID: To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmf23Xe1C9v0KAMPdQGEWoHG2BeaSPLPlElLBzlPCu8bEs44qLpUSSy2QnwaenEossPc9ac Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 16:06:30 -0000 On Wed, Jul 11, 2012 at 8:57 AM, Hannes Tschofenig wrote: > Hi Ekr, > > thanks for your quick response. > > When we started the work we just copied the functionality from RFC 6091 a= nd that RFC defined a new "cert_type" extension. > As it turns out RFC 6091 didn't IMHO clearly specify the semantic of the = value in the cert type. > > There are various scenarios, as described below. > > For example, when a client sends a cert_type=3D"raw-key, x509" does this = mean it can raw public keys for client authentication and it is OK to recei= ve an X.509 for server authentication? Does it want to receive also a raw p= ublic key from the server when the server supports it? Sure, the indication of what you want to do versus what you want the other = side to do seems poentially separable. >> >>> I) Server uses Raw Public Keys (client authentication happens at some o= ther layer) >>> (the DANE use case) >>> >>> client_hello, >>> raw-public-key-indicator=3D"Server, when you send me your raw public ke= y? >> >> Is your suggestion that this is indicating ":I would not support X.509? > > There has to be a way to indicate what is supported. The rest is not supp= orted. Well, the basic state of TLS clients is that they support X.509. And of course servers are allowed to ignore unknown extensions, so there is always some chance that you will just get an X.509 cert anyway. >>> I support this out-of-band key validation using DANE." -> >> >> Wait, who said anything about indicating DANE here? The agreed upon >> indication was >> "I would support a public key", nothing about DANE. >> >> > What happens if the client supports raw public keys but does not support = the out-of-band validation using DNSSEC? What do you mean? There are only like 50 other ways to verify raw public ke= ys, starting with fingerprints. The indication here seems to be "if you send me= a raw key I will do something sensible" >>> <- server_hello, >>> raw-public-key=3D"OK. The certificate stru= cture below contains my raw public key.", >>> certificate, // with raw public key inside >>> server_key_exchange, >>> server_hello_done >>> >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> >>> II) Client and Server use Raw Public Keys >>> (the smart object use case - CORE working group) >>> >>> client_hello, >>> raw-public-key=3D"Server, please send me your raw public key and I will= then send you mine. Are you OK processing my raw public key for client aut= hentication?" -> >> >> This is not a semantic associated with the client. In TLS the server >> requests client auth. At most the client could say "I could >> send you a raw public key for auth if you asked for it" > > The important thing here is the indication that both the server and the c= lient are able to process and accept raw public keys. Well, what the client can say is "I would accept a raw key if you sent it" and "I could send you a raw key if you asked", right? >> This is in certreq, no? > > I should have rather written. The certreq is asking for your raw public k= ey since you said you support raw public keys (but you have may other certi= ficate types). OK. >>> I use X.509 for server-side authentication", >> >> Why would this need an indication? > > I believe the problem is that we have to provide a way for the client to = figure out what is in the certificate extension. In the raw public key case= we only dump the SubjectPublicKeyInfo structure into the Certificate paylo= ad. > > We make it easier for the client to parse the content of the structure. Sure, I have no problem with "the certificate message contains the followin= g" -Ekr From hannes.tschofenig@gmx.net Wed Jul 11 09:08: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 8274121F8552 for ; Wed, 11 Jul 2012 09:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 SS9dmCQV-dHk for ; Wed, 11 Jul 2012 09:08:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 67E1321F85A2 for ; Wed, 11 Jul 2012 09:08:17 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2012 16:08:47 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.106]) [88.115.216.191] by mail.gmx.net (mp004) with SMTP; 11 Jul 2012 18:08:47 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/jtkZ+et/jkqezUEvuiER3xidMw7MNq/1103BW9Z EKOJRRX3UkeM68 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FFD98D4.1090000@gnutls.org> Date: Wed, 11 Jul 2012 19:08:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB857C7-D595-4B07-AE55-E9E77095369E@gmx.net> References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> <4FFD98D4.1090000@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 16:08:18 -0000 Hi Nikos,=20 thanks for the response.=20 On Jul 11, 2012, at 6:16 PM, Nikos Mavrogiannopoulos wrote: > On 07/11/2012 12:56 PM, Hannes Tschofenig wrote: >=20 >> Hi all,=20 >>=20 >> draft-ietf-tls-oob-pubkey 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. >>=20 >> Here is the latest draft:=20 >> http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 >>=20 >> I would be great to get your feedback on an open issue that concerns = the semantic of the exchange. I believe there are three use cases we = would like to support with this work. Below, I provide high level = message exchanges to explain those:=20 >> I) Server uses Raw Public Keys (client authentication happens at some = other layer) >=20 >=20 > If you don't need a client certificate or public key, you don't send a > certificate request. You mean: If the server does not want any client authentication then it = does not send a certificate request.=20 If that's what you mean then I agree with you.=20 But in this scenario the server provides the raw public key.=20 >=20 >> II) Client and Server use Raw Public Keys >> (the smart object use case - CORE working group) >=20 >=20 > Your draft already covers that case. That's what I thought but Paul had a different understanding.=20 It is not quite clear what the semantic of the cert_type=3D"RawPublicKey" = in the client hello message is.=20 >=20 >> II) Hybrid Scenario >=20 >> (the OAuth Holder-of-the-Key Use case) >=20 > (server X.509 certificate, client raw public key) Yes.=20 >=20 > I see two options. 1. You overload the ClientCertificateType of the > certificate request with a raw_rsa_sign that does what you intend. I currently had taken the route that I use an extension to indicate what = stuff is in the certificate payload.=20 It seems that RFC 6091 and the recently submitted OBC had chosen the = same approach.=20 > 2. > You create a new extension that modifies the format of the certificate > request to include an explicit certificate format. Of course the existing certificate format cannot (and should not) be = changed.=20 One could put an additional marker into the cert payload that makes it = easy for the client and the server to differentiate the content of the = payload. =20 In the implementation I put together for the smart object security = workshop I just used the the cert_type to determine what the content of = the cert is and I didn't had to take additional steps.=20 (Maybe I am making this too complicated and it is in fact trivial to = differentiate the two payload types.)=20 Ciao Hannes >=20 > regards, > Nikos From robert.cragie@gridmerge.com Wed Jul 11 10:01: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 EC90A11E80EF; Wed, 11 Jul 2012 10:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZf7CtXPEWkl; Wed, 11 Jul 2012 10:01:26 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6433211E80C0; Wed, 11 Jul 2012 10:01:25 -0700 (PDT) Received: from client-82-26-85-222.pete-bam-1.adsl.virginmedia.com ([82.26.85.222] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1Sp0IU-0004lP-Ad; Wed, 11 Jul 2012 18:01:54 +0100 Message-ID: <4FFDB24F.8060600@gridmerge.com> Date: Wed, 11 Jul 2012 18:05:19 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: tls@ietf.org, core References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> In-Reply-To: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070204090907070709000705" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.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 Jul 2012 17:01:27 -0000 This is a cryptographically signed message in MIME format. --------------ms070204090907070709000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, I think it would be easier to understand if the actual extensions were=20 specified in the message diagrams. This seems to reveal a problem in the = third use case (hybrid scenario), as it is not possible for the client=20 to use a different certificate type to that selected by the server=20 according to the=20 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03/RFC 6091. Robert I) Server uses Raw Public Keys (client authentication happens at some=20 other layer) (the DANE use case) client_hello, cert-type=3D(RawPublicKey, X.509) -> // (1) <- server_hello, cert-type=3DRawPublicKey, // (2) certificate, // (3) server_key_exchange, server_hello_done // (4) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data (1) Client supports both, preferring RawPublicKey. Alternatively,=20 cert-type=3D(RawPublicKey), i.e. client supports onlyRawPublicKey (2) Server supports and chooses RawPublicKey (3) With raw public key (SPKI) inside (4) Server knows OOB that it doesn't need Client certificate so doesn't=20 send certificate_request (security policy for the system) II) Client and Server use Raw Public Keys (the smart object use case -=20 CORE working group) client_hello, cert-type=3D(RawPublicKey) -> // (1) <- server_hello, cert-type=3DRawPublicKey, // (2) certificate, // (3) server_key_exchange, certificate_request, // (4) server_hello_done certificate, // (5) client_key_exchange, certificate_verify, // (6) change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data (1) Client supports only RawPublicKey (2) Server supports only RawPublicKey (3) With raw public key (SPKI) inside (4) Server knows OOB that it needs Client certificate so sends=20 certificate_request (security policy for the system) (5) With raw public key (SPKI)inside (6) Implies signing ability of raw public key III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-type=3D(RawPublicKey, X.509) -> // (1) <- server_hello, cert-type=3DX.509 // (2) certificate, // (3) server_key_exchange, certificate_request, // (4) server_hello_done certificate, // (5) client_key_exchange, certificate_verify, // (6) change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data (1) Client supports both, preferring RawPublicKey (2) Server supports and chooses X.509 (3) With X.509 cert. (4) Server knows OOB that it needs Client certificate so sends=20 certificate_request(security policy for the system). **** Note it could=20 be possible to request a RawPublicKey at this point. It is not clear=20 that CertificateRequest supports requesting of a SPKI **** (5) With raw public key(SPKI)inside *** This doesn't seem possible as=20 X.509 has been chosen **** (6) Implies signing ability of raw public key On 11/07/2012 11:56 AM, Hannes Tschofenig wrote: > Hi all, > > draft-ietf-tls-oob-pubkey specifies a new TLS certificate type for exch= anging raw public keys in Transport Layer Security (TLS) and Datagram Tra= nsport Layer Security (DTLS) for use with out-of-band public key validati= on. > > Here is the latest draft: > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-03 > > I would be great to get your feedback on an open issue that concerns th= e semantic of the exchange. I believe there are three use cases we would = like to support with this work. Below, I provide high level message excha= nges to explain those: > > I) Server uses Raw Public Keys (client authentication happens at some o= ther layer) > (the DANE use case) > > client_hello, > raw-public-key-indicator=3D"Server, when you send me your raw public ke= y? I support this out-of-band key validation using DANE." -> > > <- server_hello, > raw-public-key=3D"OK. The certificate st= ructure below contains my raw public key.", > certificate, // with raw public key insi= de > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Client and Server use Raw Public Keys > (the smart object use case - CORE working group) > > client_hello, > raw-public-key=3D"Server, please send me your raw public key and I will= then send you mine. Are you OK processing my raw public key for client a= uthentication?" -> > > <- server_hello, > raw-public-key=3D"Below you find my raw = public key and please send me your raw public key for client > authentication", > certificate, // raw public key > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > II) Hybrid Scenario > (the OAuth Holder-of-the-Key Use case) > > client_hello, > raw-public-key=3D"I would like to use my raw public key for client auth= entication with OAuth. I also process X.509 for server-side authenticatio= n." -> > > <- server_hello, > raw-public-key=3D"Please send me your ra= w public key. I use X.509 for server-side authentication", > certificate, // with X.509 cert. > server_key_exchange, > certificate_request, > server_hello_done > > certificate, // with client's raw public key > client_key_exchange, > certificate_verify, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > -------- > > QUESTION: Are these all the message exchanges we need? Are there some p= roblems with the exchanges? > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------ms070204090907070709000705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBBkwggQVAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggJFMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMTE3MDUxOVowIwYJKoZI hvcNAQkEMRYEFJ4S1D5cdqo6XurR1dWZZRIiQga1MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgbkGCSsGAQQBgjcQBDGBqzCBqDCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f 2nTvZjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwDQYJKoZIhvcNAQEBBQAEggEAFoRF OMeJ91l4AYrJANaBPfziTQytmjiReeqS0Ufm7Yc8wGyDuYXXWhC6WeHl2V3fGFYStRdNL+ih ee7D824wSVKv4pcdFCn2El8/Rknk8YjkPbSGxztF+9sMHNi2VS+AE6TZtBQ5z62ure2NucuO 8C5qa6CUVaFX6aMhzc6lqkXboY9/U05Tn4hSGv3yua2Fuoz1SmA2legBkt3IOdOr85Do2//0 Zmj96Up+EHNGsurS+3QWkHk8NeGMPiyVX5wwRHVU3CVw4MNfLfF9fhFLgawAJyrxYfOPCIKN R4TJ+UGqaHWTphZzBkr0fmkyEiCyanBsOGc5aNisoc2BGtbOwgAAAAAAAA== --------------ms070204090907070709000705-- From n.mavrogiannopoulos@gmail.com Wed Jul 11 10:36: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 E814511E8120 for ; Wed, 11 Jul 2012 10:36:17 -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 0dFnZfnMadI3 for ; Wed, 11 Jul 2012 10:36:17 -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 27D7311E8107 for ; Wed, 11 Jul 2012 10:36:04 -0700 (PDT) Received: by eekd4 with SMTP id d4so523488eek.31 for ; Wed, 11 Jul 2012 10:36:34 -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=/u+d99cfX1lEGIQiWKxNAHqTMnkcRXqW64NCMGpq9x8=; b=B25Zc7/Uq8cOuyTsmjXKffGik4RRKJtup1MbRmNvkJiNJCLpi6z8HOIiChAX9CoVGd +hxCD28/tBCkqlrEdFAqP0wS6zGRG41IOjkmG12fegEXY5sgNShdfqjKPpppLryPvGlu sg2DvVlPXWdgAfGlITH7VI1Mu8Z4BMFAwXdKv+IyMq5i+iaFrH633DQGLeJYsllA4AS1 t+dYDjQmtvXA4jWXTdZL7aHageas6mtS9D1Jsc0jP/mPuh/HUsqgUUgO/xNzWrM/A3M4 87Bg5ouR3vW4lgj7jQe6Ol4MAGOPEiYso55y9Urv55la3PcDW2+gGxV/A9MjD1uNxq2m h8lQ== Received: by 10.14.98.204 with SMTP id v52mr11710913eef.199.1342028194554; Wed, 11 Jul 2012 10:36:34 -0700 (PDT) Received: from [10.100.2.17] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id s4sm7946116eef.2.2012.07.11.10.36.33 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 10:36:33 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4FFDB9B2.2000404@gnutls.org> Date: Wed, 11 Jul 2012 19:36:50 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <1CA8C4CB-1FD8-4498-9988-41B6334F58FD@gmx.net> <4FFD98D4.1090000@gnutls.org> <4FB857C7-D595-4B07-AE55-E9E77095369E@gmx.net> In-Reply-To: <4FB857C7-D595-4B07-AE55-E9E77095369E@gmx.net> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: The Open Issue 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 Jul 2012 17:36:18 -0000 On 07/11/2012 06:08 PM, Hannes Tschofenig wrote: >>> I would be great to get your feedback on an open issue that concerns the semantic of the exchange. I believe there are three use cases we would like to support with this work. Below, I provide high level message exchanges to explain those: >>> I) Server uses Raw Public Keys (client authentication happens at some other layer) >> If you don't need a client certificate or public key, you don't send a >> certificate request. > You mean: If the server does not want any client authentication then it does not send a certificate request. > If that's what you mean then I agree with you. > But in this scenario the server provides the raw public key. This is what I mean. I don't understand understand how providing the raw public key changes this fact. Did you explicitly specified in the draft-ietf-tls-oob-pubkey that no certificate request is expected? If not I would expect the TLS semantics to remain. >>> II) Client and Server use Raw Public Keys >>> (the smart object use case - CORE working group) >> Your draft already covers that case. > That's what I thought but Paul had a different understanding. > It is not quite clear what the semantic of the cert_type="RawPublicKey" in the client hello message is. Then the semantics should cleared up. What is the different understanding? As I understand this draft, if the extension is present, then _both_ server and client certificates are encoded in "raw" format. >> 2. >> You create a new extension that modifies the format of the certificate >> request to include an explicit certificate format. > Of course the existing certificate format cannot (and should not) be changed. > One could put an additional marker into the cert payload that makes it easy for the client and the server to differentiate the content of the payload. And would also be easier to mount attacks in the protocol. If you change the format of the certificates it should be clear in the handshake what certificate format is expected. regards, Nikos From hannes.tschofenig@gmx.net Thu Jul 12 00:54: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 0187021F875A for ; Thu, 12 Jul 2012 00:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 jU1Uf4sZ8wMU for ; Thu, 12 Jul 2012 00:54:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DFAF921F8759 for ; Thu, 12 Jul 2012 00:54:18 -0700 (PDT) Received: (qmail invoked by alias); 12 Jul 2012 07:54:49 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp070) with SMTP; 12 Jul 2012 09:54:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18netw6/Dsneo97R8OqyhzcBJ8fgqRo00fHbLH39b KjbMRCslVls43p From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2012 10:54:48 +0300 Message-Id: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> To: tls@ietf.org, IETF CoRE Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: [TLS] draft-ietf-tls-oob-pubkey: My summary 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 Jul 2012 07:54:20 -0000 Hi Erk, Hi Robert, Hi Nikos,=20 thanks for your quick response. Here is an attempt to summarize your = input.=20 -------- I use three types of indications in the message exchange below for = improved clarity, namely:=20 (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning: = "I accept certificate of the following types (value-1, ..., value-n) if = you send them to me." The list is ordered by preference.=20 (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: "I = could send you certificate of the following types (value-1, ..., = value-n) if you ask." The list is ordered by preference.=20 (c) cert-info=3D(value) with the meaning: "The certificate payload in = this message contains a certificate of the following type".=20 I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) client_hello, cert-receive=3D(Raw, X.509) // (1) cert-send=3D() -> // (2) <- server_hello, cert-info=3D(Raw),// (3) certificate, // (4) server_key_exchange, server_hello_done=20 client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend:=20 (1) Client accepts to receive two types of certificates, preferring raw = public keys. (2) The client does not have a raw public key nor an X.509 certificate = for client authentication.=20 (3) The server decides to sends his raw public key and indicates this in = the cert-info field.=20 (4) The certificate payload contains the raw public key.=20 II) Client and Server use Raw Public Keys (the smart object use case - = CORE working group) client_hello, cert-receive=3D(Raw) // (1) cert-send=3D(Raw) -> // (2) <- server_hello, cert-info=3D(Raw),// (3) certificate, // (4) certificate_request, // (5) cert-receive=3D(Raw) // (6) server_key_exchange, server_hello_done=20 cert-info=3D(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend:=20 (1) Client accepts to receive raw public keys. (2) The client does have a raw public key for client authentication.=20 (3) The server decides to sends his raw public key and indicates this in = the cert-info field.=20 (4) The certificate payload contains the raw public key.=20 (5) The server wants to use client authentication and and sends a = cert-request.=20 (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)).=20 (7) The client indicates that the certificate payload contains a raw = public key (8) Here is the payload of the certificate itself.=20 III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-receive=3D(X.509, Raw) // (1) cert-send=3D(Raw) -> // (2) <- server_hello, cert-info=3D(X.509),// (3) certificate, // (4) certificate_request, // (5) cert-receive=3D(Raw) // (6) server_key_exchange, server_hello_done=20 cert-info=3D(Raw), // (7) certificate, // (8) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend:=20 (1) Client accepts to receive X.509 certs and raw public keys, in this = order of preference. (Could also be X.509 only in this example) (2) The client does have a raw public key for client authentication.=20 (3) The server decides to sends his X.509 cert and indicates this in the = cert-info field.=20 (4) The certificate payload contains the X.509 cert.=20 (5) The server wants to use client authentication and sends a = cert-request.=20 (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)).=20 (7) The client indicates that the certificate payload contains a raw = public key. (8) Here is the payload of the certificate itself.=20 =20 -------- Do these indications clarify the semantic? I personally believe so.=20 Ciao Hannes From robert.cragie@gridmerge.com Thu Jul 12 05:53: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 2273521F87C8; Thu, 12 Jul 2012 05:53:44 -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 GT9ctxycE2uT; Thu, 12 Jul 2012 05:53:43 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 72D4221F8701; Thu, 12 Jul 2012 05:53:42 -0700 (PDT) Received: from client-82-26-85-222.pete-bam-1.adsl.virginmedia.com ([82.26.85.222] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SpIuJ-0001wS-CB; Thu, 12 Jul 2012 13:54:13 +0100 Message-ID: <4FFEC9C3.8050108@gridmerge.com> Date: Thu, 12 Jul 2012 13:57:39 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: tls@ietf.org, core References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> In-Reply-To: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090709070801060205030409" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: My summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.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, 12 Jul 2012 12:53:44 -0000 This is a cryptographically signed message in MIME format. --------------ms090709070801060205030409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, The only one thing I am not sure about is the necessity for cert-send.=20 This is because traditionally the server makes the decision on whether=20 to request a certificate from the client and would not know a priori=20 whether the client supports it. That's not to say it isn't a good idea=20 though. On that basis, I would modify the exchange slightly - see below. Robert I use three types of indications in the message exchange below for=20 improved clarity, namely: (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning: "= I=20 accept certificate of the following types (value-1, ..., value-n) if you = send them to me." The list is ordered by preference. (b) 'cert-info=3Dvalue' with the meaning: "The certificate payload in thi= s=20 message contains a certificate of the following type". I) Server uses Raw Public Keys (client authentication happens at some=20 other layer) (the DANE use case) client_hello, cert-receive=3D(Raw, X.509) -> // (1) <- server_hello, cert-info=3DRaw, // (2) certificate, // (3) server_key_exchange, server_hello_done client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) The client accepts reception of X.509 certs and raw public keys,=20 preferring raw public keys. (2) The server decides to sends his raw public key and indicates this in = the cert-info field. (3) The server certificate payload contains the raw public key. II) Client and Server use Raw Public Keys (the smart object use case -=20 CORE working group) client_hello, cert-receive=3D(Raw) -> // (1) <- server_hello, cert-info=3DRaw,// (2) certificate, // (3) certificate_request, // (4) cert-receive=3D(Raw) // (5) server_key_exchange, server_hello_done cert-info=3DRaw, // (6) certificate, // (7) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) The client accepts reception of raw public keys. (2) The server decides to sends his raw public key and indicates this in = the cert-info field. (3) The server certificate payload contains the raw public key. (4) The server wants to use client authentication and and sends a=20 certificate-request. (5) The server accepts reception of raw public keys. (6) The client indicates that the certificate payload contains a raw=20 public key. (7) The client certificate payload contains the raw public key. III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) client_hello, cert-receive=3D(X.509, Raw) -> // (1) <- server_hello, cert-info=3DX.509,// (2) certificate, // (3) certificate_request, // (4) cert-receive=3D(Raw) // (5) server_key_exchange, server_hello_done cert-info=3DRaw, // (6) certificate, // (7) client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data Legend: (1) Client accepts to receive X.509 certs and raw public keys,=20 preferring X.509 certs. (Could also be X.509 only in this example) (2) The server decides to sends his X.509 cert and indicates this in the = cert-info field. (3) The server certificate payload contains the X.509 cert. (4) The server wants to use client authentication and sends a=20 certificate-request. (5) The server accepts reception of raw public keys. (6) The client indicates that the certificate payload contains a raw=20 public key. (7) The client certificate payload contains the raw public key. On 12/07/2012 8:54 AM, Hannes Tschofenig wrote: > Hi Erk, Hi Robert, Hi Nikos, > > thanks for your quick response. Here is an attempt to summarize your i= nput. > > -------- > > I use three types of indications in the message exchange below for impr= oved clarity, namely: > > (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning:= "I accept certificate of the following types (value-1, ..., value-n) if = you send them to me." The list is ordered by preference. > > (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: "I= could send you certificate of the following types (value-1, ..., value-= n) if you ask." The list is ordered by preference. > > (c) cert-info=3D(value) with the meaning: "The certificate payload in t= his message contains a certificate of the following type". > > I) Server uses Raw Public Keys (client authentication happens at some o= ther layer) (the DANE use case) > > client_hello, > cert-receive=3D(Raw, X.509) // (1) > cert-send=3D() -> // (2) > > <- server_hello, > cert-info=3D(Raw),// (3) > certificate, // (4) > server_key_exchange, > server_hello_done > > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > Legend: > > (1) Client accepts to receive two types of certificates, preferring raw= public keys. > (2) The client does not have a raw public key nor an X.509 certificate = for client authentication. > (3) The server decides to sends his raw public key and indicates this i= n the cert-info field. > (4) The certificate payload contains the raw public key. > > II) Client and Server use Raw Public Keys (the smart object use case - = CORE working group) > > > client_hello, > cert-receive=3D(Raw) // (1) > cert-send=3D(Raw) -> // (2) > > <- server_hello, > cert-info=3D(Raw),// (3) > certificate, // (4) > certificate_request, // (5) > cert-receive=3D(Raw) // (6) > server_key_exchange, > server_hello_done > > cert-info=3D(Raw), // (7) > certificate, // (8) > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > > Legend: > > (1) Client accepts to receive raw public keys. > (2) The client does have a raw public key for client authentication. > (3) The server decides to sends his raw public key and indicates this i= n the cert-info field. > (4) The certificate payload contains the raw public key. > (5) The server wants to use client authentication and and sends a cert-= request. > (6) The certificate request asks for a certificate of type 'raw' (knowi= ng that the client supports it from (2)). > (7) The client indicates that the certificate payload contains a raw pu= blic key > (8) Here is the payload of the certificate itself. > > III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) > > client_hello, > cert-receive=3D(X.509, Raw) // (1) > cert-send=3D(Raw) -> // (2) > > <- server_hello, > cert-info=3D(X.509),// (3) > certificate, // (4) > certificate_request, // (5) > cert-receive=3D(Raw) // (6) > server_key_exchange, > server_hello_done > > cert-info=3D(Raw), // (7) > certificate, // (8) > client_key_exchange, > change_cipher_spec, > finished -> > > <- change_cipher_spec, > finished > > Application Data <-------> Application Data > > Legend: > > (1) Client accepts to receive X.509 certs and raw public keys, in this = order of preference. (Could also be X.509 only in this example) > (2) The client does have a raw public key for client authentication. > (3) The server decides to sends his X.509 cert and indicates this in th= e cert-info field. > (4) The certificate payload contains the X.509 cert. > (5) The server wants to use client authentication and sends a cert-requ= est. > (6) The certificate request asks for a certificate of type 'raw' (knowi= ng that the client supports it from (2)). > (7) The client indicates that the certificate payload contains a raw pu= blic key. > (8) Here is the payload of the certificate itself. > =20 > -------- > > Do these indications clarify the semantic? > I personally believe so. > > Ciao > Hannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------ms090709070801060205030409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBBkwggQVAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggJFMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMjEyNTczOVowIwYJKoZI hvcNAQkEMRYEFD/EuHzwOCWN4x38Vkzp5R21br4uMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgbkGCSsGAQQBgjcQBDGBqzCBqDCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f 2nTvZjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwDQYJKoZIhvcNAQEBBQAEggEAX6J1 wA9x690zmKy79y7TmTjNTggPmVBqafUanoX16jflpbbKF6qD/F9q/N8RIkeWIAAmcZb8gVIC o23dZEoV/BEjVuviEHsVU9lPigN+l+vBuBC8SA9k3gMlsQPS/XWjW4Sy5hkTd0rHfScQ7MGH X7+J8xzrLVweut7ZHUzUlcoM9eQmWGubiYcZHsfB4YjoZJDtnqTb2Nn9vrO5Gn6JSx0sC/9R Cq9Q7PWBh4oc63JvjZu63wKCnStHZd/y+3tFimDCUfwuxcfTpaS5lPlKjWfmcvSPM5zIoNzo Gs+iT67A1W+Oe7C4KXNPf3ZQ3Tmlson1423BXgMMYdFOg+5YnQAAAAAAAA== --------------ms090709070801060205030409-- From alfredo@pironti.eu Thu Jul 12 07:08: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 8004521F85C6 for ; Thu, 12 Jul 2012 07:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 zUXx56--bLou for ; Thu, 12 Jul 2012 07:08:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF73A21F85C0 for ; Thu, 12 Jul 2012 07:08:51 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1657001vcq.31 for ; Thu, 12 Jul 2012 07:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=hCraPpy7cpyS0tqbHV9erFYWDPyfGDFgcr7QzE6rvsg=; b=MWQEcDn7UqhYkYHeLku5HtGB5r7IjNOel2ZiEvvarOFTe2vo9T+AfMRJo0xp6hq6ms EAM5I87GDBjZK6vSrLuO4WleU64ZpcFgnJV+9C/INqGE7Yw1nkngzERxvM+XpYDkmDdE bORrOfbE6Y6kbK0SA6oQFu/E+fMSbCJjxcckQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=hCraPpy7cpyS0tqbHV9erFYWDPyfGDFgcr7QzE6rvsg=; b=H5z/2SS8xLfRnImUBaQrnQrwuNr0vgidHY7BmHp9dwYDn9F+01ABU0ZyPpE114CmoV tw2RaQWM8Cdzs8y3oZemVrEu8vR24jlUcKhi9ISS7PpKHkVDy5AFGwB65Q8ywZxozKra yDoj9PpsbKoZNNxOkBXt2BrUMgJKj6ddOXyWJb9ZjVVq+rb8EJcTnYjhqsvauwTuRB3o ZAdq6IOS0WxKs8I7TPMwZpGhZL5lXcohXU1uVLAdF2U/6oNoE7dpIe45RYGMIX4WdU4r QrwPRNYMZ0b9ZPw5iCOYmIkGFQfLa7B/ubDeo9cfjEcPtKjMHOxM7GS0iYpdi4NEBr7r z1Aw== MIME-Version: 1.0 Received: by 10.52.73.105 with SMTP id k9mr21299205vdv.72.1342102164647; Thu, 12 Jul 2012 07:09:24 -0700 (PDT) Sender: alfredo@pironti.eu Received: by 10.220.227.133 with HTTP; Thu, 12 Jul 2012 07:09:24 -0700 (PDT) X-Originating-IP: [128.93.191.46] Date: Thu, 12 Jul 2012 16:09:24 +0200 X-Google-Sender-Auth: LLnP9CN5gqfDjmalauiprO-1jl0 Message-ID: From: Alfredo Pironti To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnRYF9RSEGzdKBO/mOQ1dt4LcnRDftk5g48IEyn5ur8ahLdYDQaGPKVfrxcXGetsia3xHy1 Subject: [TLS] Next Protocol Negotiation - Some comments 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 Jul 2012 14:10:44 -0000 Hello all, It seems to me that the NPN extension is vulnerable to some known limited version/ciphersuite rollback attack, which was affecting, for example, the proposed False-Start protocol variation [1]. Briefly, suppose a MItM wishes to know which 'selected_protocol' the client is sending to the server. He could downgrade protocol version/ciphersuite in the server hello, let the client send its encrypted "EncryptedExtensions" message, and then let the session fail. Decrypting the message once could be enough to spot that the server is offering a specific 'selected_protocol' (or at least that the client believes the server can offer it, even if not advertised), and so ban the server in the future. If we accept this weakness, I believe it would be at least worth mentioning it in section 6. On a related topic, the EncryptedExtension message is padded, to avoid leaking the length of next-protocol name. I would add an implementation caveat here. Note that handshake messages can be fragmented. In particular, if an implementation prepares the selected_protocol field and sends it to the record, then prepares the padding field and sends it to the record, we may end up with two encrypted fragments where the first reveals the length of the selected_protocol field. An implementation should ensure this message is not fragmented in the above way (or not fragmented at all). I believe it's quite unlikely implementations out there would behave like this, but again, we may want to be explicit on this. Finally, if I was to implement this extension, I would not know what to do in case of errors. For example, if I'm the server, and I receive an unsupported 'selected_protocol' from the client, what should I do? Send an alert (which one)? Cheers, Alfredo [1] http://www6.ietf.org/mail-archive/web/tls/current/msg06933.html From agl@google.com Thu Jul 12 07:35: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 793A621F87DD for ; Thu, 12 Jul 2012 07:35:00 -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 biW4boSIyLlH for ; Thu, 12 Jul 2012 07:34:59 -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 BCD5C21F87DA for ; Thu, 12 Jul 2012 07:34:58 -0700 (PDT) Received: by yhq56 with SMTP id 56so2860682yhq.31 for ; Thu, 12 Jul 2012 07:35:32 -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=zlSrrO9XakOe7utpWffP+IR2AMxfowtQnNtHZZTEDnY=; b=IQ7qHHYpz497kIkgyU0bLYb4pVVV5QEHOoJcw2aJI/zZR/CZs9YmR4jTLzXozaxnTE kx+XfK9r3B4j2fdEIDjbB2hP4SBU8vSl5iqwKyqIIhIvkwYy8bB8TQMF7kvzrMgpq8p0 jb8K0SQgkBNdfNLWXkBl1dhFXk3wUtyUINAEKW5fuXOV82J/WOOBOksFqlhCJSAb0Vu7 Hchu/IVlzNCUd3LYEKP7K7kfcaxal84/1UHX8/SLSkIcVss+gzHEZSf3w7iJohiTB8go jiy6GluYof/NnXqQYaz4X6t1kB0Hx3pYrYZc466ZDf9i/ZQvnvgAMwgImF6MRDVL9neD Dluw== 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=zlSrrO9XakOe7utpWffP+IR2AMxfowtQnNtHZZTEDnY=; b=UQXyu+xFXYKe35b3vmlUEk5QGN2wMPvAODxYgnx1206M9ALnuWqbBHQLwsMFeM1/R0 74I2uvZAcpLfORqyC2TD8PhHJwrUh0k5udCAW5ZimzB3FgH8ri9b/hLPesSt0uVu84g3 0Ki32UfoXl0+VvKIHxVdnLhWrhlYm49fJrPdKlW3xILTwlDaeS//F57c6UutLdrptwAA zRfJ8GwmnAh79sGL5WdaaJ0nL/jEQpQrZFo6DB6rGX+LdWW9MDrfv5EJC6IhPYaSZZ+H bdplG1kUeBuAgoe0G6xEjonEcJEyqZtJ9XYv+xE/77Y5Iy4UAY3KMM6/sRHWGGwrtfin 7O3A== Received: by 10.50.236.97 with SMTP id ut1mr17710726igc.50.1342103731836; Thu, 12 Jul 2012 07:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.236.97 with SMTP id ut1mr17710716igc.50.1342103731725; Thu, 12 Jul 2012 07:35:31 -0700 (PDT) Received: by 10.231.31.202 with HTTP; Thu, 12 Jul 2012 07:35:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jul 2012 10:35:31 -0400 Message-ID: From: Adam Langley To: Alfredo Pironti Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnQu4+GLO0K97vvFAIFtFhWcB4ix4/WTcrmZ1+oPOxClWCDLdNgTTxAt2i2Bewsr1jRlpz10CWKeOO/3DavHj/CjfJ9LDpPmOiU1LAJZPXyLcTf1O4OemzWkxyrnSQ96S/7srsNttSv/C8X+Ja9bIb+lkpoaVMbHMGZ11PnnXch1FXGAWg= Cc: tls@ietf.org Subject: Re: [TLS] Next Protocol Negotiation - Some comments 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 Jul 2012 14:35:00 -0000 On Thu, Jul 12, 2012 at 10:09 AM, Alfredo Pironti wrote: > Briefly, suppose a MItM wishes to know which 'selected_protocol' the > client is sending to the server. He could downgrade protocol > version/ciphersuite in the server hello, let the client send its > encrypted "EncryptedExtensions" message, and then let the session > fail. Decrypting the message once could be enough to spot that the > server is offering a specific 'selected_protocol' (or at least that > the client believes the server can offer it, even if not advertised), > and so ban the server in the future. Yep, especially if the client will allow NULL encryption ciphersuites. Quite possibly this should be noted in the spec. The purpose of encrypting and padding the protocol is to prevent large-scale, casual interference which has become so common and damaging to other protocols. It's certainly adding grey to TLS's otherwise binary world, but that's not to say that it's not useful. > On a related topic, the EncryptedExtension message is padded, to avoid > leaking the length of next-protocol name. I would add an > implementation caveat here. Note that handshake messages can be > fragmented. In particular, if an implementation prepares the > selected_protocol field and sends it to the record, then prepares the > padding field and sends it to the record, we may end up with two > encrypted fragments where the first reveals the length of the > selected_protocol field. An implementation should ensure this message > is not fragmented in the above way (or not fragmented at all). I > believe it's quite unlikely implementations out there would behave > like this, but again, we may want to be explicit on this. Yep, probably another point to be mentioned, thanks. (Although the reality is that fragmenting handshake messages doesn't actually work in the real world due to bugs.) > Finally, if I was to implement this extension, I would not know what > to do in case of errors. For example, if I'm the server, and I receive > an unsupported 'selected_protocol' from the client, what should I do? > Send an alert (which one)? That's deliberately unspecified at the moment because I don't know what the right behaviour is. What'll actually happen at the moment is that servers will use their default protocol if they don't recognise the requested protocol. But I don't think it's clear enough yet to say whether that's the right behaviour or not. Cheers AGL From ietf-ietf-tls@m.gmane.org Thu Jul 12 10:59: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 7AEE821F85FD for ; Thu, 12 Jul 2012 10:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.687 X-Spam-Level: X-Spam-Status: No, score=0.687 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_NUMERIC_HELO=2.067] 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 WozhPsZ4hTND for ; Thu, 12 Jul 2012 10:59:33 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBCB21F85C7 for ; Thu, 12 Jul 2012 10:59:32 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SpNgL-0001CE-IZ for tls@ietf.org; Thu, 12 Jul 2012 20:00:05 +0200 Received: from 12.208.167.2 ([12.208.167.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jul 2012 20:00:05 +0200 Received: from ywang by 12.208.167.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 12 Jul 2012 20:00:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Yingxian Wang Date: Tue, 10 Jul 2012 23:18:21 +0000 (UTC) Lines: 43 Message-ID: References: <201204192048.q3JKmsmY019775@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 12.208.167.2 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/534.55.3 (KHTML, like Gecko) Version/5.1.5 Safari/534.55.3) 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, 12 Jul 2012 17:59:34 -0000 Eric Rescorla rtfm.com> writes: > > On Thu, Apr 19, 2012 at 1:48 PM, Martin Rex sap.com> wrote: > > 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. > > There's no additional enrollment involved. You just HTTP fetch the > certificate from a specified location in the cert. > > -Ekr > Can anyone explain why OCSP stapling is never defined for the client certificate/chain? I can understand that the resource and performance gains that are brought with server caching and reusing the certificate status check against many clients. However, if we are doing mutual authentication, the client providing OCSP stapling on it's own certificate/chain can also result in resource and performance gains. It just seems to me to be a small extension to the one already defined for server OCSP stapling in order to support client OCSP stapling. Thanks, Yingxian Wang Principal Engineer, Mocana Corp. From wwwrun@rfc-editor.org Thu Jul 12 21:09: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 DDAB611E8114 for ; Thu, 12 Jul 2012 21:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.204 X-Spam-Level: X-Spam-Status: No, score=-102.204 tagged_above=-999 required=5 tests=[AWL=0.396, 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 MhkTY4PZHxqN for ; Thu, 12 Jul 2012 21:09:53 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B411E810C for ; Thu, 12 Jul 2012 21:09:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 18B35B1E003; Thu, 12 Jul 2012 21:10:13 -0700 (PDT) To: d3e3e3@gmail.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20120713041013.18B35B1E003@rfc-editor.org> Date: Thu, 12 Jul 2012 21:10:13 -0700 (PDT) Cc: bradford.wetmore@oracle.com, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC6066 (3283) 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 Jul 2012 04:09:54 -0000 The following errata report has been submitted for RFC6066, "Transport Layer Security (TLS) Extensions: Extension Definitions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6066&eid=3283 -------------------------------------- Type: Technical Reported by: Brad Wetmore Section: Appendix A Original Text ------------- Appendix A: The Server Name extension...(deleted)... It is provided that the ServerNameList can contain more than only one name of any particular name_type. Corrected Text -------------- Appendix A: The Server Name extension...deleted..It is provided that the ServerNameList can contain only one name of any particular name_type. Notes ----- Section 3 and Appendix A seem to be conflict with each other. Am I parsing something incorrectly here: Section 3: The ServerNameList MUST NOT contain more than one name of the same name_type. Appendix A: The Server Name extension...deleted..It is provided that the ServerNameList can contain more than only one name of any particular name_type. I think the words "more than" were not supposed to appear in the final RFC. 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. -------------------------------------- RFC6066 (draft-ietf-tls-rfc4366-bis-12) -------------------------------------- Title : Transport Layer Security (TLS) Extensions: Extension Definitions Publication Date : January 2011 Author(s) : D. Eastlake 3rd Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From hannes.tschofenig@gmx.net Fri Jul 13 02:34: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 09E5521F865C for ; Fri, 13 Jul 2012 02:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.147, 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 LAl6xYYD0tYF for ; Fri, 13 Jul 2012 02:34:58 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 010D321F846D for ; Fri, 13 Jul 2012 02:34:56 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 09:35:31 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp038) with SMTP; 13 Jul 2012 11:35:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Hgo1mXqMH1mbAxRGKAYf9e0KI7+AKHdxrNwU5pF EvaL9ArVFxrAmX From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 13 Jul 2012 12:35:30 +0300 Message-Id: <1E0BC1E0-37FA-4B7A-B35B-5353FC13BA50@gmx.net> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [TLS] TLS Cached Information Extension: Hash Algorithm Indication 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 Jul 2012 09:34:59 -0000 Hi all,=20 I went through the review comments in an attempt to compile a new draft = version by the deadline.=20 Ekr explained me that the issue of hash algorithm negotiation had been = discussed in the past already and it was decided not to provide support = for it.=20 I don't have hash algorithm negotiation in the -11 version of the draft = and so I will also not add it. Version -11 did, however, define a hash algorithm registry and Sean = asked why I am not re-using the TLS hash algorithm registry, see = http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-para= meters-17, and to use it in the newly defined field. Rob raised a = related question and suggested to re-use Stephen Farrell's work on = draft-farrell-decade-ni [1], which also seemed like a good fit.=20 We would need to make a decision about the direction we should go with = the indication of the hash algorithm. There are at least four options: 1) No indication. Just the hash is exchanged without an indication of = the hash algorithm being used.=20 2) The hash algorithm is indicated in a newly defined field and a new = hash algorithm registry is defined in the document. This is the approach = currently used in version -11 of the draft.=20 3) The hash algorithm is indicated in a newly defined field but the = existing TLS hash algorithm registry is re-used.=20 4) We use Stephen Farrell's work and use the nih URI scheme. =20 I think #3 and #4 are good approaches; I have a slight preference for = #4. =20 What are your thoughts?=20 Ciao Hannes From hannes.tschofenig@gmx.net Fri Jul 13 02:40: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 A29B221F86C5 for ; Fri, 13 Jul 2012 02:40:16 -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 wA5OQhkkXwGl for ; Fri, 13 Jul 2012 02:40:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2827B21F86B8 for ; Fri, 13 Jul 2012 02:40:14 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 09:40:49 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp019) with SMTP; 13 Jul 2012 11:40:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX184cuUrNAw4cj1Pbm1mhsW7oUmDkccT2CMFTSqiM8 IGfv6KlRU3CX7Z Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4F2FC5AA.5070600@comodo.com> Date: Fri, 13 Jul 2012 12:40:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7E329BCB-EFA1-423B-8F20-F6EA382D2901@gmx.net> References: <4EF84292.50201@gmx.net> <4F2FC5AA.5070600@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] TLS Cached Information Extension - version 11 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 Jul 2012 09:40:16 -0000 Hi Rob,=20 me again.=20 >=20 > 2. Currently, cached-info only allows a TLS Client to indicate to the = TLS Server a list of static Objects that it _doesn't_ want to receive = (because it already has them). > i.e. "Don't send me any Objects of Type X, Y or Z that match Digests = A, B or C". >=20 > How about extending this so that the TLS Client can indicate types of = Object that it _does_ want to receive? > i.e. "Do send me any Objects of Type X, Y and Z that you have, = excluding any that match Digests A, B or C". I am open for feedback from the group on this issue. I have not heard = anyone asking for it so far.=20 >=20 > This added functionality could meet the needs of several other TLS = extensions that are being proposed, for example... > - Multiple OCSP Responses [2]. > - Audit proofs for Google's Certificate Transparency proposal [3]. > - TACK rules for Convergence [4]. >=20 > Or, is it your explicit intention to restrict cached-info so that it = only supports the "standard" TLS handshake objects (e.g. Certificate, = Trusted CAs list). > (I can see that such a restriction could help to ensure that = client-side code can be implemented entirely within the network layer = rather than bleeding into the application layer). There is no intention to restrict the functionality to certain = extensions.=20 I do, however, believe that new documents should add a description to = their document how this document could be used in combination with the = TLS cached information extension.=20 I don't think it makes sense to add text about, for example, = draft-pettersen-tls-ext-multiple-ocsp when that work is still in = progress.=20 Ciao Hannes [2] http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp [3] = http://www.links.org/file/CertificateAuthorityTransparencyandAuditability.= pdf [4] https://github.com/moxie0/Convergence/wiki/TACK= From Hannes.Tschofenig@gmx.net Fri Jul 13 02:45: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 E8B4921F8683 for ; Fri, 13 Jul 2012 02:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 d-cABUasx0ds for ; Fri, 13 Jul 2012 02:45:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EAE9321F8638 for ; Fri, 13 Jul 2012 02:45:20 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 09:45:55 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp010) with SMTP; 13 Jul 2012 11:45:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+D4H4cjpyDCJyNm5Iz1W6FNx9Ryl7p3J0mqjkpZ/ JN388mSN9+Vooo Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4F7397D3.4060801@nic.cz> Date: Fri, 13 Jul 2012 12:45:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7594BFD0-9019-4AB8-93AB-3895BA3A1087@gmx.net> References: <4F7397D3.4060801@nic.cz> To: Ondrej Mikle X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-ietf-tls-cached-info-11 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 Jul 2012 09:45:22 -0000 (added the TLS working group to share the review feedback) Hi Ondrej,=20 thanks for your feedback. > What I found to to be missing is an example or use-case that would = illustrate > what the extension is good for. Basically an extended version of what = you were > talking about during your tls session presentation. >=20 > For example, it could look like (if I understood correctly): >=20 > 1. Bootstrap: the client does the "usual" TLS handshake, stores the > certificates and/or their hashes >=20 > 2. On each subsequent connection, the client uses the new extension to = say > that it knows about one specific chain >=20 > 3. In case the chain changes, the client does full regular handshake = (i.e. goto 1) >=20 In can add text as you suggested.=20 > Question regarding this paragraph: >=20 > When the CachedInformationType identifies a certificate_chain, then > the hash_value field MUST include a hash calculated over the > certificate_list element of a server side Certificate message, > excluding the three length bytes of the certificate_list vector. >=20 > My interpretation: the hash is computed over the chain retrieved from > handshake (i.e. excluding any "possible fancy validation-path-building = code" > at the client's side) The hash is only computed over the message structures and not over any = code.=20 Did I understood your concern correctly?=20 >=20 > Question about "trusted_cas" and the trust anchors' fingerprint: I = can't > figure out what it is supposed to accomplish from the draft. TLS exchanges different payloads and some of them could be larger (and = they rarely change) and there it makes sense to only exchange a hash = over them and to send the hash instead of repeatedly sending the value. = Bob, in his review, noted that there are a few extensions being = developed that could also benefit from this cached extension = functionality, such as draft-pettersen-tls-ext-multiple-ocsp.=20 Ciao Hannes >=20 > If you'd like we could discuss it today (Thursday). >=20 >=20 > Ondrej > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) >=20 > iQEcBAEBAgAGBQJPc5fTAAoJEAy6xNgMZCEgTj4H/1yf2sytbkm475n8XLUKuSBy > Y6QG3+T3MNgjDb09GVj16sNsmE0DstGNsyilytJfSwSIZTVhKY7GxKn0M14wVijs > sqHT7B/haKveE1dDTK7NyTRB0Kcq43FQEb4bfInAWl0NE7z3tGmV971tPcTPfBlj > QUJ4WYTO8R8CHZ+eXv/v5JHt8aOZNeEn4BNfQ3XEihGzLvOGd2ZMV7HMx6N7UX9U > 1kpmnAx4YusUzWIMUOp/LvsJpr0b/YdSlHw8JtZkKxC2vyR0vEV+ItXUVHrXjovQ > w118+6gD/dNPq4VZ0BsFAIOqpotUoVAMbqAmzwmuDP108Ct3Sxn3KbHov1/JLWc=3D > =3DKd+Z > -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Fri Jul 13 03:39: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 38A1F21F86B8 for ; Fri, 13 Jul 2012 03:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 v-ROq-lbVU2f for ; Fri, 13 Jul 2012 03:39:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E2F2C21F8628 for ; Fri, 13 Jul 2012 03:39:07 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 10:39:42 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp012) with SMTP; 13 Jul 2012 12:39:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX199pW0IJVp9ucgrp41CY5xbKw0xyUwZwx4mY8/eWw 7xPYZB1dVzaBQ5 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <1E0BC1E0-37FA-4B7A-B35B-5353FC13BA50@gmx.net> Date: Fri, 13 Jul 2012 13:39:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1E0BC1E0-37FA-4B7A-B35B-5353FC13BA50@gmx.net> To: tls@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: Re: [TLS] TLS Cached Information Extension: Hash Algorithm Indication 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 Jul 2012 10:39:09 -0000 I made a minor mistake below: The suggestion was to re-use the Named = Information (ni) URI and not the Human-speakable (nih) URI format. An = example for such a URI is = ni:///sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk (taken from http://tools.ietf.org/html/draft-farrell-decade-ni-09) On Jul 13, 2012, at 12:35 PM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > I went through the review comments in an attempt to compile a new = draft version by the deadline.=20 >=20 > Ekr explained me that the issue of hash algorithm negotiation had been = discussed in the past already and it was decided not to provide support = for it.=20 >=20 > I don't have hash algorithm negotiation in the -11 version of the = draft and so I will also not add it. >=20 > Version -11 did, however, define a hash algorithm registry and Sean = asked why I am not re-using the TLS hash algorithm registry, see = http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-para= meters-17, and to use it in the newly defined field. Rob raised a = related question and suggested to re-use Stephen Farrell's work on = draft-farrell-decade-ni [1], which also seemed like a good fit.=20 >=20 > We would need to make a decision about the direction we should go with = the indication of the hash algorithm. There are at least four options: >=20 > 1) No indication. Just the hash is exchanged without an indication of = the hash algorithm being used.=20 > 2) The hash algorithm is indicated in a newly defined field and a new = hash algorithm registry is defined in the document. This is the approach = currently used in version -11 of the draft.=20 > 3) The hash algorithm is indicated in a newly defined field but the = existing TLS hash algorithm registry is re-used.=20 > 4) We use Stephen Farrell's work and use the nih URI scheme. =20 >=20 > I think #3 and #4 are good approaches; I have a slight preference for = #4. >=20 > What are your thoughts?=20 >=20 > Ciao > Hannes >=20 From hannes.tschofenig@gmx.net Fri Jul 13 04:44: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 3925721F8742 for ; Fri, 13 Jul 2012 04:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 3jh4WvjxIlMb for ; Fri, 13 Jul 2012 04:44:10 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 851AD21F8720 for ; Fri, 13 Jul 2012 04:44:09 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2012 11:44:40 -0000 Received: from unknown (EHLO [10.255.128.232]) [194.251.119.201] by mail.gmx.net (mp072) with SMTP; 13 Jul 2012 13:44:40 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18IMM1gJ7YINALtu/hncqGOgghcoHq/LGRC6jwcsB QtI0Pj+b1ZqJOr Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4FFEC9C3.8050108@gridmerge.com> Date: Fri, 13 Jul 2012 14:44:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> <4FFEC9C3.8050108@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org, core Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: My summary 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 Jul 2012 11:44:10 -0000 Hi Robert,=20 I am not changing the paradigm that the server asks the client for a = certificate. It still does.=20 What I had proposed is to include information that allows the server to = ask for something that the client actually has given that we now include = support for different certificate types, a feature that was not = previously available.=20 So, in your example below a client cannot say that he has a raw public = key for client authentication but not an X.509 certificate.=20 Ciao Hannes On Jul 12, 2012, at 3:57 PM, Robert Cragie wrote: > Hi Hannes, >=20 > The only one thing I am not sure about is the necessity for cert-send. = This is because traditionally the server makes the decision on whether = to request a certificate from the client and would not know a priori = whether the client supports it. That's not to say it isn't a good idea = though. >=20 > On that basis, I would modify the exchange slightly - see below. >=20 > Robert >=20 > I use three types of indications in the message exchange below for = improved clarity, namely: >=20 > (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the = meaning: "I accept certificate of the following types (value-1, ..., = value-n) if you send them to me." The list is ordered by preference. >=20 > (b) 'cert-info=3Dvalue' with the meaning: "The certificate payload in = this message contains a certificate of the following type". >=20 > I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) >=20 > client_hello, > cert-receive=3D(Raw, X.509) -> // (1) >=20 > <- server_hello, > cert-info=3DRaw, // (2) > certificate, // (3) > server_key_exchange, > server_hello_done >=20 > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 > Legend: >=20 > (1) The client accepts reception of X.509 certs and raw public keys, = preferring raw public keys. > (2) The server decides to sends his raw public key and indicates this = in the cert-info field. > (3) The server certificate payload contains the raw public key. >=20 > II) Client and Server use Raw Public Keys (the smart object use case - = CORE working group) >=20 >=20 > client_hello, > cert-receive=3D(Raw) -> // (1) >=20 > <- server_hello, > cert-info=3DRaw,// (2) > certificate, // (3) > certificate_request, // (4) > cert-receive=3D(Raw) // (5) > server_key_exchange, > server_hello_done >=20 > cert-info=3DRaw, // (6) > certificate, // (7) > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 >=20 > Legend: >=20 > (1) The client accepts reception of raw public keys. > (2) The server decides to sends his raw public key and indicates this = in the cert-info field. > (3) The server certificate payload contains the raw public key. > (4) The server wants to use client authentication and and sends a = certificate-request. > (5) The server accepts reception of raw public keys. > (6) The client indicates that the certificate payload contains a raw = public key. > (7) The client certificate payload contains the raw public key. >=20 > III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >=20 > client_hello, > cert-receive=3D(X.509, Raw) -> // (1) >=20 > <- server_hello, > cert-info=3DX.509,// (2) > certificate, // (3) > certificate_request, // (4) > cert-receive=3D(Raw) // (5) > server_key_exchange, > server_hello_done >=20 > cert-info=3DRaw, // (6) > certificate, // (7) > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 > Legend: >=20 > (1) Client accepts to receive X.509 certs and raw public keys, = preferring X.509 certs. (Could also be X.509 only in this example) > (2) The server decides to sends his X.509 cert and indicates this in = the cert-info field. > (3) The server certificate payload contains the X.509 cert. > (4) The server wants to use client authentication and sends a = certificate-request. > (5) The server accepts reception of raw public keys. > (6) The client indicates that the certificate payload contains a raw = public key. > (7) The client certificate payload contains the raw public key. >=20 >=20 >=20 >=20 > On 12/07/2012 8:54 AM, Hannes Tschofenig wrote: >> Hi Erk, Hi Robert, Hi Nikos, >>=20 >> thanks for your quick response. Here is an attempt to summarize your = input. >>=20 >> -------- >>=20 >> I use three types of indications in the message exchange below for = improved clarity, namely: >>=20 >> (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the = meaning: "I accept certificate of the following types (value-1, ..., = value-n) if you send them to me." The list is ordered by preference. >>=20 >> (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: = "I could send you certificate of the following types (value-1, ..., = value-n) if you ask." The list is ordered by preference. >>=20 >> (c) cert-info=3D(value) with the meaning: "The certificate payload in = this message contains a certificate of the following type". >>=20 >> I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) >>=20 >> client_hello, >> cert-receive=3D(Raw, X.509) // (1) >> cert-send=3D() -> // (2) >>=20 >> <- server_hello, >> cert-info=3D(Raw),// (3) >> certificate, // (4) >> server_key_exchange, >> server_hello_done >>=20 >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >> Legend: >>=20 >> (1) Client accepts to receive two types of certificates, preferring = raw public keys. >> (2) The client does not have a raw public key nor an X.509 = certificate for client authentication. >> (3) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (4) The certificate payload contains the raw public key. >>=20 >> II) Client and Server use Raw Public Keys (the smart object use case = - CORE working group) >>=20 >>=20 >> client_hello, >> cert-receive=3D(Raw) // (1) >> cert-send=3D(Raw) -> // (2) >>=20 >> <- server_hello, >> cert-info=3D(Raw),// (3) >> certificate, // (4) >> certificate_request, // (5) >> cert-receive=3D(Raw) // (6) >> server_key_exchange, >> server_hello_done >>=20 >> cert-info=3D(Raw), // (7) >> certificate, // (8) >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >>=20 >> Legend: >>=20 >> (1) Client accepts to receive raw public keys. >> (2) The client does have a raw public key for client authentication. >> (3) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (4) The certificate payload contains the raw public key. >> (5) The server wants to use client authentication and and sends a = cert-request. >> (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)). >> (7) The client indicates that the certificate payload contains a raw = public key >> (8) Here is the payload of the certificate itself. >>=20 >> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >>=20 >> client_hello, >> cert-receive=3D(X.509, Raw) // (1) >> cert-send=3D(Raw) -> // (2) >>=20 >> <- server_hello, >> cert-info=3D(X.509),// (3) >> certificate, // (4) >> certificate_request, // (5) >> cert-receive=3D(Raw) // (6) >> server_key_exchange, >> server_hello_done >>=20 >> cert-info=3D(Raw), // (7) >> certificate, // (8) >> client_key_exchange, >> change_cipher_spec, >> finished -> >>=20 >> <- change_cipher_spec, >> finished >>=20 >> Application Data <-------> Application Data >>=20 >> Legend: >>=20 >> (1) Client accepts to receive X.509 certs and raw public keys, in = this order of preference. (Could also be X.509 only in this example) >> (2) The client does have a raw public key for client authentication. >> (3) The server decides to sends his X.509 cert and indicates this in = the cert-info field. >> (4) The certificate payload contains the X.509 cert. >> (5) The server wants to use client authentication and sends a = cert-request. >> (6) The certificate request asks for a certificate of type 'raw' = (knowing that the client supports it from (2)). >> (7) The client indicates that the certificate payload contains a raw = public key. >> (8) Here is the payload of the certificate itself. >> -------- >>=20 >> Do these indications clarify the semantic? >> I personally believe so. >>=20 >> Ciao >> Hannes >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From robert.cragie@gridmerge.com Fri Jul 13 07:06: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 78C0921F8786; Fri, 13 Jul 2012 07:06:05 -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 BtDSo9aCEDLP; Fri, 13 Jul 2012 07:06:04 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id B828121F8783; Fri, 13 Jul 2012 07:06:03 -0700 (PDT) Received: from client-86-23-114-225.brhm.adsl.virginmedia.com ([86.23.114.225] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SpgVx-0005Z3-J8; Fri, 13 Jul 2012 15:06:38 +0100 Message-ID: <50002B6E.6090806@gridmerge.com> Date: Fri, 13 Jul 2012 15:06:38 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <213AE838-274D-4809-B841-CCCC51C7B3CD@gmx.net> <4FFEC9C3.8050108@gridmerge.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090703010805090806080408" X-Authenticated-As: robert.cragie@gridmerge.com Cc: tls@ietf.org, core Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: My summary X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.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, 13 Jul 2012 14:06:05 -0000 This is a cryptographically signed message in MIME format. --------------ms090703010805090806080408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hannes, Agreed, but you are changing the knowledge the server has prior to the=20 request; I was simply questioning whether this was necessary. The server = can present a list of certificate types it accepts and the client=20 chooses one, so it is the same mechanism as the client uses initially=20 when (implicitly) requesting a certificate from the server (according to = cipher suite) and thus more balanced. Robert On 13/07/2012 12:44 PM, Hannes Tschofenig wrote: > Hi Robert, > > I am not changing the paradigm that the server asks the client for a ce= rtificate. It still does. > > What I had proposed is to include information that allows the server to= ask for something that the client actually has given that we now include= support for different certificate types, a feature that was not previous= ly available. > > So, in your example below a client cannot say that he has a raw public = key for client authentication but not an X.509 certificate. > > Ciao > Hannes > > On Jul 12, 2012, at 3:57 PM, Robert Cragie wrote: > >> Hi Hannes, >> >> The only one thing I am not sure about is the necessity for cert-send.= This is because traditionally the server makes the decision on whether t= o request a certificate from the client and would not know a priori wheth= er the client supports it. That's not to say it isn't a good idea though.= >> >> On that basis, I would modify the exchange slightly - see below. >> >> Robert >> >> I use three types of indications in the message exchange below for imp= roved clarity, namely: >> >> (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meaning= : "I accept certificate of the following types (value-1, ..., value-n) if= you send them to me." The list is ordered by preference. >> >> (b) 'cert-info=3Dvalue' with the meaning: "The certificate payload in = this message contains a certificate of the following type". >> >> I) Server uses Raw Public Keys (client authentication happens at some = other layer) (the DANE use case) >> >> client_hello, >> cert-receive=3D(Raw, X.509) -> // (1) >> >> <- server_hello, >> cert-info=3DRaw, // (2) >> certificate, // (3) >> server_key_exchange, >> server_hello_done >> >> client_key_exchange, >> change_cipher_spec, >> finished -> >> >> <- change_cipher_spec, >> finished >> >> Application Data <-------> Application Data >> >> Legend: >> >> (1) The client accepts reception of X.509 certs and raw public keys, p= referring raw public keys. >> (2) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (3) The server certificate payload contains the raw public key. >> >> II) Client and Server use Raw Public Keys (the smart object use case -= CORE working group) >> >> >> client_hello, >> cert-receive=3D(Raw) -> // (1) >> >> <- server_hello, >> cert-info=3DRaw,// (2) >> certificate, // (3) >> certificate_request, // (4) >> cert-receive=3D(Raw) // (5) >> server_key_exchange, >> server_hello_done >> >> cert-info=3DRaw, // (6) >> certificate, // (7) >> client_key_exchange, >> change_cipher_spec, >> finished -> >> >> <- change_cipher_spec, >> finished >> >> Application Data <-------> Application Data >> >> >> Legend: >> >> (1) The client accepts reception of raw public keys. >> (2) The server decides to sends his raw public key and indicates this = in the cert-info field. >> (3) The server certificate payload contains the raw public key. >> (4) The server wants to use client authentication and and sends a cert= ificate-request. >> (5) The server accepts reception of raw public keys. >> (6) The client indicates that the certificate payload contains a raw p= ublic key. >> (7) The client certificate payload contains the raw public key. >> >> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >> >> client_hello, >> cert-receive=3D(X.509, Raw) -> // (1) >> >> <- server_hello, >> cert-info=3DX.509,// (2) >> certificate, // (3) >> certificate_request, // (4) >> cert-receive=3D(Raw) // (5) >> server_key_exchange, >> server_hello_done >> >> cert-info=3DRaw, // (6) >> certificate, // (7) >> client_key_exchange, >> change_cipher_spec, >> finished -> >> >> <- change_cipher_spec, >> finished >> >> Application Data <-------> Application Data >> >> Legend: >> >> (1) Client accepts to receive X.509 certs and raw public keys, preferr= ing X.509 certs. (Could also be X.509 only in this example) >> (2) The server decides to sends his X.509 cert and indicates this in t= he cert-info field. >> (3) The server certificate payload contains the X.509 cert. >> (4) The server wants to use client authentication and sends a certific= ate-request. >> (5) The server accepts reception of raw public keys. >> (6) The client indicates that the certificate payload contains a raw p= ublic key. >> (7) The client certificate payload contains the raw public key. >> >> >> >> >> On 12/07/2012 8:54 AM, Hannes Tschofenig wrote: >>> Hi Erk, Hi Robert, Hi Nikos, >>> >>> thanks for your quick response. Here is an attempt to summarize your= input. >>> >>> -------- >>> >>> I use three types of indications in the message exchange below for im= proved clarity, namely: >>> >>> (a) 'cert-receive=3D(value-1, value-2, ..., value-n)' with the meanin= g: "I accept certificate of the following types (value-1, ..., value-n) i= f you send them to me." The list is ordered by preference. >>> >>> (b) 'cert-send=3D(value-1, value-2, ..., value-n)' with the meaning: = "I could send you certificate of the following types (value-1, ..., valu= e-n) if you ask." The list is ordered by preference. >>> >>> (c) cert-info=3D(value) with the meaning: "The certificate payload in= this message contains a certificate of the following type". >>> >>> I) Server uses Raw Public Keys (client authentication happens at some= other layer) (the DANE use case) >>> >>> client_hello, >>> cert-receive=3D(Raw, X.509) // (1) >>> cert-send=3D() -> // (2) >>> >>> <- server_hello, >>> cert-info=3D(Raw),// (3) >>> certificate, // (4) >>> server_key_exchange, >>> server_hello_done >>> >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> Legend: >>> >>> (1) Client accepts to receive two types of certificates, preferring r= aw public keys. >>> (2) The client does not have a raw public key nor an X.509 certificat= e for client authentication. >>> (3) The server decides to sends his raw public key and indicates this= in the cert-info field. >>> (4) The certificate payload contains the raw public key. >>> >>> II) Client and Server use Raw Public Keys (the smart object use case = - CORE working group) >>> >>> >>> client_hello, >>> cert-receive=3D(Raw) // (1) >>> cert-send=3D(Raw) -> // (2) >>> >>> <- server_hello, >>> cert-info=3D(Raw),// (3) >>> certificate, // (4) >>> certificate_request, // (5) >>> cert-receive=3D(Raw) // (6) >>> server_key_exchange, >>> server_hello_done >>> >>> cert-info=3D(Raw), // (7) >>> certificate, // (8) >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> >>> Legend: >>> >>> (1) Client accepts to receive raw public keys. >>> (2) The client does have a raw public key for client authentication. >>> (3) The server decides to sends his raw public key and indicates this= in the cert-info field. >>> (4) The certificate payload contains the raw public key. >>> (5) The server wants to use client authentication and and sends a cer= t-request. >>> (6) The certificate request asks for a certificate of type 'raw' (kno= wing that the client supports it from (2)). >>> (7) The client indicates that the certificate payload contains a raw = public key >>> (8) Here is the payload of the certificate itself. >>> >>> III) Hybrid Scenario (the OAuth Holder-of-the-Key Use case) >>> >>> client_hello, >>> cert-receive=3D(X.509, Raw) // (1) >>> cert-send=3D(Raw) -> // (2) >>> >>> <- server_hello, >>> cert-info=3D(X.509),// (3) >>> certificate, // (4) >>> certificate_request, // (5) >>> cert-receive=3D(Raw) // (6) >>> server_key_exchange, >>> server_hello_done >>> >>> cert-info=3D(Raw), // (7) >>> certificate, // (8) >>> client_key_exchange, >>> change_cipher_spec, >>> finished -> >>> >>> <- change_cipher_spec, >>> finished >>> >>> Application Data <-------> Application Data >>> >>> Legend: >>> >>> (1) Client accepts to receive X.509 certs and raw public keys, in thi= s order of preference. (Could also be X.509 only in this example) >>> (2) The client does have a raw public key for client authentication. >>> (3) The server decides to sends his X.509 cert and indicates this in = the cert-info field. >>> (4) The certificate payload contains the X.509 cert. >>> (5) The server wants to use client authentication and sends a cert-re= quest. >>> (6) The certificate request asks for a certificate of type 'raw' (kno= wing that the client supports it from (2)). >>> (7) The client indicates that the certificate payload contains a raw = public key. >>> (8) Here is the payload of the certificate itself. >>> -------- >>> >>> Do these indications clarify the semantic? >>> I personally believe so. >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > --------------ms090703010805090806080408 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBBkwggQVAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggJFMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxMzE0MDYzOFowIwYJKoZI hvcNAQkEMRYEFGdmep9ouLVOK5OG75h2O+bxZaFeMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZI AWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgbkGCSsGAQQBgjcQBDGBqzCBqDCB kzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f 2nTvZjCBuwYLKoZIhvcNAQkQAgsxgauggagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwDQYJKoZIhvcNAQEBBQAEggEAdXqE rDMkXDBVxL4xEzg6okJO+9Bh3yqTzrFlVvbtwPxG8njFOcChV52/PLVGuElFSlWCVRdmGVIZ iqbJNGVM3FO+nNMajSsgtslmTBUmnT1ihgr2AqOtVlZNzz/es9WsXeC7p+L+pPWeL20Lfu9t 9DuM3uznRFboshwdS7pBRIqGfm/ayx28eZuQDH5mAcDl25h9srL4Mq2M5hpfcNj4k3Z9Qpjg Byj4JD2/UcdLbBirC+HpgQFauJJUkeZgD/SCFKDRFH9cyn/hhs8ebtqcL1m2nUEH9968Lfyq oaXS3AoMWf23VoGy1Y6Ef+MAF64T1gFLO4snK8v6sIu51GzgPgAAAAAAAA== --------------ms090703010805090806080408-- From internet-drafts@ietf.org Mon Jul 16 09:30: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 9943911E80B5; Mon, 16 Jul 2012 09:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 BIFqeORXYmle; Mon, 16 Jul 2012 09:30:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731D611E80BC; Mon, 16 Jul 2012 09:30:26 -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.30p3 Message-ID: <20120716163026.30359.65042.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 09:30:26 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-04.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, 16 Jul 2012 16:30:27 -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 Group of= the IETF. Title : Out-of-Band Public Key Validation for Transport Layer Se= curity Author(s) : Paul Wouters John Gilmore Samuel Weiler Tero Kivinen Hannes Tschofenig Filename : draft-ietf-tls-oob-pubkey-04.txt Pages : 12 Date : 2012-07-16 Abstract: This document specifies a new 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. This document introduces the support for raw public keys in TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 16 09:33: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 CD2AE11E8087; Mon, 16 Jul 2012 09:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 vKpMjcT96K4I; Mon, 16 Jul 2012 09:33:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0BAB11E80D5; Mon, 16 Jul 2012 09:33:30 -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.30p3 Message-ID: <20120716163330.2961.55975.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 09:33:30 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-cached-info-12.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, 16 Jul 2012 16:33:33 -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 Group of= the IETF. Title : Transport Layer Security (TLS) Cached Information Extens= ion Author(s) : Stefan Santesson Hannes Tschofenig Filename : draft-ietf-tls-cached-info-12.txt Pages : 16 Date : 2012-07-16 Abstract: Transport Layer Security (TLS) handshakes often include fairly static information, such as the server certificate and a list of trusted Certification Authorities (CAs). This information can be of considerable size, particularly if the server certificate is bundled with a complete certificate path (including all intermediary certificates up to the trust anchor public key). This document defines an extension that omits the exchange of already available information. The TLS client informs a server of cached information, for example from a previous TLS handshake, allowing the server to omit the already available information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-cached-info There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-cached-info-12 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-cached-info-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From d.sturek@att.net Mon Jul 16 10:49: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 20BA311E823E for ; Mon, 16 Jul 2012 10:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.895 X-Spam-Level: X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=-1.552, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 7KEnEjOpk4Sm for ; Mon, 16 Jul 2012 10:49:23 -0700 (PDT) Received: from nm28.access.bullet.mail.sp2.yahoo.com (nm28.access.bullet.mail.sp2.yahoo.com [98.139.44.155]) by ietfa.amsl.com (Postfix) with SMTP id 8AA7911E8158 for ; Mon, 16 Jul 2012 10:49:23 -0700 (PDT) Received: from [98.139.44.100] by nm28.access.bullet.mail.sp2.yahoo.com with NNFMP; 16 Jul 2012 17:50:06 -0000 Received: from [98.139.44.90] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 16 Jul 2012 17:50:06 -0000 Received: from [127.0.0.1] by omp1027.access.mail.sp2.yahoo.com with NNFMP; 16 Jul 2012 17:50:06 -0000 X-Yahoo-Newman-Id: 416322.22997.bm@omp1027.access.mail.sp2.yahoo.com Received: (qmail 97468 invoked from network); 16 Jul 2012 17:50:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1342461005; bh=BubFqD5KmD2FyQsqSMatb3z/Ophg0Fsnwg5BgPukPX8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:Mime-version:Content-type; b=z2lBG8lav1wXUsx/auBPNRJOwCEPr94b5x+jvU5cFOUU3XRQxqDYl1uLgbjgMxHNA2fKAul9Hu7Kha9lCpS1t0clvyizU8B7Oa0QiBdPhrcz9JJ0+OHGyiJyVwElc2sSHFsGJ958tZEgNW5RFgub7Z0AUEcMIsCKD9nBwEdTBCw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zW0zxMsVM1kOk9kcKS23W2KsNCahnxn1sNF.TDWw5WO04oq W3CTPV9C3m_wpYHc_dLM8uZmDu8ZnQXu2rDSFPvwYCZJGza8MftuOp8QagcP bsa41SkYypD_LaTc.3aKG2o5LpxoU4OsZUvvSZ2nfZS.ezDx2gCV0oNcQ7ZB iVU_wKwOxRNWIPLlJD7Cmkda9m7XJYcRAQiZJqu_ZbTMS.QDJCa7XtY22cFh XnGiT0OXEIFUYndsqlRNLFExL8U1Z0kqduLvq2ZZZRNRIpDF.CQIpvYtWIn3 dBx9GW5jGOg1NGklM4nymCJfHltV42QGo72ggTn6yIqUPt7IzyDmt8UXACBG pn2y3LhI.Uf_FnE1w.4lv9jpP0x4cfEONqAO.Tj1vc_irLbyAQD0axKnv0nI Ft.sd2Godn3T3nNwI_9dVdH1wUg_HY1AB6bjErAdlpy9hcSES0CPtUiiYFoc ave524rGjbNYcIJGii5tMS1btB_KCipNX1jwxxC2kMd2F_7BgQ4VffMfVyP0 ljAe3U07RuoyGBCDRiMvx7NFIwuF4nRTO0ugTQQ-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.105] (d.sturek@66.27.60.174 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 16 Jul 2012 10:50:05 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 16 Jul 2012 10:50:03 -0700 From: Don Sturek To: Message-ID: Thread-Topic: IANA Considerations Section for draft-mcgrew-tls-aes-ccm-ecc Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3425280605_127209" Subject: [TLS] IANA Considerations Section for draft-mcgrew-tls-aes-ccm-ecc 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 Jul 2012 17:49:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3425280605_127209 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Here is a link to the latest draft: http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/ In the latest draft, the IANA Considerations section states that IANA has assigned values for the Ciphersuites in Section 2, though section 2 lists the values as TBD. We are using this draft and the Ciphersuites identified in Section 2 do not have assigned values. It would be worthwhile to have the draft updated to note the need in IANA assigned numbers for the Ciphersuites. Don Sturek --B_3425280605_127209 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Here is a link to the latest= draft:    http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc= /

In the latest draft, the IANA Considerations = section states that IANA has assigned values for the Ciphersuites in Section= 2, though section 2 lists the values as TBD.

We ar= e using this draft and the Ciphersuites identified in Section 2 do not have = assigned values.

It would be worthwhile to have the= draft updated to note the need in IANA assigned numbers for the Ciphersuite= s.

Don Sturek






--B_3425280605_127209-- From d3e3e3@gmail.com Mon Jul 16 21:25: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 79DFE21F8559 for ; Mon, 16 Jul 2012 21:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.511 X-Spam-Level: X-Spam-Status: No, score=-103.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 Htb1tV6ky3Xd for ; Mon, 16 Jul 2012 21:25:11 -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 59DE321F8551 for ; Mon, 16 Jul 2012 21:25:11 -0700 (PDT) Received: by yenq13 with SMTP id q13so6310068yen.31 for ; Mon, 16 Jul 2012 21:25:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=bPKIt9vOPL5v0/vV0lB7Kl47ozdD72xdrMR8ggzgioE=; b=KIwTsq4tf/KLv3ktJWA14wqCK3SbFTm7/qT4GX9DRQk3JZvitbpqUo0A/fJ4ZDtTdn Z5SQ/eZjcxbwPmsiphdYy/wNPj8s3eyTyNlkBVMxGyk51dNIpzhbLBBLZFiDX1731qgW uWIZ9YoA26s81S2kIthCBgWoQCwJ12VyS1N2OsibacKE0GzgyqrxryUiT8aVIXeQKsCI lnz+KJSx5j7bD34miJ7pk9w2iZeZsOmZuKKTFCf9esROVW6sRoO7e5b/JMaNC8beBNMF rQkQhlKh4aB/eFC+cLYQUgi5rEiLwneiAjRmcUM4k1ztm+pNvVD7/XlEKzF01SDO5gCX N3Jw== Received: by 10.50.34.200 with SMTP id b8mr193343igj.50.1342499157433; Mon, 16 Jul 2012 21:25:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.16.227 with HTTP; Mon, 16 Jul 2012 21:25:37 -0700 (PDT) In-Reply-To: <20120713041013.18B35B1E003@rfc-editor.org> References: <20120713041013.18B35B1E003@rfc-editor.org> From: Donald Eastlake Date: Tue, 17 Jul 2012 00:25:37 -0400 Message-ID: To: stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com, bradford.wetmore@oracle.com, tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 18 Jul 2012 08:13:13 -0700 Subject: Re: [TLS] [Technical Errata Reported] RFC6066 (3283) 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 Jul 2012 04:25:12 -0000 I believe this Errata is correct. The words "more than" should not be there in the appendix. I would guess that at one point it said "no more than one" and somehow, in changing to "only one", it got garbled. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com On Fri, Jul 13, 2012 at 12:10 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC6066, > "Transport Layer Security (TLS) Extensions: Extension Definitions". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6066&eid=3283 > > -------------------------------------- > Type: Technical > Reported by: Brad Wetmore > > Section: Appendix A > > Original Text > ------------- > Appendix A: The Server Name extension...(deleted)... It is provided that the ServerNameList can contain more than only one name of any particular name_type. > > Corrected Text > -------------- > Appendix A: The Server Name extension...deleted..It is provided that the ServerNameList can contain only one name of any particular name_type. > > Notes > ----- > Section 3 and Appendix A seem to be conflict with each other. Am I parsing something incorrectly here: > > Section 3: The ServerNameList MUST NOT contain more than one name of the same name_type. > > Appendix A: The Server Name extension...deleted..It is provided that the ServerNameList can contain more than only one name of any particular name_type. > > I think the words "more than" were not supposed to appear in the final RFC. > > 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. > > -------------------------------------- > RFC6066 (draft-ietf-tls-rfc4366-bis-12) > -------------------------------------- > Title : Transport Layer Security (TLS) Extensions: Extension Definitions > Publication Date : January 2011 > Author(s) : D. Eastlake 3rd > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG From jsalowey@cisco.com Wed Jul 18 09:03: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 C7A7B21F8675 for ; Wed, 18 Jul 2012 09:03:41 -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 NLwcUWhpv3kB for ; Wed, 18 Jul 2012 09:03:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1210221F8717 for ; Wed, 18 Jul 2012 09:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=793; q=dns/txt; s=iport; t=1342627472; x=1343837072; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=TkVLQT+ylA6MHhiliNRl2vsTm3ij8t1JU93tl1RZz14=; b=THKj3hE/RCOV2QQmUT9uGZafay25zjTDYOAV1/7P2ToAX45+rrN838M1 3JlwlbCnuR4cpY53Ij+Zac/x9jL3Sj4BreKdq/ql3pAYM6fjUF+iRqOFK PRlzCB4r1zJjIZsrHn7mWTrp72J844ADoEAgWUKS+FE/sBpeLgJOnId4x 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADzeBlCtJXG+/2dsb2JhbABFuTOBB4InEgEnUQE+QicENYdrC5xUgSigI4tAhW9gA5VEgRONEIFmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,610,1336348800"; d="scan'208";a="103111063" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2012 16:04:31 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6IG4VYv023575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Jul 2012 16:04:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 11:04:31 -0500 From: "Joseph Salowey (jsalowey)" To: "tls@ietf.org" Thread-Topic: TLS Draft meeting agenda IETF-84 Thread-Index: AQHNZP8EvfaegYH8jEmF1oMRZwTBMQ== Date: Wed, 18 Jul 2012 16:04:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.174] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19048.005 x-tm-as-result: No--19.416100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0266FBF431A43D43A8453A7CFD1B4AD8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS Draft meeting agenda IETF-84 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 Jul 2012 16:03:42 -0000 Draft agenda is uploaded, copied below for your convenience.=20 Joe IETF-84 TLS Meeting Tuesday, July 31, 2012 - 1030-1130 ---------------------------------- 1. Note Well, Agenda, Note Takers, Blue sheets (5 Min) 2. Out-of-band public key validation (15 Min) - Tschofenig http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 3. Cached Info (15 Min) - Tschofenig http://tools.ietf.org/html/draft-ietf-tls-cached-info-12 4. Certificate Status Extension (5 Min) - Pettersen http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01 5. Version Rollback (10 min) - Pettersen http://tools.ietf.org/id/draft-pettersen-tls-version-rollback-removal-00.tx= t 6. Dragonfly/TLS-PWD update (5 Min) - Harkins http://tools.ietf.org/id/draft-harkins-tls-pwd-02.txt From turners@ieca.com Wed Jul 18 14:12: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 317EF11E8162 for ; Wed, 18 Jul 2012 14:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, 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 SXXwHlLshaar for ; Wed, 18 Jul 2012 14:12:40 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [70.85.130.22]) by ietfa.amsl.com (Postfix) with ESMTP id 9158411E8095 for ; Wed, 18 Jul 2012 14:12:40 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 2B862B9071452; Wed, 18 Jul 2012 16:13:32 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 1AA0FB9071401 for ; Wed, 18 Jul 2012 16:13:32 -0500 (CDT) Received: from [71.191.15.186] (port=46289 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SrbYp-00056G-BC; Wed, 18 Jul 2012 16:13:31 -0500 Message-ID: <500726FA.8080807@ieca.com> Date: Wed, 18 Jul 2012 17:13:30 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Don Sturek References: 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: (thunderfish.local) [71.191.15.186]:46289 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] IANA Considerations Section for draft-mcgrew-tls-aes-ccm-ecc 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 Jul 2012 21:12:41 -0000 On 7/16/12 1:50 PM, Don Sturek wrote: > Here is a link to the latest draft: > http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/ > > In the latest draft, the IANA Considerations section states that IANA > has assigned values for the Ciphersuites in Section 2, though section 2 > lists the values as TBD. > > We are using this draft and the Ciphersuites identified in Section 2 do > not have assigned values. > > It would be worthwhile to have the draft updated to note the need in > IANA assigned numbers for the Ciphersuites. > > Don Sturek Don, There's a couple of more steps before IANA registers the #s ;) I'll circle back with the authors to make sure all the outstanding issues are addressed. spt From jsalowey@cisco.com Wed Jul 25 22:38: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 4E57521F86DD for ; Wed, 25 Jul 2012 22:38:23 -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 KLRYSGfK83DJ for ; Wed, 25 Jul 2012 22:38:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE8B21F86DC for ; Wed, 25 Jul 2012 22:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1170; q=dns/txt; s=iport; t=1343281099; x=1344490699; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=JcRgWEWRFNiloDWgoB7mGFyiEMHPIB1wtsDGMpN+5XQ=; b=KYBDzu1pXFeKj/eJLRC7zXeyxPoWZJZTIk9cHLndhlw9VsvcUQJIi2UV jQLnW7FLIHMrr51JdExCtCYOoJWudYLwsUS/lVqkvf7YATEvz1UwFmwT1 EIkNOPSB7SV65LC9drwE9QR4B3ztiMAabqAPHF+7h9NaQIu+MkfqVcc5M s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADDXEFCtJXG+/2dsb2JhbABFuUaBB4InEgEnUQE+QicENYdrC5lugSigUotNhhRgA5VIgRSNE4Fmgl+BWCM X-IronPort-AV: E=Sophos;i="4.77,657,1336348800"; d="scan'208";a="105466907" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 26 Jul 2012 05:38:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6Q5cIac027968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Jul 2012 05:38:18 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 00:38:18 -0500 From: "Joseph Salowey (jsalowey)" To: "tls@ietf.org" Thread-Topic: Revised agenda for IETF 84 Thread-Index: AQHNavDclmv8D+O3lE6zzAfMu68A7Q== Date: Thu, 26 Jul 2012 05:38:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.93] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.004 x-tm-as-result: No--24.577100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <891038A59ACC874DA900ED53BD2B40AD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Revised agenda for IETF 84 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 Jul 2012 05:38:25 -0000 A revised agenda is posted (and copied below). We have a very full agenda.= I'm looking for a note taker and Jabber scribe so we can skip the usual s= ilence and inevitable arm twisting part at the beginning of the meeting, vo= lunteers? Also please send me any presentations you have as soon as possib= le. =20 Thanks, Joe IETF-84 TLS Meeting Tuesday, July 31, 2012 - 1030-1130 ---------------------------------- 1. Note Well, Agenda, Note Takers, Blue sheets (1 Min) 2. Out-of-band public key validation (20 Min) - Wouters http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 3. Cached Info (10 Min) - Tschofenig http://tools.ietf.org/html/draft-ietf-tls-cached-info-12 4. Certificate Status Extension (2 Min) - Pettersen/Chairs http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01 5. Version Rollback (15 min) - Pettersen/Rescorla/Langley http://tools.ietf.org/id/draft-pettersen-tls-version-rollback-removal-00.tx= t 6. Dragonfly/TLS-PWD update (2 Min) - Harkins http://tools.ietf.org/id/draft-harkins-tls-pwd-02.txt 7. TLS Proxy - Nir (10 Min) http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01= From Michael.Staubermann@webolution.de Thu Jul 26 00:30: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 CEABE21F865F for ; Thu, 26 Jul 2012 00:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449] 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 jmv4EPk0lVLU for ; Thu, 26 Jul 2012 00:30:43 -0700 (PDT) Received: from mail.webolution.de (mail.webolution.de [80.152.246.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B821F85D8 for ; Thu, 26 Jul 2012 00:30:43 -0700 (PDT) Received: from staubermann.webolution.de ([192.168.168.32] helo=StaubermannPC) by mail.webolution.de with esmtp (Exim 4.69) (envelope-from ) id 1SuIWt-0001h6-Is; Thu, 26 Jul 2012 09:30:40 +0200 From: "Michael Staubermann" To: "'Johannes Merkle'" , References: <4FF6A52F.1030308@secunet.com> In-Reply-To: <4FF6A52F.1030308@secunet.com> Date: Thu, 26 Jul 2012 09:31:01 +0200 Message-ID: <05ec01cd6b00$9e76f2e0$db64d8a0$@Staubermann@webolution.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1bU32GodjG0fSkQky+sb7dzxgCggPpi5XQ Content-Language: de X-SA-Exim-Connect-IP: 192.168.168.32 X-SA-Exim-Mail-From: Michael.Staubermann@webolution.de X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on mail.webolution.de) Subject: Re: [TLS] Using ECC Brainpool curves with TLS 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 Jul 2012 07:30:44 -0000 Hello, i see the need for additional named ECC Curves like Brainpool Curves within the next months. Therefore it makes sense have NamedCurves for ECC Curves currently not present in RFC5639. What is unclear to me is, why the decision was taken to have an additional NamedCurve IANA assigned Registry for TLS, while RFC5480 (2.1.1.1) and RFC5753 (e.g. 3.1.1) already use namedCurves with ObjectIdentifiers. Was the intention to select a "more secure" recommended subset or "only" to have a compact representation for the identifiers (instead of ASN.1 BER Encoded OIDs)? >From RFC4492: struct { ECCurveType curve_type; select (curve_type) { case explicit_prime: opaque prime_p <1..2^8-1>; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case explicit_char2: uint16 m; ECBasisType basis; select (basis) { case ec_trinomial: opaque k <1..2^8-1>; case ec_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case named_curve: NamedCurve namedcurve; }; } ECParameters; namedcurve: Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve. Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02). >From RFC5480: ECParameters ::= CHOICE { namedCurve OBJECT IDENTIFIER -- implicitCurve NULL -- specifiedCurve SpecifiedECDomain } -- implicitCurve and specifiedCurve MUST NOT be used in PKIX. -- Details for SpecifiedECDomain can be found in [X9.62]. -- Any future additions to this CHOICE should be coordinated -- with ANSI X9 >From RFC5753 3.1.1: If the parameters are ECParameters, then they MUST be namedCurve. Instead of duplicating the already existing NamedCurves of the OID-Tree used in RFC5480 2.1.1.1 and RFC5753 (e.g. 3.1.1 Use of ECC Algorithms in CMS) i propose to add a new ECCurveType to the RFC4492 enum ECCurveTypes: enum { explicit_prime (1), explicit_char2 (2), named_curve (3), identified_curve (4), reserved(248..255) } ECCurveType; struct { ECCurveType curve_type; select (curve_type) { case explicit_prime: opaque prime_p <1..2^8-1>; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case explicit_char2: uint16 m; ECBasisType basis; select (basis) { case ec_trinomial: opaque k <1..2^8-1>; case ec_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; ECCurve curve; ECPoint base; opaque order <1..2^8-1>; opaque cofactor <1..2^8-1>; case named_curve: NamedCurve namedcurve; case identified_curve: opaque CurveOID<3..15> ; }; } ECParameters; Of course - for security reasons - there must be an exclusive-or for the curve_type choice in the RFC to remove reduncancy, i.e. only NamedCurve or identified_curve must be used. To answer your questions: Q1: Additionally to the above: Yes, we should have IANA Registry assigned CurveIDs for Brainpool ECC Q2: Currently RFC5639 is informational, it seems this we be sufficient. Q4: From your latest post it think it is worth to have to have to different IDs for the quadratic twisted and untwisted version (it would stretch the semantics of the point format to much to put it there) Q5: That surprises me a little bit. Shouldn't RFC 4492 be also used for DTLS? Best regards, Michael Staubermann -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Johannes Merkle Sent: Friday, July 06, 2012 10:43 AM To: tls@ietf.org Subject: [TLS] Using ECC Brainpool curves with TLS Hello all, in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile, support for these ECC Brainpool Curves has been included in some crypto libraries as openssl (recently) and crypto++. However, in order to use the Brainpool Curves with TSL (for authentication and/or key agreement), still some specifications and IANA registry updates are needed. Therefore, an RFC specifying the usage of the ECC Brainpool Curves with TLS has to be written. In order to go forward with this, we would like to discuss some questions and potential issues. We would appreciate any feedback on the following. [Question 1] According to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be shepherded by the TLS WG. Therefore, our first and most important question is: Is the WG willing to shepherd this RFC? [Question 2] What category will be preferred for this RFC, Standards Track or Informational RFC? [Question 3] Actually, we also plan to prepare analogous specifications for IKE, so an option may be to write a common RFC for TLS and IKE analogously to RFC 5114. Would this be a good idea, in particular as this would imply shepherding by two WGs, or would it be better to prepare separate RFCs for IKE and TLS? [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one being the "quadratic twist" of the other having the same algebraic structure (and hence, security level), but one of them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the implementation we propose to register IANA values (for EC Named Curve) for both curves for each bit length. Of course, this doubles the number of number assignments. Does anyone consider this a problem? [Question 5] No IANA registries are required for DTLS. However, authors have to specify whether new identifiers for TLS are suitable for DTLS as well. This should be done for the ECC Brainpool curves. Any comments on this? Johannes -- Johannes Merkle secunet Security Networks AG johannes.merkle@secunet.com www.secunet.com _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From pritikin@cisco.com Thu Jul 26 10:37: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 6E5DD21F860D for ; Thu, 26 Jul 2012 10:37:26 -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 p8Yf4hiWzYyj for ; Thu, 26 Jul 2012 10:37:25 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B1FE821F8601 for ; Thu, 26 Jul 2012 10:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pritikin@cisco.com; l=1487; q=dns/txt; s=iport; t=1343324245; x=1344533845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uH+o04iKPVKO+0syYygbRQUIXGoKBHnYsnrEqFwPNkg=; b=CJ2w4XS8GnSnN3KfpCqeekhw5UrIuhEi8cw780buGuXUEjOtsPe4iT0E p0mh/upwcULSoP2g4gFlnhUeVmYCjPh8aJiaUB0St4d5La/H6GBTDIAj9 y+NRTmf8WPspdq87Au2WJbQhwsjg9URtS2ZjlLPq9DZbqTzEBnY7fvcuK s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABd/EVCtJV2Z/2dsb2JhbABFuTmBB4IgAQEBAwEBAQEPASc0CwULAgEINhAnCyUCBA4FIodlBgubZqBJi0+GFGADlUiBFI0TgWaCX4FYIw X-IronPort-AV: E=Sophos;i="4.77,660,1336348800"; d="scan'208";a="105455073" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2012 17:37:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6QHbPHm026320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Jul 2012 17:37:25 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.117]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 12:37:24 -0500 From: "Max Pritikin (pritikin)" To: "Joseph Salowey (jsalowey)" Thread-Topic: [TLS] Revised agenda for IETF 84 Thread-Index: AQHNavDclmv8D+O3lE6zzAfMu68A7Zc8KS8A Date: Thu, 26 Jul 2012 17:37:20 +0000 Message-ID: <0DB2568C-21AC-441B-9EEF-91C2C4AB8A5F@cisco.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.21.0.162] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19064.005 x-tm-as-result: No--34.577100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <0D9099D2DE4DAC43AC835D67C293BA70@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Revised agenda for IETF 84 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 Jul 2012 17:37:26 -0000 Joe, I'll be there and can take notes if needed,=20 - max On Jul 25, 2012, at 11:38 PM, Joseph Salowey (jsalowey) wrote: > A revised agenda is posted (and copied below). We have a very full agend= a. I'm looking for a note taker and Jabber scribe so we can skip the usual= silence and inevitable arm twisting part at the beginning of the meeting, = volunteers? Also please send me any presentations you have as soon as poss= ible. =20 >=20 > Thanks, >=20 > Joe >=20 > IETF-84 TLS Meeting > Tuesday, July 31, 2012 - 1030-1130 > ---------------------------------- > 1. Note Well, Agenda, Note Takers, Blue sheets (1 Min) > 2. Out-of-band public key validation (20 Min) - Wouters > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 > 3. Cached Info (10 Min) - Tschofenig > http://tools.ietf.org/html/draft-ietf-tls-cached-info-12 > 4. Certificate Status Extension (2 Min) - Pettersen/Chairs > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-= 01 > 5. Version Rollback (15 min) - Pettersen/Rescorla/Langley > http://tools.ietf.org/id/draft-pettersen-tls-version-rollback-removal-00.= txt > 6. Dragonfly/TLS-PWD update (2 Min) - Harkins > http://tools.ietf.org/id/draft-harkins-tls-pwd-02.txt > 7. TLS Proxy - Nir (10 Min) > http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Johannes.Merkle@secunet.com Tue Jul 31 08:57: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 532E121F86BA for ; Tue, 31 Jul 2012 08:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 4rlPXFgGB9q1 for ; Tue, 31 Jul 2012 08:57:16 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB2B21F86B0 for ; Tue, 31 Jul 2012 08:57:16 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 37B2D1A007D; Tue, 31 Jul 2012 17:57:00 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 2782B1A007F; Tue, 31 Jul 2012 17:56:33 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 31 Jul 2012 17:56:47 +0200 Message-ID: <5018003F.2000701@secunet.com> Date: Tue, 31 Jul 2012 17:56:47 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Michael Staubermann References: <4FF6A52F.1030308@secunet.com> <05ec01cd6b00$9e76f2e0$db64d8a0$@Staubermann@webolution.de> In-Reply-To: <05ec01cd6b00$9e76f2e0$db64d8a0$@Staubermann@webolution.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2012 15:56:47.0486 (UTC) FILETIME=[1715B1E0:01CD6F35] Cc: tls@ietf.org Subject: Re: [TLS] Using ECC Brainpool curves with TLS 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, 31 Jul 2012 15:57:17 -0000 > i see the need for additional named ECC Curves like Brainpool Curves within > the next months. Therefore it makes sense have NamedCurves for ECC Curves > currently not present in RFC5639. Do you mean that there are further curves that need to be used? > > Instead of duplicating the already existing NamedCurves of the OID-Tree used > in RFC5480 2.1.1.1 and RFC5753 (e.g. 3.1.1 Use of ECC Algorithms in CMS) i > propose to add a new ECCurveType to the RFC4492 enum ECCurveTypes: Your idea would allow specifying in the Server KE message any curve by reference, which is much preferred over explicit specification as explicitly specified parameters require validation to prevent certain attacks. However, this would only solve part of the problem: In the client hello message, the client proposes the curves to be used in the Supported Elliptic Curve Extension (RFC 4492). Due to the missing IANA assignments for the registry namedCurve, a client can currently not propose the use of (one or several) Brainpool curves. He could use arbitrary_explicit_prime_curves and hope that the server chooses a curve acceptable for him, but if the curve chosen by the server does not meet its capabilities or policies, the client would have to end the handshake with an error alert. This is not a nice way to negotiate the parameters, and since Supported Elliptic Curve Extension is the mechanism intended for curve negotiation I would strongly advocate using this extension. This requires further assignments for namedCurve. I would very much welcome a mechanism that re-uses OIDs instead of defining (just another) identifier for each curve, but I do not see how this can be incorporated in the Supported Elliptic Curve Extension. > Of course - for security reasons - there must be an exclusive-or for the > curve_type choice in the RFC to remove reduncancy, i.e. only NamedCurve or > identified_curve must be used. Agreed. > > To answer your questions: > > Q1: Additionally to the above: Yes, we should have IANA Registry assigned > CurveIDs for Brainpool ECC For this, we need either a WG document or an AD-sponsored RFC. Given the lack of response to my posting I am not very confident about getting the WG engaged in this. > Q4: From your latest post it think it is worth to have to have to different > IDs for the quadratic twisted and untwisted version (it would stretch the > semantics of the point format to much to put it there) I agree. Furthermore, the registry has 16 bits. > Q5: That surprises me a little bit. Shouldn't RFC 4492 be also used for > DTLS? > RFC 6347 requires "When new identifiers are assigned for TLS, authors MUST specify whether they are suitable for DTLS." My preference is to allow the Brainpool curves for DTLS as well. -- Johannes From Scott@DigiCert.com Tue Jul 31 18:45: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 1613521F87F5 for ; Tue, 31 Jul 2012 18:45:01 -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 ZQWSTs6U90X6 for ; Tue, 31 Jul 2012 18:44:59 -0700 (PDT) Received: from mail.digicert.com (mail.digicert.com [64.78.193.232]) by ietfa.amsl.com (Postfix) with ESMTP id D28C321F87F3 for ; Tue, 31 Jul 2012 18:44:59 -0700 (PDT) Received: from [10.211.55.9] (unknown [64.114.255.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digicert.com (Postfix) with ESMTPSA id B9267906CAA; Tue, 31 Jul 2012 19:44:58 -0600 (MDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=digicert.com; s=mail; t=1343785499; bh=gKOV/QBF7Cl2QkuEXf7wMUfUmSXt7prR2oqKsc/3k/U=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=tMZE28EGE/53STkawlhubqa01cxlM0n7o81dx++mhszyg+vLn4v4ZU7gj/K3ca1sj HPMX7A9clgbfcxtoMoXeIB0rVNnt4vn2Ui2hGBOgi5d+IAC3p8JTDOA2/+J7wHdBzY YRk772VzAtaoj9l2IDigQkZgJBNxnavnL7OLPU28= Message-ID: <50188A16.2040604@DigiCert.com> Date: Tue, 31 Jul 2012 19:44:54 -0600 From: Scott Rea User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.4) Gecko/20120421 Thunderbird/10.0.4 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 Jul 2012 18:55:52 -0700 Subject: [TLS] RFC 6125 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, 01 Aug 2012 01:45:01 -0000 We'd like to address a few concerns with RFC 6125. Because the relevant discussion list is not active, we contacted the authors and TLS Chair who instructed us to post our concerns to this list. Our primary concern with RFC 6125 is that Wildcard certificate use is wide-spread and has proved to be a cost-effective alternative to multi-domain certificates. Asking for the deprecation of wildcard certificates undermines a lot of existing infrastructure and current establishments. We feel that RFC's current recommendations fail to adequately balance the risks and convenience of an existing practice, is based only on theoretical problems, and does not accurately reflect current industry practices or beliefs. We suggest the following changes to RFC 6125: ------- Section 1.5 - Overview of Recommendations [........Edit..................] Move away from the issuance of so-called wildcard certificates (e.g., a certificate containing an identifier for "*.example.com"). [........Replace with....] Follow the established rule set for interpreting wildcard certificates (e.g., a certificate containing an identifier for "*.example.com"). --------- Section 4.1 - Rules [........Edit..................] 7. Unless a specification that reuses this one allows continued support for the wildcard character '*', the DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, whether as the complete left-most label within the identifier (following the description of labels and domain names in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment thereof (e.g., *oo.example.com, f*o.example.com, or fo*.example.com). A more detailed discussion of so-called "wildcard certificates" is provided under Section 7.2. [........Replace with....] 7. Unless a specification that reuses this one allows continued support for the wildcard character '*', the DNS domain name portion of a presented identifier SHOULD NOT contain the wildcard character, unless the wildcard character is the complete left-most label within the identifier (following the description of labels and domain names in [DNS-CONCEPTS], e.g., "*.example.com") and ONLY a single wildcard character is present within an identifier. Wildcard characters should not be a fragment of a DNS domain name or presented identifier (e.g., *oo.example.com, f*o.example.com, or fo*.example.com). A more detailed discussion of so-called "wildcard certificates" is provided under Section 7.2. ------------ Section 7.2 - Wildcard Certificates [........Edit..................] This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). As a result, the rules provided in this document are more restrictive than the rules for many existing application technologies (such as those excerpted under Appendix B). Several security considerations justify tightening the rules: o Wildcard certificates automatically vouch for any and all host names within their domain. This can be convenient for administrators but also poses the risk of vouching for rogue or buggy hosts. See for example [Defeating-SSL] (beginning at slide 91) and [HTTPSbytes] (slides 38-40). o Specifications for existing application technologies are not clear or consistent about the allowable location of the wildcard character, such as whether it can be: * only the complete left-most label (e.g., *.example.com) * some fragment of the left-most label (e.g., fo*.example.com, f*o.example.com, or *oo.example.com) * all or part of a label other than the left-most label (e.g., www.*.example.com orwww.foo*.example.com) * all or part of a label that identifies a so-called "public suffix" (e.g., *.co.uk or *.com) * included more than once in a given label (e.g., f*b*r.example.com * included as all or part of more than one label (e.g., *.*.example.com) These ambiguities might introduce exploitable differences in identity checking behavior among client implementations and necessitate overly complex and inefficient identity checking algorithms. o There is no specification that defines how the wildcard character may be embedded within the A-labels or U-labels [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a result, implementations are strongly discouraged from including or attempting to check for the wildcard character embedded within the A-labels or U-labels of an internationalized domain name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a presented domain name identifier MAY contain the wildcard character as long as that character occupies the entire left-most label position, where all of the remaining labels are valid NR-LDH labels, A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org"). Notwithstanding the foregoing security considerations, specifications that reuse this one can legitimately encourage continued support for the wildcard character if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]). [........Replace with....] This document states that the wildcard character '*' SHOULD NOT be included in presented identifiers, except as provided for herein, but MAY be checked by application clients (mainly for the sake of backward compatibility with deployed infrastructure). As a result, the rules provided in this document are more restrictive than the rules for many existing application technologies (such as those excerpted under Appendix B). Several security considerations justify tightening the rules: o Wildcard certificates are commonly used to secure host names within a specified domain. o Some specifications for existing application technologies are not clear or consistent about the allowable location of the wildcard character, such as whether it can be: * only the complete left-most label (e.g., *.example.com) * some fragment of the left-most label (e.g., fo*.example.com, f*o.example.com, or *oo.example.com) * all or part of a label other than the left-most label (e.g., www.*.example.com orwww.foo*.example.com) * all or part of a label that identifies a so-called "public suffix" (e.g., *.co.uk or *.com) * included more than once in a given label (e.g.,f*b*r.example.com * included as all or part of more than one label (e.g., *.*.example.com) o Although there are no specifications that defines how the wildcard character may be embedded within the A-labels or U-labels [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO], the commonly accepted usage is to include the wildcard character only as the leftmost character of the domain and to use only a single wildcard character per identifier. Therefore, a presented domain name identifier MAY contain the wildcard character as long as that character occupies the entire left-most label position, where all of the remaining labels are valid NR-LDH labels, A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org"). Notwithstanding the foregoing security considerations, specifications that reuse this one can legitimately encourage continued support for uses of the wildcard character other than as described herein if they have good reasons to do so, such as backward compatibility with deployed infrastructure (see, for example, [EV-CERTS]). -------------- Appendix B-9 - SIP (2010) [........Edit..................] In 2010, [SIP-CERTS] specified the following text regarding application service identity verification in SIP: ###### 7.2. Comparing SIP Identities When an implementation (either client or server) compares two values as SIP domain identities: Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison. Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by [DNS-CASE]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of [PKIX]. Implementations MUST match the values in their entirety: Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com". Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com." [HTTP-TLS] allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". [PKIX], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. [SIP] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains. ###### [........Replace with....] In 2010, [SIP-CERTS] specified the following text regarding application service identity verification in SIP: ###### 7.2. Comparing SIP Identities When an implementation (either client or server) compares two values as SIP domain identities: Implementations MUST compare only the DNS name component of each SIP domain identifier; an implementation MUST NOT use any scheme or parameters in the comparison. Implementations MUST compare the values as DNS names, which means that the comparison is case insensitive as specified by [DNS-CASE]. Implementations MUST handle Internationalized Domain Names (IDNs) in accordance with Section 7.2 of [PKIX]. Implementations MUST match the values in their entirety: Implementations MUST NOT match suffixes. For example, "foo.example.com" does not match "example.com". Implementations MAY match wildcard character prefixes if the wildcard character is the leftmost name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. [HTTP-TLS] allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". [PKIX], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. [SIP] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document recommends using its guidelines on the presence of wildcards for SIP domains. ....... Regards, -- Scott Rea, DigiCert.