From lloyd@randombit.net Fri Nov 2 08:49:48 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501DF11E8097 for ; Fri, 2 Nov 2012 08:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.406 X-Spam-Level: X-Spam-Status: No, score=-1.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nuys9uGKBEi for ; Fri, 2 Nov 2012 08:49:47 -0700 (PDT) Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id D6E491F0C42 for ; Fri, 2 Nov 2012 08:49:47 -0700 (PDT) Received: by chihiro.randombit.net (Postfix, from userid 1000) id 806961248AFC; Fri, 2 Nov 2012 11:49:45 -0400 (EDT) Date: Fri, 2 Nov 2012 11:49:45 -0400 From: Jack Lloyd To: tls@ietf.org Message-ID: <20121102154944.GG21750@randombit.net> Mail-Followup-To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [TLS] DTLS 1.2 epoch wrap around 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, 02 Nov 2012 15:49:48 -0000 RFC 6347 section 4.1 says both "In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime." and "Similarly, implementations MUST NOT allow the epoch to wrap, but instead MUST establish a new association [...]" As best I can tell, DTLS v1.0 allows epoch wrapping modulo the MSL time limit. Is the intent to prohibit epoch wrapping in DTLS v1.2 only while allowing it in v1.0? Or are there security implications to allowing the epoch to ever wrap and it should avoided in all versions? Thanks in advance for any advice. Regards, Jack From n.mavrogiannopoulos@gmail.com Fri Nov 2 16:20:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320B811E80FC for ; Fri, 2 Nov 2012 16:20:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq1yr3JSZZxZ for ; Fri, 2 Nov 2012 16:20:37 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 50B3F11E80FF for ; Fri, 2 Nov 2012 16:20:37 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so1427530wib.13 for ; Fri, 02 Nov 2012 16:20: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:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=MPWXVqdInwFaRfJgFv6h4n51Y62O3YoWXbEJ9/OHzsg=; b=N5SGNHvVpIb/3/U5LLKtG1APA4IXjqGQKutYJVWiSKPQ6RZ7xcnjjEBWXiu6n1V/PM xJ2ZaAHZfQaRtgFBJKBaMlfXGY3ladNgjwZ9zYsyNhmUVB9q2S8UpqNeih/xNKxurTpk AA5lyMEf1gORjt+6zzrqh1qr6mFRdLvKn5k390wzuV1y4EzI8uu7XNdFj0vXcv9Q7Ym2 SFjL5jaxEI7HwcQA/pjSMkN+pSL44jmhPn4qZsC5aSMR7/aOJcU4sOh8pvsiHqeEYUYE n7Wn60hpynz22zqd/zNHIm0BVNW6E5h+eE0oL0AbYFsLjO+HL1HbMHq+oz1VcbqzwUoC Nagg== Received: by 10.216.193.136 with SMTP id k8mr1121728wen.188.1351898434380; Fri, 02 Nov 2012 16:20:34 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f1sm351379wiy.2.2012.11.02.16.20.32 (version=SSLv3 cipher=OTHER); Fri, 02 Nov 2012 16:20:33 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <5094553B.5060009@gnutls.org> Date: Sat, 03 Nov 2012 00:20:27 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: "tls@ietf.org" , John Gilmore , paul@nohats.ca, Hannes Tschofenig X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] draft-ietf-tls-oob-pubkey-06 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, 02 Nov 2012 23:20:38 -0000 Hello, I've read the new draft "Out-of-Band Public Key Validation for Transport Layer Security", and I was surprised by the approach chosen to define the new certificate type for TLS. Some background. There is already a certificate type extension in TLS, called "cert_type" defined in the RFC6091. The exact extension is copied in the "draft-ietf-tls-oob-pubkey-06" document, with a different name (called "certificate_type"), and different and incompatible certificate type assignment values. Even more it does not define the any old types from RFC6091 meaning that somebody in order to support RFC6091 and draft-ietf-tls-oob-pubkey-06 MUST support two different certificate type extensions. In the text there is no reasoning on the need of the new extension and even the reference to RFC6091 was removed (I couldn't find a discussion on the ML either). I don't want to think what it is going to happen when we have a 3rd certificate type to be defined for TLS. Do we really need a different extension for every possible certificate type? Can't we fix a single certificate type extension that will be used for all possible certificate types? As an implementer I'd like to support both openpgp and SubjectPublicKeyInfo types but the current approach chosen is really unacceptable. regards, Nikos From hannes.tschofenig@gmx.net Sat Nov 3 09:00:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0F21F9C3E for ; Sat, 3 Nov 2012 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkn1a48CV5Fa for ; Sat, 3 Nov 2012 09:00:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5ABEE21F9C43 for ; Sat, 3 Nov 2012 09:00:02 -0700 (PDT) Received: (qmail invoked by alias); 03 Nov 2012 16:00:00 -0000 Received: from unknown (EHLO [10.187.85.30]) [38.101.231.254] by mail.gmx.net (mp032) with SMTP; 03 Nov 2012 17:00:00 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+sGFFeXw2sPEwiLLd3pCLJ4aav3TqE0rHxxhB1z+ 9G3hM8Ydwc2/wE Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <5094553B.5060009@gnutls.org> Date: Sat, 3 Nov 2012 17:59:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> References: <5094553B.5060009@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "tls@ietf.org" , John Gilmore Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 16:00:03 -0000 Hi Nikos,=20 around the last IETF meeting I got feedback from the working group about = avoiding a normative reference to RFC 6091.=20 The current document version avoids that dependency. I didn't see the need to add OpenPGP support in this document.=20 Ciao Hannes On Nov 3, 2012, at 1:20 AM, Nikos Mavrogiannopoulos wrote: > Hello, > I've read the new draft "Out-of-Band Public Key Validation for > Transport Layer Security", and I was surprised by the approach chosen = to > define the new certificate type for TLS. >=20 > Some background. There is already a certificate type extension in TLS, > called "cert_type" defined in the RFC6091. The exact extension is = copied > in the "draft-ietf-tls-oob-pubkey-06" document, with a different name > (called "certificate_type"), and different and incompatible = certificate > type assignment values. Even more it does not define the any old types > from RFC6091 meaning that somebody in order to support RFC6091 and > draft-ietf-tls-oob-pubkey-06 MUST support two different certificate = type > extensions. In the text there is no reasoning on the need of the new > extension and even the reference to RFC6091 was removed (I couldn't = find > a discussion on the ML either). >=20 > I don't want to think what it is going to happen when we have a 3rd > certificate type to be defined for TLS. Do we really need a different > extension for every possible certificate type? Can't we fix a single > certificate type extension that will be used for all possible > certificate types? As an implementer I'd like to support both openpgp > and SubjectPublicKeyInfo types but the current approach chosen is = really > unacceptable. >=20 > regards, > Nikos From paul.hoffman@vpnc.org Sat Nov 3 11:13:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07AB21F8975 for ; Sat, 3 Nov 2012 11:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP5DWRikk8K4 for ; Sat, 3 Nov 2012 11:13:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 397A821F895F for ; Sat, 3 Nov 2012 11:13:42 -0700 (PDT) Received: from [192.168.65.155] ([207.239.114.206]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qA3IDYQ1087188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Nov 2012 11:13:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> Date: Sat, 3 Nov 2012 11:13:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84E3EA7E-D2F4-46CA-8F19-44BF7D519D57@vpnc.org> References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: "tls@ietf.org" , John Gilmore Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:13:42 -0000 On Nov 3, 2012, at 8:59 AM, Hannes Tschofenig = wrote: > around the last IETF meeting I got feedback from the working group = about avoiding a normative reference to RFC 6091.=20 > The current document version avoids that dependency. >=20 > I didn't see the need to add OpenPGP support in this document.=20 +1 to both statements. --Paul Hoffman= From n.mavrogiannopoulos@gmail.com Sat Nov 3 11:30: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 E03D121F9CA1 for ; Sat, 3 Nov 2012 11:30:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb8pRcciET45 for ; Sat, 3 Nov 2012 11:30:22 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 324A921F9C9B for ; Sat, 3 Nov 2012 11:30:21 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2013891eaa.31 for ; Sat, 03 Nov 2012 11:30:21 -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=gpFQjvNzF9B2udy8qcxyorxk26y+WAYIRVs17UlB2tk=; b=zjXjkyvC+lhbH/Hi/zGRy+Jq86YXY6qaAt5pRx9lw4Bg+6eBeQknle6wcgorvNA2tO bNTpWUscJMr0pS41kol/2N1XlJhj0mfaPhIwmFK6t077OzB91l/afYyorzHxj42Zuh1G fHCrRiVeSFS27o8WvSgfcDeSEa6/uKe8JAMFBuFuFd9K9HhLfi/+qAI6a+TjTj5UBitg DaEwJynIgzDd3opTz4mxaXodtk+9Kc6bKuY/PBg+1az0QyQtJ4kLYx6624eahvCLyJfE xkul30om1P5BmKx2XsmXlw8+hZwTg7KCY+sTDBwjBsmrMlAupchSZ1iy8oWD27iYQgkb popA== Received: by 10.14.193.136 with SMTP id k8mr19132515een.30.1351967421079; Sat, 03 Nov 2012 11:30:21 -0700 (PDT) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id a44sm33530676eeo.7.2012.11.03.11.30.19 (version=SSLv3 cipher=OTHER); Sat, 03 Nov 2012 11:30:20 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <509562B5.60407@gnutls.org> Date: Sat, 03 Nov 2012 19:30:13 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> In-Reply-To: <078C4585-EFCF-4871-B8AE-C5BBDDB90536@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" , John Gilmore Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:30:23 -0000 On 11/03/2012 04:59 PM, Hannes Tschofenig wrote: > Hi Nikos, > around the last IETF meeting I got feedback from the working group about avoiding a normative reference to RFC 6091. > The current document version avoids that dependency. Hello, May I ask what were the arguments for that, or it is a secret? > I didn't see the need to add OpenPGP support in this document. So the idea is to have multiple certificate type extensions for TLS? This was the meeting consensus? Why wasn't this brought up to the mailing list given that this overrides the previous consensus [0] on the mailing list? regards, Nikos [0]. http://www.ietf.org/mail-archive/web/tls/current/msg08290.html From hannes.tschofenig@gmx.net Sat Nov 3 11:59: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 169A021F9C7D for ; Sat, 3 Nov 2012 11:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gy6YNGk8FJDr for ; Sat, 3 Nov 2012 11:59:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2A12D21F9C5E for ; Sat, 3 Nov 2012 11:59:56 -0700 (PDT) Received: (qmail invoked by alias); 03 Nov 2012 18:59:55 -0000 Received: from unknown (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp016) with SMTP; 03 Nov 2012 19:59:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/ArisxxnHAcl34Qhf+0kesosCL1dcom1Bd8HDbF7 PxIaTUJTAeKiT0 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <509562B5.60407@gnutls.org> Date: Sat, 3 Nov 2012 14:58:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4CB478E7-E6DE-4CBC-A35C-4632D937E2BE@gmx.net> References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509562B5.60407@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "tls@ietf.org" , John Gilmore Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2012 18:59:58 -0000 Hi Nikos,=20 thanks for the quick response.=20 On Nov 3, 2012, at 2:30 PM, Nikos Mavrogiannopoulos wrote: > On 11/03/2012 04:59 PM, Hannes Tschofenig wrote: >=20 >> Hi Nikos,=20 >> around the last IETF meeting I got feedback from the working group = about avoiding a normative reference to RFC 6091.=20 >> The current document version avoids that dependency. >=20 >=20 > Hello, > May I ask what were the arguments for that, or it is a secret? >=20 I unfortunately missed the meeting last time so I am probably not the = best person to reflect the discussion from the meeting myself. RFC 6091is an informational RFC and would require to be upgraded to a = standards track document or a downref needs to be specified in the = tls-oob-pubkey document.=20 Dealing with such a downref to RFC 6091 would be useful if RFC 6091 = would actually be a good fit. There are two problems: 1. OpenPGP support in TLS is IMHO not deployed. =20 2. A problem I noticed with re-using RFC 6091 is that the certificate = capability indication does not allow a client to distinguish whether it = supports processing of OpenPGP certificates vs. whether it is able to = provide OpenPGP certificates. For this reason the structure is different = in draft-ietf-tls-oob-pubkey. >> I didn't see the need to add OpenPGP support in this document.=20 >=20 >=20 > So the idea is to have multiple certificate type extensions for TLS? > This was the meeting consensus? >=20 Luckily there are not that many certificate formats. If someone would = want to define a new extension then they should be using = draft-ietf-tls-oob-pubkey. > Why wasn't this brought up to the mailing list given that this = overrides > the previous consensus [0] on the mailing list? I am not the chair of the group. I let them to judge consensus in the = way they want.=20 Ciao Hannes >=20 > regards, > Nikos >=20 > [0]. http://www.ietf.org/mail-archive/web/tls/current/msg08290.html From n.mavrogiannopoulos@gmail.com Sun Nov 4 02:55:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C44621F86A5 for ; Sun, 4 Nov 2012 02:55:40 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyb0rBrogyJ0 for ; Sun, 4 Nov 2012 02:55:40 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4DE021F8653 for ; Sun, 4 Nov 2012 02:55:39 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2169552eaa.31 for ; Sun, 04 Nov 2012 02:55:39 -0800 (PST) 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=8rur0My/A8Sfcfpp14qdn56AgB1kV0SuviOApTiYng8=; b=fnyhHoPsw8YGJ3DMpoyPzY1fBnMTE7bUtuVyyzgng300haScoNKdZyRZVXwxFYyTkV Sc7vMlXM0n0Gpj0hnqJZXf4uKFdlTgXRJu4xLolKdDpXLJbAqYDNLb6vFpR2hzWtWo7b jd17PcMKW16xc4x84a7XmEiPTOIc3sLACIU9DiPJ2Bb+DR4M9qPlZ/kXkvTDWO7mC9oa 1v4IvdR2/zFVQL4vKrPHvPKe/Fo2fzxJEvHv+J+S62Crsy+X83v7HQPPqhN/0cir0AGe 0QVhIHuZi7lQS1Q0sKEzdC0oZaNgyXd6qKbMERfMmJ8Tp4P44tRuYFDkIV/Dp6iIBZkx SJGw== Received: by 10.14.219.2 with SMTP id l2mr25788535eep.3.1352026538935; Sun, 04 Nov 2012 02:55:38 -0800 (PST) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id f2sm38937328eep.2.2012.11.04.02.55.37 (version=SSLv3 cipher=OTHER); Sun, 04 Nov 2012 02:55:38 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <509649A8.7090706@gnutls.org> Date: Sun, 04 Nov 2012 11:55:36 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509562B5.60407@gnutls.org> <4CB478E7-E6DE-4CBC-A35C-4632D937E2BE@gmx.net> In-Reply-To: <4CB478E7-E6DE-4CBC-A35C-4632D937E2BE@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" , John Gilmore Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 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, 04 Nov 2012 10:55:40 -0000 On 11/03/2012 07:58 PM, Hannes Tschofenig wrote: > I unfortunately missed the meeting last time so I am probably not the best person to reflect the discussion from the meeting myself. > RFC 6091is an informational RFC and would require to be upgraded to a standards track document or a downref needs to be specified in the tls-oob-pubkey document. > Dealing with such a downref to RFC 6091 would be useful if RFC 6091 would actually be a good fit. There are two problems: > 1. OpenPGP support in TLS is IMHO not deployed. Hello, I've never done a survey on the deployment, but I trust your research. > 2. A problem I noticed with re-using RFC 6091 is that the certificate capability indication does not allow a client to distinguish whether it supports processing of OpenPGP certificates vs. whether it is able to provide OpenPGP certificates. For this reason the structure is different in draft-ietf-tls-oob-pubkey. >>> I didn't see the need to add OpenPGP support in this document. >> So the idea is to have multiple certificate type extensions for TLS? >> This was the meeting consensus? > Luckily there are not that many certificate formats. If someone would want to define a new extension then they should be using draft-ietf-tls-oob-pubkey. Shouldn't in that case the oob-pubkey draft obsolete or update rfc6091? I don't think that both the certificate type registries should be active. >> Why wasn't this brought up to the mailing list given that this overrides >> the previous consensus [0] on the mailing list? > I am not the chair of the group. I let them to judge consensus in the way they want. This was not a question for you. regards, Nikos From n.mavrogiannopoulos@gmail.com Tue Nov 6 07:07: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 07C3321F8921 for ; Tue, 6 Nov 2012 07:07:59 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-lJjr5H81Dp for ; Tue, 6 Nov 2012 07:07:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38E1D21F88C3 for ; Tue, 6 Nov 2012 07:07:58 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so379490eek.31 for ; Tue, 06 Nov 2012 07:07:57 -0800 (PST) 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=aIF+zrmQ5CHw+3Bzu7wCvl2WGP9eRR50Tq0dynJidzs=; b=WWhcAxRTI0SsVGe+PCvHXvMkDbAseA0kYtZMN38+YBw5oS8nWiBc8AWhkq0MwS+bOl UfeY6N4zu0NeQjjLlJtXWmXB8WNsy5RlKArlZdKzjBbIVnFdAg7Zl2SFUsUdFOPjvmdV IZLydnohjEg4ZrZF5V3Vs7vJD9QSnPVpohVuaFXPLxawfOvZu4VdyB+Y6EMLX7Ssbnm+ n7ePPhPlwckbN2tq+cymwQpMFxPFhRlgS5Yey2Fhh3tR0fk1ghFnt22YrDTr2c6a9Eov tG6Qb5hTSrkQI9PhvDEGMwGAk5ONPY930i4xzUQ729eM5gvnwSJHbArNaac7bLEZCmzD gcUw== Received: by 10.14.0.198 with SMTP id 46mr4462161eeb.21.1352214477238; Tue, 06 Nov 2012 07:07:57 -0800 (PST) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id 42sm56689784eee.0.2012.11.06.07.07.53 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 07:07:54 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <509927C4.1070404@gnutls.org> Date: Tue, 06 Nov 2012 16:07:48 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> In-Reply-To: <078C4585-EFCF-4871-B8AE-C5BBDDB90536@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" , John Gilmore Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 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, 06 Nov 2012 15:07:59 -0000 On 11/03/2012 04:59 PM, Hannes Tschofenig wrote: > Hi Nikos, > > around the last IETF meeting I got feedback from the working group about avoiding a normative reference to RFC 6091. > The current document version avoids that dependency. > I didn't see the need to add OpenPGP support in this document. If the meeting that you mean is IETF-84 then my reading of the minutes [0] is different. There is no suggestion to create a new certificate type anywhere. My reading is that the suggestion is to use the existing type by copying it to the new draft. In any case, even if your belief is correct that the OpenPGP type has to be deprecated, I think that intentionally creating conflicting extensions is bad practice. [0]. http://tools.ietf.org/wg/tls/minutes?item=minutes-84-tls.html regards, Nikos From peter.sylvester@edelweb.fr Tue Nov 6 07:32: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 6D93D21F8842 for ; Tue, 6 Nov 2012 07:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.037 X-Spam-Level: X-Spam-Status: No, score=-1.037 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyIbUOLwWT5C for ; Tue, 6 Nov 2012 07:32:24 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 915D321F879A for ; Tue, 6 Nov 2012 07:32:24 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id C663B5E092 for ; Tue, 6 Nov 2012 16:30:05 +0100 (CET) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id AC4085E08D for ; Tue, 6 Nov 2012 16:30:05 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id B7CFA5E2CB for ; Tue, 6 Nov 2012 16:32:20 +0100 (CET) Received: from smtps.on-x.com (imaps.on-x.com [192.168.14.31]) by mail1.on-x.com (Postfix) with ESMTP id AA4805E2B4 for ; Tue, 6 Nov 2012 16:32:20 +0100 (CET) Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id 23B485E2EB for ; Tue, 6 Nov 2012 16:33:39 +0100 (CET) Message-ID: <50992DBB.60406@edelweb.fr> Date: Tue, 06 Nov 2012 16:33:15 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: tls@ietf.org References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> In-Reply-To: <509927C4.1070404@gnutls.org> Content-Type: multipart/alternative; boundary="------------030709030502020109020008" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06 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, 06 Nov 2012 15:32:25 -0000 This is a multi-part message in MIME format. --------------030709030502020109020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi (Hannes), - Is there a need to make a normative reference to 6091. If the definition is completely make in a compatible way, an informative reference is sufficient IMO. - What does is the problem to make the definitions compatible i.e. define a value for pgp? - Besides that, a public key is not exactly a "certificate" type? - How would one add a sunrise hash chain as a new certificate type? peter On 11/06/2012 04:07 PM, Nikos Mavrogiannopoulos wrote: > On 11/03/2012 04:59 PM, Hannes Tschofenig wrote: > >> Hi Nikos, >> >> around the last IETF meeting I got feedback from the working group about avoiding a normative reference to RFC 6091. >> The current document version avoids that dependency. >> I didn't see the need to add OpenPGP support in this document. > If the meeting that you mean is IETF-84 then my reading of the minutes > [0] is different. There is no suggestion to create a new certificate > type anywhere. My reading is that the suggestion is to use the existing > type by copying it to the new draft. > > In any case, even if your belief is correct that the OpenPGP type has to > be deprecated, I think that intentionally creating conflicting > extensions is bad practice. > > [0]. http://tools.ietf.org/wg/tls/minutes?item=minutes-84-tls.html > > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Peter Sylvester --------------030709030502020109020008 Content-Type: multipart/related; boundary="------------060007000409010406010209" --------------060007000409010406010209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi (Hannes),

- Is there a need to make a normative reference to  6091.
If the definition is completely make in a compatible way,
an informative reference is sufficient IMO.

- What does is the problem to make the definitions compatible
  i.e. define a value for pgp?

- Besides that, a public key is not exactly a "certificate" type?

- How would one add a sunrise hash chain as a new certificate type?


peter


On 11/06/2012 04:07 PM, Nikos Mavrogiannopoulos wrote:
On 11/03/2012 04:59 PM, Hannes Tschofenig wrote:


Hi Nikos, 

around the last IETF meeting I got feedback from the working group about avoiding a normative reference to RFC 6091. 
The current document version avoids that dependency.


      

        
I didn't see the need to add OpenPGP support in this document.


      

      
If the meeting that you mean is IETF-84 then my reading of the minutes
[0] is different. There is no suggestion to create a new certificate
type anywhere. My reading is that the suggestion is to use the existing
type by copying it to the new draft.

In any case, even if your belief is correct that the OpenPGP type has to
be deprecated, I think that intentionally creating conflicting
extensions is bad practice.

[0]. http://tools.ietf.org/wg/tls/minutes?item=minutes-84-tls.html

regards,
Nikos
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


    

    

    

    
-- 

      
      Peter Sylvester
    

  


--------------060007000409010406010209
Content-Type: image/jpeg;
 name="on-x.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline;
 filename="on-x.jpg"

/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8l
JCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIo
Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAAR
CABdANcDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA
AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl
5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA
AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk
NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk
5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiiigAopKKAFopKKAFopKKAFopKWgAop
KKAFopKKAFooooAKKSigBaKSigBaKSigBaKSigBaKSloAKKKKACkpaKAOf1TU7n+1DYwzrbI
ke9pCMlvYVo6PdG709JTKZTkgsRjNS3enWl9j7RCrkdD3qS3tobSERQIEQdAKBmZ4hv7mxS3
+ztjzJNrYHOKTQ9Qubq6uoZmykRGzeMP+Iq5evpshQXcsOUOVDMODT4EspLlrmAxtIwwWRs5
FK6Hyu17Bql21jp01yib2jXIWsC11i/insnluY7lLs4MSDmOuoZVdSrAEHgg1Ut9IsLWczQ2
yJIe9MRcPSubTWpxbakZJlWWE4iB610lUZ9L064n82WCNpO5z1oEO0meW50uCabmR1y1Z2ua
hc2uoW0EUjJHKDuKjJrbTYqhFwAOABUclpBLOk7xgyR/db0oAr6RLezWW6+TbJuIX1K9iaoe
I9RurF7VLd9vmsQ3GTW6SAMk4qrd2dnfBftCJJt6ZPSgA0x5HskaVy7HqSMGrdQ2sENtCIoF
wg6DOamoAwPGWpXWl6Ibi0k2SBwM4rz7/hOde/5+x/3zXb/EL/kW2/3xXk9cVeUlPRn0eWUa
c6F5RT1Oh/4TnXv+fsf980f8Jzr3/P2P++a54DPSlwfSsOeXc9L6tR/kX3HQf8Jzr3/P2P8A
vmj/AITnXv8An7H/AHzXP7T6UnSjnl3D6tR/kX3HQ/8ACc69/wA/Y/75o/4TnXv+fsf981z+
0+lIQR1FHtJdw+rUf5F9x6/4N1o6xpO6afzLlD+8B6iuirzD4axyNrM0ivhEj+dfXPSvTq76
MnKF2fL4+lGlXcY7bi0UUVqcQUlLSUARXVzDZ273E7hI4xlmNcFL4m1DxTrKaZpbta2zH5nH
3ivc034ja07XCaVE+EUbpMdzTPhlbBr27uCPuKAD9a5Zzcp8i2PaoYaNHDPETV30Ovt/C2kw
xgPb+e+OXlO4mquqeGIUtnuNJZ7O6jG5PLbhvYiuioPpW7hG1rHmRxFVS5uY4rwx44NzOuna
tiOfO1ZegY+hrta8W8TQfYvEd2iHbiTcMdq9J8Gay2saIhlbM0PyOfX0NY0ajb5ZHoY/CRjB
V6asnuvU6CuE8YeE7W20jU9Xiv8AUEuVQyKFnO0H2Fd5WB44/wCRP1H/AK5/1rpPIPm238We
ILS6inGqXReNgwDyHB9iK+jvBHi228XaDHeRkLcINs8fdW/wryr4l+BfK0q08R6ZBiJoEF1G
g6HH3q5LwL4uuPCOvJdKS1tIQtxHnhl9aAPpbWNKh1mxa0nlmiRjndC+1vzrz/8A4RS2/wCE
+OjHUdSNr9j83b9oOd31r0axvrfUrGK8tZBJDMoZGB7Vyv8AzVw/9g4fzoA6TR9Jh0WwWzgm
mlRSTumfc351fpKWgDlviF/yLbf74ryevWPiF/yLbf74ryeuDEfGfUZV/u/zZc03UP7OmaT7
PFPuGMSrkCu98Iy6T4ghlS5063W5iPIVcZHrXm1aOg6tJo2rQ3aE7QcOPVe9RTnyvXY6cVh/
awfLpI9J8QaPbWGlSXenabbPJF8zKyZyvevLry7+1XhuPJjjyc7EGBXuMMsV7aLKhDxSpn6g
15re+EvI8VSI4KaeoM7SHoF9PrW9aGzR5mXYlLmjU3X9WJG1CGy8PR3t3plp9pnIFvHs/hHV
jXL6lqH9ozLJ9nih2jGIlwDU2u6odV1FpVG2FPkhQdFUdKza55SvoetRoqK5mtX+HkdB4Jv2
sfEcGDhJjsYfWvYK8Y8JWr3fiO0RQTtfefoK9nrqw1+Vnh5uo+1i1vYWiiiuk8cKSlpKAPFf
FE7XHiO9Zu0hArsPhko+yXbdywFcz41sWs/ElwSuFlO8H1zXRfDGUFLyLPIwa4KelXU+nxTU
sBePZHf0lLSV3nzB5B45AHii5wMdK2fhjKwvLyLPylQcVi+N3D+J7rHY4rpPhnYskF1fMCA5
CL+FcENax9PiGlgFfsjva5/xz/yJ+o/9c/610Fc/45/5E/Uf+uf9a7z5gu6fbQ3nhy3triMS
RS2yq6noQRXzt8RPBc3hHXWWNCbGcloH7D/Zr6O0X/kC2f8A1wX+VUvFfhq08VaHNp1yoyRm
J+6N2NAHkfwg8ef2bdjQNSmxazt+4dj/AKtvSvRBz8XCf+ocP51876vpV74f1eaxu0aOe3fr
6+hFes/C3xFc+JfFSTXYzPa2IhZ/74HQ0Aeu3E4traSYoziNS21Rkn6VzI8eQEf8gbU/+/Nd
VRigDhNb1pPE9idOitLmzYnd5t0mxPpmub/4RGb/AKCFl/38rtviFx4bb/fFeU5P94/nXDXa
59UfSZZGboe7K2vYu6ppb6XKsbzxSlhnMTZFUaCSepJ+tFc7PXimlqz0b4d695sLaTO/zp80
We49K6HxXp02paDPDbuVkA3cfxY7V5/oezw9p39uzpunkOy1jPf1avTtMv4tU06G7iIKyLk+
x7iu2k+aHKz5vHQ9lX9tTWl/xPC2UqxVhgg4IpB1xXVeO9D/ALM1X7VEuILnkY7N3FcxBIIp
0kK7grAketccouLsz6ClVjVpqcep6d4C8PHTrL7fcLie4Hyg/wAK119Zuh6vaaxp8c1q4+VQ
GTuprSr0qaSikj5DEznOrJ1NxaKKKs5wpKWigDmvGXhw63p4kgH+lQcr/tD0rkPAV2dN8RtZ
3A8szAoQ3HzV6nWLrPhbT9XcTsDBcqcrNHwc1hOn73PHc9LD4tKk6FX4X17G1TJpkgheWRgq
IpYk9qxIrfxLaKIluba6ReFaQYb8ahu9E1jWl8nU79IbbOWitxy3sTVuTtojmVGF/emrf10P
PxZ3PinxJN9mUlZJCS+OFWvWtM0+HS9Pis4R8sYxn1PrTNM0iy0i3EFnCI17nufqau1NOny6
vc2xmM9vaEdIoWuf8c/8ifqP/XP+tb9clrXh/wASavFdWh1mBLOfjZ5I3BfrWxwHQaL/AMga
z/64L/Krtc5o+l+I7GeCO71aCe0iXaY1hAJA6c10dAHnvxV8Cr4i0o6nZR/8TC0XPA/1i+lc
T8DFKeKbxWUqwhIIPUGveDXLaZ4Kg0fxrda7ZMscN3HiSEDo3qKAOp7UtJS0Act8Qv8AkW2/
3xXk9esfEL/kW24J+cdK8o2N/db8q4MR8Z9RlX+7/NiVpaFpR1XUFjY7YIxvmfsqjrVaykjt
7pJbi2aeNesfIzW/D4n0+3tZbWHQykc338Ocn2zWUUurO6tKolaEbv5GZ4g1Qanf4hGy2gHl
woOgUd66L4d679num0ud8JL80eT0PpXI3skVxdNJbWpgjPROTitHTNVsbCGPzdKaW4jbcJQ5
FVGVp3uZVqKnQ9monqfiHSE1rSJbVgN+Mxn0avFp4Xt53hkUh4yVYH1ruR8TpwP+QV+prE1T
X7DVDNK+i+XcSj/WKx4PritKsoT1TOPAUsRh04Tjp8if4fXU0PiJYUY7JVIZfWvV68p+Htuz
+JFcqQI42JyK9WrbD/Aefm1vrGnZC0UUV0HlBRRRQAUlLRQAlFLRQAlLRRQAUlLRQAUlLRQA
lFLRQAUUUUARzQRXCbJo1kX0YZFV/wCydP8A+fKH/vgVcopWRSlJbMp/2Tp//PlD/wB8Cj+y
dP8A+fKH/vgVcoosh88+5T/snT/+fKH/AL4FH9k6f/z5Q/8AfAq5RRZBzz7lP+ydP/58of8A
vgUf2Tp//PlD/wB8CrlFFkHPPuQQWVrbMWgt442PBKrip6KKZLbe4UUUUCP/2Q==
--------------060007000409010406010209--

--------------030709030502020109020008--

From hannes.tschofenig@gmx.net  Tue Nov  6 07:53: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 42E2921F84DA for ; Tue,  6 Nov 2012 07:53:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq7ujhjsHst9 for ; Tue,  6 Nov 2012 07:53:09 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id DE65D21F87AB for ; Tue,  6 Nov 2012 07:53:08 -0800 (PST)
Received: (qmail invoked by alias); 06 Nov 2012 15:53:07 -0000
Received: from dhcp-17ac.meeting.ietf.org (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp071) with SMTP; 06 Nov 2012 16:53:07 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+snm4i3nusPjVaxA2EmCgrHAHX2Y4I3fUsGmyI8e Su5Ii/VGJnT3ey
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <50992DBB.60406@edelweb.fr>
Date: Tue, 6 Nov 2012 10:53:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr>
To: Peter Sylvester 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06
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, 06 Nov 2012 15:53:10 -0000

Hi Peter,=20

thanks for your comments.=20

On Nov 6, 2012, at 10:33 AM, Peter Sylvester wrote:

> Hi (Hannes),
>=20
> - Is there a need to make a normative reference to  6091.
> If the definition is completely make in a compatible way,
> an informative reference is sufficient IMO.

The current version of the document does not make any reference to RFC =
6091.=20

A normative reference is required when we use functionality from RFC =
6091, such as the cert_type parameter and the registry.=20

>=20
> - What does is the problem to make the definitions compatible
>   i.e. define a value for pgp?

There is no problem to add a value for OpenPGP if there is interest in =
doing so.=20
The question for me is:=20
 * Who cares about client authentication using OpenPGP?=20
 * Who cares about server authentication using OpenPGP?

>=20
> - Besides that, a public key is not exactly a "certificate" type?
>=20
I am happy to change the name. In any case the idea is to put the =
SubjectPublicKeyInfo into the certificate payload.=20
So, using certificate_type does not seem too far fetched.=20

> - How would one add a sunrise hash chain as a new certificate type?

Not sure I understand what you would like to do.=20

Ciao
Hannes

>=20
>=20
> peter=20
>=20
>=20
> On 11/06/2012 04:07 PM, Nikos Mavrogiannopoulos wrote:
>> On 11/03/2012 04:59 PM, Hannes Tschofenig wrote:
>>=20
>>=20
>>> Hi Nikos,=20
>>>=20
>>> around the last IETF meeting I got feedback from the working group =
about avoiding a normative reference to RFC 6091.=20
>>> The current document version avoids that dependency.
>>>=20
>>> I didn't see the need to add OpenPGP support in this document.
>>>=20
>> If the meeting that you mean is IETF-84 then my reading of the =
minutes
>> [0] is different. There is no suggestion to create a new certificate
>> type anywhere. My reading is that the suggestion is to use the =
existing
>> type by copying it to the new draft.
>>=20
>> In any case, even if your belief is correct that the OpenPGP type has =
to
>> be deprecated, I think that intentionally creating conflicting
>> extensions is bad practice.
>>=20
>> [0].=20
>> http://tools.ietf.org/wg/tls/minutes?item=3Dminutes-84-tls.html
>>=20
>>=20
>> regards,
>> Nikos
>> _______________________________________________
>> TLS mailing list
>>=20
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
> --=20
>  Peter Sylvester
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From paul@nohats.ca  Tue Nov  6 07:56:06 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B48D21F8A17 for ; Tue,  6 Nov 2012 07:56:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdP9B19s+f9k for ; Tue,  6 Nov 2012 07:56:06 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8A321F8A16 for ; Tue,  6 Nov 2012 07:56:06 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 70C3482B5B; Tue,  6 Nov 2012 10:55:22 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 64A6482B21; Tue,  6 Nov 2012 10:55:22 -0500 (EST)
Date: Tue, 6 Nov 2012 10:55:22 -0500 (EST)
From: Paul Wouters 
To: Peter Sylvester 
In-Reply-To: <50992DBB.60406@edelweb.fr>
Message-ID: 
References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06
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, 06 Nov 2012 15:56:06 -0000

On Tue, 6 Nov 2012, Peter Sylvester wrote:

> - What does is the problem to make the definitions compatible
>  i.e. define a value for pgp?

I believe the problem was that 6091 was not a standards track document.

> - Besides that, a public key is not exactly a "certificate" type?

It is how the TLS WG preferred the raw public key format to be
supported.

> - How would one add a sunrise hash chain as a new certificate type?

One would not. If the rae public key certificate format does not satisfy
your needs, use the existing PKIX certificate, or create a new
certificate type?

Paul

From d.thakore@cablelabs.com  Tue Nov  6 08:09: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 6373E21F8A0F for ; Tue,  6 Nov 2012 08:09:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level: 
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMIqP5T9hdWS for ; Tue,  6 Nov 2012 08:09:04 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id D309021F89F1 for ; Tue,  6 Nov 2012 08:09:03 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id qA6G92kN026215 for ; Tue, 6 Nov 2012 09:09:02 -0700
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 06 Nov 2012 09:09:02 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 6 Nov 2012 09:09:02 -0700
From: Darshak Thakore 
To: "tls@ietf.org" 
Date: Tue, 6 Nov 2012 09:09:02 -0700
Thread-Topic: New Authz extension to use DTCP certificates in TLS SD handshake message
Thread-Index: Ac28OQlHDc3W/IRTTPePDuyO+gfQxw==
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.4.120824
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CCBEA04EEFE7dthakorecablelabscom_"
MIME-Version: 1.0
X-Approved: ondar
Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message
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, 06 Nov 2012 16:09:04 -0000

--_000_CCBEA04EEFE7dthakorecablelabscom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,
I am sending this email to obtain feedback and guidance on the following I-=
D, which proposes a new Authorization Data Format to the TLS SupplementalDa=
ta Handshake extension to use DTCP certificates as authorization data. If t=
his WG is not the forum to seek feedback on this proposal, please redirect =
me accordingly.

http://tools.ietf.org/html/draft-dthakore-authz-01

>From the Abstract:

  "This document specifies the use of DTCP certificate as an
   authorization extension in the Transport Layer Security Handshake
   Protocol, according to guidelines in RFC 5878.  Extensions carried in
   the client and server Hello messages confirm that both parties
   support the desired authorization data types.  Then if supported by
   both the client and server, DTCP certificates are exchanged in the
   supplemental data handshake TLS handshake message as specified in
   RFC4680."

Thanks in advance

Regards,

Darshak Thakore

--_000_CCBEA04EEFE7dthakorecablelabscom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Folks,
I am se=
nding this email to obtain feedback and guidance on the following I-D, whic=
h proposes a new Authorization Data Format to the TLS SupplementalData Hand=
shake extension to use DTCP certificates as authorization data. If this WG =
is not the forum to seek feedback on this proposal, please redirect me acco=
rdingly.


  "This document specifies the us=
e of DTCP certificate as an
   authorization extension in the Transport Layer Security Handshake
   Protocol, according to guidelines in RFC 5878.  Extensions carried in
   the client and server Hello messages confirm that both parties
   support the desired authorization data types.  Then if supported by
   both the client and server, DTCP certificates are exchanged in the
   supplemental data handshake TLS handshake message as specified in
   RFC4680."
Thanks=
 in advance 
Regards,
Darshak Thakore


--_000_CCBEA04EEFE7dthakorecablelabscom_--

From peter.sylvester@edelweb.fr  Tue Nov  6 08:33:42 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECE521F84E3 for ; Tue,  6 Nov 2012 08:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level: 
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.781,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-sSfDT-T-fn for ; Tue,  6 Nov 2012 08:33:41 -0800 (PST)
Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id E5AE821F8B20 for ; Tue,  6 Nov 2012 08:33:35 -0800 (PST)
Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id CF2555E06C; Tue,  6 Nov 2012 17:31:17 +0100 (CET)
Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id B46015E06B; Tue,  6 Nov 2012 17:31:17 +0100 (CET)
Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id D4B6C5E326; Tue,  6 Nov 2012 17:33:32 +0100 (CET)
Received: from smtps.on-x.com (unknown [192.168.14.34]) by mail1.on-x.com (Postfix) with ESMTP id C7B2C5E087; Tue,  6 Nov 2012 17:33:32 +0100 (CET)
Received: from [192.168.18.180] (unknown [192.168.18.180]) by smtps.on-x.com (Postfix) with ESMTPSA id C9DFD5E350; Tue,  6 Nov 2012 17:32:05 +0100 (CET)
Message-ID: <50993C13.20201@edelweb.fr>
Date: Tue, 06 Nov 2012 17:34:27 +0100
From: Peter Sylvester 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-AV-Checked: ClamAV using ClamSMTP
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06
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, 06 Nov 2012 16:33:42 -0000

On 11/06/2012 04:53 PM, Hannes Tschofenig wrote:
> Hi Peter,
>
> thanks for your comments.
>
> On Nov 6, 2012, at 10:33 AM, Peter Sylvester wrote:
>
>> Hi (Hannes),
>>
>> - Is there a need to make a normative reference to  6091.
>> If the definition is completely make in a compatible way,
>> an informative reference is sufficient IMO.
> The current version of the document does not make any reference to RFC 6091.
RFC  6091 has

     enum { client, server } ClientOrServerExtension;

       enum { X.509(0), OpenPGP(1), (255) } CertificateType;

       struct {
          select(ClientOrServerExtension) {
             case client:
                CertificateType certificate_types<1..2^8-1>;
             case server:
                CertificateType certificate_type;
          }
       } CertificateTypeExtension;

ietf-tls-oob-pubkey has

enum { client, server } ClientOrServerExtension;

    enum { X.509-Accept (0),
           X.509-Offer (1),
           RawPublicKey-Accept (2),
           RawPublicKey-Offer (3),
           (255)
          } CertificateType;

    struct {
       select(ClientOrServerExtension)
           case client:
             CertificateType certificate_types<1..2^8-1>;
           case server:
             CertificateType certificate_type;
       }
    } CertTypeExtension;


I find this rather unfortunate not to share the same extension.

>
> A normative reference is required when we use functionality from RFC 6091, such as the cert_type parameter and the registry.

rfc4897 says you can as far as I see:

       A note is included in the reference text that indicates that the
       reference is to a target document of a lower maturity level, that
       some caution should be used since it may be less stable than the
       document from which it is being referenced, and, optionally,
       explaining why the downward reference is appropriate.


>
>> - What does is the problem to make the definitions compatible
>>    i.e. define a value for pgp?
> There is no problem to add a value for OpenPGP if there is interest in doing so.
> The question for me is:
>   * Who cares about client authentication using OpenPGP?
>   * Who cares about server authentication using OpenPGP?
Why do you care?

One could use any other number the 0 and 1 for the first options?

>
>> - Besides that, a public key is not exactly a "certificate" type?
>>
> I am happy to change the name. In any case the idea is to put the SubjectPublicKeyInfo into the certificate payload.
> So, using certificate_type does not seem too far fetched.
IMO it may be the contrary:  An info has nothing to do how it is 
'certified' or 'asserted' or whether.
The whole thing could be called KeyInfo or something.
The title of the document indicate 'oob'.

>
>> - How would one add a sunrise hash chain as a new certificate type?
> Not sure I understand what you would like to do.
oops, sunlight, not sunrise

http://tools.ietf.org/html/draft-laurie-pki-sunlight-00

Tschö
Peter


From hannes.tschofenig@gmx.net  Tue Nov  6 08:53:39 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F2621F8590 for ; Tue,  6 Nov 2012 08:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iOe6ATsZMNw for ; Tue,  6 Nov 2012 08:53:39 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 9AB0721F8496 for ; Tue,  6 Nov 2012 08:53:38 -0800 (PST)
Received: (qmail invoked by alias); 06 Nov 2012 16:53:36 -0000
Received: from dhcp-17ac.meeting.ietf.org (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp037) with SMTP; 06 Nov 2012 17:53:36 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Yucokr40YtZhubzYdUwEKuzwP5VnpqOObo5L2JJ 7i7AGquGN4K8L8
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: Hannes Tschofenig 
In-Reply-To: <50993C13.20201@edelweb.fr>
Date: Tue, 6 Nov 2012 11:53:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr>  <50993C13.20201@edelweb.fr>
To: Peter Sylvester 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06
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, 06 Nov 2012 16:53:39 -0000

Hi Peter,=20

while the approach taken by RFC 6091 and by draft-ietf-tls-oob-pubkey-06 =
look similar the semantic is actually different.=20
The difference between the two approaches is that =
draft-ietf-tls-oob-pubkey-06 allows you to pick different certificate =
types for the client and the server whereas RFC 6091 does not seem to =
have such a provision.=20

I am aware of RFC 4897. I know that a downref is possible and till =
version -03 I had envisioned that the approach we would be using. I then =
realized that the semantic is different.=20

Regarding the support of OpenPGP I am not against adding the support for =
it but I would like to understand whether there is a chance that someone =
implements and deploys it. I don't think we should just add =
functionality because it is theoretically possible.=20

KeyInfo sounds good to me.=20

I will take a look at draft-laurie-pki-sunlight-00

Ciao
Hannes

On Nov 6, 2012, at 11:34 AM, Peter Sylvester wrote:

> On 11/06/2012 04:53 PM, Hannes Tschofenig wrote:
>> Hi Peter,
>>=20
>> thanks for your comments.
>>=20
>> On Nov 6, 2012, at 10:33 AM, Peter Sylvester wrote:
>>=20
>>> Hi (Hannes),
>>>=20
>>> - Is there a need to make a normative reference to  6091.
>>> If the definition is completely make in a compatible way,
>>> an informative reference is sufficient IMO.
>> The current version of the document does not make any reference to =
RFC 6091.
> RFC  6091 has
>=20
>    enum { client, server } ClientOrServerExtension;
>=20
>      enum { X.509(0), OpenPGP(1), (255) } CertificateType;
>=20
>      struct {
>         select(ClientOrServerExtension) {
>            case client:
>               CertificateType certificate_types<1..2^8-1>;
>            case server:
>               CertificateType certificate_type;
>         }
>      } CertificateTypeExtension;
>=20
> ietf-tls-oob-pubkey has
>=20
> enum { client, server } ClientOrServerExtension;
>=20
>   enum { X.509-Accept (0),
>          X.509-Offer (1),
>          RawPublicKey-Accept (2),
>          RawPublicKey-Offer (3),
>          (255)
>         } CertificateType;
>=20
>   struct {
>      select(ClientOrServerExtension)
>          case client:
>            CertificateType certificate_types<1..2^8-1>;
>          case server:
>            CertificateType certificate_type;
>      }
>   } CertTypeExtension;
>=20
>=20
> I find this rather unfortunate not to share the same extension.
>=20
>>=20
>> A normative reference is required when we use functionality from RFC =
6091, such as the cert_type parameter and the registry.
>=20
> rfc4897 says you can as far as I see:
>=20
>      A note is included in the reference text that indicates that the
>      reference is to a target document of a lower maturity level, that
>      some caution should be used since it may be less stable than the
>      document from which it is being referenced, and, optionally,
>      explaining why the downward reference is appropriate.
>=20
>=20
>>=20
>>> - What does is the problem to make the definitions compatible
>>>   i.e. define a value for pgp?
>> There is no problem to add a value for OpenPGP if there is interest =
in doing so.
>> The question for me is:
>>  * Who cares about client authentication using OpenPGP?
>>  * Who cares about server authentication using OpenPGP?
> Why do you care?
>=20
> One could use any other number the 0 and 1 for the first options?
>=20
>>=20
>>> - Besides that, a public key is not exactly a "certificate" type?
>>>=20
>> I am happy to change the name. In any case the idea is to put the =
SubjectPublicKeyInfo into the certificate payload.
>> So, using certificate_type does not seem too far fetched.
> IMO it may be the contrary:  An info has nothing to do how it is =
'certified' or 'asserted' or whether.
> The whole thing could be called KeyInfo or something.
> The title of the document indicate 'oob'.
>=20
>>=20
>>> - How would one add a sunrise hash chain as a new certificate type?
>> Not sure I understand what you would like to do.
> oops, sunlight, not sunrise
>=20
> http://tools.ietf.org/html/draft-laurie-pki-sunlight-00
>=20
> Tsch=F6
> Peter
>=20


From n.mavrogiannopoulos@gmail.com  Tue Nov  6 09:19: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 02A8721F88A3 for ; Tue,  6 Nov 2012 09:19:04 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uU47riLiK6vn for ; Tue,  6 Nov 2012 09:19:03 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3714621F8850 for ; Tue,  6 Nov 2012 09:19:03 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id k13so316948eaa.31 for ; Tue, 06 Nov 2012 09:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=d1N5o7dyMRD3FFGWo395iKQQY+R0PGek5wieq2YYoNs=; b=YunhGp5k0NwK5noQus6eiMnlk512tDa73x+bDsjPHC1eMWKpSfN6ikf0r4yQcxJTxs +aidPwtP00Hgd/7rkFbh9K0T6ShOevnLb1EyzCNptNB0hJcAyImXwurpiP6SufzXXwZF k2YBB+LQPgeVGqgatEagQYEjBrAHqmEOzWVuSSaWbJYYyhCAvoPCxNpuy/pw53Vrpw8/ PjZ25NHyfzvx7jsZqLZlJN/4N0ZWAGGMpIhdBFUpfNDFc93Vr0F8y5K1z5l0LT1sg7XI E5sPYreP1Cks7h1f5c0m6s45hXp/2msBW0Uxf/ScAUSaydDRyEtRXMvG3xjTjogLwG0S fUCQ==
Received: by 10.14.225.71 with SMTP id y47mr5769604eep.0.1352222342444; Tue, 06 Nov 2012 09:19:02 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id z43sm57444731een.16.2012.11.06.09.19.01 (version=SSLv3 cipher=OTHER); Tue, 06 Nov 2012 09:19:01 -0800 (PST)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <50994684.8010701@gnutls.org>
Date: Tue, 06 Nov 2012 18:19:00 +0100
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: tls@ietf.org
References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr>  <50993C13.20201@edelweb.fr> 
In-Reply-To: 
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06
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, 06 Nov 2012 17:19:04 -0000

On 11/06/2012 05:53 PM, Hannes Tschofenig wrote:

> while the approach taken by RFC 6091 and by
> draft-ietf-tls-oob-pubkey-06 look similar the semantic is actually
> different. The difference between the two approaches is that
> draft-ietf-tls-oob-pubkey-06 allows you to pick different certificate
> types for the client and the server whereas RFC 6091 does not seem to
> have such a provision. I am aware of RFC 4897. I know that a downref
> is possible and till version -03 I had envisioned that the approach
> we would be using. I then realized that the semantic is different.


The semantic difference may or may not require to break backwards
compatibility.

> Regarding the support of OpenPGP I am not against adding the support
> for it but I would like to understand whether there is a chance that
> someone implements and deploys it. I don't think we should just add
> functionality because it is theoretically possible.


Do you really have that assurance of the SubjectPublicKeyInfo extension?
In any case TLS with openpgp is implemented and deployed. There is even
an apache module supporting it.

regards,
Nikos

From hannes.tschofenig@gmx.net  Tue Nov  6 09:27:38 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC69521F8958 for ; Tue,  6 Nov 2012 09:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqe3-EHaSzdw for ; Tue,  6 Nov 2012 09:27:38 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 05BD121F898E for ; Tue,  6 Nov 2012 09:27:37 -0800 (PST)
Received: (qmail invoked by alias); 06 Nov 2012 17:27:36 -0000
Received: from dhcp-17ac.meeting.ietf.org (EHLO dhcp-17ac.meeting.ietf.org) [130.129.23.172] by mail.gmx.net (mp039) with SMTP; 06 Nov 2012 18:27:36 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18Qs9loB1AQnwLZZkPMFepuyxJ952ffxcxAytAv+E 67DVvJNj56DboI
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: <50994684.8010701@gnutls.org>
Date: Tue, 6 Nov 2012 12:27:32 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <312F1D0E-0C86-439E-A854-ADBBA0D7D23A@gmx.net>
References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr>  <50993C13.20201@edelweb.fr>  <50994684.8010701@gnutls.org>
To: Nikos Mavrogiannopoulos 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-06
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, 06 Nov 2012 17:27:39 -0000

Hi Nikos,=20

On Nov 6, 2012, at 12:19 PM, Nikos Mavrogiannopoulos wrote:

> On 11/06/2012 05:53 PM, Hannes Tschofenig wrote:
>=20
>> while the approach taken by RFC 6091 and by
>> draft-ietf-tls-oob-pubkey-06 look similar the semantic is actually
>> different. The difference between the two approaches is that
>> draft-ietf-tls-oob-pubkey-06 allows you to pick different certificate
>> types for the client and the server whereas RFC 6091 does not seem to
>> have such a provision. I am aware of RFC 4897. I know that a downref
>> is possible and till version -03 I had envisioned that the approach
>> we would be using. I then realized that the semantic is different.
>=20
>=20
> The semantic difference may or may not require to break backwards
> compatibility.

How was RFC 6091 supposed to be used? Was the expectation that the =
server provides a PGP certificate?=20


>> Regarding the support of OpenPGP I am not against adding the support
>> for it but I would like to understand whether there is a chance that
>> someone implements and deploys it. I don't think we should just add
>> functionality because it is theoretically possible.
>=20
>=20
> Do you really have that assurance of the SubjectPublicKeyInfo =
extension?
> In any case TLS with openpgp is implemented and deployed. There is =
even
> an apache module supporting it.
>=20
Good to hear.

So, what prevents those people just continuing to use RFC 6091?=20

Ciao
Hannes

> regards,
> Nikos
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From stefan@aaa-sec.com  Wed Nov  7 08:42: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 F26BF21F8C69 for ; Wed,  7 Nov 2012 08:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.249
X-Spam-Level: 
X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liPfFPp3LGnE for ; Wed,  7 Nov 2012 08:42:22 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id C142321F8C41 for ; Wed,  7 Nov 2012 08:42:19 -0800 (PST)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DDD29361C3 for ; Wed,  7 Nov 2012 17:42:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CI__Xliv3s4M for ; Wed,  7 Nov 2012 17:42:18 +0100 (CET)
Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 683E955FC6 for ; Wed,  7 Nov 2012 17:42:18 +0100 (CET)
Received: (qmail 32734 invoked from network); 7 Nov 2012 16:42:17 -0000
Received: from dhcp-170c.meeting.ietf.org (HELO [130.129.23.12]) (stefan@fiddler.nu@[130.129.23.12]) (envelope-sender ) by s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Nov 2012 16:42:17 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Wed, 07 Nov 2012 11:42:19 -0400
From: Stefan Santesson 
To: 
Message-ID: 
Thread-Topic: Comments on the cached-info draft 
In-Reply-To: <312F1D0E-0C86-439E-A854-ADBBA0D7D23A@gmx.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [TLS] Comments on the cached-info draft
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, 07 Nov 2012 16:42:24 -0000

It was quite a while since I wrote the first version of this draft.
Now that I bring it up to my attention I found a problem that I think
should be fixed.

After a close examination I'm convinced that the current spec breaks TLS.


The current approach is to exchange support for cached-info in client and
server hellos.
This includes hashes for cached objects (clients) and confirmation of
cached objects (server).

In addition to this, this protocol allows the cached data in handshake
messages to be swapped with cached object hashes.
This is a violation of the syntax of these handshake messages.

Take the Certificate handshake message for example. The spec suggest here
to replace the certificate_list vector to be replaced with a vector of
CachedObejct structured data.
This breaks the syntax of this handshake message. A strict processing of
the certificate_list vector will expect an ASN.1 encoded binary containing
a sequence of certificates, not a vector of data objects according to the
CachedObject structure.

My first thought was that we actually need a new handshake message.
However that is not helpful either.
The TLS spec require the Certificate handshake message to be sent in case
the chosen cipher suite demands it, so it MUST be sent.
It can't be replaced by another handshake message.

My current belief is that we simply should omit the cached data, and that
each cachedInfo type need to defined how to omit cached data.

In case of the certificate handshake message, the certificate list should
be replaced with an empty sequence.


There is actually no need to send the hash of the cached data in the
handshake message. Not if the confirmation of the cached info is exchanged
in the server hello. Sending the hash once more in the handshake message
is then redundant.


So I propose the following:

1) Clients send hashes of cached objects in client hello.
2) Server responds with one or zero hashes per cachedInfo type, that a)
matches a cached object sent by the client b) will be omitted by the
server in the corresponding handshake message.
3) How information is omitted from the handshake message is defined per
cached info type. For the current defined 2 types this is:
  A) cached certificate cahins in Certificate: replace the sequence of
certificates with an empty sequence.
  B) certificate_authorities in Certificate Request: Send an empty list of
DistinguishedName
4) Clients will act as if the cached objects (confirmed in server hello)
were sent in the handshake messages.
5) Everything else according to the current spec


The proposed approach will somewhat limit the functionality of the current
spec, but it ads value in simplicity.
I can't imagine a valid use case that would not be covered by this change,
but I might overlook something.






  










From mark@redphonesecurity.com  Wed Nov  7 11:55: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 2FCEF21F8C93 for ; Wed,  7 Nov 2012 11:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9xAVzpsTkmM for ; Wed,  7 Nov 2012 11:55:24 -0800 (PST)
Received: from g2host.com (mailfront4.g2host.com [208.42.184.242]) by ietfa.amsl.com (Postfix) with ESMTP id 56AA421F8C90 for ; Wed,  7 Nov 2012 11:55:23 -0800 (PST)
Received: from [24.118.98.157] (account mkbrown@visi.com HELO RPUD4) by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPA id 84549200; Wed, 07 Nov 2012 13:55:22 -0600
From: "Mark Brown" 
To: "'Darshak Thakore'" , 
References: 
In-Reply-To: 
Date: Wed, 7 Nov 2012 13:55:10 -0600
Message-ID: <05e501cdbd21$cb97b520$62c71f60$@redphonesecurity.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E6_01CDBCEF.80FE7DA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIk9jXGjrz9na5vCN38DTXdvnsmsJcwK4Cw
Content-Language: en-us
Subject: Re: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message
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, 07 Nov 2012 19:55:28 -0000

This is a multipart message in MIME format.

------=_NextPart_000_05E6_01CDBCEF.80FE7DA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Darshak,

I have feedback and questions for you ranging from details to requirements.
I did a quick scan of the DTCP and DTCP-IP documents, and I may have
misunderstood them at places. I suspect that others on this TLS list might
not want to invest a lot of time doing the same. You might refer to DTCP's
relevant sections more specifically (and at relevant places in your ID) to
ease the recruitment of TLS readers.

 

1. Section (3.2) What *should* be signed and why? Struct "dtcp_authz_data"
does not contain a *signed* nonce, but simply concatenates it with the
signed struct. Did you want to ensure freshness / avoid replay attacks, or
am I misunderstanding your purpose? This purpose should be clarified in your
ID.
 
2. Section (1) Regarding why you are using TLS and AUTHZ, your introduction
raises more questions than it answers for me, even though I suspect that
content protection and authorizations go together at a high level. First,
IMHO, the DTCP and DTCP-IP documents seem to have a lot of overlap with the
basic motivations for an encryption protocol, which is what TLS provides
too. So, why two similar protocols? Is your goal primarily to tunnel the
DTCP protocol within the TLS protocol? While authorization can be understood
in several ways, protocol tunneling is a not typical meaning for
authorization. Or is the primary goal to "determine the type of protected
data to be exchanged"? If so, please describe the authorization decision
that might take place in this determination, and document the semantics of
"access_denied" alert messages for your authorizations.
 
3. Section (1): Which security/encryption features do you need? DTCP seems
to require mutual authentication (my quick read is that it always uses EC
Difffie Hellman key agreement between two non-X.509 certificates under a
DTLA-lite certificate authority [CA]). However, DTCP does not provide TLS's
flexibility and it uses mismatched key strengths (80bit EC vs. 128 bit AES,
see, e.g. http://www.nsa.gov/business/programs/elliptic_curve.shtml ).
Asking, "Why use TLS at all?" might help clarify. Are you interested in the
flexibility or strength of its ciphersuites, or its history of vulnerability
and protocol analysis, or its history of standard use?  If so, which
protocol's session keys and encryptors will you use, and what do the keys
mean to the overall security argument? Why does the DTCP certificate need to
be "cryptographically tied to the X.509 certificate being used during the
TLS [handshake]"?  Why not create the X.509 cert already bound to the DTCP
cert? I think you should clarify your purpose and then document it in a
revised Introduction.
 
4. Regarding DTCP nonstandard certificates (4.2.3.1, Fig 7) vs. X.509
certificates: IMHO, and perhaps DTCP agrees, ASN.1 BER/DER seems like
language overkill for simple certs. Parsing ASN.1 found in Certificate
handshake messages is an arcane, complex, software-oriented, and risky
(read: pointer-arithmetic-rich) operation that can mix up tasks of
first-time validation with every-time verification. But if you plan on
generating both a DTLA certificate and an X.509 certificate for the same
keypair, then you might consider simply using the existing TLS client
(mutual) authentication instead of separately signing just your
authorization token. Just look at the CertificateVerify (CV) message already
defined for TLS, which runs a hash over the client's and the server's
nonces, the rest of the handshake, and your SupplementalData, then signs. If
you use the existing TLS CV message, then your DTCP protocol should be able
to offload the standardized certificate validations onto the TLS protocol,
for which ASN.1 parsers are already present in implementations, including
management of the CA lists and OCSP checking. 
 
Best regards,
--mark

 

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Darshak Thakore
Sent: Tuesday, November 06, 2012 10:09 AM
To: tls@ietf.org
Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD
handshake message

 

Folks,

I am sending this email to obtain feedback and guidance on the following
I-D, which proposes a new Authorization Data Format to the TLS
SupplementalData Handshake extension to use DTCP certificates as
authorization data. If this WG is not the forum to seek feedback on this
proposal, please redirect me accordingly.

 

http://tools.ietf.org/html/draft-dthakore-authz-01

 

>From the Abstract:

  "This document specifies the use of DTCP certificate as an
   authorization extension in the Transport Layer Security Handshake
   Protocol, according to guidelines in RFC 5878.  Extensions carried in
   the client and server Hello messages confirm that both parties
   support the desired authorization data types.  Then if supported by
   both the client and server, DTCP certificates are exchanged in the
   supplemental data handshake TLS handshake message as specified in
   RFC4680."
Thanks in advance 
Regards,
Darshak Thakore

------=_NextPart_000_05E6_01CDBCEF.80FE7DA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Darshak,
I have feedback and questions for you ranging from details to =
requirements. I did a quick scan of the DTCP and DTCP-IP documents, and =
I may have misunderstood them at places. I suspect that others on this =
TLS list might not want to invest a lot of time doing the same. You =
might refer to DTCP’s relevant sections more specifically (and at =
relevant places in your ID) to ease the recruitment of TLS =
readers.
 
1. Section (3.2) What *should* be signed and why? Struct =
“dtcp_authz_data” does not contain a *signed* nonce, but simply concatenates it =
with the signed struct. Did you want to ensure freshness / avoid replay =
attacks, or am I misunderstanding your purpose? This purpose should be =
clarified in your ID.
 
2. Section (1) Regarding why you are using TLS and AUTHZ, your =
introduction raises more questions than it answers for me, even though I =
suspect that content protection and authorizations go together at a high =
level. First, IMHO, the DTCP and DTCP-IP documents seem to have a lot of =
overlap with the basic motivations for an encryption protocol, which is =
what TLS provides too. So, why two similar protocols? Is your goal =
primarily to tunnel the DTCP protocol within the TLS protocol? While =
authorization can be understood in several ways, protocol tunneling is a =
not typical meaning for authorization. Or is the primary goal to =
“determine the type of protected data to be exchanged”? If =
so, please describe the authorization decision that might take place in =
this determination, and document the semantics of =
“access_denied” alert messages for your =
authorizations.
 
3. Section (1): Which security/encryption features do you need? DTCP =
seems to require mutual authentication (my quick read is that it always =
uses EC Difffie Hellman key agreement between two non-X.509 certificates =
under a DTLA-lite certificate authority [CA]). However, DTCP does not =
provide TLS’s flexibility and it uses mismatched key strengths =
(80bit EC vs. 128 bit AES, see, e.g. http:/=
/www.nsa.gov/business/programs/elliptic_curve.shtml ). Asking, =
“Why use TLS at all?” might help clarify. Are you interested =
in the flexibility or strength of its ciphersuites, or its history of =
vulnerability and protocol analysis, or its history of standard use? =
 If so, which protocol’s session keys and encryptors will you =
use, and what do the keys mean to the overall security argument? Why =
does the DTCP certificate need to be “cryptographically tied to =
the X.509 certificate being used during the TLS [handshake]”? =
 Why not create the X.509 cert already bound to the DTCP cert? I =
think you should clarify your purpose and then document it in a revised =
Introduction.
 
4. Regarding DTCP nonstandard certificates (4.2.3.1, Fig 7) vs. X.509 =
certificates: IMHO, and perhaps DTCP agrees, ASN.1 BER/DER seems like =
language overkill for simple certs. Parsing ASN.1 found in Certificate =
handshake messages is an arcane, complex, software-oriented, and risky =
(read: pointer-arithmetic-rich) operation that can mix up tasks of =
first-time validation with every-time verification. But if you plan on =
generating both a DTLA certificate and an X.509 certificate for the same =
keypair, then you might consider simply using the existing TLS client =
(mutual) authentication instead of separately signing just your =
authorization token. Just look at the CertificateVerify (CV) message =
already defined for TLS, which runs a hash over the client’s and =
the server’s nonces, the rest of the handshake, and your =
SupplementalData, then signs. If you use the existing TLS CV message, =
then your DTCP protocol should be able to offload the standardized =
certificate validations onto the TLS protocol, for which ASN.1 parsers =
are already present in implementations, including management of the CA =
lists and OCSP checking. 
 
Best regards,
--mark
 
From:=
 =
tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of =
Darshak Thakore
Sent: Tuesday, November 06, 2012 10:09 =
AM
To: tls@ietf.org
Subject: [TLS] New Authz =
extension to use DTCP certificates in TLS SD handshake =
message
 
Folks,
I am sending this email to obtain feedback and guidance on the =
following I-D, which proposes a new Authorization Data Format to the TLS =
SupplementalData Handshake extension to use DTCP certificates as =
authorization data. If this WG is not the forum to seek feedback on this =
proposal, please redirect me =
accordingly.
 
 
From the Abstract:
  =
"This document specifies the use of DTCP certificate as =
an
   =
authorization extension in the Transport Layer Security =
Handshake
   =
Protocol, according to guidelines in RFC 5878.  Extensions carried =
in
   =
the client and server Hello messages confirm that both =
parties
   =
support the desired authorization data types.  Then if supported =
by
   =
both the client and server, DTCP certificates are exchanged in =
the
   =
supplemental data handshake TLS handshake message as specified =
in
   =
RFC4680."
Thanks in =
advance 
Regards,
Darshak =
Thakore

------=_NextPart_000_05E6_01CDBCEF.80FE7DA0--


From d.thakore@cablelabs.com  Wed Nov  7 20:37: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 BC07421F8A4B for ; Wed,  7 Nov 2012 20:37:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level: 
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5KWpjzGuJdX for ; Wed,  7 Nov 2012 20:37:51 -0800 (PST)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1A87421F8A3B for ; Wed,  7 Nov 2012 20:37:50 -0800 (PST)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id qA84bm26021661; Wed, 7 Nov 2012 21:37:49 -0700
Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Wed, 07 Nov 2012 21:37:48 -0700 (MST)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 7 Nov 2012 21:37:49 -0700
From: Darshak Thakore 
To: "tls@ietf.org" , Mark Brown 
Date: Wed, 7 Nov 2012 21:37:46 -0700
Thread-Topic: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message
Thread-Index: Ac29as313r+GPuiwTgSyDwjReLVTxw==
Message-ID: 
In-Reply-To: <05e501cdbd21$cb97b520$62c71f60$@redphonesecurity.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.4.120824
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_CCC08BA4F126dthakorecablelabscom_"
MIME-Version: 1.0
X-Approved: ondar
Subject: Re: [TLS] New Authz extension to use DTCP certificates in TLS SD handshake message
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, 08 Nov 2012 04:37:52 -0000

--_000_CCC08BA4F126dthakorecablelabscom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Mark,
Thanks a lot for the review. This was exactly the feedback i was looking fo=
r. I will incorporate your points in the I-D and upload a new version in th=
e next couple of days.
I've also attempted to clarify some of the points below.


From: Mark Brown >
Date: Wednesday, November 7, 2012 2:55 PM
To: Darshak Thakore >, "tls@ietf.org" >
Subject: RE: [TLS] New Authz extension to use DTCP certificates in TLS SD h=
andshake message

Darshak,
I have feedback and questions for you ranging from details to requirements.=
 I did a quick scan of the DTCP and DTCP-IP documents, and I may have misun=
derstood them at places. I suspect that others on this TLS list might not w=
ant to invest a lot of time doing the same. You might refer to DTCP=92s rel=
evant sections more specifically (and at relevant places in your ID) to eas=
e the recruitment of TLS readers.

DT>> I will update the I-D to reference the relevant sections from the DTCP=
 specs



1. Section (3.2) What *should* be signed and why? Struct =93dtcp_authz_data=
=94 does not contain a *signed* nonce, but simply concatenates it with the =
signed struct. Did you want to ensure freshness / avoid replay attacks, or =
am I misunderstanding your purpose? This purpose should be clarified in you=
r ID.

DT>> The intent here is to cryptographically tie the DTCP certificate with =
the X.509 certificate of the sender in order to avoid replay and MITM attac=
ks. Since this data will be going in the clear (within the SupplementalData=
 handshake message) this structure contains the {DTCP Certificate, X.509 Ce=
rtificate} and a signature covering both the elements that allows the recei=
ver to verify that the possessor of the X.509 certificate is also the posse=
ssor of the DTCP Certificate. The signature will be generated using the pri=
vate key associated with the DTCP certificate. I will update this section a=
nd try to clarify this.




2. Section (1) Regarding why you are using TLS and AUTHZ, your introduction=
 raises more questions than it answers for me, even though I suspect that c=
ontent protection and authorizations go together at a high level. First, IM=
HO, the DTCP and DTCP-IP documents seem to have a lot of overlap with the b=
asic motivations for an encryption protocol, which is what TLS provides too=
. So, why two similar protocols? Is your goal primarily to tunnel the DTCP =
protocol within the TLS protocol? While authorization can be understood in =
several ways, protocol tunneling is a not typical meaning for authorization=
. Or is the primary goal to =93determine the type of protected data to be e=
xchanged=94? If so, please describe the authorization decision that might t=
ake place in this determination, and document the semantics of =93access_de=
nied=94 alert messages for your authorizations.

DT>> That's a great question and goes to the heart of this proposal. No, th=
e intent here is not to tunnel the DTCP-IP encryption protocol thru TLS. In=
 fact the intent is to avoid the DTCP encryption protocol (specified as AKE=
 =96 Authentication Key Exchange) since DTCP AKE is meant for content prote=
ction only and has limited use. The intent is to reuse the DTCP certificate=
s as additional authorization data in a TLS handshake. As i had very briefl=
y mentioned in the presentation, the devices that contain these DTCP certif=
icates are becoming web enabled and have full HTML5 User Agents on them. Wh=
en these devices are being used to access services over https, if a server =
can verify that the devices posses a valid DTCP certificate, then it can pr=
ovide web enabled services to these devices that it would not typically pro=
vide to a normal user agent. A server would typically not deny access compl=
etely to a device that does not provide a DTCP certificate but may not prov=
ide a full spectrum of services.





3. Section (1): Which security/encryption features do you need? DTCP seems =
to require mutual authentication (my quick read is that it always uses EC D=
ifffie Hellman key agreement between two non-X.509 certificates under a DTL=
A-lite certificate authority [CA]). However, DTCP does not provide TLS=92s =
flexibility and it uses mismatched key strengths (80bit EC vs. 128 bit AES,=
 see, e.g. http://www.nsa.gov/business/programs/elliptic_curve.shtml ). Ask=
ing, =93Why use TLS at all?=94 might help clarify. Are you interested in th=
e flexibility or strength of its ciphersuites, or its history of vulnerabil=
ity and protocol analysis, or its history of standard use?  If so, which pr=
otocol=92s session keys and encryptors will you use, and what do the keys m=
ean to the overall security argument? Why does the DTCP certificate need to=
 be =93cryptographically tied to the X.509 certificate being used during th=
e TLS [handshake]=94?  Why not create the X.509 cert already bound to the D=
TCP cert? I think you should clarify your purpose and then document it in a=
 revised Introduction.

DT>> To answer "Why use TLS at all?", its all of the above that you mention=
ed plus the fact that its defacto for http traffic. The session keys and en=
cryptors will be used as per TLS.  The reason the DTCP certificate needs to=
 be cryptographically tied to the X.509 certificate is to avoid MITM attack=
 since the DTCP certificate is easily accessible. The idea here is to use D=
TCP certificate as additional authorization that entitles the device to rec=
eive additional services




4. Regarding DTCP nonstandard certificates (4.2.3.1, Fig 7) vs. X.509 certi=
ficates: IMHO, and perhaps DTCP agrees, ASN.1 BER/DER seems like language o=
verkill for simple certs. Parsing ASN.1 found in Certificate handshake mess=
ages is an arcane, complex, software-oriented, and risky (read: pointer-ari=
thmetic-rich) operation that can mix up tasks of first-time validation with=
 every-time verification. But if you plan on generating both a DTLA certifi=
cate and an X.509 certificate for the same keypair, then you might consider=
 simply using the existing TLS client (mutual) authentication instead of se=
parately signing just your authorization token. Just look at the Certificat=
eVerify (CV) message already defined for TLS, which runs a hash over the cl=
ient=92s and the server=92s nonces, the rest of the handshake, and your Sup=
plementalData, then signs. If you use the existing TLS CV message, then you=
r DTCP protocol should be able to offload the standardized certificate vali=
dations onto the TLS protocol, for which ASN.1 parsers are already present =
in implementations, including management of the CA lists and OCSP checking.

DT>> We would not be generating a DTLA certificate and X.509 certificate fo=
r the same key pair (i wish=85 :). In fact the X.509 certificate will very =
likely be totally independent of the DTCP certificate (the client may not e=
ven use an X.509 certificate in which case there won't be any CV message). =
The proposal here is to exchange the DTCP certificates with minimal impact =
to the TLS semantics and that's why the use of SupplementalData is attracti=
ve since it puts the onus of processing the authorization data at the appli=
cation layer.

I hope that provides some clarification. Once again thanks a lot for the fe=
edback and i look forward to answering more questions

Regards,
Darshak Thakore



From: tls-bounces@ietf.org [mailto:tls-bounces=
@ietf.org] On Behalf Of Darshak Thakore
Sent: Tuesday, November 06, 2012 10:09 AM
To: tls@ietf.org
Subject: [TLS] New Authz extension to use DTCP certificates in TLS SD hands=
hake message

Folks,
I am sending this email to obtain feedback and guidance on the following I-=
D, which proposes a new Authorization Data Format to the TLS SupplementalDa=
ta Handshake extension to use DTCP certificates as authorization data. If t=
his WG is not the forum to seek feedback on this proposal, please redirect =
me accordingly.

http://tools.ietf.org/html/draft-dthakore-authz-01

>From the Abstract:

  "This document specifies the use of DTCP certificate as an

   authorization extension in the Transport Layer Security Handshake

   Protocol, according to guidelines in RFC 5878.  Extensions carried in

   the client and server Hello messages confirm that both parties

   support the desired authorization data types.  Then if supported by

   both the client and server, DTCP certificates are exchanged in the

   supplemental data handshake TLS handshake message as specified in

   RFC4680."

Thanks in advance

Regards,

Darshak Thakore

--_000_CCC08BA4F126dthakorecablelabscom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



Hi Mark,
Thanks a lot=
 for the review. This was exactly the feedback i was looking for. I will in=
corporate your points in the I-D and upload a new version in the next coupl=
e of days.
I've also attempted to clarify some of the points belo=
w. 


From:  Mark Brown <mark@redphonesecurity.com>
Date:  Wednesday, November 7, 2012 2:55 PM
To:  Darshak Thakore <d.thakore@cablelabs.com>, "tls@ietf.org" <tls@ietf=
.org>
Subject:  RE: [TLS]=
 New Authz extension to use DTCP certificates in TLS SD handshake message

=

Darshak,
 
1. Section (3.2) What *should* be sign=
ed and why? Struct =93dtcp_authz_data=94 does not =
contain a *signed* nonce, but simply concatenates it with the signed struct=
. Did you want to ensure freshness / avoid replay attacks, or am I misunder=
standing your purpose? This purpose should be clarified in your ID.<=
/pre>

DT>> T=
he intent here is to cryptographically tie the DTCP certificate with the X.=
509 certificate of the sender in order to avoid replay and MITM attacks. Si=
nce this data will be going in the clear (within the SupplementalData hands=
hake message) this structure contains the {DTCP Certificate, X.509 Certific=
ate} and a signature covering both the elements that allows the receiver to=
 verify that the possessor of the X.509 certificate is also the possessor o=
f the DTCP Certificate. The signature will be generated using the private k=
ey associated with the DTCP certificate. I will update this section and try=
 to clarify this.

=
 
2. Section (1) Regardi=
ng why you are using TLS and AUTHZ, your introduction raises more questions=
 than it answers for me, even though I suspect that content protection and =
authorizations go together at a high level. First, IMHO, the DTCP and DTCP-=
IP documents seem to have a lot of overlap with the basic motivations for a=
n encryption protocol, which is what TLS provides too. So, why two similar =
protocols? Is your goal primarily to tunnel the DTCP protocol within the TL=
S protocol? While authorization can be understood in several ways, protocol=
 tunneling is a not typical meaning for authorization. Or is the primary go=
al to =93determine the type of protected data to be exchanged=94? If so, pl=
ease describe the authorization decision that might take place in this dete=
rmination, and document the semantics of =93access_denied=94 alert messages=
 for your authorizations.

DT>> That's a great question and goes to the hea=
rt of this proposal. No, the intent here is not to tunnel the DTCP-IP encry=
ption protocol thru TLS. In fact the intent is to avoid the DTCP encryption=
 protocol (specified as AKE =96 Authentication Key Exchange) since DTCP AKE=
 is meant for content protection only and has limited use. The intent is to=
 reuse the DTCP certificates as additional authorization data in a TLS hand=
shake. As i had very briefly mentioned in the presentation, the devices tha=
t contain these DTCP certificates are becoming web enabled and have full HT=
ML5 User Agents on them. When these devices are being used to access servic=
es over https, if a server can verify that the devices posses a valid DTCP =
certificate, then it can provide web enabled services to these devices that=
 it would not typically provide to a normal user agent. A server would typi=
cally not deny access completely to a device that does not provide a DTCP c=
ertificate but may not provide a full spectrum of services.

<=
/div>

 <=
/span>
3. Section (1): Which security/encryptio=
n features do you need? DTCP seems to require mutual authentication (my qui=
ck read is that it always uses EC Difffie Hellman key agreement between two=
 non-X.509 certificates under a DTLA-lite certificate authority [CA]). Howe=
ver, DTCP does not provide TLS=92s flexibility and it uses mismatched key s=
trengths (80bit EC vs. 128 bit AES, see, e.g. http://www.nsa.gov/business/progra=
ms/elliptic_curve.shtml ). Asking, =93Why use TLS at all?=94 might help=
 clarify. Are you interested in the flexibility or strength of its ciphersu=
ites, or its history of vulnerability and protocol analysis, or its history=
 of standard use?  If so, which protocol=92s session keys and encrypto=
rs will you use, and what do the keys mean to the overall security argument=
? Why does the DTCP certificate need to be =93cryptographically tied to the=
 X.509 certificate being used during the TLS [handshake]=94?  Why not =
create the X.509 cert already bound to the DTCP cert? I think you should cl=
arify your purpose and then document it in a revised Introduction.

DT>> To=
 answer "Why use TLS at all?", its all of the above that you ment=
ioned plus the fact that its defacto for http traffic. The session keys and=
 encryptors will be used as per TLS.  The reason the DTCP certificate =
needs to be cryptographically tied to the X.509 certificate is to avoid MIT=
M attack since the DTCP certificate is easily accessible. The idea here is =
to use DTCP certificate as additional authorization that entitles the devic=
e to receive additional services  

<=
div class=3D"WordSection1">
<=
pre> 
=
4. Regarding DTCP nonstandard certificates (4.2.3.1, Fig 7) vs. X.509 certi=
ficates: IMHO, and perhaps DTCP agrees, ASN.1 BER/DER seems like language o=
verkill for simple certs. Parsing ASN.1 found in Certificate handshake mess=
ages is an arcane, complex, software-oriented, and risky (read: pointer-ari=
thmetic-rich) operation that can mix up tasks of first-time validation with=
 every-time verification. But if you plan on generating both a DTLA certifi=
cate and an X.509 certificate for the same keypair, then you might consider=
 simply using the existing TLS client (mutual) authentication instead of se=
parately signing just your authorization token. Just look at the Certificat=
eVerify (CV) message already defined for TLS, which runs a hash over the cl=
ient=92s and the server=92s nonces, the rest of the handshake, and your Sup=
plementalData, then signs. If you use the existing TLS CV message, then you=
r DTCP protocol should be able to offload the standardized certificate vali=
dations onto the TLS protocol, for which ASN.1 parsers are already present =
in implementations, including management of the CA lists and OCSP checking.=
 

DT&=
gt;> We would not be generating a DTLA certificate and X.509 certificate=
 for the same key pair (i wish=85 :). In fact the X.509 certificate will ve=
ry likely be totally independent of the DTCP certificate (the client may no=
t even use an X.509 certificate in which case there won't be any CV message=
). The proposal here is to exchange the DTCP certificates with minimal impa=
ct to the TLS semantics and that's why the use of SupplementalData is attra=
ctive since it puts the onus of processing the authorization data at the ap=
plication layer.

I hope that provides some clarifi=
cation. Once again thanks a lot for the feedback and i look forward to answ=
ering more questions

Regards,
Darshak Th=
akore



From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org]
On Behalf Of Darshak Thakore
Sent: Tuesday, November 06, 2=
012 10:09 AM
To: tls@ietf.org=

Subject: [TLS] New Authz extension to use DTCP certificates in T=
LS SD handshake message
 
Folks,<=
/o:p>
I am sending thi=
s email to obtain feedback and guidance on the following I-D, which propose=
s a new Authorization Data Format to the TLS SupplementalData Handshake
 extension to use DTCP certificates as authorization data. If this WG is no=
t the forum to seek feedback on this proposal, please redirect me according=
ly.
&n=
bsp;
 
From the Abstract:
  "=
;This document specifies the use of DTCP certificate as an
   Protocol, according to guidelines in R=
FC 5878.  Extensions carried in
   the cli=
ent and server Hello messages confirm that both parties
&=
nbsp;  support the desired authorization data types.  Then if sup=
ported by
   both the client and server, DTCP c=
ertificates are exchanged in the
   supplementa=
l data handshake TLS handshake message as specified in
&n=
bsp;  RFC4680."
Thanks in advance =

Regards,
Darshak Thakore
<=
/div>


--_000_CCC08BA4F126dthakorecablelabscom_--

From albrecht.schwarz@alcatel-lucent.com  Thu Nov  8 01:48: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 52EF521F86E4 for ; Thu,  8 Nov 2012 01:48:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.248
X-Spam-Level: 
X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kOBTVPL2usk for ; Thu,  8 Nov 2012 01:48:14 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9154D21F88B1 for ; Thu,  8 Nov 2012 01:48:10 -0800 (PST)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA89kcrQ012991 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 8 Nov 2012 10:48:07 +0100
Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.50]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 8 Nov 2012 10:47:55 +0100
From: "Schwarz, Albrecht (Albrecht)" 
To: "TLS@ietf.org" 
Date: Thu, 8 Nov 2012 10:47:51 +0100
Thread-Topic: draft-tschofenig-lwig-tls-minimal = TLS profile proposal
Thread-Index: Ac29lh4nAa8BGdNASWaPe5rCLaEE7A==
Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9623DF010287@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-puzzleid: {A0EDB32E-157A-49C5-ACAF-56394F2B058B}
x-cr-hashedpuzzle: Abm+ AjkZ A4kS DxaR Etkg FaTF FslD GGFn GPrr Gnz4 G4fQ G+KR Il3x Imzh JDjs J2HP; 1; dABsAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {A0EDB32E-157A-49C5-ACAF-56394F2B058B}; YQBsAGIAcgBlAGMAaAB0AC4AcwBjAGgAdwBhAHIAegBAAGEAbABjAGEAdABlAGwALQBsAHUAYwBlAG4AdAAuAGMAbwBtAA==; Thu, 08 Nov 2012 09:47:51 GMT; ZAByAGEAZgB0AC0AdABzAGMAaABvAGYAZQBuAGkAZwAtAGwAdwBpAGcALQB0AGwAcwAtAG0AaQBuAGkAbQBhAGwAIAA9ACAAVABMAFMAIABwAHIAbwBmAGkAbABlACAAcAByAG8AcABvAHMAYQBsAA==
acceptlanguage: de-DE, en-US
Content-Type: multipart/alternative; boundary="_000_5F7BCCF5541B7444830A2288ABBEBC9623DF010287FRMRSSXCHMBSD_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal
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, 08 Nov 2012 09:48:16 -0000

--_000_5F7BCCF5541B7444830A2288ABBEBC9623DF010287FRMRSSXCHMBSD_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear All,
like to raise a general comment to the group, driven by the "TLS minimal" d=
raft:

Do agree to the message of this doc, guess that the subject as such is out =
of question in the TLS community.
Actually I've expected more concrete specification guidelines from the conc=
lusion section.
Notions such as "TLS can be customized ...", "... required TLS functionalit=
y" or "It can be tailored to fit the needs of a specific deployment environ=
ment." point out that TLS related parameters and procedures could and shoul=
d be specified in detail for a particular communication (and security) envi=
ronment.

The answer could be the explicit introduction of a profile concept, - which=
 is very well known already for some protocols.
Profiles could be more high level (like the "RTP profiles" (e.g. RFC 3551 a=
s a "minimum" ...) or fairly detailed (such as the 3GPP "SIP Gm profile" or=
 H.248 profiles).

And there are already concepts for "TLS profiles" around, see e.g.
- "3GPP TLS Protocol Profile" (Annex E/33.310)
- "OMA TLS Profile" (OMA-TS-TLS-V1_...) or
- "Operating system xyz TLS Profile" ('xyz' as a placeholder for some well =
known OSs)

However, all these TLS profile concepts are not really identical, sharing s=
ome common capabilities, but also adding some specifics.
The rational behind is the fact that an explicit TLS profile concept is not=
 (yet?) introduced in the IETF TLS core RFCs in my understanding.

We faced the same situation in ITU-T SG16 in work items for H.248-controlle=
d TLS services.
Thus, we made a definition proposal as a working assumption.

Interested parties may have a look in:
a) H.248.TLS "H.248 packages for control of transport security"
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-23.zip

3.2.6   TLS-profile: A selection of options from a set of TLS related param=
eters and procedures.

and a concrete example may be found in:
8.7      Example for the TLS profile concept

b) H.248.TLSPROF "Guidelines on the use of H.248 capabilities for transport=
 security in TLS networks in H.248 Profiles"
http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-24.zip


Would be interested whether the TLS WG experts
a) thought already about the definition of a profile for TLS (and DTLS)?
[Which would be a terminology definition and could be additionally a templa=
te for protocol profiling]
b) got any comments on our proposed TLS terms in above ITU-T work items?

Thanks,
Albrecht







--_000_5F7BCCF5541B7444830A2288ABBEBC9623DF010287FRMRSSXCHMBSD_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear All,


like to raise a general comment to the group, driven by the “TLS=
 minimal” draft:


 


Do agree to the message of this doc, guess that the subject as such is=
 out of question in the TLS community.


Actually I’ve expected more concrete specification guidelines fr=
om the conclusion section.


Notions such as “TLS can be customized …”, “&#=
8230; required TLS functionality” or “It can be tailored to fit=
 the needs of a specific deployment environment.” point out that TLS =
related parameters and procedures could and should be specified in detail f=
or a
particular communication (and security) environment.


 


The answer could be the explicit introduction of a profile concept, - =
which is very well known already for some protocols.


Profiles could be more high level (like the “RTP profiles”=
 (e.g. RFC 3551 as a “minimum” …) or fairly detailed (suc=
h as the 3GPP “SIP Gm profile” or H.248 profiles).


 


And there are already concepts for “TLS profiles” around, =
see e.g.


- „3GPP TLS Protocol Profile“ (Annex E/33.310)


- „OMA TLS Profile“ (OMA-TS-TLS-V1_...) or


- „Operating system xyz TLS Profile“ (‘xyz’ as=
 a placeholder for some well known OSs) 


 


However, all these TLS profile concepts are not really identical, shar=
ing some common capabilities, but also adding some specifics.


The rational behind is the fact that an explicit TLS profile concept i=
s not (yet?) introduced in the IETF TLS core RFCs in my understanding.

 


We faced the same situation in ITU-T SG16 in work items for H.248-cont=
rolled TLS services.


Thus, we made a definition proposal as a working assumption.


 


Interested parties may have a look in:


a) H.248.TLS "H.248 packages for control of transport security=
"



 


3.2.6   TLS=
-profile: A selection of options from a set of TLS related parameters a=
nd procedures.


 


and a concrete example m=
ay be found in:=



8.7      Example for the TLS profile concept


 


b) H.248.TLSPROF "Guidelines on the use of H.248 capabilit=
ies for transport security in TLS networks in H.248 Profiles"



 


 


Would be interested whether the TLS WG experts 


a) thought already about the definition of a profile for TLS (and DTLS=
)?


[Which would be a terminology definition and could be additionally a templa=
te for protocol profiling]


b) got any comments on our proposed TLS terms in above ITU-T work item=
s?


 


Thanks,


Albrecht


 


 


 


 


 


 





--_000_5F7BCCF5541B7444830A2288ABBEBC9623DF010287FRMRSSXCHMBSD_--

From balfanz@google.com  Thu Nov  8 13:22: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 5D7D921F8B3B for ; Thu,  8 Nov 2012 13:22:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2K48tpmS5tm for ; Thu,  8 Nov 2012 13:22:34 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCAF21F89E5 for ; Thu,  8 Nov 2012 13:22:34 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so2395738qca.31 for ; Thu, 08 Nov 2012 13:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZVxELHxVduHhiojJguco20g+cjnOq1yhZB1/ToHww50=; b=TMj0KqPfIwY8ozypz8CeGC+h3YvtHwMsjm6YGwjlyRda0s7a4tK7jTtakCpO37vKT/ 9Q5I9G2pShkSM7PcN4doBrYtU58Dn+5QSS/95DpyGaiFQyf3KezdKmg+Pn5evMM3Ea/F L/qXvT8yI3MG59xeef4QSd1i+cfeQEw8Z5Mt/YYBI0kvCWCGJ6UxjYI4JeRS2mICyd/8 J8cKUvBzYzNfFg0WcxwOJXJckWDx18OyLAmdsFopvNKM0E8MhDuCpbxsd3AysK3D6uN3 lHWc35tLe+elE1LIQoITzpL8nmK5C3lH1PSsznKPIBPsCXZUxVPKAdF7UQgkauiimntP K6/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ZVxELHxVduHhiojJguco20g+cjnOq1yhZB1/ToHww50=; b=Jtx9H5MWkAWVIzvrkjzgfQhR6eYUoauyUVjnJxYmpF6K+XvmKmapXWl18B25EFoXsH qmlDaLv8j0RfJ7I8pbh8uMxk7zC17pjNEcmwsSgGJoaotB8S4fElKfe0jwYNbdv1ZPUk 5DHcPJyMEeX2uRSFWaQ0lWfo3p7pQ3Z1ElPuijxhOBoRQ38acgD0t4sOiYNhEBZzY+so B22IzIbB15sXhNsoOsXNlKPkz/vz//vfe/AMGCYK0+6xrWlfwdluKhmkXRlM4G4OOQlv ZU90UWJ9h0NvxO673EOg7Yz1rScW1DsvkcBQrQhKvCwxutzpX2gkoV4P9b05oQS3o/6E EDjQ==
MIME-Version: 1.0
Received: by 10.49.75.3 with SMTP id y3mr16407361qev.12.1352409753632; Thu, 08 Nov 2012 13:22:33 -0800 (PST)
Received: by 10.229.114.17 with HTTP; Thu, 8 Nov 2012 13:22:33 -0800 (PST)
Date: Thu, 8 Nov 2012 13:22:33 -0800
Message-ID: 
From: Dirk Balfanz 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=047d7bdcad28f4befe04ce026e9d
X-Gm-Message-State: ALoCoQlgcKk6Lwjdg5VzHv82TtRBSKX7RvFA/6YQPFZo5KmnnV/EzBtr0kSok/H4d4+Gz0vL5JYdsSg73CFAm1ajiTSz1RMPvRLK7i0ucx5Tv8X4tENRheRLXMLEN61+URmpMFcdRFMd7kWSwq9AEK968jLBUU1ETKXtYeAhL1aB/mcNLTtwIeOFT9XUs1gO7RafvYX3zgAp
Subject: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 08 Nov 2012 21:22:35 -0000

--047d7bdcad28f4befe04ce026e9d
Content-Type: text/plain; charset=ISO-8859-1

Hello everybody,

As you might have noticed, I have let the TLS-Origin-Bound Certificates
(TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
expire. The reason for this is that we (i.e., Google) had implemented
TLS-OBC as described in the draft (in Chrome and server-side), and we
weren't too happy with it. There were a few of problems:

(1) Client certificates are part of the session state. Not only does that
mean that the session state is now considerably bigger than it used to be,
it also means that anyone that can steal session secrets (malware on the
client) can make it look to the server as if they were in possession of the
client's private key, even if that private key sits in a TPM on the client.

(2) The logic in the client and server that treated OBCs and normal client
certs differently, even though they were delivered through the same kind of
Certificate message, turned out to be a little more complex that we wanted
it to be.

(3) To keep the public key of the client (which acts like a machine
identifier) away from prying eyes, we had to entangle the TLS-OBC extension
with another extension that reordered handshake messages (and sent the
Certificate message after the ChangeCipherSpec message). That added further
ugly complexity.

(4) The main use case for this was to be able to "channel-bind" cookies.
Cookies, however, can be set across more than just a web origin. When the
underlying transport uses different client keys for different origins
inside the same TLD, then we can't bind a domain cookie to the underlying
TLS channel.

(If you were at IETF 85 you might have seen Adam give a short talk about
this.)

To fix all this, we wrote a new proposed spec:
http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

This spec is silent on the scope of the keys (but in practice we expect
browsers to use eTLD+1 now instead of more fine-grained origins), and
addresses all the other issues explicitly: the Channel IDs are not part of
the TLS session state, and are exchanged after encryption is turned on.

A comment on the new name: One of the ways the new spec is simpler than the
old one is that there are no more X.509 certs involved in proving
possession of the client key - so there goes the "C(ert)" in the "OBC"
acronym. Because of the agnosticism of the new spec toward the scope of the
client keys, there is also no "O(rigin)" anymore. Hence, we needed a new
name.

You can play with this proposed mechanism by getting Chrome 24 (just
released to the beta channel), and observing its connections to Google web
properties.

Thoughts?

Cheers,

Dirk.

--047d7bdcad28f4befe04ce026e9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


<=
div style=3D"font-family:arial,sans-serif;font-size:13px">Hello everybody,=
=A0


As you might hav=
e noticed, I have let the TLS-Origin-Bound Certificates (TLS-OBC:=A0http://tools.ietf.org/id/draft-balfanz-tls-obc-=
01.txt) draft expire. The reason for this is that we (i.e., Google) had=
 implemented TLS-OBC as described in the draft (in Chrome and server-side),=
 and we weren't too happy with it. There were a few of problems:



(1) Client certificates are part of the session state. Not only does t=
hat mean that the session state is now considerably bigger than it used to =
be, it also means that anyone that can steal session secrets (malware on th=
e client) can make it look to the server as if they were in possession of t=
he client's private key, even if that private key sits in a TPM on the =
client.=A0



(2) The log=
ic in the client and server that treated OBCs and normal client certs diffe=
rently, even though they were delivered through the same kind of Certificat=
e message, turned out to be a little more complex that we wanted it to be.<=
/div>


(3) To keep=
 the public key of the client (which acts like a machine identifier) away f=
rom prying eyes, we had to entangle the TLS-OBC extension with another exte=
nsion that reordered handshake messages (and sent the Certificate message a=
fter the ChangeCipherSpec message). That added further ugly complexity.


=

(4) The main use=
 case for this was to be able to "channel-bind" cookies. Cookies,=
 however, can be set across more than just a web origin. When the underlyin=
g transport uses different client keys for different origins inside the sam=
e TLD, then we can't bind a domain cookie to the underlying TLS channel=
.



(If you were at IETF 8=
5 you might have seen Adam give a short talk about this.)


To fix=
 all this, we wrote a new proposed spec:=A0http://tools.ietf.org/html/draft-balf=
anz-tls-channelid-00



This spec is silent on=
 the scope of the keys (but in practice we expect browsers to use eTLD+1 no=
w instead of more fine-grained origins), and addresses all the other issues=
 explicitly: the Channel IDs are not part of the TLS session state, and are=
 exchanged after encryption is turned on.



A comment on the new n=
ame: One of the ways the new spec is simpler than the old one is that there=
 are no more X.509 certs involved in proving possession of the client key -=
 so there goes the "C(ert)" in the "OBC" acronym. Becau=
se of the agnosticism of the new spec toward the scope of the client keys, =
there is also no "O(rigin)" anymore. Hence, we needed a new name.=




You can play with this=
 proposed mechanism by getting Chrome 24 (just released to the beta channel=
), and observing its connections to Google web properties.



Thoughts?


Cheers,=A0
=

Dirk.<=
/div>

<=
/div>

--047d7bdcad28f4befe04ce026e9d--

From n.mavrogiannopoulos@gmail.com  Thu Nov  8 14:04:42 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A72E21F88B4 for ; Thu,  8 Nov 2012 14:04:42 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZPdNCxLsdPH for ; Thu,  8 Nov 2012 14:04:42 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C4CBF21F8883 for ; Thu,  8 Nov 2012 14:04:41 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr13so1493162wgb.13 for ; Thu, 08 Nov 2012 14:04:41 -0800 (PST)
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=uW3AiOGiYLF3GucsQHvmQ6oUKUjj5TynrZAaDuVvMJo=; b=E/abpOTwvdywUqAg9nbSl6qG0p2pbQz1UUFob7kgKEWO7II0mD+Bzr6m8omoHDqj9O cXFu55mm+H6SCrEkpKDcYoZev2H8ftDepS4WRv8zbOsGugXn3WDezIW08yq97Y/Ciyd3 beP8SEc609QNbgicwWFqJRekUWTZtn4dThJpbNcVxN3a2z8jGzVWk/6HnpTqciOsmrYy Xoy71EBaFoXckiQnGqmh7Lcsl8Yin3jcEW2HS8t6muQvvLbpdnbiqCadCNJi8w4bOR6k WDqI8mqW0LJ0NCLmnh8g4dda8rRy2ysd3UpwA94oDl/0d59yyhniZWYiEHeG0Y6KfuW4 /m5w==
Received: by 10.180.77.38 with SMTP id p6mr15847298wiw.1.1352412280970; Thu, 08 Nov 2012 14:04:40 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id i6sm288932wix.5.2012.11.08.14.04.39 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 14:04:40 -0800 (PST)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <509C2C71.8070100@gnutls.org>
Date: Thu, 08 Nov 2012 23:04:33 +0100
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: Dirk Balfanz 
References: 
In-Reply-To: 
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] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 08 Nov 2012 22:04:42 -0000

On 11/08/2012 10:22 PM, Dirk Balfanz wrote:

> Hello everybody,


Hello,
 Some comments/questions inline.

> (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft

> expire. The reason for this is that we (i.e., Google) had implemented
> TLS-OBC as described in the draft (in Chrome and server-side), and we
> weren't too happy with it. There were a few of problems:
> 
> (1) Client certificates are part of the session state. Not only does that
> mean that the session state is now considerably bigger than it used to be,
> it also means that anyone that can steal session secrets (malware on the
> client) can make it look to the server as if they were in possession of the
> client's private key, even if that private key sits in a TPM on the client.


How is that? Do you mean by session resumption? Isn't it the same on the
current draft?

> This spec is silent on the scope of the keys (but in practice we expect
> browsers to use eTLD+1 now instead of more fine-grained origins), and
> addresses all the other issues explicitly: the Channel IDs are not part of
> the TLS session state, and are exchanged after encryption is turned on.
> 
> A comment on the new name: One of the ways the new spec is simpler than the
> old one is that there are no more X.509 certs involved in proving
> possession of the client key - so there goes the "C(ert)" in the "OBC"
> acronym. Because of the agnosticism of the new spec toward the scope of the
> client keys, there is also no "O(rigin)" anymore. Hence, we needed a new
> name.


The approach actually looks like a prime user of the
draft-ietf-tls-oob-pubkey extension that allows to send the
SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
allows any type of client public key, instead of sticking to a fixed
ECDSA curve? No additional extension would be required.

regards,
Nikos

From agl@google.com  Thu Nov  8 14:46: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 1E37321F849C for ; Thu,  8 Nov 2012 14:46:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ql93FXzjtSKa for ; Thu,  8 Nov 2012 14:45:56 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id E189921F8495 for ; Thu,  8 Nov 2012 14:45:49 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so5614337iec.31 for ; Thu, 08 Nov 2012 14:45:48 -0800 (PST)
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; bh=/o0dFC9YyCMbwjM/A3Q6HCXnptmz/VFDYYdKmeIu82M=; b=OURAsU9VuC7kSt2hRwZVjplOgVdDryUdMKZ/GAEOhyuiOfTBYRxB+CLn9oV85PZAMO KvIDYHGloYz+QmYHPnbQyS69SfgfqLOtvutLc/3loxTDmV2TGDxQYVYouKMT+WsjYbUJ U06iLhWz7TFwTSxIBYk6cNuieV3DYFEwC1/rdok6jEM8DH9RGJDFjOtqBpgD7YeuNAOJ X9tyVFbsp8OKbpr8SheAzPlGCUWbI2oBMotothJ0PhEQ/ENj3JYV4qd0AuILqzeQzwPk Wc1NE2L/62eMwy9aM2LuKp8bBhIxnfTaE4OAjAn/Hkkm10PS3IKyHiXh45uAQ9jA6QpC bckg==
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-gm-message-state; bh=/o0dFC9YyCMbwjM/A3Q6HCXnptmz/VFDYYdKmeIu82M=; b=DFEgGBUbq/sJDCqzNpuA8AlvWYAiRpNaHWjT99lZQqM3n+lt6oUYgOtG8G2ca1996x v1zbmbqdvkxNaW5CCa4U3k5yGeSHveayL2S9VLIhSI+JIpJrEvEkz9Kv4HjD1S1ZiVn+ XN9Z5GMQRZKZ2/Ky1tm08AS5CDjpnwHcfZUIzzNI3R5ssJBlWe4CqaodtftxX2XVEiiD 2GZ22cOwn94Xds7MVfnwpwENh5orOj3OLkFzDOZGIgFYNz0imkAqjptS6hAcsQIAL4co uRIybBpYMrV/+oBnqX1HMtPNTFjV4XrR/5eUqTOERZ16f24eidD07q84kH45KwLAblfy Ksmw==
MIME-Version: 1.0
Received: by 10.50.40.166 with SMTP id y6mr9603636igk.57.1352414748387; Thu, 08 Nov 2012 14:45:48 -0800 (PST)
Received: by 10.231.56.89 with HTTP; Thu, 8 Nov 2012 14:45:48 -0800 (PST)
Received: by 10.231.56.89 with HTTP; Thu, 8 Nov 2012 14:45:48 -0800 (PST)
In-Reply-To: <509C2C71.8070100@gnutls.org>
References:  <509C2C71.8070100@gnutls.org>
Date: Thu, 8 Nov 2012 17:45:48 -0500
Message-ID: 
From: Adam Langley 
To: Nikos Mavrogiannopoulos 
Content-Type: multipart/alternative; boundary=14dae934045baaa9c304ce0398b4
X-Gm-Message-State: ALoCoQnK1gSiOJhmNdXCqD+QhCOKW2jsLjKIjKYoSwDVHeszcgc3Ltk8zyz0yxBPUDYjD7/mKDPAgFIwY3WN8pk9hV/z8Oip3kg+SnMr7VVlAh3CSImyHQtUgJSnO1CLPEXEH9JjBZjR+X/G4s9hoidUncQCDmej58KFEe6itlc/VUKzOIQkxCgJjFQYq8+ozJhQiDVdx8W6
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 08 Nov 2012 22:46:01 -0000

--14dae934045baaa9c304ce0398b4
Content-Type: text/plain; charset=UTF-8

On Nov 8, 2012 5:04 PM, "Nikos Mavrogiannopoulos"  wrote:
>
> On 11/08/2012 10:22 PM, Dirk Balfanz wrote:
>
> > Hello everybody,
>
>
> Hello,
>  Some comments/questions inline.
>
> > (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
>
> > expire. The reason for this is that we (i.e., Google) had implemented
> > TLS-OBC as described in the draft (in Chrome and server-side), and we
> > weren't too happy with it. There were a few of problems:
> >
> > (1) Client certificates are part of the session state. Not only does
that
> > mean that the session state is now considerably bigger than it used to
be,
> > it also means that anyone that can steal session secrets (malware on the
> > client) can make it look to the server as if they were in possession of
the
> > client's private key, even if that private key sits in a TPM on the
client.
>
>
> How is that? Do you mean by session resumption? Isn't it the same on the
> current draft

ChannelIDs are not part of the session state and need to be sent in an
abbreviated handshake. (The draft may be unclear on that point.)

>
> > This spec is silent on the scope of the keys (but in practice we expect
> > browsers to use eTLD+1 now instead of more fine-grained origins), and
> > addresses all the other issues explicitly: the Channel IDs are not part
of
> > the TLS session state, and are exchanged after encryption is turned on.
> >
> > A comment on the new name: One of the ways the new spec is simpler than
the
> > old one is that there are no more X.509 certs involved in proving
> > possession of the client key - so there goes the "C(ert)" in the "OBC"
> > acronym. Because of the agnosticism of the new spec toward the scope of
the
> > client keys, there is also no "O(rigin)" anymore. Hence, we needed a new
> > name.
>
>
> The approach actually looks like a prime user of the
> draft-ietf-tls-oob-pubkey extension that allows to send the
> SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
> allows any type of client public key, instead of sticking to a fixed
> ECDSA curve? No additional extension would be required.

That was suggested in the meeting. The reasons why that wouldn't work
without modification are that: it's part of the session state, it's
unencrypted in the handshake and we cannot also have a client cert if we do
that.

One of our reasons for doing something else rather than modifying client
certs was our experience that doing so turned into a bit of a mess when we
did it last time.

Cheers

AGL

>
> regards,
> Nikos
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--14dae934045baaa9c304ce0398b4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Nov 8, 2012 5:04 PM, "Nikos Mavrogiannopoulos" =
<nmav@gnutls.org> wrote:

>

> On 11/08/2012 10:22 PM, Dirk Balfanz wrote:

>

> > Hello everybody,

>

>

> Hello,

> =C2=A0Some comments/questions inline.

>

> > (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft=


>

> > expire. The reason for this is that we (i.e., Google) had impleme=
nted

> > TLS-OBC as described in the draft (in Chrome and server-side), an=
d we

> > weren't too happy with it. There were a few of problems:

> >

> > (1) Client certificates are part of the session state. Not only d=
oes that

> > mean that the session state is now considerably bigger than it us=
ed to be,

> > it also means that anyone that can steal session secrets (malware=
 on the

> > client) can make it look to the server as if they were in possess=
ion of the

> > client's private key, even if that private key sits in a TPM =
on the client.

>

>

> How is that? Do you mean by session resumption? Isn't it the same =
on the

> current draft


ChannelIDs are not part of the session state and need to be =
sent in an abbreviated handshake. (The draft may be unclear on that point.)=



>

> > This spec is silent on the scope of the keys (but in practice we =
expect

> > browsers to use eTLD+1 now instead of more fine-grained origins),=
 and

> > addresses all the other issues explicitly: the Channel IDs are no=
t part of

> > the TLS session state, and are exchanged after encryption is turn=
ed on.

> >

> > A comment on the new name: One of the ways the new spec is simple=
r than the

> > old one is that there are no more X.509 certs involved in proving=


> > possession of the client key - so there goes the "C(ert)&quo=
t; in the "OBC"

> > acronym. Because of the agnosticism of the new spec toward the sc=
ope of the

> > client keys, there is also no "O(rigin)" anymore. Hence=
, we needed a new

> > name.

>

>

> The approach actually looks like a prime user of the

> draft-ietf-tls-oob-pubkey extension that allows to send the

> SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
> allows any type of client public key, instead of sticking to a fixed
> ECDSA curve? No additional extension would be required.


That was suggested in the meeting. The reasons why that woul=
dn't work without modification are that: it's part of the session s=
tate, it's unencrypted in the handshake and we cannot also have a clien=
t cert if we do that.



One of our reasons for doing something else rather than modi=
fying client certs was our experience that doing so turned into a bit of a =
mess when we did it last time.


Cheers


AGL


>

> regards,

> Nikos

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

> https://www.ietf=
.org/mailman/listinfo/tls




--14dae934045baaa9c304ce0398b4--

From n.mavrogiannopoulos@gmail.com  Fri Nov  9 01:55:48 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E819621F860E for ; Fri,  9 Nov 2012 01:55:48 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcMDBqLkKY9e for ; Fri,  9 Nov 2012 01:55:48 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8D921F860D for ; Fri,  9 Nov 2012 01:55:48 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so6280699iec.31 for ; Fri, 09 Nov 2012 01:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4MYf8OePJmvwXtFvYpOhI1WXoj/PlnY8xrPF7zSpD7s=; b=WPo2fazejTHIO9KIgQRghdWh0IXtmOGSlUqH/6yFzuFewWKOfu0izTEffYZwe6jBze cnr6W1jw0bcov9cM83Yv1kYckB4bK52AwTmodT1+NsgROeuWnZKQUL9iJ4mUAtlCYWaL oieDwNakgCoos2t8TJdmBtc7Vulg/vi9g443nkbQHHydOlSj2HSaXzTQ1IHhdh93VGum KOotUs/n11nZG/opGOzi3MEiiZpz8wbwm6AAfExqY5vre7klS6OUNgAOclL7LNclAuMd /ql2qku99M/6Lc9rm3O5vt9qwHKzSvArCHtoSQGc2MvDaFONnkz/dezTGKf4o4Gw9VUU gz7g==
MIME-Version: 1.0
Received: by 10.42.65.6 with SMTP id j6mr9699239ici.2.1352454948039; Fri, 09 Nov 2012 01:55:48 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.64.34.171 with HTTP; Fri, 9 Nov 2012 01:55:47 -0800 (PST)
In-Reply-To: 
References:  <509C2C71.8070100@gnutls.org> 
Date: Fri, 9 Nov 2012 10:55:47 +0100
X-Google-Sender-Auth: UBEEJKZxh7wQP3D1O0bJcdkamMo
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: Adam Langley 
Content-Type: text/plain; charset=UTF-8
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 09 Nov 2012 09:55:49 -0000

On Thu, Nov 8, 2012 at 11:45 PM, Adam Langley  wrote:

>> The approach actually looks like a prime user of the
>> draft-ietf-tls-oob-pubkey extension that allows to send the
>> SubjectPublicKeyInfo. Why not use send a SubjectPublicKeyInfo which
>> allows any type of client public key, instead of sticking to a fixed
>> ECDSA curve? No additional extension would be required.
> That was suggested in the meeting. The reasons why that wouldn't work
> without modification are that: it's part of the session state, it's
> unencrypted in the handshake and we cannot also have a client cert if we do
> that.

Hello,
 The part of the session state I think would be hard to overcome.
Everything used in a TLS handshake is part of the state. What do you
actually need there is that this key and signature need to be resent
even if the client is resuming a session?

The unencrypted in the handshake is an early design choice in TLS. I
think TLS should be updated to cope with that, rather than each
individual extension try to patch that issue. Having said that there
was Marsh's proposal but I don't know if it is still active. In any
case this could be combined with a generic mechanism to have data in
TLS send after encryption is enabled (so that other extensions that do
that wouldn't reinvent the wheel).

About having a client certificate wouldn't it be more useful if a
client could submit more than one certificates/public keys? I haven't
seen much protocols doing that, but that is what your approach is
actually doing.

> One of our reasons for doing something else rather than modifying client
> certs was our experience that doing so turned into a bit of a mess when we
> did it last time.

Was it due to client constraints or because of the required changes?

regards,
Nikos

From agl@google.com  Fri Nov  9 06:46:51 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3E421F86DD for ; Fri,  9 Nov 2012 06:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECBHI6UUxLxV for ; Fri,  9 Nov 2012 06:46:51 -0800 (PST)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26CAE21F86D0 for ; Fri,  9 Nov 2012 06:46:51 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id x24so3112333iak.31 for ; Fri, 09 Nov 2012 06:46:50 -0800 (PST)
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; bh=RiQxhef+oROToeR0zQmwQNz755V2eE8CM1NwdT+ry30=; b=ALFpwlbCNtKiYCYsgyUHGwFdux/w6OPcrEgGV9e3Y/A50hfyhK18q5NCvdKnNm4GYW FKEw8xe8Pw+YmgPdfuQfO7VZpQ2a/h7AsK3PxlragqQFh55fZMd/O4sDgJ5tOvYDAzBN 5zLa12YRGzpdUEN0ux9v5tF+ZV4/fdBS/87+Y0zpEd8Y1bKSLreB1dLhZ1+qXrLaLpNs hvekU6FrzzVeiHdhaubfoA66IBhzk4qqnjYe/c0YVeDRbq+xEXEJ7EQ20AB27Bw52vUa IxSwam3SH1YFHSLENxlNMS8mcZjoCNEvv1Mm5BwCWxD8vyjbBkotT9i+ibkxW6iv1J5C etBg==
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-gm-message-state; bh=RiQxhef+oROToeR0zQmwQNz755V2eE8CM1NwdT+ry30=; b=Uz7J9SWj1jgHopW+UJuRQLC/PKhAzLpVKcA8qaaB0wURiZHECiZphCQpOS9rjG101/ FurmB0P22ZR8FwssX6CAUKkpMCi52rG9ROp4DjyHByuwRhYOUrg9dcdC1eO//zOauFqq +di/Sh2OhC9WpfZh7Jzj3MgNjK5tIFGWMPBhkGzyKCpI7L3MEJ3OpOycMiQKa7SCrtZV uB1JEdz7KogyEIHKuXlSMHRiy5/w8ymXXnP+rWLsfNPBew81N/rW2sbViJrP/MbbdxU5 G6OC+RTiJE6OJn/T2K+cmPl1Lb0i6ry9Cd60y9qbTQI4olXJarNl2BE8iyXVA/QJT/md WOmQ==
MIME-Version: 1.0
Received: by 10.50.213.34 with SMTP id np2mr1484253igc.57.1352472410706; Fri, 09 Nov 2012 06:46:50 -0800 (PST)
Received: by 10.231.56.89 with HTTP; Fri, 9 Nov 2012 06:46:50 -0800 (PST)
In-Reply-To: 
References:  <509C2C71.8070100@gnutls.org>  
Date: Fri, 9 Nov 2012 09:46:50 -0500
Message-ID: 
From: Adam Langley 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQmv8nvXII1d6LDLv0OCe1KUAB0DZOszehAv2WoaVmu2AR/ehDM2SLUzfoYvaM+tck856a0OtwEGNnlOosYBZiB4nJt7hB4udo9N6vszJpp+3BRLSCpKilvAtm1Ut2lkzBC01t9Zj65RBH8vMIviOKcmh1T2Z0EwtokZILWI5iRuBopcQ68IlA9YrOKg+uzy4Uw5E3hr
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 09 Nov 2012 14:46:51 -0000

On Fri, Nov 9, 2012 at 4:55 AM, Nikos Mavrogiannopoulos  wrote:
>  The part of the session state I think would be hard to overcome.
> Everything used in a TLS handshake is part of the state. What do you
> actually need there is that this key and signature need to be resent
> even if the client is resuming a session?

Yes. Since the aim is to eliminate barer tokens as a means of
authentication it's unfortunately, for our purposes, that session
resumption makes a barer token out of the key pair!

> The unencrypted in the handshake is an early design choice in TLS. I
> think TLS should be updated to cope with that, rather than each
> individual extension try to patch that issue. Having said that there
> was Marsh's proposal but I don't know if it is still active. In any
> case this could be combined with a generic mechanism to have data in
> TLS send after encryption is enabled (so that other extensions that do
> that wouldn't reinvent the wheel).

We do use the EncryptedExtensions mechanism which was suggested by
someone on this list (sorry, I forget who) for NPN. (And it part of
the NPN spec now.) So it does use a generic mechanism for sending
encrypted handshake data, but it doesn't solve the generic problem of
encrypting client-certificates any longer.

>> One of our reasons for doing something else rather than modifying client
>> certs was our experience that doing so turned into a bit of a mess when we
>> did it last time.
>
> Was it due to client constraints or because of the required changes?

It was because our use turns out to be substantially different from
client-side certificates that the code to support both in a single
mechanism turned into a lot of ugly exceptions.


Cheers

AGL

From chris@randomnonce.org  Fri Nov  9 12:30:39 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AD621F8645 for ; Fri,  9 Nov 2012 12:30:39 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+j0488IS7-F for ; Fri,  9 Nov 2012 12:30:39 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D20BE21F8647 for ; Fri,  9 Nov 2012 12:30:38 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id jg9so349959bkc.31 for ; Fri, 09 Nov 2012 12:30:32 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=r6Qz+wHRQE94R5cUohlmc6DilVg7jbcvcm3xZ45RZys=; b=XuWy7GaX49BaX60FEa31nEXPVq03WAaX1Y7uAQ10CESl0lewhhAdNGWBYZ7euADUUS Fnd4VtV8x1BAPS9NXb2C7bDE9Ugs9X7AN3vK3xob2N6bq3W7h3XbZRxkZT72b0NVdJEw 9ihXEloG5ZhSweoScujtD4uuamEqQJbQfjhLar+g319MzMwz2LLxOteU3WHUOpTkN4VP Q1QLaxY6kxjveOzdWv6XW1J3PHOQAueI1IehPsNu6SGLmZy3QP2DJITupbh5chMG1PDl iwZYzOnn3e6RvEI+9aq3/X7GRmIxtue80f73MSw6nUs+ebc7xiee8l4P/+KzqEwV0nSs eBmw==
MIME-Version: 1.0
Received: by 10.204.145.219 with SMTP id e27mr1143382bkv.140.1352493032490; Fri, 09 Nov 2012 12:30:32 -0800 (PST)
Received: by 10.205.125.132 with HTTP; Fri, 9 Nov 2012 12:30:32 -0800 (PST)
X-Originating-IP: [71.179.106.208]
In-Reply-To: 
References: 
Date: Fri, 9 Nov 2012 15:30:32 -0500
Message-ID: 
From: Chris Richardson 
To: Dirk Balfanz 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlExK/60ape3+ltL5AOnkk7dptpIqyuRshK/NbbgaOdhjWiO2bu5h9hqZHuSb89IUmhmAXy
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 09 Nov 2012 20:30:39 -0000

Perhaps I'm being picky, section 4 requires an illegal_parameter alert
if the cipher suite is insufficiently strong.  Doesn't
handshake_failure make more sense here?


On Thu, Nov 8, 2012 at 4:22 PM, Dirk Balfanz  wrote:
> Hello everybody,
>
> As you might have noticed, I have let the TLS-Origin-Bound Certificates
> (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
> expire. The reason for this is that we (i.e., Google) had implemented
> TLS-OBC as described in the draft (in Chrome and server-side), and we
> weren't too happy with it. There were a few of problems:
>
> (1) Client certificates are part of the session state. Not only does that
> mean that the session state is now considerably bigger than it used to be,
> it also means that anyone that can steal session secrets (malware on the
> client) can make it look to the server as if they were in possession of the
> client's private key, even if that private key sits in a TPM on the client.
>
> (2) The logic in the client and server that treated OBCs and normal client
> certs differently, even though they were delivered through the same kind of
> Certificate message, turned out to be a little more complex that we wanted
> it to be.
>
> (3) To keep the public key of the client (which acts like a machine
> identifier) away from prying eyes, we had to entangle the TLS-OBC extension
> with another extension that reordered handshake messages (and sent the
> Certificate message after the ChangeCipherSpec message). That added further
> ugly complexity.
>
> (4) The main use case for this was to be able to "channel-bind" cookies.
> Cookies, however, can be set across more than just a web origin. When the
> underlying transport uses different client keys for different origins inside
> the same TLD, then we can't bind a domain cookie to the underlying TLS
> channel.
>
> (If you were at IETF 85 you might have seen Adam give a short talk about
> this.)
>
> To fix all this, we wrote a new proposed spec:
> http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
>
> This spec is silent on the scope of the keys (but in practice we expect
> browsers to use eTLD+1 now instead of more fine-grained origins), and
> addresses all the other issues explicitly: the Channel IDs are not part of
> the TLS session state, and are exchanged after encryption is turned on.
>
> A comment on the new name: One of the ways the new spec is simpler than the
> old one is that there are no more X.509 certs involved in proving possession
> of the client key - so there goes the "C(ert)" in the "OBC" acronym. Because
> of the agnosticism of the new spec toward the scope of the client keys,
> there is also no "O(rigin)" anymore. Hence, we needed a new name.
>
> You can play with this proposed mechanism by getting Chrome 24 (just
> released to the beta channel), and observing its connections to Google web
> properties.
>
> Thoughts?
>
> Cheers,
>
> Dirk.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From agl@google.com  Fri Nov  9 13:51:57 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62A821F86DD for ; Fri,  9 Nov 2012 13:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kTelH7wXDn2 for ; Fri,  9 Nov 2012 13:51:56 -0800 (PST)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B296821F86DC for ; Fri,  9 Nov 2012 13:51:56 -0800 (PST)
Received: by mail-ia0-f172.google.com with SMTP id x24so3414889iak.31 for ; Fri, 09 Nov 2012 13:51:56 -0800 (PST)
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; bh=8adWCAEy0hS0Cjd6ZsZvjHrnEmzZZP0X4kYKYeofAjU=; b=SrTbW7ui5VSmA0cL+QkAHFUg5D0TQkvGHYBHZ2C9dqz+jNEsYKitJyH+tSLN1TPX06 g6KMah43cL9lOWyb+/X+GCZWqdaPdJZoFIwXtCGnWfjsUHhiqE2erZgQeITXJgeuXruV 0kKymF75efmYBVBersa1NLKC4JJvups4vTlVCbbZf9RF66aTAu7AjWzZ3aOqOzeVBsC3 thSlRjBGVcY2+QBlPFog8LBVbuVVvT9NUez2f+1quPx/K2vjPcP6dSTknbCU7JzoduuA f2JZFV2WsJxgZaKmiU7bqeTbMZlROCGsZ8b4fP9cAK0y8klnOR7I+xPyEYcbuazwH9RI pJww==
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-gm-message-state; bh=8adWCAEy0hS0Cjd6ZsZvjHrnEmzZZP0X4kYKYeofAjU=; b=d5+yCKagk3KnR3m4itF4BC15R5hcIi4VEAcV0RJiyegY/nCdTc67NBIJj2N9lrFo2j Envd3clxv4jJ9MAQ8gRmNthsLzYQJt/7pRS17mF87tT65AjZ6cPeeCGXOeMpkjy6EXN9 WOUMrTmljfV+jVf1xS+VbW3iwM5eJTdYyOhDCR2Bv2lnH659a4hbyMqDCuZ2xbq9ZPwZ t71CSfUuuBNaNV2siKEh5+YC8EQuTZkoZEH7IvbwB7v4dcimkzebKANYsis824xMj9AD Megbn7lEuk87rOqmnDsLoPJ+kvIN5wCBU1yNXgQqDoLYEshmSeDOZryD/OiA0DP/KIsp u+iA==
MIME-Version: 1.0
Received: by 10.42.37.142 with SMTP id y14mr11005824icd.44.1352497916159; Fri, 09 Nov 2012 13:51:56 -0800 (PST)
Received: by 10.231.220.207 with HTTP; Fri, 9 Nov 2012 13:51:56 -0800 (PST)
In-Reply-To: 
References:  
Date: Fri, 9 Nov 2012 16:51:56 -0500
Message-ID: 
From: Adam Langley 
To: Chris Richardson 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQn2Rh3NOPy1y2kLb42RpeskIzNB0z032SrwBcpQMWPT+z7cPFf/kuK26lZFx7IzY6SC1DfEuQ+uo9qiSeIoS+uiGv//XIqZejCcrJHX+IT95RioMwcfTwrBWlKp+ohyJc4G3Kas1l6wOblrhvfZaFilN7uSUke6HVUjii9VABsXwQ3V2jOS/8Qjz0EllMQ40JASDRrm
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 09 Nov 2012 21:51:57 -0000

On Fri, Nov 9, 2012 at 3:30 PM, Chris Richardson  wrote:
> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
> if the cipher suite is insufficiently strong.  Doesn't
> handshake_failure make more sense here?

Does it? From RFC 5246:

illegal_parameter
      A field in the handshake was out of range or inconsistent with
      other fields.  This message is always fatal.

Seems to make sense, no?


Cheers

AGL

From n.mavrogiannopoulos@gmail.com  Sat Nov 10 02:21:36 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7661821F8522 for ; Sat, 10 Nov 2012 02:21:36 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEFFiQ-HM4pe for ; Sat, 10 Nov 2012 02:21:35 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63CDD21F8521 for ; Sat, 10 Nov 2012 02:21:35 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr13so2158417wgb.13 for ; Sat, 10 Nov 2012 02:21:34 -0800 (PST)
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=WePQt6E3CHlzQGS0GWw5HKGDAAejeldDrbkGAqIt6tk=; b=CVcm+WfoD6UrllLVIh/K1TKrNVuGi4RKCl1iDmccuyrnGKbvFXCUoHKBpvKOjjqwQm DjLYVNiPz7cq3GjhzeIkgCQitBqCQQfb9gKBGrwn1Eek2iqGjnQfI6Kwl4yO3ZHa8+PV dbpDmu3Bms+rpubkZTN/wy9nAdsLKzJE/pW160FDSCSu2eRjTYotxwGD0+Z62xqsWsTs C7spF82/ScnCLWvv/+SNyolqBtgTE7KgNFQml2P3cLROWhdmNgKFohIP4M47PputXSg6 5urmxkpuGxMWMLpLurTAtd7DJfpradI7FIW8mNBcvEn/DbPTJlq/+ZWd7Q9CKMtKwjh2 vN8A==
Received: by 10.180.99.5 with SMTP id em5mr6629934wib.8.1352542894427; Sat, 10 Nov 2012 02:21:34 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id s12sm5581798wik.11.2012.11.10.02.21.32 (version=SSLv3 cipher=OTHER); Sat, 10 Nov 2012 02:21:33 -0800 (PST)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <509E2AA7.1040206@gnutls.org>
Date: Sat, 10 Nov 2012 11:21:27 +0100
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120805 Icedove/10.0.6
MIME-Version: 1.0
To: Adam Langley 
References:  <509C2C71.8070100@gnutls.org>   
In-Reply-To: 
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Nov 2012 10:21:36 -0000

On 11/09/2012 03:46 PM, Adam Langley wrote:

> On Fri, Nov 9, 2012 at 4:55 AM, Nikos Mavrogiannopoulos  wrote:
>>  The part of the session state I think would be hard to overcome.
>> Everything used in a TLS handshake is part of the state. What do you
>> actually need there is that this key and signature need to be resent
>> even if the client is resuming a session?
> Yes. Since the aim is to eliminate barer tokens as a means of
> authentication it's unfortunately, for our purposes, that session
> resumption makes a barer token out of the key pair!


You cannot really avoid that since this is the purpose of the session
resumption. Authentication only occurs in full sessions, so by modifying
resumption and requiring a signature you convert it to some kind of
resumption with some authentication. Don't the time limitations of
resuming sessions compensate for your concerns? (which I suppose is
preventing someone to authenticate by stealing session data).

>>> That was suggested in the meeting. The reasons why that wouldn't work
>>> without modification are that: it's part of the session state, it's
>>> unencrypted in the handshake and we cannot also have a client cert if we do
>>> that.


Thinking it again, the draft is pretty much about using pseudonyms
(public keys) to authenticate to servers over TLS. Authenticating with
both the pseudonym and the named certificate doesn't look like the main
use-case but a server may want to associate them and that could follow a
mechanism similar to what you propose.

>> Was it due to client constraints or because of the required changes?

> It was because our use turns out to be substantially different from
> client-side certificates that the code to support both in a single
> mechanism turned into a lot of ugly exceptions.


What if the server indicates early whether he'd like an authentication
with a pseudonym or a named certificate (or both for association)?
Wouldn't that simplify the handling of the client provided certificate?

regards,
Nikos


From chris@randomnonce.org  Sat Nov 10 11:27:02 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7645821F84F8 for ; Sat, 10 Nov 2012 11:27:02 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e55s4iJR-9-j for ; Sat, 10 Nov 2012 11:27:02 -0800 (PST)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B357E21F84E8 for ; Sat, 10 Nov 2012 11:27:01 -0800 (PST)
Received: by mail-bk0-f44.google.com with SMTP id jg9so529988bkc.31 for ; Sat, 10 Nov 2012 11:27:00 -0800 (PST)
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:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ZiK5eXjp1sjAqa1mX8uysZLa8gJ+qIH74aEk1G9aS4k=; b=b5zlNQ5BID9BIIAl+6zyOhOyDMaH7FhOARMwBlCyH81VT57PdwtN/0WMefbtWMaDAS 7+zFN1uQxNbBHDHvYAW93iNXBO5vSLHoHKKk6kZzAIoY2dfSq6Hq4n8VXA2+yOk974WI RAl1TbeyukCpUrxwL/9CwbTDbVJrR5k0bljuKGPDaibkG1ovpkdY+mx0A/l6wONfySu/ q6srxr/+X0cP7HiCU/WIbiaJBNVncedU4HEjkKfH5MScjU34qBwugroSrwXVIBQrxuWA vABFX0ZV9EfUEx+SLKCxaPXSXefIBSQaxEcQ0lv+5KmbDDMzU86XQOvV043UjdR91k4M tQvQ==
MIME-Version: 1.0
Received: by 10.204.157.145 with SMTP id b17mr5132314bkx.68.1352575620637; Sat, 10 Nov 2012 11:27:00 -0800 (PST)
Received: by 10.205.125.132 with HTTP; Sat, 10 Nov 2012 11:27:00 -0800 (PST)
X-Originating-IP: [71.179.106.208]
In-Reply-To: 
References:   
Date: Sat, 10 Nov 2012 14:27:00 -0500
Message-ID: 
From: Chris Richardson 
To: Adam Langley 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmKm13gGaUQ939U2Ra1AXb3dcyF5G/0e8CF4Shi/IgsT2BCjIs8tCITUBAvKy+vC+CvuLlt
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Nov 2012 19:27:02 -0000

If I was looking at a packet capture and wanted to figure out what
exactly went wrong and how to make the connection succeed,
illegal_parameter would lead me to incorrect conclusions.
handshake_failure ("unable to negotiate an acceptable set of security
parameters") would lead me in the right direction.
insufficient_security would be ideal, but it is only supposed to be
sent from server to client.

On Fri, Nov 9, 2012 at 4:51 PM, Adam Langley  wrote:
> On Fri, Nov 9, 2012 at 3:30 PM, Chris Richardson  wrote:
>> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
>> if the cipher suite is insufficiently strong.  Doesn't
>> handshake_failure make more sense here?
>
> Does it? From RFC 5246:
>
> illegal_parameter
>       A field in the handshake was out of range or inconsistent with
>       other fields.  This message is always fatal.
>
> Seems to make sense, no?
>
>
> Cheers
>
> AGL

From paul.hoffman@vpnc.org  Sun Nov 11 17:30: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 013D321F84DF for ; Sun, 11 Nov 2012 17:30:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnFivVP1GdHF for ; Sun, 11 Nov 2012 17:30:40 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1708621F8481 for ; Sun, 11 Nov 2012 17:30:38 -0800 (PST)
Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAC1UXZM003296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Nov 2012 18:30:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: 
Date: Sun, 11 Nov 2012 17:30:34 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: "tls@ietf.org" 
X-Mailer: Apple Mail (2.1499)
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 01:30:41 -0000

Is is possible for you to do a separate Internet-Draft on =
EncryptedExtensions, and then point to it from =
draft-balfanz-tls-channelid? I ask because there are probably other =
future extensions that will want to use that extension, and if the RFC =
level of ChannelID doesn't permit it, we'll be in a similar situation as =
we are for RFC 6091.

FWIW, I think ChannelID is a fine idea and should be adopted here, but =
I'm not convinced it will be put on Standards Track.

--Paul Hoffman=

From benl@google.com  Mon Nov 12 05:09:02 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83A921F8576 for ; Mon, 12 Nov 2012 05:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.776
X-Spam-Level: 
X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYzEOUclpEHs for ; Mon, 12 Nov 2012 05:09:01 -0800 (PST)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8866E21F84DD for ; Mon, 12 Nov 2012 05:09:01 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id hm6so1983186wib.13 for ; Mon, 12 Nov 2012 05:09:00 -0800 (PST)
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; bh=a6Mus8FS+ss/XXgXCeGyeR5mEgCKm/60+ZN49vWCjbM=; b=H7f5xfmVSnSoBbeTrI//5vUa2PG58JVkNckTXOp9ZOfPA15qFq8etq5Aurz/99+72x w4mNpm2QWdB2QZj610Cj2yigc5FqGlF9cDM5yRjqRjeNL78PIJVhxP0CK0rmHO63CtpI bJ1AGffWTYTZMxOegWDpuMsE/gzaTDs+BXSFyY6yW7aafzBuRjtEQu5SHCbFPDAmcznk sM6pI6mzf0VB8bFHe/z46vVUY1/u6MgaiIgLAeELjnX8YomAsczroTdG5HI9uRy8l/Ny BoT8a9R6/lRvpy05VIw1QViqv1JQAv+FTvp5QqtaWfejaKlwBNFUBl7Z/5uaZ1iEYe7v aXeQ==
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-gm-message-state; bh=a6Mus8FS+ss/XXgXCeGyeR5mEgCKm/60+ZN49vWCjbM=; b=BE8M+zxgJlEEJG5vSLgKTsKrvWGY1sDL0st5WZ22dEN203nUHaTJDtxC+VUHIPsM3T 8Jq3gzEpg7o39trnn1g5OEdnTRWuzxZqALEbxj5gVuKuCUaGN9oo2OR9EDlNrCaFm5H0 6bnmXNFVSVVvgGUUM4N/YrwNQI/ClIW3ZJK4q5zDzoIF4qQ/13xy8kNYbcjM4sjWVcnf x37ksYV00LHcJYqCkipBCreBPtnzt26TWyjZ/FueCUt/yqqOcDdmKSqToSb+oWza/Al7 6c2dkua7OagTcIh9Y882Dxc/tSTXbVpgUtYw4lQ9D/MOMnylGck5pCdTBfVgzzzqFEdO LvXQ==
MIME-Version: 1.0
Received: by 10.216.201.28 with SMTP id a28mr8182389weo.74.1352725740666; Mon, 12 Nov 2012 05:09:00 -0800 (PST)
Received: by 10.194.51.100 with HTTP; Mon, 12 Nov 2012 05:09:00 -0800 (PST)
In-Reply-To: 
References:  <509C2C71.8070100@gnutls.org>   
Date: Mon, 12 Nov 2012 13:09:00 +0000
Message-ID: 
From: Ben Laurie 
To: Adam Langley 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmnpcoZ9Cuk2Q3z8kzbHj9WDjyF6wj2V///KbSIyctjgt3TINoCSTqWpDGRPyJ30i9Sy/V7k3yIayEuerx0DiBEJEX59uslGshQi3JLQFBxAFSooJqxdObypoRWq4lQbHH3dUJbfUcD962HbGIlSiwmh8HbRHZ+7MsphoBA5aPs+DfDwgoDtNrm7tmx+K37Z5G0u38u
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 13:09:02 -0000

On 9 November 2012 14:46, Adam Langley  wrote:
> On Fri, Nov 9, 2012 at 4:55 AM, Nikos Mavrogiannopoulos  wrote:
>>  The part of the session state I think would be hard to overcome.
>> Everything used in a TLS handshake is part of the state. What do you
>> actually need there is that this key and signature need to be resent
>> even if the client is resuming a session?
>
> Yes. Since the aim is to eliminate barer tokens

"bearer" :-)

> as a means of
> authentication it's unfortunately, for our purposes, that session
> resumption makes a barer token out of the key pair!
>
>> The unencrypted in the handshake is an early design choice in TLS. I
>> think TLS should be updated to cope with that, rather than each
>> individual extension try to patch that issue. Having said that there
>> was Marsh's proposal but I don't know if it is still active. In any
>> case this could be combined with a generic mechanism to have data in
>> TLS send after encryption is enabled (so that other extensions that do
>> that wouldn't reinvent the wheel).
>
> We do use the EncryptedExtensions mechanism which was suggested by
> someone on this list (sorry, I forget who) for NPN. (And it part of
> the NPN spec now.) So it does use a generic mechanism for sending
> encrypted handshake data, but it doesn't solve the generic problem of
> encrypting client-certificates any longer.
>
>>> One of our reasons for doing something else rather than modifying client
>>> certs was our experience that doing so turned into a bit of a mess when we
>>> did it last time.
>>
>> Was it due to client constraints or because of the required changes?
>
> It was because our use turns out to be substantially different from
> client-side certificates that the code to support both in a single
> mechanism turned into a lot of ugly exceptions.
>
>
> Cheers
>
> AGL
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From benl@google.com  Mon Nov 12 05:24: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 E235721F8574 for ; Mon, 12 Nov 2012 05:24:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMKTdpAihhQL for ; Mon, 12 Nov 2012 05:24:24 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9021F84CF for ; Mon, 12 Nov 2012 05:24:24 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id dr13so2914177wgb.13 for ; Mon, 12 Nov 2012 05:24:23 -0800 (PST)
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; bh=nvKU87HJhLL1R3hAZHWfxTx9AdQkV4ZUjoIsV1bsg9w=; b=oWx8gv4OUlLUYcsSqWbFb4uqtyIz/dHtLcBwvI/YwNIpHibh/pwnQtp8M6dgjJzuZ9 FfXwHnwxkIv3i85Sz1qhH9RrDDYUuuIkPHHU+T+wt2eWl0hVbagg6jy7hg0UuQYOX25k djea6VoV/eKCgsGqTTylBCFqOX/gabAQWvfjC41IYS/zwzq0bVbjSYCXH+yGexdmtrU2 xhRXhekbz35jT1Iet6f4k9J197XECYxevCHXidHdbgf75opB8P4vURCds+raGcjxszFI 3Y8txO0a3WsjxFOO+pIO7OfPsAcF7/ENrGOUmbw7jr+zlZFaCViGDMx3QHRtEa6DJgzx 0iCg==
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-gm-message-state; bh=nvKU87HJhLL1R3hAZHWfxTx9AdQkV4ZUjoIsV1bsg9w=; b=iEfK0JzjYQGyIt2JboYoUqI1fruvBHPS4ib4wrm7c28oyIRHpgFP8aDCaCWy4NVRqZ 7PsAMHbrCZaPb9rt7VTXMTQdBADFMwg0hUbhEK40grK4Y9fhFOS/GVBIhjL0zbDNmYfs j92qzs4YNywgPcsisZSIUwAvo6yGrIRW621uVdy7Jm/5MeJ3ZQf5AafQvE+ali/UaLji g8EpV3uw93qsXYPaCEWs3Xd3cOHmSFERdte8l0UBmJZwWYJEgD8da6/aG5ppwCor/bzR Y88j31fS6If2nXRnWNIjdKS1bBkLZt/e7Oby8oQOXNl9FXB6bFzuNA+gOULsBPyDa80G O0fg==
MIME-Version: 1.0
Received: by 10.216.201.133 with SMTP id b5mr8094501weo.213.1352726663167; Mon, 12 Nov 2012 05:24:23 -0800 (PST)
Received: by 10.194.51.100 with HTTP; Mon, 12 Nov 2012 05:24:23 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 12 Nov 2012 13:24:23 +0000
Message-ID: 
From: Ben Laurie 
To: Dirk Balfanz 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQnrbFK/GWgwW0u6jQXc889NYdbjD0CHBFhBbZT/dyxQXzJ96vehDVe5u5zdwOo0RsD7yTeLJdX9k07IhaRV/9dp0+7Dl6W95h51TRYa6Gwr9Psn1pLf+5ud4eslpMKDbWA/MJFJsv8jxE+WspQd4H2D/SqCeYa/ZnKdLTqAdLcvFawt2rxv4PgOVd8+VhAlrSp6VmaP
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 13:24:26 -0000

On 8 November 2012 21:22, Dirk Balfanz  wrote:
> Hello everybody,
>
> As you might have noticed, I have let the TLS-Origin-Bound Certificates
> (TLS-OBC: http://tools.ietf.org/id/draft-balfanz-tls-obc-01.txt) draft
> expire. The reason for this is that we (i.e., Google) had implemented
> TLS-OBC as described in the draft (in Chrome and server-side), and we
> weren't too happy with it. There were a few of problems:
>
> (1) Client certificates are part of the session state. Not only does that
> mean that the session state is now considerably bigger than it used to be,
> it also means that anyone that can steal session secrets (malware on the
> client) can make it look to the server as if they were in possession of the
> client's private key, even if that private key sits in a TPM on the client.
>
> (2) The logic in the client and server that treated OBCs and normal client
> certs differently, even though they were delivered through the same kind of
> Certificate message, turned out to be a little more complex that we wanted
> it to be.
>
> (3) To keep the public key of the client (which acts like a machine
> identifier) away from prying eyes, we had to entangle the TLS-OBC extension
> with another extension that reordered handshake messages (and sent the
> Certificate message after the ChangeCipherSpec message). That added further
> ugly complexity.
>
> (4) The main use case for this was to be able to "channel-bind" cookies.
> Cookies, however, can be set across more than just a web origin. When the
> underlying transport uses different client keys for different origins inside
> the same TLD, then we can't bind a domain cookie to the underlying TLS
> channel.
>
> (If you were at IETF 85 you might have seen Adam give a short talk about
> this.)
>
> To fix all this, we wrote a new proposed spec:
> http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
>
> This spec is silent on the scope of the keys (but in practice we expect
> browsers to use eTLD+1 now instead of more fine-grained origins), and
> addresses all the other issues explicitly: the Channel IDs are not part of
> the TLS session state, and are exchanged after encryption is turned on.

a) How can this be usable unless it is specified what browsers do?

b) eTLD+1 ... how will you deal with, e.g, uk, which has just proposed
removing a level from the TLDs? Hasn't this kind of mechanism already
been shown to be impossible to maintain (cookies are supposed to be
banned from eTLDs but in practice aren't always, IIRC)?

From dkg@fifthhorseman.net  Mon Nov 12 07:07: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 28C8C21F8561 for ; Mon, 12 Nov 2012 07:07:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSnJXoG6feGF for ; Mon, 12 Nov 2012 07:06:59 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3331D21F8529 for ; Mon, 12 Nov 2012 07:06:59 -0800 (PST)
Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 04188F970; Mon, 12 Nov 2012 10:06:54 -0500 (EST)
Message-ID: <50A11089.6080806@fifthhorseman.net>
Date: Mon, 12 Nov 2012 10:06:49 -0500
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.10) Gecko/20121028 Icedove/10.0.10
MIME-Version: 1.0
To: Ben Laurie 
References:  
In-Reply-To: 
X-Enigmail-Version: 1.5a1pre
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAE28BBD08FA542024FA3A3CE"
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 15:07:00 -0000

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigAE28BBD08FA542024FA3A3CE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/12/2012 08:24 AM, Ben Laurie wrote:

> b) eTLD+1 ... how will you deal with, e.g, uk, which has just proposed
> removing a level from the TLDs? Hasn't this kind of mechanism already
> been shown to be impossible to maintain (cookies are supposed to be
> banned from eTLDs but in practice aren't always, IIRC)?

fwiw, this actually is currently "maintained" by tracking a ton of
special cases; the usual place this work is coordinated publicly is at
http://publicsuffix.org/

It's not a particularly pretty solution, but people do use it.  I can't
tell if it's the intent to reuse this same list for channelID or not,
though.

	--dkg


--------------enigAE28BBD08FA542024FA3A3CE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQJ8BAEBCgBmBQJQoRCKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD
Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpMj4P/0Gh0Hwyf9P6+Q6xzTLFWgsr
PIwp+/4UVIB8DkCqjHt1wBraNvgmY2MrX+mESdKAsqNovJvqorSLuB6GOVBRipja
lbUASrB4DcoQ/DVYR3V44wfm45SZYCZOUmfIxWqEMcD0pST/1Yww7M3QfzNq3JoG
DCqr3sHlG9lGcrKdH37U72K/T+JrknXTiqT9y+5TsxzBG3EZJjX99dfX8IMKYOV9
jaAVt5kEEaPYPlFRbGnBP+sgGzf26vEM6hefK8iZIHbD9ptskbAcI7Y4szckXAhI
UH9UL80b6GIpXPbkroEq65o+K5rVFJdp0aUD3tQopYl2nzqal+blbdIvYO75ux89
fszTGouyNQmpwvVGR60pfWY2oAptvbAjuumoV5Or6q9jqBQ1bXL2ihue8dhI0VBH
HL2A6xfmFQdOLhdVH4kYy4PflW56mSnPSlqwW7M+dwfnGW44PllsqZ6mYNRwbna/
7DR+H4m2/UrCqdcMK5SRXO5k3m9/epHJRyjpBTrDUFpHSS9kTYWRgt4tH32ChYjy
bjrGXBe7wNYrl1cNyqL7GqCUbivahdeia4oYbos0cYfOL5QdpGRtA5rRFm9U/cja
teF0r+FpdCrNveK3m0INQHIquwF3/zJx9N4Bz1XP52I1Q/smSRoH4gGGuvGuuWDA
jyj7NkR6TbjvJfXXhugk
=Hy0G
-----END PGP SIGNATURE-----

--------------enigAE28BBD08FA542024FA3A3CE--

From agl@google.com  Mon Nov 12 08:20: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 AD1F321F8512 for ; Mon, 12 Nov 2012 08:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiEnyRSpgn2X for ; Mon, 12 Nov 2012 08:20:05 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37EF421F8319 for ; Mon, 12 Nov 2012 08:20:05 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so10291242iec.31 for ; Mon, 12 Nov 2012 08:20:04 -0800 (PST)
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; bh=A+gVkNhi89PWSZ7C6atWvmHQx21bivy3aFc42CgO05M=; b=AprADybcZLnzwfhha72vAIdNvWNvxy/vS/G3WriAFI9XoK9lwxiDPdfVYtwMpWbOQA NQLly1DOAYkkCEMqsKpfOrixmJ2US4G69ZqEfAbMA8Tn52McpXJ31dxT1irRZS1Qz3IY FM9xONYb+qXbNQGmX8XRKsvFjz+d3kE1zl4h1LaK+g82Efm3KIySTtpSTzMlsGUCeQcR 5weJS8zgTzoV+Yuc5eZ/OQUN7I7AFbpOoTui0Ub+DA8tCEZPp1DWYMXpBFDFeVr5NOdK Xxibgv6YW5cdnzF62DM3kni0KR+tD6O/3U6DDs7Tz8B2e3srFveoIgwJVSmh/dMEIZjc Aiog==
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-gm-message-state; bh=A+gVkNhi89PWSZ7C6atWvmHQx21bivy3aFc42CgO05M=; b=NLL5+GTwcc7F6C1fe0tOengAvoz5hG19p86iulvhGP6wi3/MLVA9Kqw3nX6t/pQX/o ODI3TJ7s1zUI4khWBKb4kA1LMF6APzT3DhkeVYZ//0tOFS4gdvbtCWkqBxZI8iIKs3CH pTuSnTj3rLE6uVH/BeWH+uu3fLuIRdPjXfowdQ4AmV/bCN4HYuk5sW9f6g0uU6Nv2OK2 v95rQRGFHMZBJoSJwbXAewT0Uu9cBt6Hz4RcoSEUgZyTjJR5r5a5UckYOrUnr1E+M4fJ 3Ekx/GYTbmsArtNe2Cq8/5Jr53v0rvflK5wkmuwVtrf6vJk4gESWVAT4Ynq9ZNF4fNIJ ZwOw==
MIME-Version: 1.0
Received: by 10.50.213.34 with SMTP id np2mr8353626igc.57.1352737204692; Mon, 12 Nov 2012 08:20:04 -0800 (PST)
Received: by 10.231.85.9 with HTTP; Mon, 12 Nov 2012 08:20:04 -0800 (PST)
In-Reply-To: <509E2AA7.1040206@gnutls.org>
References:  <509C2C71.8070100@gnutls.org>    <509E2AA7.1040206@gnutls.org>
Date: Mon, 12 Nov 2012 11:20:04 -0500
Message-ID: 
From: Adam Langley 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQlsmMMdbvwh/9gcqKU6wRJY5VXifWro44msLjik7567kK5XGxxmGgXWcRxhoThIYZEKyBDQ2v+8qx3ArE/FRXs6j9GvvrYoWKHsh94oPpNdunsRWUETxgJTVlMjaMCHWeIwv5PeDhX/VfclINFMs5d4By7IW9foP/hyL9Q6eioo2yHVUZYvmlzUHDes/EjXe3xlcEH7
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 16:20:05 -0000

On Sat, Nov 10, 2012 at 5:21 AM, Nikos Mavrogiannopoulos
 wrote:
> Don't the time limitations of
> resuming sessions compensate for your concerns? (which I suppose is
> preventing someone to authenticate by stealing session data).

Time limits would be better than no time limits, but any time limit
short enough to be acceptable in this case would make session
resumption completely ineffective.

> What if the server indicates early whether he'd like an authentication
> with a pseudonym or a named certificate (or both for association)?
> Wouldn't that simplify the handling of the client provided certificate?

All the special case handling basically made a mess of the code. I
don't think any small changes would have changed that. (This is not a
precise argument, and it may not apply in all code bases. I am
orientated towards OpenSSL and NSS for obvious reasons.)


Cheers

AGL

From agl@google.com  Mon Nov 12 08:21: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 C06FD21F863A for ; Mon, 12 Nov 2012 08:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCDOFtLEp+ES for ; Mon, 12 Nov 2012 08:21:10 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 518FB21F8630 for ; Mon, 12 Nov 2012 08:21:10 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so10293365iec.31 for ; Mon, 12 Nov 2012 08:21:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4jOxBfvwGWEYogFCOe1m2a5Ie9yvDtjAkeUU0SKr2Lo=; b=UQl0LrHKBpyVTzvTVkGqdUw082jqj2/EJU6jsFbYv3yrnRccb0JLZrfPHnOsFuC988 +MsMfa46NcvMAUzkPQaHfwbiQu6l+BSW9+AcGbQRfhnZhYYK9UA1AAh4MQbFUXUudvOZ jOYhDDZIu1rU7WNfJsGDa10oTtCFz2TSCBMw+mVrWlBwwPs9otqT5kFv8wYkyw0Jkbvh xo6lPpKxCjPpsuZgxFam5rPIdgSKZSIfvSD+MLxBCm+OL2LrrJwOp/y5PONP3gH6SStF X9G4LrzeYnRG6uLj08UPpj/Jze6N1D5X58j+KMXuh3p3I726zXgUyIurQbk0kbRhmwUl VkYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=4jOxBfvwGWEYogFCOe1m2a5Ie9yvDtjAkeUU0SKr2Lo=; b=RJW0BJ5CSdX17r7mDJVzuYbfy2hcvc/fr6dvZdcIiYG7MqCpx01A35bxIJlapPdOzU ztAn8eFV1k77J9EeFLWk9zVXlIS63lnSl3+gjOt11xCV4R4z7qKugmKW7PyGqKRTOxDP OfyfNq4PFD04kjrhgZSVl+WCghFlOHZhvbUeZi1kS/vI3O1n3+8hPbjCLmJOm7KNm9/g W+5RjA93L1+3bKP2ICL5JCqXiQuJZDrTPwniUbLmJFMRrwX2M0JtXQL4B5Aux4H91J0d za1K4LrL7t9stLnsNvZ745diFcFeVLnh3YPh6kFkKdylST99s5kDHpnSsbT8UooC7+sR Du7g==
MIME-Version: 1.0
Received: by 10.43.7.132 with SMTP id oo4mr18924117icb.6.1352737269949; Mon, 12 Nov 2012 08:21:09 -0800 (PST)
Received: by 10.231.85.9 with HTTP; Mon, 12 Nov 2012 08:21:09 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 12 Nov 2012 11:21:09 -0500
Message-ID: 
From: Adam Langley 
To: Paul Hoffman 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQn2iHSJLuA89t95TiDwPW1SxtxCr8ksHM3pqrbmyhwn647iKRSEPRODrvac+TC4hRxkGRH7tiDTfC7FBsvQSQBqb8vWtXZunuiUIcIoCnrIDie2SE7PHRsBJoRrIqqVPZ22ZM0Mq4UP8fCTGSI4cg7gfynt7DkqnRyavIqToVkny4ccLP6w2nQexr6zgulRcbq6riOQ
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 16:21:10 -0000

On Sun, Nov 11, 2012 at 8:30 PM, Paul Hoffman  wrote=
:
> Is is possible for you to do a separate Internet-Draft on EncryptedExtens=
ions, and then point to it from draft-balfanz-tls-channelid? I ask because =
there are probably other future extensions that will want to use that exten=
sion, and if the RFC level of ChannelID doesn't permit it, we'll be in a si=
milar situation as we are for RFC 6091.
>
> FWIW, I think ChannelID is a fine idea and should be adopted here, but I'=
m not convinced it will be put on Standards Track.

EncryptedExtensions is also used in the NPN. I'd be happy to split it
off if the WG were to adopt something that required it.


Cheers

AGL

From agl@google.com  Mon Nov 12 08:23:29 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9F521F866B for ; Mon, 12 Nov 2012 08:23:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level: 
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh77XBmMfCYv for ; Mon, 12 Nov 2012 08:23:28 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCEE21F8686 for ; Mon, 12 Nov 2012 08:23:28 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so10297812iec.31 for ; Mon, 12 Nov 2012 08:23:28 -0800 (PST)
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; bh=QsGRHC6IVXXAF5WSb5kgYfvs5gPlU1xS5Bq56M/kQr0=; b=PmJ9z/+BLiVhvODU0S4kHK6z5lOw0ScgcZKhaN14dRmpCyL0mZwhS7KZMQVpoKujna ui1w4s0pmkOIpWjnkmLkr72NOiZr0NIVn4JT+6SLjKqGyD1BgWhFEt5WPRmW5kVqS13V kCjmxRNhhnb4ck+LSMuMpHDXmH/ZLhMtNuANTgvykEj/Y/5zx/IWRWcWys+iSQcz8ZEJ lQkBEZxOPkzgskxQpEQIHjq8UBlx+0I9FbU39kXYSzLteJYT0U9a/e1q0dWZypmH6c+C Ter1nEkWFVLRBEcOgj3fOpa7fMdLSelq46/+WLkHs0D05WySLSTWikooGSp5XX/EkXw3 t4WQ==
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-gm-message-state; bh=QsGRHC6IVXXAF5WSb5kgYfvs5gPlU1xS5Bq56M/kQr0=; b=EA/SxL4WcACoCb72wADphBhFwnatnLutv/I2dvS8UHEez6DRyFmhKhLd5mIpcj47pG NaJ8c1tQrD5tECxlYGKT6/Ev7QIbc7Onw1GS+DJkJ3H176jmKqObgkONfdyrJs0Q6mp+ D/Hdnu5VDubDBCfYov8wt4HiTtrIYitcL3pTOHOrmkruCgw2QtxHSv/KNFf49Uboq91J lEkZuOJ4+KTWOEGOeFsQQtgcwWvD+VQW7h/fvA5QHKHSspeS4+JPM6xkBbLZsbiZ4laU +cerckg6uKuxPa1L2OYZI4OlfpzE4rS0NOkp7XFR0LEn5U5fovQsMzjjVtdCem5Tt9Nw vrBg==
MIME-Version: 1.0
Received: by 10.50.182.133 with SMTP id ee5mr8515739igc.54.1352737408082; Mon, 12 Nov 2012 08:23:28 -0800 (PST)
Received: by 10.231.85.9 with HTTP; Mon, 12 Nov 2012 08:23:28 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 12 Nov 2012 11:23:28 -0500
Message-ID: 
From: Adam Langley 
To: Ben Laurie 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQm4gicg6tAA6MGeYEpwXdKjbRukTEqvpi0mohyZ8dDXPWAHRVFZ+hgdQerxGx0WQaWP58l5fG4LHu1s3wL2GPtNLhZJ5FHl72bv0a2XooTWcGiVqaORnMqQSs/gDO2exYqUv24pFqRxy4wfNQqn7w1jX2RLY52d+/LbfvasvCa/eMgWJMiLiJXfHK5arWTViq0blSsK
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
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, 12 Nov 2012 16:23:29 -0000

On Mon, Nov 12, 2012 at 8:24 AM, Ben Laurie  wrote:
> a) How can this be usable unless it is specified what browsers do?

It seemed that the higher-level behaviour wasn't in-scope for a
document about TLS protocol changes. Although I agree that it should
be documented, I think it's a different document.

(Higher level behaviour pulls in messy hacks like the Public Suffix
List, as you note in (b))


Cheers

AGL

From fweimer@redhat.com  Tue Nov 13 02:02:50 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADC621F85FF for ; Tue, 13 Nov 2012 02:02:50 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvhOtzdX7Rva for ; Tue, 13 Nov 2012 02:02:50 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5952F21F85FE for ; Tue, 13 Nov 2012 02:02:48 -0800 (PST)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qADA2kHb012847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Nov 2012 05:02:46 -0500
Received: from fweimer.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qADA2j6j029899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Nov 2012 05:02:46 -0500
Message-ID: <50A21AC4.1050003@redhat.com>
Date: Tue, 13 Nov 2012 11:02:44 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Subject: [TLS] draft-weimer-tls-previous-certificate-01
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, 13 Nov 2012 10:02:51 -0000

I submitted an update to draft-weimer-tls-previous-certificate:



Compared to the previous version, I added an explanation of the expected 
server-side processing and the interaction with client certificates.  I 
clarified that a handshake which succeeds solely because of a user 
override may still be considered as successful handshake.

I'm not sure how to move this forward.  I think for interoperability 
trials, it makes sense to fix the codepoints for the extensions, but the 
registry requires IETF Consensus, so the RFC has to come first.

-- 
Florian Weimer / Red Hat Product Security Team

From fweimer@redhat.com  Tue Nov 13 05:17: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 55CDE21F84E4 for ; Tue, 13 Nov 2012 05:17:59 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cFtSDp4592l for ; Tue, 13 Nov 2012 05:17:58 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2233121F8455 for ; Tue, 13 Nov 2012 05:17:57 -0800 (PST)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qADDHsbW022617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 13 Nov 2012 08:17:55 -0500
Received: from fweimer.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qADDHrie019803 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 13 Nov 2012 08:17:54 -0500
Message-ID: <50A2487B.7080401@redhat.com>
Date: Tue, 13 Nov 2012 14:17:47 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2
MIME-Version: 1.0
To: "tls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
Subject: [TLS] close_notify race condition
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, 13 Nov 2012 13:17:59 -0000

I'm not sure if this has been discussed before, it probably has. 
Section 7.2.1 of RFC 5246 says this:

"If the application protocol will not transfer any additional data, but 
will only close the underlying transport connection, then the 
implementation MAY choose to close the transport without waiting for the 
responding close_notify."

This advice is of questionable value when running TLS over TCP, and the 
other side is still sending data.  In that case, closing the transport 
will generate a TCP RST segment because TCP treats this as a data loss 
event.  This RST segment (generated by the party which sent the 
close_notify alert) can be received before the close_notify alert is 
read from the TCP receive buffer, essentially flushing it.  As a result, 
the close_notify alert is lost, and what started as an orderly 
connection shutdown looks like a potentially hostile connection truncation.

-- 
Florian Weimer / Red Hat Product Security Team

From pkix@inbox.lv  Tue Nov 13 14:36:39 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D83D21F86A2 for ; Tue, 13 Nov 2012 14:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.214
X-Spam-Level: 
X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0ISVwu5xfh5 for ; Tue, 13 Nov 2012 14:36:38 -0800 (PST)
Received: from shark3.inbox.lv (shark3.inbox.lv [89.111.3.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7D48121F86D3 for ; Tue, 13 Nov 2012 14:36:37 -0800 (PST)
Received: by shark3.inbox.lv (Postfix, from userid 1000) id EC27D10337; Wed, 14 Nov 2012 00:36:34 +0200 (EET)
Received: from localhost (localhost [127.0.0.1]) by shark3-plain-b64d2.inbox.lv (Postfix) with ESMTP id D13701031A for ; Wed, 14 Nov 2012 00:36:34 +0200 (EET)
Received: from localhost ([10.0.1.11]) by localhost (shark3.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id nzxcVO48l9xT for ; Wed, 14 Nov 2012 00:36:34 +0200 (EET)
Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Wed, 14 Nov 2012 00:36:34 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Compose: web=mail.inbox.lv, node=w1.inbox.lv, l=en, compose=Plaintext
X-REMOTE-ADDR: 193.40.12.10
X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/11.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Message-ID: <1352846194.50a2cb72ba804@mail.inbox.lv>
Date: Wed, 14 Nov 2012 00:36:34 +0200
From: "Andris Berzins" 
To: tls@ietf.org
User-Agent: Inbox.lv Webmail
Subject: [TLS] why TLS 1.2 uses length prefixed messages
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, 13 Nov 2012 22:36:39 -0000

I have noticed that TLS 1.2 introduces additional length field for messages=
=2E
For example CertificateVerify:

Structure of this message (TLS 1.1):
      struct {
           Signature signature;
      } CertificateVerify;

Structure of this message (TLS 1.2):
      struct {
           digitally-signed struct {
               opaque handshake_messages[handshake_messages_length];
           }
      } CertificateVerify;

Is there reason why TLS 1.2 uses additional length field?


From mrex@sap.com  Tue Nov 13 14:44: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 C793721F8780 for ; Tue, 13 Nov 2012 14:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.105
X-Spam-Level: 
X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rBctvsMiXbA for ; Tue, 13 Nov 2012 14:44:20 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1269921F86EA for ; Tue, 13 Nov 2012 14:44:19 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qADMiHE8017834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 23:44:17 +0100 (MET)
In-Reply-To: <50A2487B.7080401@redhat.com>
To: Florian Weimer 
Date: Tue, 13 Nov 2012 23:44:17 +0100 (CET)
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: <20121113224417.8B4991A36F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] close_notify race condition
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2012 22:44:20 -0000

Florian Weimer wrote:
>
> I'm not sure if this has been discussed before, it probably has. 
> Section 7.2.1 of RFC 5246 says this:
> 
> "If the application protocol will not transfer any additional data, but 
> will only close the underlying transport connection, then the 
> implementation MAY choose to close the transport without waiting for the 
> responding close_notify."
> 
> This advice is of questionable value when running TLS over TCP, and the 
> other side is still sending data.  In that case, closing the transport 
> will generate a TCP RST segment because TCP treats this as a data loss 
> event.  This RST segment (generated by the party which sent the 
> close_notify alert) can be received before the close_notify alert is 
> read from the TCP receive buffer, essentially flushing it.  As a result, 
> the close_notify alert is lost, and what started as an orderly 
> connection shutdown looks like a potentially hostile connection truncation.


Which probably means that when your application protocol is full duplex,
you should also use application-level protocol framing and application
level state signaling in order to distinguish graceful connection
closures from any other kind of connection less (which is not necessarily
hostile).

The "recommendation" to purge a TLS session from the session cache
when no close-notify alerts have been exchanged have always been
obviously bogus (and would be quite detrimental to TLS session
resume ratio between a Web Browser and a Web Server).


But what is your actual question?

-Martin

From nico@cryptonector.com  Tue Nov 13 15:56: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 D6D5621F8795 for ; Tue, 13 Nov 2012 15:56:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75Jsd4sdYBqx for ; Tue, 13 Nov 2012 15:56:17 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 8408A21F878F for ; Tue, 13 Nov 2012 15:56:09 -0800 (PST)
Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 4B715678063 for ; Tue, 13 Nov 2012 15:56:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=1zMphBdCvYHwC0UN+xtC 7gdZfHc=; b=c3nNg1sOuK07byClqthZRxHpHG1zr+9DgdYCcFkAkVAeDbK9czdI d6eHgLqmCriX3KuME7HF/NjNmGQCDnseYF6vZFiD9UJXZ2SAiZVypAPDI7QvPqXA ySpD/wPiL5oca+zP3G4nxLyDj2gwIfvhm0EhJMtP42SS77c1YNMkfYQ=
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 2BFEA678055 for ; Tue, 13 Nov 2012 15:56:07 -0800 (PST)
Received: by mail-da0-f44.google.com with SMTP id h15so3513426dan.31 for ; Tue, 13 Nov 2012 15:56:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.230.66 with SMTP id sw2mr66002147pbc.119.1352850966613; Tue, 13 Nov 2012 15:56:06 -0800 (PST)
Received: by 10.68.128.234 with HTTP; Tue, 13 Nov 2012 15:56:06 -0800 (PST)
In-Reply-To: <20121113224417.8B4991A36F@ld9781.wdf.sap.corp>
References: <50A2487B.7080401@redhat.com> <20121113224417.8B4991A36F@ld9781.wdf.sap.corp>
Date: Tue, 13 Nov 2012 17:56:06 -0600
Message-ID: 
From: Nico Williams 
To: "mrex@sap.com" 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] close_notify race condition
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, 13 Nov 2012 23:56:17 -0000

On Tue, Nov 13, 2012 at 4:44 PM, Martin Rex  wrote:
> Florian Weimer wrote:
> > [...]
>
> [...]
> But what is your actual question?

I took Florian's post to be a query for what people think of this
matter.  My take is that Florian is correct, this race exists, and the
advice in the RFC should be corrected, though in practice correcting
that advice will hardly correct behavior in deployed systems.

Nico
--

From fweimer@redhat.com  Wed Nov 14 01:02:19 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF7621F855A for ; Wed, 14 Nov 2012 01:02:19 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW4i2lnEeBmw for ; Wed, 14 Nov 2012 01:02:18 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84A21F84FB for ; Wed, 14 Nov 2012 01:02:17 -0800 (PST)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAE92DRP031805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Nov 2012 04:02:14 -0500
Received: from fweimer.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAE92CoX008878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 04:02:13 -0500
Message-ID: <50A35E13.20509@redhat.com>
Date: Wed, 14 Nov 2012 10:02:11 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2
MIME-Version: 1.0
To: mrex@sap.com
References: <20121113224417.8B4991A36F@ld9781.wdf.sap.corp>
In-Reply-To: <20121113224417.8B4991A36F@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: "tls@ietf.org" 
Subject: Re: [TLS] close_notify race condition
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, 14 Nov 2012 09:02:19 -0000

On 11/13/2012 11:44 PM, Martin Rex wrote:

>> This advice is of questionable value when running TLS over TCP, and the
>> other side is still sending data.  In that case, closing the transport
>> will generate a TCP RST segment because TCP treats this as a data loss
>> event.  This RST segment (generated by the party which sent the
>> close_notify alert) can be received before the close_notify alert is
>> read from the TCP receive buffer, essentially flushing it.  As a result,
>> the close_notify alert is lost, and what started as an orderly
>> connection shutdown looks like a potentially hostile connection truncation.

> Which probably means that when your application protocol is full duplex,
> you should also use application-level protocol framing and application
> level state signaling in order to distinguish graceful connection
> closures from any other kind of connection less (which is not necessarily
> hostile).

A protocol which is essentially half-duplex, but permits request 
pipelining could exhibit this, too.  Not sure if this already falls 
under "full duplex".

> But what is your actual question?

I was merely sharing an observation.  I think it would make sense to 
reconsider this piece of advice if the document is updated.

-- 
Florian Weimer / Red Hat Product Security Team

From Andrei.Popov@microsoft.com  Wed Nov 14 12:33:42 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06A821F8792 for ; Wed, 14 Nov 2012 12:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSkLm7AM+edw for ; Wed, 14 Nov 2012 12:33:41 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 680D021F86F0 for ; Wed, 14 Nov 2012 12:33:41 -0800 (PST)
Received: from BL2FFO11FD010.protection.gbl (10.173.161.203) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.556.9; Wed, 14 Nov 2012 20:33:38 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Wed, 14 Nov 2012 20:33:37 +0000
Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 14 Nov 2012 20:32:50 +0000
Received: from mail34-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 20:32:22 +0000
Received: from mail34-ch1 (localhost [127.0.0.1])	by mail34-ch1-R.bigfish.com (Postfix) with ESMTP id 852E544026B	for ; Wed, 14 Nov 2012 20:32:22 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -27
X-BigFish: PS-27(zzbb2dI98dI9371Id6eah542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh9a9j1155h)
Received-SPF: softfail (mail34-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en;
Received: from mail34-ch1 (localhost.localdomain [127.0.0.1]) by mail34-ch1 (MessageSwitch) id 1352925140776667_10321; Wed, 14 Nov 2012 20:32:20 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252])	by mail34-ch1.bigfish.com (Postfix) with ESMTP id BB24A3A01F7;	Wed, 14 Nov 2012 20:32:20 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 20:32:20 +0000
Received: from BN1PR03MB071.namprd03.prod.outlook.com (10.255.225.155) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.233.3; Wed, 14 Nov 2012 20:32:20 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB071.namprd03.prod.outlook.com (10.255.225.155) with Microsoft SMTP Server (TLS) id 15.0.545.9; Wed, 14 Nov 2012 20:32:19 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.68]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.106]) with mapi id 15.00.0545.000; Wed, 14 Nov 2012 20:32:00 +0000
From: Andrei Popov 
To: Adam Langley 
Thread-Topic: [TLS] Next Protocol Negotiation 03
Thread-Index: AQHNIlzPyXJEV/H1YEG2j4FhINiIPJarp+EAgAAXsQCAADAaAIE/FnRA
Date: Wed, 14 Nov 2012 20:31:59 +0000
Message-ID: 
References:  <4F981528.9010903@gnutls.org>  <4F985162.7040405@extendedsubset.com>
In-Reply-To: <4F985162.7040405@extendedsubset.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.156.151]
x-forefront-prvs: 066517B35B
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%CHROMIUM.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(13464001)(377454001)(24454001)(479174001)(47976001)(5343655001)(54356001)(16676001)(51856001)(56816001)(53806001)(6806001)(47736001)(49866001)(4396001)(23726001)(50986001)(50466001)(550184003)(44976002)(47776002)(46102001)(47446002)(33646001)(76482001)(31966008)(46406002)(74502001)(54316002)(56776001)(74662001)(24736002); DIR:OUT; SFP:; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 066517B35B
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 20:33:42 -0000

A number of issues have been raised with regard to the TLS NPN Internet-Dra=
ft, including the downgrade attack described by Marsh. Is an updated draft =
in the works?

Cheers,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Marsh=
 Ray
Sent: Wednesday, April 25, 2012 12:33 PM
To: Adam Langley
Cc: tls@ietf.org
Subject: Re: [TLS] Next Protocol Negotiation 03

On 04/25/2012 11:40 AM, Adam Langley wrote:
>
> The idea would be that the server doesn't advertise Tor, or any other=20
> possibly suspect protocol. Rather the client would simply select "tor"
> as the protocol.
>
> The fact that the server advertises is unfortunate, but necessary to=20
> avoid an extra round trip. I'd rather see NPN in the clear as a=20
> standard ClientHello/ServerHello negotiation then take an extra round=20
> trip.

I don't speak for the Tor project, but I don't think this design is going t=
o meet anyone's requirements for serious censorship resistance.

Nevertheless, giving some privacy to the significant bits of the handshake =
in a way that is more latency-friendly than full renegotiation is very appe=
aling. It seems likely to enable new and interesting applications, SPDY is =
just one good example.

Unfortunately, we must keep in mind that anything sent before receiving the=
 other endpoint's Finished message is going to raise similar considerations=
 as False Start. The security guarantees provided to this data are somewhat=
 squishy, as they tend to depend on all sorts of not-yet-fully authenticate=
d details of the in-progress negotiation. As we saw with ServerKeyExchange =
DHE_RSA/ECDH, even the future introduction of new key exchanges and cipher =
suites can change these properties.

In the case of something like NP(N), a MitM might utilize a downgrade attac=
k which allows him to decrypt the client's NP record (possibly offline). Th=
is could break the handshake, but clients are so eager to retry the user mi=
ght not even notice.

So maybe any facility for "privately" negotiating handshake extensions ough=
t to be held to a clear standard lest we invite disaster, namely, it should=
 provide the same security guarantees as are provided to application data.

- Marsh
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls





From agl@google.com  Wed Nov 14 14:51: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 19BC921F874A for ; Wed, 14 Nov 2012 14:51:41 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XbhF0havJjI for ; Wed, 14 Nov 2012 14:51:40 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 818E321F8721 for ; Wed, 14 Nov 2012 14:51:40 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so1579510iec.31 for ; Wed, 14 Nov 2012 14:51:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZvYfqm6ZZKiFNhyAc4yn070uXKyzua0MFDmDirBOfLA=; b=PHPd/czcaHgVCptpJ5xXM+LJ7oo2A2WG7gHj81ot0fWH3vymWCoOw26xL2R2Luo2Tc 3pdgbDXvZEulAWSeAxV19DDUN7VVIE/mwGV6wFYzRZFSINX8t8nNUs50NH/bATN9jQ2l FEeFqPqeplUZCPtAnTzbIIdLx1Vj/4nXPn+WzPrmlZCF/NXoiQNjaHTWZiCb1RrdLIA8 4JxN0SWZtraUUYrxfsKWYBjylT2v2crIYJgEozTGHLpR5olZNfYpiwXKWaCc205Tf/fM A5I+9QIIduF+g66KemXSsNrbICTnR3TxitgpuSkKKydgwZgpGffCMQt24y1WUoqpYhym ewxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=ZvYfqm6ZZKiFNhyAc4yn070uXKyzua0MFDmDirBOfLA=; b=TS/F8rA8NJplFtXXmlJWY/V/fvTd0dQQSKACrO7qxzAOXsRiaIiRnUII4Lu3XlG2zx 7ZzEwljfgCC9YNQeIAMeUWbqWc6vHhpFpSKW5stqmXEgusWtwLxyS3vHcm8v7gi9qs4F 9WvJcjEf7gF14EEDjDUvbSL1BxI4utQdxdT2wrDGAzib+z5LD6Xv5yw9VW5zmEBe+ZWE giVAmXje3sbFLjUBD0HrABpY1FLz9jTsfBuW/I/JzRFrNEjlgnz25/zJUl+K4YBdEePp S/TkC0R8EZAsp3wPdFO0UF7iE0gkZ0a1DMw2v++GDlzq4Hx5X2juXv6OqTKesqRDoJSr gvaw==
MIME-Version: 1.0
Received: by 10.50.0.204 with SMTP id 12mr838133igg.54.1352933499783; Wed, 14 Nov 2012 14:51:39 -0800 (PST)
Sender: agl@google.com
Received: by 10.231.85.9 with HTTP; Wed, 14 Nov 2012 14:51:39 -0800 (PST)
In-Reply-To: 
References:  <4F981528.9010903@gnutls.org>  <4F985162.7040405@extendedsubset.com> 
Date: Wed, 14 Nov 2012 17:51:39 -0500
X-Google-Sender-Auth: 2Jpvbs1PRoA8vohEmbFsk6FynT4
Message-ID: 
From: Adam Langley 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQkDC3F+YZ5sg3zM9TZCTVMT5n0iYhX/J6O+544v17xF5wqtWHxwZk3Hl3ZQNyVaMUlU3AIMTYYWEoT2ogXXO2NC98npaSu0JENbhefwX4WTLxZJRBQXQaQOnzBOguTTNjyhgwEZ/hSwQo0d+/VY6NgTKOkWTjk3Rwfe3LwZvH27qfF9UU/G/cg2fV8O7LYxx5A1OTzT
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 22:51:41 -0000

On Wed, Nov 14, 2012 at 3:31 PM, Andrei Popov
 wrote:
> A number of issues have been raised with regard to the TLS NPN Internet-Draft, including the downgrade attack described by Marsh. Is an updated draft in the works?

I've nothing to add to -04 at the moment.

I'm afraid you'll have to highlight the attack that you're referring
to. Since the messages are covered by the Finished hash, there's no
downgrade attack that doesn't also work against anything else in the
handshake.

The major point of contention that I'm aware of is the addition of
encrypted extensions, rather than just negotiating in the client and
server hello messages, in the clear.

This is clearly additional complexity and the benefit is limited by
the fact that the server still advertises in the clear. It's the best
that can be done without adding additional round trips.

On the complexity side, there haven't been any significant issues with
implementations of the similar version of NPN that's currently used by
SPDY, except in the case of one hardware accelerator product who had
issues. They, however, appear to have figured it out.

On the benefits side, although having the server advertise in the
clear is unfortunate, that's only needed for supporting client
fallback. If the client knows what protocol it supports, it can simply
choose it and that choice is protected. Since we're in this position
partly because TCP port numbers have become unusable, it seems to be
the height of folly to create another cleartext selector and expect a
different result.

So those reasons, I believe that the current NPN design is the correct one.


Cheers

AGL

From Andrei.Popov@microsoft.com  Wed Nov 14 15:33: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 B1CC721F85B3 for ; Wed, 14 Nov 2012 15:33:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJtUSHk3aGbd for ; Wed, 14 Nov 2012 15:33:35 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 13C9821F8595 for ; Wed, 14 Nov 2012 15:33:34 -0800 (PST)
Received: from BL2FFO11FD016.protection.gbl (10.173.161.202) by BL2FFO11HUB002.protection.gbl (10.173.161.20) with Microsoft SMTP Server (TLS) id 15.0.556.9; Wed, 14 Nov 2012 23:33:26 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Wed, 14 Nov 2012 23:33:25 +0000
Received: from db3outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 14 Nov 2012 23:32:59 +0000
Received: from mail113-db3-R.bigfish.com (10.3.81.242) by DB3EHSOBE004.bigfish.com (10.3.84.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 14 Nov 2012 23:30:20 +0000
Received: from mail113-db3 (localhost [127.0.0.1])	by mail113-db3-R.bigfish.com (Postfix) with ESMTP id 4F8AC44046C	for ; Wed, 14 Nov 2012 23:30:20 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -25
X-BigFish: PS-25(zz98dI9371Id6eah542Mzz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz31h2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h9a9j1155h)
Received-SPF: softfail (mail113-db3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en;
Received: from mail113-db3 (localhost.localdomain [127.0.0.1]) by mail113-db3 (MessageSwitch) id 1352935818157997_10592; Wed, 14 Nov 2012 23:30:18 +0000 (UTC)
Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.235])	by mail113-db3.bigfish.com (Postfix) with ESMTP id 1AE8920001D; Wed, 14 Nov 2012 23:30:18 +0000 (UTC)
Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 14 Nov 2012 23:30:17 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.233.3; Wed, 14 Nov 2012 23:30:17 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) with Microsoft SMTP Server (TLS) id 15.0.545.9; Wed, 14 Nov 2012 23:30:09 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.68]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.106]) with mapi id 15.00.0545.000; Wed, 14 Nov 2012 23:30:09 +0000
From: Andrei Popov 
To: Adam Langley 
Thread-Topic: [TLS] Next Protocol Negotiation 03
Thread-Index: AQHNIlzPyXJEV/H1YEG2j4FhINiIPJarp+EAgAAXsQCAADAaAIE/FnRAgAAqXYCAAAHEsA==
Date: Wed, 14 Nov 2012 23:30:09 +0000
Message-ID: <462d1af8e2f84827abfac376f21d06d2@BN1PR03MB072.namprd03.prod.outlook.com>
References:  <4F981528.9010903@gnutls.org>  <4F985162.7040405@extendedsubset.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.156.151]
x-forefront-prvs: 066517B35B
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%CHROMIUM.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377454001)(13464001)(74662001)(47446002)(49866001)(23676001)(550184003)(47776002)(31966008)(51856001)(53806001)(44976002)(54356001)(56816001)(56776001)(16676001)(46102001)(5343635001)(54316002)(50986001)(76482001)(4396001)(5343655001)(6806001)(47736001)(47976001)(74502001)(33646001)(50466001)(24736002); DIR:OUT; SFP:; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 066517B35B
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2012 23:33:35 -0000

SGVyZSBpcyBhbiBleGFtcGxlIGFjdGl2ZSBhdHRhY2sgd2hpY2ggY291bGQgcmV2ZWFsIHRoZSBu
ZWdvdGlhdGVkIHByb3RvY29sOg0KLSBNSVRNIGRvd25ncmFkZXMgdGhlIGNpcGhlciBkdXJpbmcg
VExTIGhhbmRzaGFrZS4NCi0gTUlUTSBjYW4gZGVjcnlwdCBFbmNyeXB0ZWRFeHRlbnNpb25zIG1l
c3NhZ2UgYW5kIGZpbmQgb3V0IHdoaWNoIGFwcGxpY2F0aW9uIHByb3RvY29sIGhhcyBiZWVuIG5l
Z290aWF0ZWQgYmV0d2VlbiB0aGUgc2VydmVyIGFuZCB0aGUgY2xpZW50Lg0KLSBGaW5pc2hlZCBt
ZXNzYWdlcyBhcmUgZXhjaGFuZ2VkLCBhdCB3aGljaCBwb2ludCB0aGUgYXR0YWNrIGlzIGRldGVj
dGVkIGFuZCB0aGUgc2Vzc2lvbiBpcyBhYm9ydGVkLiBCdXQgdGhlIGF0dGFja2VyIGtub3dzIHRo
ZSBhcHBsaWNhdGlvbiBwcm90b2NvbCB0aGF0IGlzIGxpa2VseSB0byBiZSBuZWdvdGlhdGVkIGJl
dHdlZW4gdGhpcyBzZXJ2ZXIgYW5kIHRoaXMgY2xpZW50IGluIHRoZSBmdXR1cmUuDQoNCk5lZ290
aWF0aW5nIGluIHRoZSBjbGllbnQgYW5kIHNlcnZlciBoZWxsbyBtZXNzYWdlcyAoaW4gdGhlIGNs
ZWFyKSBhY2hpZXZlcyB0aGUgZ29hbCBvZiByZWR1Y2luZyByb3VuZCB0cmlwcy4gVGhlIGFkZGVk
IGNvbXBsZXhpdHkgb2YgRW5jcnlwdGVkRXh0ZW5zaW9ucyBkb2VzIG5vdCBwcm92aWRlIG11Y2gg
c2VjdXJpdHkgdmFsdWUuDQoNCkluIHRob3NlIHNpdHVhdGlvbnMgd2hlcmUgdGhlIG5leHQgcHJv
dG9jb2wgbmVnb3RpYXRpb24gbmVlZHMgdG8gYmUgY29uZmlkZW50aWFsLCBvbmUgY291bGQgdXNl
IFRMUyByZW5lZ290aWF0aW9uLiBBbHRlcm5hdGl2ZWx5LCB0aGUgbmV4dCBwcm90b2NvbCBjYW4g
YmUgbmVnb3RpYXRlZCBhZnRlciBleGNoYW5naW5nIEZpbmlzaGVkIG1lc3NhZ2VzLCBvdXRzaWRl
IG9mIHRoZSBUTFMgaGFuZHNoYWtlLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYWdsQGdvb2dsZS5jb20gW21haWx0bzphZ2xAZ29vZ2xl
LmNvbV0gT24gQmVoYWxmIE9mIEFkYW0gTGFuZ2xleQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJl
ciAxNCwgMjAxMiAyOjUyIFBNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogdGxzQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW1RMU10gTmV4dCBQcm90b2NvbCBOZWdvdGlhdGlvbiAwMw0KDQpPbiBXZWQs
IE5vdiAxNCwgMjAxMiBhdCAzOjMxIFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNy
b3NvZnQuY29tPiB3cm90ZToNCj4gQSBudW1iZXIgb2YgaXNzdWVzIGhhdmUgYmVlbiByYWlzZWQg
d2l0aCByZWdhcmQgdG8gdGhlIFRMUyBOUE4gSW50ZXJuZXQtRHJhZnQsIGluY2x1ZGluZyB0aGUg
ZG93bmdyYWRlIGF0dGFjayBkZXNjcmliZWQgYnkgTWFyc2guIElzIGFuIHVwZGF0ZWQgZHJhZnQg
aW4gdGhlIHdvcmtzPw0KDQpJJ3ZlIG5vdGhpbmcgdG8gYWRkIHRvIC0wNCBhdCB0aGUgbW9tZW50
Lg0KDQpJJ20gYWZyYWlkIHlvdSdsbCBoYXZlIHRvIGhpZ2hsaWdodCB0aGUgYXR0YWNrIHRoYXQg
eW91J3JlIHJlZmVycmluZyB0by4gU2luY2UgdGhlIG1lc3NhZ2VzIGFyZSBjb3ZlcmVkIGJ5IHRo
ZSBGaW5pc2hlZCBoYXNoLCB0aGVyZSdzIG5vIGRvd25ncmFkZSBhdHRhY2sgdGhhdCBkb2Vzbid0
IGFsc28gd29yayBhZ2FpbnN0IGFueXRoaW5nIGVsc2UgaW4gdGhlIGhhbmRzaGFrZS4NCg0KVGhl
IG1ham9yIHBvaW50IG9mIGNvbnRlbnRpb24gdGhhdCBJJ20gYXdhcmUgb2YgaXMgdGhlIGFkZGl0
aW9uIG9mIGVuY3J5cHRlZCBleHRlbnNpb25zLCByYXRoZXIgdGhhbiBqdXN0IG5lZ290aWF0aW5n
IGluIHRoZSBjbGllbnQgYW5kIHNlcnZlciBoZWxsbyBtZXNzYWdlcywgaW4gdGhlIGNsZWFyLg0K
DQpUaGlzIGlzIGNsZWFybHkgYWRkaXRpb25hbCBjb21wbGV4aXR5IGFuZCB0aGUgYmVuZWZpdCBp
cyBsaW1pdGVkIGJ5IHRoZSBmYWN0IHRoYXQgdGhlIHNlcnZlciBzdGlsbCBhZHZlcnRpc2VzIGlu
IHRoZSBjbGVhci4gSXQncyB0aGUgYmVzdCB0aGF0IGNhbiBiZSBkb25lIHdpdGhvdXQgYWRkaW5n
IGFkZGl0aW9uYWwgcm91bmQgdHJpcHMuDQoNCk9uIHRoZSBjb21wbGV4aXR5IHNpZGUsIHRoZXJl
IGhhdmVuJ3QgYmVlbiBhbnkgc2lnbmlmaWNhbnQgaXNzdWVzIHdpdGggaW1wbGVtZW50YXRpb25z
IG9mIHRoZSBzaW1pbGFyIHZlcnNpb24gb2YgTlBOIHRoYXQncyBjdXJyZW50bHkgdXNlZCBieSBT
UERZLCBleGNlcHQgaW4gdGhlIGNhc2Ugb2Ygb25lIGhhcmR3YXJlIGFjY2VsZXJhdG9yIHByb2R1
Y3Qgd2hvIGhhZCBpc3N1ZXMuIFRoZXksIGhvd2V2ZXIsIGFwcGVhciB0byBoYXZlIGZpZ3VyZWQg
aXQgb3V0Lg0KDQpPbiB0aGUgYmVuZWZpdHMgc2lkZSwgYWx0aG91Z2ggaGF2aW5nIHRoZSBzZXJ2
ZXIgYWR2ZXJ0aXNlIGluIHRoZSBjbGVhciBpcyB1bmZvcnR1bmF0ZSwgdGhhdCdzIG9ubHkgbmVl
ZGVkIGZvciBzdXBwb3J0aW5nIGNsaWVudCBmYWxsYmFjay4gSWYgdGhlIGNsaWVudCBrbm93cyB3
aGF0IHByb3RvY29sIGl0IHN1cHBvcnRzLCBpdCBjYW4gc2ltcGx5IGNob29zZSBpdCBhbmQgdGhh
dCBjaG9pY2UgaXMgcHJvdGVjdGVkLiBTaW5jZSB3ZSdyZSBpbiB0aGlzIHBvc2l0aW9uIHBhcnRs
eSBiZWNhdXNlIFRDUCBwb3J0IG51bWJlcnMgaGF2ZSBiZWNvbWUgdW51c2FibGUsIGl0IHNlZW1z
IHRvIGJlIHRoZSBoZWlnaHQgb2YgZm9sbHkgdG8gY3JlYXRlIGFub3RoZXIgY2xlYXJ0ZXh0IHNl
bGVjdG9yIGFuZCBleHBlY3QgYSBkaWZmZXJlbnQgcmVzdWx0Lg0KDQpTbyB0aG9zZSByZWFzb25z
LCBJIGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBOUE4gZGVzaWduIGlzIHRoZSBjb3JyZWN0IG9u
ZS4NCg0KDQpDaGVlcnMNCg0KQUdMDQoNCg0K


From agl@google.com  Wed Nov 14 16:09: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 2303821F85C4 for ; Wed, 14 Nov 2012 16:09:05 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAkTVajjYl83 for ; Wed, 14 Nov 2012 16:09:04 -0800 (PST)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3134B21F859A for ; Wed, 14 Nov 2012 16:09:04 -0800 (PST)
Received: by mail-ie0-f172.google.com with SMTP id 9so1669338iec.31 for ; Wed, 14 Nov 2012 16:09:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=utD8pm0enxgJ1Imo2c3I5tKtKwwN4+dHaIoQemrwnDk=; b=NiTF21jHZ36snY7bfJ8w3jLkcL0iFmP542b+5+AeRAruZ9oHAuYeAF0FpdSjbkg0ws XHazhTS8JgJr2DXNkD+53/EtpluUjr4nnAxJED+zzhb8Jv3Kb8EJMXD69UePohd28tVE 4biFmyxgpXWMpFACfyvMAOXd5cVpW/1ZiSxTYHzRl8V5ROMloKASB4bxhwJdFRAg+yAZ j84bwJcwltOGjRec2DO29FzfGJzDRSiRFi0AmDAsAVmZML8UwOLbptZYv/JE14g2/iz6 nfkABJRknIf5IWYszhilx4HfCy1fFF/MdRXct+uAxQCBgikc82FeA/5NNkCMfBoUWCcY jLeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=utD8pm0enxgJ1Imo2c3I5tKtKwwN4+dHaIoQemrwnDk=; b=F6la6gYGyEavPFd84lMNt3ASHGfvGXJKFl2Xeztw88FRJ5oX+nhxOVmh1KB8QeOc15 0cLq2HMToNT4GK80H9JCJUu3FwxnxNi6S4vOD9Mj/ESMkU3DVRJpuHPpK8zdiQszxwUL XYrBT+Syi+6eO8/P15PkoYtJ/1nzzrnDqyzAG89/kh+s2jt2XmP9UN/wpYJMBYi4iQgC BX7urHr9s9I1/LD9AmrKmLGamdAxcTtkVO4BQc6NVaX6OZtnDFMeJOxSipWSrQkXuEs+ Jb3cAjdFgg40nwDwmcgUMOm1ohZANRXlWcNqwqC15GgG4NNSjeT3qbt1ToDKH9+NkrDY 5lfw==
MIME-Version: 1.0
Received: by 10.50.42.168 with SMTP id p8mr618775igl.57.1352938143567; Wed, 14 Nov 2012 16:09:03 -0800 (PST)
Sender: agl@google.com
Received: by 10.231.85.9 with HTTP; Wed, 14 Nov 2012 16:09:03 -0800 (PST)
In-Reply-To: <462d1af8e2f84827abfac376f21d06d2@BN1PR03MB072.namprd03.prod.outlook.com>
References:  <4F981528.9010903@gnutls.org>  <4F985162.7040405@extendedsubset.com>   <462d1af8e2f84827abfac376f21d06d2@BN1PR03MB072.namprd03.prod.outlook.com>
Date: Wed, 14 Nov 2012 19:09:03 -0500
X-Google-Sender-Auth: pY9R6Obw88poTSRWd3qPZC2tv8A
Message-ID: 
From: Adam Langley 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
X-Gm-Message-State: ALoCoQmkPFxXQKmkxI6QzeJm+4vngAuTug10wgT6/feYQGEcTO0jBAEN7Nx8q+3xepnfOBMyp5Kj1uQSD2RfGLtVNTKjfN8Am9lHS/kzIwpR4G8KxYU+oF8AkD9bQwx9Kc0jX8Gc6/iJClnh1IrqXN5HEbxQSvEyRRDm2a1C8PZjtR1KFTJVA4MMuSS/78+xPpUAKZROi52i
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 00:09:05 -0000

On Wed, Nov 14, 2012 at 6:30 PM, Andrei Popov
 wrote:
> Here is an example active attack which could reveal the negotiated protocol:
> - MITM downgrades the cipher during TLS handshake.
> - MITM can decrypt EncryptedExtensions message and find out which application protocol has been negotiated between the server and the client.
> - Finished messages are exchanged, at which point the attack is detected and the session is aborted. But the attacker knows the application protocol that is likely to be negotiated between this server and this client in the future.

Ah yes, I'm sorry, in my mind I was trying to think of a way to
downgrade the protocol when you referenced that.

That attack can certainly cause the protocol to be sent using the
weakest cipher the the client supports (which is generally 3DES for
the clients in question).

However, I don't believe that your conclusion that this demonstrates
that the complexity isn't justified is correct. I think everyone
recognises that traffic is moving towards port 80 and 443 because of
filtering of TCP ports by middleware. If we create another plaintext
protocol negotiation then I'll be back here in a few years time with a
draft for NPN2 - because the plaintext negotiation will also be the
target of filtering.

The fact that a middlebox can perform an active attack and get the
protocol encrypted with 3DES doesn't affect that reasoning. I agree
that this is shade of security gray which is generally not something
that TLS deals with. None the less, I believe that it still has
significant value even through it's not white: the end-to-end
principle is worth defending.


Cheers

AGL

From paul.hoffman@vpnc.org  Wed Nov 14 16:56: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 4B64F21F866E for ; Wed, 14 Nov 2012 16:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.537
X-Spam-Level: 
X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bDqFw9oHZar for ; Wed, 14 Nov 2012 16:56:27 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id ADEA321F8646 for ; Wed, 14 Nov 2012 16:56:27 -0800 (PST)
Received: from [10.20.30.102] (50-0-66-243.dsl.dynamic.fusionbroadband.com [50.0.66.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id qAF0uPRD036139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Nov 2012 17:56:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Paul Hoffman 
In-Reply-To: <462d1af8e2f84827abfac376f21d06d2@BN1PR03MB072.namprd03.prod.outlook.com>
Date: Wed, 14 Nov 2012 16:56:31 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <7C5DB110-3025-477E-9B59-C7D05C2AEB63@vpnc.org>
References:  <4F981528.9010903@gnutls.org>  <4F985162.7040405@extendedsubset.com>   <462d1af8e2f84827abfac376f21d06d2@BN1PR03MB072.namprd03.prod.outlook.com>
To: Andrei Popov 
X-Mailer: Apple Mail (2.1499)
Cc: tls@ietf.org
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 00:56:28 -0000

On Nov 14, 2012, at 3:30 PM, Andrei Popov  =
wrote:

> Here is an example active attack which could reveal the negotiated =
protocol:
> - MITM downgrades the cipher during TLS handshake.
> - MITM can decrypt EncryptedExtensions message and find out which =
application protocol has been negotiated between the server and the =
client.
> - Finished messages are exchanged, at which point the attack is =
detected and the session is aborted. But the attacker knows the =
application protocol that is likely to be negotiated between this server =
and this client in the future.

This is arguing that the EncryptedExtensions message might be misnamed, =
in that an active MITM who doesn't mind breaking the exchange can view =
it. This is similar to identity-exposing attacks in IKEv1. It's a design =
tradeoff.

> Negotiating in the client and server hello messages (in the clear) =
achieves the goal of reducing round trips. The added complexity of =
EncryptedExtensions does not provide much security value.

I like the current design of NPN better than negotiating in the clear =
(and thus giving passive MITM firewalls another place to block based on =
policy). It doesn't feel that EncryptedExtensions is complex and it =
forces an MITM who wants to know the protocol being used to become =
noticeable active attackers.

> In those situations where the next protocol negotiation needs to be =
confidential, one could use TLS renegotiation. Alternatively, the next =
protocol can be negotiated after exchanging Finished messages, outside =
of the TLS handshake.

Renegotiation adds round trips and complexity, as we have seen in this =
WG. "Outside of the TLS handshake" just pushes this off to layer 7 and =
forces a change to all application servers and clients to do the =
negotiation. It seems cleaner to keep this in TLS.

--Paul Hoffman=

From turners@ieca.com  Thu Nov 15 10:46:42 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E438E21F85C3 for ; Thu, 15 Nov 2012 10:46:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.332
X-Spam-Level: 
X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJ3z2Q6+8tlE for ; Thu, 15 Nov 2012 10:46:42 -0800 (PST)
Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.236.19]) by ietfa.amsl.com (Postfix) with ESMTP id 682B621F8563 for ; Thu, 15 Nov 2012 10:46:42 -0800 (PST)
Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 55DD87AF0843A; Thu, 15 Nov 2012 12:46:42 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 4B01A7AF0840C for ; Thu, 15 Nov 2012 12:46:42 -0600 (CST)
Received: from pool-108-18-174-45.washdc.east.verizon.net ([108.18.174.45]:54906 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TZ4SX-0007O7-Kj for tls@ietf.org; Thu, 15 Nov 2012 12:46:41 -0600
Message-ID: <50A53890.4090502@ieca.com>
Date: Thu, 15 Nov 2012 13:46:40 -0500
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-108-18-174-45.washdc.east.verizon.net (thunderfish.local) [108.18.174.45]:54906
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 0
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: [TLS] Impact of draft-ietf-mptcp-api on 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, 15 Nov 2012 18:46:43 -0000

The Multipath TCP (MPTCP) work is starting to bubble up to the IESG:
http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
Both Stephen and I have concerns about its interactions with TLS:
https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ballot/

Has anybody here had a look at mptcp (or want to have a look) and have 
any thoughts about its interactions with TLS?

spt

From Andrei.Popov@microsoft.com  Thu Nov 15 11:43: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 A215921F8A00 for ; Thu, 15 Nov 2012 11:43:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.533
X-Spam-Level: 
X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bns6qvqijUv4 for ; Thu, 15 Nov 2012 11:43:18 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3354921F8946 for ; Thu, 15 Nov 2012 11:43:18 -0800 (PST)
Received: from BY2FFO11FD007.protection.gbl (10.1.15.202) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.556.9; Thu, 15 Nov 2012 19:43:16 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.556.9 via Frontend Transport; Thu, 15 Nov 2012 19:43:15 +0000
Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 15 Nov 2012 19:42:45 +0000
Received: from mail220-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 15 Nov 2012 19:41:18 +0000
Received: from mail220-tx2 (localhost [127.0.0.1])	by mail220-tx2-R.bigfish.com (Postfix) with ESMTP id 0EF53BC01C4	for ; Thu, 15 Nov 2012 19:41:18 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -2
X-BigFish: PS-2(zz98dI9371I146fI1432Izz1de0h1202h1d1ah1d2ahzz8275bhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h9a9j1155h)
Received-SPF: softfail (mail220-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(299001);DIR:OUT;LANG:en;
Received: from mail220-tx2 (localhost.localdomain [127.0.0.1]) by mail220-tx2 (MessageSwitch) id 1353008476146763_1066; Thu, 15 Nov 2012 19:41:16 +0000 (UTC)
Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.245])	by mail220-tx2.bigfish.com (Postfix) with ESMTP id 182E9B800E5; Thu, 15 Nov 2012 19:41:16 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 15 Nov 2012 19:41:15 +0000
Received: from BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.233.3; Thu, 15 Nov 2012 19:41:14 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) with Microsoft SMTP Server (TLS) id 15.0.545.9; Thu, 15 Nov 2012 19:41:07 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.68]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.7.106]) with mapi id 15.00.0545.000; Thu, 15 Nov 2012 19:41:07 +0000
From: Andrei Popov 
To: Paul Hoffman 
Thread-Topic: [TLS] Next Protocol Negotiation 03
Thread-Index: AQHNIlzPyXJEV/H1YEG2j4FhINiIPJarp+EAgAAXsQCAADAaAIE/FnRAgAAqXYCAAAHEsIAAIR+AgAEzNSA=
Date: Thu, 15 Nov 2012 19:41:07 +0000
Message-ID: 
References:  <4F981528.9010903@gnutls.org>  <4F985162.7040405@extendedsubset.com>   <462d1af8e2f84827abfac376f21d06d2@BN1PR03MB072.namprd03.prod.outlook.com> <7C5DB110-3025-477E-9B59-C7D05C2AEB63@vpnc.org>
In-Reply-To: <7C5DB110-3025-477E-9B59-C7D05C2AEB63@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.156.151]
x-forefront-prvs: 0666E15D35
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%VPNC.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(52314002)(377454001)(51704002)(24454001)(4396001)(54316002)(76482001)(46406002)(16676001)(49866001)(31966008)(74662001)(6806001)(47736001)(33646001)(53806001)(47976001)(51856001)(54356001)(50986001)(56776001)(46102001)(74502001)(50466001)(47776002)(56816001)(44976002)(5343635001)(47446002)(23726001)(24736002); DIR:OUT; SFP:; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0666E15D35
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Next Protocol Negotiation 03
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2012 19:43:18 -0000

Paul Hoffman [mailto:paul.hoffman@vpnc.org]  wrote:

> On Nov 14, 2012, at 3:30 PM, Andrei Popov  wr=
ote:

> > In those situations where the next protocol negotiation needs to be con=
fidential, one could use TLS renegotiation. Alternatively, the next protoco=
l can be negotiated after exchanging Finished messages, outside of the TLS =
handshake.

> Renegotiation adds round trips and complexity, as we have seen in this WG=
. "Outside of the TLS handshake" just pushes this off to layer 7 and forces=
 a change to all application servers and clients to do the negotiation. It =
seems cleaner to keep this in TLS.

The servers and clients (and/or middleware that they use) will likely need =
an update anyway, in order to:
1. Enable the TLS-NPN extension;
2. Communicate next protocol options to the TLS layer;
3. Extract the negotiated protocol info from the TLS layer;
4. Switch to the negotiated protocol.

Andrei Popov


From jsalowey@cisco.com  Fri Nov 16 09:08:19 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77F321F86AB for ; Fri, 16 Nov 2012 09:08:19 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJEP2tu2PIVy for ; Fri, 16 Nov 2012 09:08:19 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2039621F8688 for ; Fri, 16 Nov 2012 09:08:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=354; q=dns/txt; s=iport; t=1353085699; x=1354295299; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=/XrWYiHLKPBdabZg915vwHkGCa0c6RsWYzCPI2fp20k=; b=k4rKKBtQgQ1CVDJaQyWQh653AUZVjmytt3nYPuk0aqsrQVKN268wB1yw dhD0PibIIIq5FhPxlluvwkz7aUFNYcjhVa6uqHyGsOpyMzs0CfyA8HvA9 7BBvcLhbSX8bi7bSLzkb9EZL/zJ7mtP/xqOwvLS5G4dprcog2xEokeHZd E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0JAGxyplCtJXG//2dsb2JhbABEhVe9D4EBB4IgAQQSAQodUQEqFEInBBsah2sLnRmBK6AXjDOELGEDlxiNPIFrgm+CGQ
X-IronPort-AV: E=McAfee;i="5400,1158,6898"; a="143273014"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 16 Nov 2012 17:08:18 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAGH8IBU016687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 16 Nov 2012 17:08:18 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.196]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.001; Fri, 16 Nov 2012 11:08:18 -0600
From: "Joseph Salowey (jsalowey)" 
To: "tls@ietf.org" 
Thread-Topic: WGLC for draft-ietf-tls-multiple-cert-status-extension-02
Thread-Index: AQHNxBz4XTZ6AP0xt0yDR62IxYeJog==
Date: Fri, 16 Nov 2012 17:08:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.248.147]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <598F7EE1CE7E1945A9E4F1D062639401@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02
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, 16 Nov 2012 17:08:20 -0000

This is a working group last call for draft-ietf-tls-multiple-cert-status-e=
xtension-02 on "The TLS Multiple Certificate Status Request Extension".  Th=
e draft is available here:

http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-02

Please send you comments to the TLS list  by December 17, 2012.  =20

Thanks,

Joe=

From mrex@sap.com  Mon Nov 19 16:26: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 3C52811E809B for ; Mon, 19 Nov 2012 16:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.856
X-Spam-Level: 
X-Spam-Status: No, score=-9.856 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kViHXfogIJ2c for ; Mon, 19 Nov 2012 16:26:14 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE19C21F87A6 for ; Mon, 19 Nov 2012 16:26:13 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qAK0Q6xK015066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 01:26:11 +0100 (MET)
In-Reply-To: <50A21AC4.1050003@redhat.com>
To: Florian Weimer 
Date: Tue, 20 Nov 2012 01:26:05 +0100 (CET)
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: <20121120002605.F28EF1A393@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] draft-weimer-tls-previous-certificate-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 00:26:16 -0000

Florian Weimer wrote:
> I submitted an update to draft-weimer-tls-previous-certificate:
> 
> 
> 
> Compared to the previous version, I added an explanation of the expected 
> server-side processing and the interaction with client certificates.  I 
> clarified that a handshake which succeeds solely because of a user 
> override may still be considered as successful handshake.
> 
> I'm not sure how to move this forward.  I think for interoperability 
> trials, it makes sense to fix the codepoints for the extensions, but the 
> registry requires IETF Consensus, so the RFC has to come first.


On a quick read, the statement in the last paragraph of
Section 2. slightly irritates me:

   A TLS server MAY ignore this extension.  It MUST NOT assume a
   particular order of the presented certificates.  It SHOULD NOT
   include it in the server hello.  A client MUST ignore the extension
   if it is included in the server hello.


This wording has the potential to make the existing mess even for
the certificates in the server's Certificate handshake message worse
than it already is.

If anything, this ought to be EXACTLY the certificate_list sent by the
server as certificate_list in the server's Certificate TLS handshake
message on a previous handshake -- with no additions, no removals
and no reorderings of certificates.  In particular, it should not be
the resulting certificate path that a weird&fancy TLS client creates
by performing a full blown path discovery on the server certificate,
while the originally accompanying path certificate were only used as
hints / candidates for the discovery among other sources (cert caching,
and/or (oh my god) AIA-chasing).


   http://tools.ietf.org/html/rfc2246#page-39

   certificate_list
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.


I know there exist several defective TLS server implementations,
that will send arbitrarily garbled certificate_lists in the Certificate
handshake message, although it is pretty clear that the spec has always
required to send a correctly ordered list.

  http://tools.ietf.org/html/rfc6101#section-5.6.2


For implementations with a concept of PKI credential management,
a correctly ordered certificate_list may be an automatic by-product
of the credential management operation that creates (and validates)
the PKI credential.  TLS implementations that lack a concept of
PKI credentials should probably sort the (chain) certificates when
loading the PKI credentials cert chain from external storage,
so that the server admin will immediately get an helpful error message
if any path certificates are missing and any Certificate handshake
messages in the following (thousands) of handshake will be conforming
to the TLS specification without wasting CPU cycles for the very
same operation again and again and again.


-Martin

From ynir@checkpoint.com  Tue Nov 20 05:10:14 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230B321F853F for ; Tue, 20 Nov 2012 05:10:14 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NfQ4EM9syKG for ; Tue, 20 Nov 2012 05:10:13 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3139021F853C for ; Tue, 20 Nov 2012 05:10:12 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id qAKDAAVb018274; Tue, 20 Nov 2012 15:10:10 +0200
X-CheckPoint: {50AB7DE6-3-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.194]) by IL-EX10.ad.checkpoint.com ([169.254.2.194]) with mapi id 14.02.0318.004; Tue, 20 Nov 2012 15:10:07 +0200
From: Yoav Nir 
To: Florian Weimer 
Thread-Topic: [TLS] draft-weimer-tls-previous-certificate-01
Thread-Index: AQHNwYYUV0HtK2qzOEqmzfHaY/8YWJfynCWA
Date: Tue, 20 Nov 2012 13:10:07 +0000
Message-ID: <4613980CFC78314ABFD7F85CC302772101C2FC@IL-EX10.ad.checkpoint.com>
References: <50A21AC4.1050003@redhat.com>
In-Reply-To: <50A21AC4.1050003@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [91.90.139.66]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11120b863ce83390901a76258b704eb2dc54a66f62
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2318C6091DECCF40BE5765504721E5E8@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] draft-weimer-tls-previous-certificate-01
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, 20 Nov 2012 13:10:14 -0000

Hi Florian

This seems like a lighter-weight alternative to certificate transparency. W=
hile we don't get the client-side benefit (the client can't check if some c=
ertificate is legitimate), the server will eventually be notified of any ce=
rtificate out there pretending to be for it.

One thing I don't like about this proposal, is the bandwidth requirements. =
You're sending a massive chain in the first handshake message, which will l=
ikely slow down the whole thing, because the TCP window is still small at t=
his stage.  Wouldn't it make more sense to have the extension send only a h=
ash of the previous chain?  In that case, the server would not send anythin=
g back if it has already seen this hash. If it hasn't, it will send this ex=
tension, and then the client can send the whole chain to the server.

There's two ways here. First, you can add a new handshake message that cont=
ains the previous certificate. But what I would like even better, is if the=
 server response contained a URL, where the client can POST the certificate=
 chain, in a separate connection that does not interfere with the handshake=
 any more than is needed.

Interoperability trials can be done with a big extension identifier. It's n=
ot polite to put this in the big browsers, at least by default, but it's fi=
ne for testing. And of course, it's easier to get an RFC when you have some=
 real-world experience.

Yoav

On Nov 13, 2012, at 12:02 PM, Florian Weimer wrote:

> I submitted an update to draft-weimer-tls-previous-certificate:
>=20
> 
>=20
> Compared to the previous version, I added an explanation of the expected =
server-side processing and the interaction with client certificates.  I cla=
rified that a handshake which succeeds solely because of a user override ma=
y still be considered as successful handshake.
>=20
> I'm not sure how to move this forward.  I think for interoperability tria=
ls, it makes sense to fix the codepoints for the extensions, but the regist=
ry requires IETF Consensus, so the RFC has to come first.




From mrex@sap.com  Tue Nov 20 13:09:57 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A8721F8825 for ; Tue, 20 Nov 2012 13:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.142
X-Spam-Level: 
X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu9gF2DqAP7i for ; Tue, 20 Nov 2012 13:09:56 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3B52821F8824 for ; Tue, 20 Nov 2012 13:09:53 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qAKL9jXE011157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 22:09:50 +0100 (MET)
In-Reply-To: 
To: Chris Richardson 
Date: Tue, 20 Nov 2012 22:09:45 +0100 (CET)
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: <20121120210945.994CA1A397@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Update on Origin-Bound Certificates: Now called "Channel ID"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2012 21:09:57 -0000

Chris Richardson wrote:
>
> Adam Langley  wrote:
>>
>> Chris Richardson  wrote:
>>>
>>> Perhaps I'm being picky, section 4 requires an illegal_parameter alert
>>> if the cipher suite is insufficiently strong.  Doesn't
>>> handshake_failure make more sense here?
>>
>> Does it? From RFC 5246:
>>
>> illegal_parameter
>>       A field in the handshake was out of range or inconsistent with
>>       other fields.  This message is always fatal.
>>
>> Seems to make sense, no?
>
> If I was looking at a packet capture and wanted to figure out what
> exactly went wrong and how to make the connection succeed,
> illegal_parameter would lead me to incorrect conclusions.
> handshake_failure ("unable to negotiate an acceptable set of security
> parameters") would lead me in the right direction.
> insufficient_security would be ideal, but it is only supposed to be
> sent from server to client.
 
Are you refering to this (*) text:

  http://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-4

   A new handshake message type ("encrypted_extensions(TBD)") is
   defined.  If the server included a "channel_id" extension in its
   "ServerHello" message, the client MUST verify that the selected
*  cipher suite is sufficiently strong.  If the cipher suite provides <
*  80-bits of security, the client MUST abort the handshake with a fatal
*  "illegal_parameter" alert.  Otherwise, the client MUST send an
   "EncryptedExtensions" message after its "ChangeCipherSpec" and before
   its "Finished" message.


rfc5246 defines for the alert "insufficient security" like this.

  http://tools.ietf.org/html/rfc5246#page-33

   insufficient_security
      Returned instead of handshake_failure when a negotiation has
      failed specifically because the server requires ciphers more
      secure than those supported by the client.  This message is always
      fatal.

The second sentence "This message is always fatal" should to be interpreted
as a requirement.  The first sentence describes the purpose for which
rfc5246 uses this alert, it can not be interpreted to limit its usage
for server->client signaling.


However, in a TLS handshake, the client *MUST* include the list of
cipher suites acceptable to the client in ClientHello.  If a cipher
suite is not acceptable to the client, it should not appear in the
ClientHello in the first place.  If it appears, it MUST be acceptable
to the client if the server chooses it.

The suggexted "illegal_parameter" is probably meant for the situation
where the server chooses a cipher suite that the client never offered
(which _might_ be the result of an Man-in-the-Middle attacker).

To me, it is difficult to conceive a usage scenario where the alert
"insufficient_security" would be the appropriate response, rather than
an indication that the client is goofing the list of acceptable
cipher suites in ClientHello.


A client that did _not_ offer AES256_CBC-SHA1 (due to configuration)
should also abort with an illegal_parameter alert if the server chooses
that cipher suite, even though I'm not aware of any security concerns
about that cipher suite (pre-TLS1.1 IVs is a different issue).


-Martin

From n.mavrogiannopoulos@gmail.com  Tue Nov 20 15:27:40 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B06F21F85EB for ; Tue, 20 Nov 2012 15:27:40 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2+zR0fttT18 for ; Tue, 20 Nov 2012 15:27:40 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8EBC21F85EA for ; Tue, 20 Nov 2012 15:27:39 -0800 (PST)
Received: by mail-we0-f172.google.com with SMTP id r3so754514wey.31 for ; Tue, 20 Nov 2012 15:27:38 -0800 (PST)
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=03lfu5zNFfwgbf7sxKZu/0WVcQ9xTdxZQtayCSs6ID0=; b=XDzx0/DqemZFwt28TNfY5EENOLPNqS1V+Nmw//XJPETEZXWKOIN8WInEnceJ5+YQeo qmPSyNK9gMfsXfzDhQMeY9F0ckIzsqhAA8w/pI9HGHnI++RETk1hNGqRfYyozcbyswan bZp7mrNrRE0px3IJgS432z68C7nzqgnzhA+fCVeqc/1ed6iZCq+ZgpA7ZWgaZ8Y8DScf zaNz8f7m+K2R7kOZVRjHSRsdvMeLBwE9VSQFNIrmaG5Oi5E0Qaniy0RO4T/lpfjVHNXU HIsUqb1tjTNXMs8ZNLId5EEbTY9RT8ttnZxtmGzePI4kjbEEtXRDONELcOTZLAkgi7QP kPHw==
Received: by 10.180.74.20 with SMTP id p20mr7537573wiv.0.1353454058775; Tue, 20 Nov 2012 15:27:38 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id r10sm22243406wiz.0.2012.11.20.15.27.37 (version=SSLv3 cipher=OTHER); Tue, 20 Nov 2012 15:27:37 -0800 (PST)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <50AC11E3.2010209@gnutls.org>
Date: Wed, 21 Nov 2012 00:27:31 +0100
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10
MIME-Version: 1.0
To: mrex@sap.com
References: <20121120210945.994CA1A397@ld9781.wdf.sap.corp>
In-Reply-To: <20121120210945.994CA1A397@ld9781.wdf.sap.corp>
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: [TLS] illegal alert [was: Update on Origin-Bound Certificates: Now called "Channel ID"]
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, 20 Nov 2012 23:27:40 -0000

On 11/20/2012 10:09 PM, Martin Rex wrote:


> The suggexted "illegal_parameter" is probably meant for the situation
> where the server chooses a cipher suite that the client never offered
> (which _might_ be the result of an Man-in-the-Middle attacker).
> 
> To me, it is difficult to conceive a usage scenario where the alert
> "insufficient_security" would be the appropriate response, rather than
> an indication that the client is goofing the list of acceptable
> cipher suites in ClientHello.


There is a use-case for this alert (although not in its description).
Think of a server that uses a 256-bit DH key. In that case,
unfortunately, the client cannot do much except close the connection
with an alert.

regards,
Nikos

From mrex@sap.com  Tue Nov 20 17:26: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 0629E21F86B2 for ; Tue, 20 Nov 2012 17:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level: 
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TinHYzz8VMWx for ; Tue, 20 Nov 2012 17:26:36 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 47E1621F86FE for ; Tue, 20 Nov 2012 17:26:36 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qAL1QVwG013417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Nov 2012 02:26:32 +0100 (MET)
In-Reply-To: <50AC11E3.2010209@gnutls.org>
To: Nikos Mavrogiannopoulos 
Date: Wed, 21 Nov 2012 02:26:31 +0100 (CET)
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: <20121121012631.770FA1A39B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] illegal alert [was: Update on Origin-Bound Certificates: Now called "Channel ID"]
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, 21 Nov 2012 01:26:37 -0000

Nikos Mavrogiannopoulos wrote:
>
> Martin Rex wrote:
>> 
>> The suggexted "illegal_parameter" is probably meant for the situation
>> where the server chooses a cipher suite that the client never offered
>> (which _might_ be the result of an Man-in-the-Middle attacker).
>> 
>> To me, it is difficult to conceive a usage scenario where the alert
>> "insufficient_security" would be the appropriate response, rather than
>> an indication that the client is goofing the list of acceptable
>> cipher suites in ClientHello.
> 
> There is a use-case for this alert (although not in its description).
> Think of a server that uses a 256-bit DH key. In that case,
> unfortunately, the client cannot do much except close the connection
> with an alert.


Thanks!  

Yes, that looks like a perfectly valid client-side use case for the
"insufficient_security" alert.


-Martin

From turners@ieca.com  Tue Nov 27 11:11:45 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C84821F857D for ; Tue, 27 Nov 2012 11:11:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.282
X-Spam-Level: 
X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV2IuFXky5bn for ; Tue, 27 Nov 2012 11:11:45 -0800 (PST)
Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.94.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0B85221F8743 for ; Tue, 27 Nov 2012 11:11:45 -0800 (PST)
Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 69E6786FD826B; Tue, 27 Nov 2012 13:11:24 -0600 (CST)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id A0CF486FD7F83 for ; Tue, 27 Nov 2012 13:11:23 -0600 (CST)
Received: from [108.45.19.185] (port=56052 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TdQZ2-00079Y-4x for tls@ietf.org; Tue, 27 Nov 2012 13:11:24 -0600
Message-ID: <50B5105B.1050806@ieca.com>
Date: Tue, 27 Nov 2012 14:11:23 -0500
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: tls@ietf.org
References: <50A53890.4090502@ieca.com>
In-Reply-To: <50A53890.4090502@ieca.com>
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) [108.45.19.185]:56052
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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, 27 Nov 2012 19:11:45 -0000

On 11/15/12 1:46 PM, Sean Turner wrote:
> The Multipath TCP (MPTCP) work is starting to bubble up to the IESG:
> http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
> Both Stephen and I have concerns about its interactions with TLS:
> https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ballot/
>
> Has anybody here had a look at mptcp (or want to have a look) and have
> any thoughts about its interactions with TLS?

What's on offer to for the mptcp api draft is as follows:

"Implementations of TLS [RFC5246] making use of the basic API that
compare the addresses used by MPTCP against names or addresses present
in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses
used in the initial subflow since MPTCP itself handles the security of
subsequent subflows. A need for finer-grained controls would imply a
need to use an advanced API."

Thoughts?

spt

From jsalowey@cisco.com  Tue Nov 27 21:19:06 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AD21F85A4 for ; Tue, 27 Nov 2012 21:19:06 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLCptls3BbqL for ; Tue, 27 Nov 2012 21:19:06 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id DD7DB21F859D for ; Tue, 27 Nov 2012 21:19:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3932; q=dns/txt; s=iport; t=1354079946; x=1355289546; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H2rrs+A04UJqbdOSr8vwB5fKIjGkdHpQ9hJtKxgBW3E=; b=hAr45f222U+WW99hynA4rRteXQx6KqC4OoZ4m8VURp6Ck1ozavrjfFxK 1FhDQbePkZ/C8x6VbNOTX+o39T/04uSJa8Swg3gUNvMv/hEipxNCPIwp6 MF6q21YCm/iNrMhKmnLGM1Jo7hF4j4FNXBLOfXGKl0wUtaEvhybUZsHB1 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALqdtVCtJV2b/2dsb2JhbABFwCMWc4IeAQEBAwEBAQE3NAsFCwIBCCIUECcLJQIEDgUIh38GDL8dBIw6FQGDSmEDpkWCcIFiAQYZHg
X-IronPort-AV: E=McAfee;i="5400,1158,6909"; a="146949165"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 28 Nov 2012 05:19:05 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAS5J55l002431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 05:19:05 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.22]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.001; Tue, 27 Nov 2012 23:19:05 -0600
From: "Joseph Salowey (jsalowey)" 
To: Stefan Santesson 
Thread-Topic: [TLS] Comments on the cached-info draft
Thread-Index: AQHNvQbiOxf7J2O3YEykXagetKXYEZf/Oi2A
Date: Wed, 28 Nov 2012 05:19:04 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.248.147]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6CFD9B4535CFC64E980B149A64D07793@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] Comments on the cached-info draft
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, 28 Nov 2012 05:19:06 -0000

Hi Stefan,

This new proposal of omitting the data sounds a bit simpler to me.   You sa=
y the new approach will limit the functionality in some way.  In what way i=
s it limited? =20

Do you think we could accommodate the case where the endpoint has intermedi=
ate CA certificates cached but not the end entity certificate? This would r=
equire parsing the certificate message, but the response could just omit th=
e certs that were indicated in the cachedInfo.   The parsing of the cert me=
ssage is a bit more complex, but it could satisfy some of the use cases dis=
cussed at the meeting.

Thanks,

Joe=20



On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote:

> It was quite a while since I wrote the first version of this draft.
> Now that I bring it up to my attention I found a problem that I think
> should be fixed.
>=20
> After a close examination I'm convinced that the current spec breaks TLS.
>=20
>=20
> The current approach is to exchange support for cached-info in client and
> server hellos.
> This includes hashes for cached objects (clients) and confirmation of
> cached objects (server).
>=20
> In addition to this, this protocol allows the cached data in handshake
> messages to be swapped with cached object hashes.
> This is a violation of the syntax of these handshake messages.
>=20
> Take the Certificate handshake message for example. The spec suggest here
> to replace the certificate_list vector to be replaced with a vector of
> CachedObejct structured data.
> This breaks the syntax of this handshake message. A strict processing of
> the certificate_list vector will expect an ASN.1 encoded binary containin=
g
> a sequence of certificates, not a vector of data objects according to the
> CachedObject structure.
>=20
> My first thought was that we actually need a new handshake message.
> However that is not helpful either.
> The TLS spec require the Certificate handshake message to be sent in case
> the chosen cipher suite demands it, so it MUST be sent.
> It can't be replaced by another handshake message.
>=20
> My current belief is that we simply should omit the cached data, and that
> each cachedInfo type need to defined how to omit cached data.
>=20
> In case of the certificate handshake message, the certificate list should
> be replaced with an empty sequence.
>=20
>=20
> There is actually no need to send the hash of the cached data in the
> handshake message. Not if the confirmation of the cached info is exchange=
d
> in the server hello. Sending the hash once more in the handshake message
> is then redundant.
>=20
>=20
> So I propose the following:
>=20
> 1) Clients send hashes of cached objects in client hello.
> 2) Server responds with one or zero hashes per cachedInfo type, that a)
> matches a cached object sent by the client b) will be omitted by the
> server in the corresponding handshake message.
> 3) How information is omitted from the handshake message is defined per
> cached info type. For the current defined 2 types this is:
>  A) cached certificate cahins in Certificate: replace the sequence of
> certificates with an empty sequence.
>  B) certificate_authorities in Certificate Request: Send an empty list of
> DistinguishedName
> 4) Clients will act as if the cached objects (confirmed in server hello)
> were sent in the handshake messages.
> 5) Everything else according to the current spec
>=20
>=20
> The proposed approach will somewhat limit the functionality of the curren=
t
> spec, but it ads value in simplicity.
> I can't imagine a valid use case that would not be covered by this change=
,
> but I might overlook something.
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From fweimer@redhat.com  Wed Nov 28 00:05:42 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12B921F850C for ; Wed, 28 Nov 2012 00:05:41 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMGON3UE3Oiu for ; Wed, 28 Nov 2012 00:05:41 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 75CE021F8458 for ; Wed, 28 Nov 2012 00:05:41 -0800 (PST)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAS85dYp032104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Nov 2012 03:05:39 -0500
Received: from fweimer.str.redhat.com (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAS85b0C021398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2012 03:05:38 -0500
Message-ID: <50B5C5D0.8060904@redhat.com>
Date: Wed, 28 Nov 2012 09:05:36 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Sean Turner 
References: <50A53890.4090502@ieca.com> <50B5105B.1050806@ieca.com>
In-Reply-To: <50B5105B.1050806@ieca.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Cc: tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 08:05:42 -0000

On 11/27/2012 08:11 PM, Sean Turner wrote:
> On 11/15/12 1:46 PM, Sean Turner wrote:
>> The Multipath TCP (MPTCP) work is starting to bubble up to the IESG:
>> http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
>> Both Stephen and I have concerns about its interactions with TLS:
>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ballot/
>>
>> Has anybody here had a look at mptcp (or want to have a look) and have
>> any thoughts about its interactions with TLS?
>
> What's on offer to for the mptcp api draft is as follows:
>
> "Implementations of TLS [RFC5246] making use of the basic API that
> compare the addresses used by MPTCP against names or addresses present
> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses
> used in the initial subflow since MPTCP itself handles the security of
> subsequent subflows. A need for finer-grained controls would imply a
> need to use an advanced API."

I think the "since" part is wrong.  The security of the subsequent 
subflows must depend on TLS itself, not MPTCP.

-- 
Florian Weimer / Red Hat Product Security Team

From fweimer@redhat.com  Wed Nov 28 06:37:54 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631CF21F87DE for ; Wed, 28 Nov 2012 06:37:54 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3n1r0XXOldb for ; Wed, 28 Nov 2012 06:37:53 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id D8DE921F87AC for ; Wed, 28 Nov 2012 06:37:53 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qASEbirD029472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Nov 2012 09:37:44 -0500
Received: from fweimer.str.redhat.com (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qASEbd80019619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 28 Nov 2012 09:37:43 -0500
Message-ID: <50B621B3.4000008@redhat.com>
Date: Wed, 28 Nov 2012 15:37:39 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Yoav Nir 
References: <50A21AC4.1050003@redhat.com> <4613980CFC78314ABFD7F85CC302772101C2FC@IL-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC302772101C2FC@IL-EX10.ad.checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: "" 
Subject: Re: [TLS] draft-weimer-tls-previous-certificate-01
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, 28 Nov 2012 14:37:54 -0000

On 11/20/2012 02:10 PM, Yoav Nir wrote:

> This seems like a lighter-weight alternative to certificate transparency. While we don't get the client-side benefit (the client can't check if some certificate is legitimate), the server will eventually be notified of any certificate out there pretending to be for it.

Right.

> One thing I don't like about this proposal, is the bandwidth requirements. You're sending a massive chain in the first handshake message, which will likely slow down the whole thing, because the TCP window is still small at this stage.

I don't think this will introduce additional network round-trips with 
reasonably sized chains and the current initial CWND recommendations. 
However, the bytes themselves take some time to transmit, adding around 
50ms at 384kpbs with a medium-sized chain.  And this overhead is also 
present during session resumption.

I guess this overhead pretty much kills the idea. 8-(

 >Wouldn't it make more sense to have the extension send only a hash of 
the previous chain?  In that case, the server would not send anything 
back if it has already seen this hash. If it hasn't, it will send this 
extension, and then the client can send the whole chain to the server.
>
> There's two ways here. First, you can add a new handshake message that contains the previous certificate. But what I would like even better, is if the server response contained a URL, where the client can POST the certificate chain, in a separate connection that does not interfere with the handshake any more than is needed.

Interesting idea.

It's certainly more difficult to deploy for server operators.  But the 
POST-based indirection would eliminate the mismatch between the maximum 
extension size in the client hello and the maximum chain size, 
simplifying the client implementation.

On the other hand, the certificate submission will not be protected by 
the TLS handshake anymore, so a handshake can be successful with the 
original/genuine certificate, but the previous certificate chain with 
the spoofed one is never submitted.  This would make it simpler for 
attackers to cover their tracks.

-- 
Florian Weimer / Red Hat Product Security Team

From stephen.farrell@cs.tcd.ie  Wed Nov 28 07:25: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 BB4A521F8867 for ; Wed, 28 Nov 2012 07:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez5iAwAHBSG3 for ; Wed, 28 Nov 2012 07:25:16 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0903021F8891 for ; Wed, 28 Nov 2012 07:25:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C5C7BE62; Wed, 28 Nov 2012 15:24:53 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQeADm09ccQA; Wed, 28 Nov 2012 15:24:52 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:9999:53ef:87e7:8281] (unknown [IPv6:2001:770:10:203:9999:53ef:87e7:8281]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4AEAFBE20; Wed, 28 Nov 2012 15:24:52 +0000 (GMT)
Message-ID: <50B62CC4.6090109@cs.tcd.ie>
Date: Wed, 28 Nov 2012 15:24:52 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Florian Weimer 
References: <50A53890.4090502@ieca.com> <50B5105B.1050806@ieca.com> <50B5C5D0.8060904@redhat.com>
In-Reply-To: <50B5C5D0.8060904@redhat.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 15:25:17 -0000

On 11/28/2012 08:05 AM, Florian Weimer wrote:
> On 11/27/2012 08:11 PM, Sean Turner wrote:
>> On 11/15/12 1:46 PM, Sean Turner wrote:
>>> The Multipath TCP (MPTCP) work is starting to bubble up to the IESG:
>>> http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/
>>> Both Stephen and I have concerns about its interactions with TLS:
>>> https://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ballot/
>>>
>>> Has anybody here had a look at mptcp (or want to have a look) and have
>>> any thoughts about its interactions with TLS?
>>
>> What's on offer to for the mptcp api draft is as follows:
>>
>> "Implementations of TLS [RFC5246] making use of the basic API that
>> compare the addresses used by MPTCP against names or addresses present
>> in X.509 certificates [RFC5280,RFC6125] MUST only consider the addresses
>> used in the initial subflow since MPTCP itself handles the security of
>> subsequent subflows. A need for finer-grained controls would imply a
>> need to use an advanced API."
> 
> I think the "since" part is wrong.  The security of the subsequent
> subflows must depend on TLS itself, not MPTCP.

Fair point. I can try re-word it, but first to the real
question I'd like to check...

Does anyone care that e.g. a server cert that contains IP
address 'a' might be used for the first subflow, but
subsequent packets for that TLS session can end up going
vis MPTCP to IP address 'b' where 'b' is not mentioned
in the cert?

Ah crap - I just remembered excludedSubtrees can apply to
IP address name constraints. Anyone here care about that?

Cheers,
S.

> 

From mrex@sap.com  Wed Nov 28 07:37: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 14A4C21F887C for ; Wed, 28 Nov 2012 07:37:00 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6mZdwuPu7Aj for ; Wed, 28 Nov 2012 07:36:59 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACEE21F886E for ; Wed, 28 Nov 2012 07:36:59 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qASFaqU4023029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 28 Nov 2012 16:36:52 +0100 (MET)
In-Reply-To: <50B62CC4.6090109@cs.tcd.ie>
To: Stephen Farrell 
Date: Wed, 28 Nov 2012 16:36:50 +0100 (CET)
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: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on TLS
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, 28 Nov 2012 15:37:00 -0000

Stephen Farrell wrote:
> 
>> 
>> I think the "since" part is wrong.  The security of the subsequent
>> subflows must depend on TLS itself, not MPTCP.
> 
> Fair point. I can try re-word it, but first to the real
> question I'd like to check...
> 
> Does anyone care that e.g. a server cert that contains IP
> address 'a' might be used for the first subflow, but
> subsequent packets for that TLS session can end up going
> vis MPTCP to IP address 'b' where 'b' is not mentioned
> in the cert?
> 
> Ah crap - I just remembered excludedSubtrees can apply to
> IP address name constraints. Anyone here care about that?


I somehow fail to understand the discussion.  The IP-address
that the socket shows after connection establishment is
completely irrelevant to the security of TLS, even when
Server-Certificates with IP-Addresses in the SubjectAltName
are used for server endpoint identification according to
rfc2818 section 3.1.

What is actually matched is the "information SOURCE" that the application
uses to establish the network connection and the Certificate presented
by the server in the TLS handshake.  Whether there are HTTP CONNECT
proxies or even network-address-transparent MITMs on the path does
not matter for the security provided by TLS, because that information
is not (must not be) part of the information that is matched
during server endpoint identification.

-Martin

From stephen.farrell@cs.tcd.ie  Wed Nov 28 07:53:02 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5334321F8890 for ; Wed, 28 Nov 2012 07:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7exZcCqLpAQW for ; Wed, 28 Nov 2012 07:53:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AA24621F887C for ; Wed, 28 Nov 2012 07:53:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A4CFBE84; Wed, 28 Nov 2012 15:52:40 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxka4a8eVVGd; Wed, 28 Nov 2012 15:52:35 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:9999:53ef:87e7:8281] (unknown [IPv6:2001:770:10:203:9999:53ef:87e7:8281]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 924A0BE6B; Wed, 28 Nov 2012 15:52:28 +0000 (GMT)
Message-ID: <50B6333C.50606@cs.tcd.ie>
Date: Wed, 28 Nov 2012 15:52:28 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp>
In-Reply-To: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 15:53:02 -0000

Hi Martin,

On 11/28/2012 03:36 PM, Martin Rex wrote:
> Stephen Farrell wrote:
>>
>>>
>>> I think the "since" part is wrong.  The security of the subsequent
>>> subflows must depend on TLS itself, not MPTCP.
>>
>> Fair point. I can try re-word it, but first to the real
>> question I'd like to check...
>>
>> Does anyone care that e.g. a server cert that contains IP
>> address 'a' might be used for the first subflow, but
>> subsequent packets for that TLS session can end up going
>> vis MPTCP to IP address 'b' where 'b' is not mentioned
>> in the cert?
>>
>> Ah crap - I just remembered excludedSubtrees can apply to
>> IP address name constraints. Anyone here care about that?
> 
> 
> I somehow fail to understand the discussion.  

We're trying to figure out if the mptcp API document needs
to say anything about tls, and if so, what. And I'd like
to do that so mptcp doesn't have to fall back to just tcp
for all cases where you need tls, if that's ok, so that
mptcp has a chance to get used. (I figure its hard enough
being a new transport these days, but being a new transport
that is useless under TLS seems like a bit of a killer.)

> The IP-address
> that the socket shows after connection establishment is
> completely irrelevant to the security of TLS, even when
> Server-Certificates with IP-Addresses in the SubjectAltName
> are used for server endpoint identification according to
> rfc2818 section 3.1.

Well, 2818 is just http/tls/tcp and the context here is
anything/tls/mptcp so I'm not sure that solves the problem
of what to say.

I think its true that there's no security issue, but there
might be an interop issue, if different folks implement
tls/mptcp differently. If the tls code just uses the normal
socket api then there's nothing to say, but it won't get
the benefit of mptcp. If the tls code uses the basic api
then it can see which subflows are being used and different
folks might do different comparisons to the certs used.

Cheers,
S.


> 
> What is actually matched is the "information SOURCE" that the application
> uses to establish the network connection and the Certificate presented
> by the server in the TLS handshake.  Whether there are HTTP CONNECT
> proxies or even network-address-transparent MITMs on the path does
> not matter for the security provided by TLS, because that information
> is not (must not be) part of the information that is matched
> during server endpoint identification.
> 
> -Martin
> 
> 

From geoffk@geoffk.org  Wed Nov 28 11:52: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 290F621F8853 for ; Wed, 28 Nov 2012 11:52:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2JfNH8ufHUx for ; Wed, 28 Nov 2012 11:52:33 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id A2CFC21F84E1 for ; Wed, 28 Nov 2012 11:52:33 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 2DDDF33D04B; Wed, 28 Nov 2012 19:52:32 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Stephen Farrell 
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie>
From: Geoffrey Keating 
Date: 28 Nov 2012 11:52:31 -0800
In-Reply-To: <50B6333C.50606@cs.tcd.ie>
Message-ID: 
Lines: 44
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 19:52:34 -0000

Stephen Farrell  writes:

> Hi Martin,
> 
> We're trying to figure out if the mptcp API document needs
> to say anything about tls, and if so, what. And I'd like
> to do that so mptcp doesn't have to fall back to just tcp
> for all cases where you need tls, if that's ok, so that
> mptcp has a chance to get used. (I figure its hard enough
> being a new transport these days, but being a new transport
> that is useless under TLS seems like a bit of a killer.)

> On 11/28/2012 03:36 PM, Martin Rex wrote:
> > The IP-address
> > that the socket shows after connection establishment is
> > completely irrelevant to the security of TLS, even when
> > Server-Certificates with IP-Addresses in the SubjectAltName
> > are used for server endpoint identification according to
> > rfc2818 section 3.1.
> 
> Well, 2818 is just http/tls/tcp and the context here is
> anything/tls/mptcp so I'm not sure that solves the problem
> of what to say.
> 
> I think its true that there's no security issue, but there
> might be an interop issue, if different folks implement
> tls/mptcp differently. If the tls code just uses the normal
> socket api then there's nothing to say, but it won't get
> the benefit of mptcp. If the tls code uses the basic api
> then it can see which subflows are being used and different
> folks might do different comparisons to the certs used.

Maybe a related example will help: suppose the user is trying to
connect to https://198.51.100.3.  There is an HTTP proxy configured,
so what the browser actually does is make a TCP connection to
192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
SSL negotiation.  The certificate still has to mention 198.51.100.3,
and doesn't have to mention 192.0.2.99.

So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
whatever), then 198.51.100.3 is the address that has to appear in the
certificate, even if the connection is redirected to some other
endpoint, even if the redirection happens before any data is actually
sent on the connection.

From stpeter@stpeter.im  Wed Nov 28 13:41: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 E3A2021F8593 for ; Wed, 28 Nov 2012 13:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.498
X-Spam-Level: 
X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXX5KoONp6w2 for ; Wed, 28 Nov 2012 13:41:09 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 170CD21F8575 for ; Wed, 28 Nov 2012 13:41:09 -0800 (PST)
Received: from [10.129.24.67] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2D4CD40062; Wed, 28 Nov 2012 14:46:06 -0700 (MST)
Message-ID: <50B684F6.4050004@stpeter.im>
Date: Wed, 28 Nov 2012 14:41:10 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Geoffrey Keating 
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie> 
In-Reply-To: 
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 21:41:10 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/28/12 12:52 PM, Geoffrey Keating wrote:
> Stephen Farrell  writes:
> 
>> Hi Martin,
>> 
>> We're trying to figure out if the mptcp API document needs to say
>> anything about tls, and if so, what. And I'd like to do that so
>> mptcp doesn't have to fall back to just tcp for all cases where
>> you need tls, if that's ok, so that mptcp has a chance to get
>> used. (I figure its hard enough being a new transport these days,
>> but being a new transport that is useless under TLS seems like a
>> bit of a killer.)
> 
>> On 11/28/2012 03:36 PM, Martin Rex wrote:
>>> The IP-address that the socket shows after connection
>>> establishment is completely irrelevant to the security of TLS,
>>> even when Server-Certificates with IP-Addresses in the
>>> SubjectAltName are used for server endpoint identification
>>> according to rfc2818 section 3.1.
>> 
>> Well, 2818 is just http/tls/tcp and the context here is 
>> anything/tls/mptcp so I'm not sure that solves the problem of
>> what to say.
>> 
>> I think its true that there's no security issue, but there might
>> be an interop issue, if different folks implement tls/mptcp
>> differently. If the tls code just uses the normal socket api then
>> there's nothing to say, but it won't get the benefit of mptcp. If
>> the tls code uses the basic api then it can see which subflows
>> are being used and different folks might do different comparisons
>> to the certs used.
> 
> Maybe a related example will help: suppose the user is trying to 
> connect to https://198.51.100.3.  There is an HTTP proxy
> configured, so what the browser actually does is make a TCP
> connection to 192.0.2.99, send 'CONNECT https://198.51.100.3', and
> then start the SSL negotiation.  The certificate still has to
> mention 198.51.100.3, and doesn't have to mention 192.0.2.99.
> 
> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or 
> whatever), then 198.51.100.3 is the address that has to appear in
> the certificate, even if the connection is redirected to some
> other endpoint, even if the redirection happens before any data is
> actually sent on the connection.

This is basically the "CertID" problem (RFC 6125). When Jeff Hodges
and I worked on that spec, we deliberately left IP addresses out of
scope, but if someone wants to work on a similar (though much simpler)
document about IP addresses instead of domain names, I'm sure they
could find quite a bit of text to borrow.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlC2hPYACgkQNL8k5A2w/vxh+QCgozvyk8K6K1z6lHEz8hafzTGL
CEYAoL6fF0tgUeP3oohDbXmLRafdTEqj
=iJ0P
-----END PGP SIGNATURE-----

From stephen.farrell@cs.tcd.ie  Wed Nov 28 15:26:33 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E04921F841C for ; Wed, 28 Nov 2012 15:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L41HA4NKhGgl for ; Wed, 28 Nov 2012 15:26:31 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 33F5C21F8319 for ; Wed, 28 Nov 2012 15:26:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 34226BE65; Wed, 28 Nov 2012 23:26:08 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2c3hniWmjCw; Wed, 28 Nov 2012 23:26:07 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.44.77.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 12187BE4D; Wed, 28 Nov 2012 23:26:07 +0000 (GMT)
Message-ID: <50B69D8E.2050309@cs.tcd.ie>
Date: Wed, 28 Nov 2012 23:26:06 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Geoffrey Keating 
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie> 
In-Reply-To: 
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Florian Weimer , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 23:26:33 -0000

Hi Geoffrey,

On 11/28/2012 07:52 PM, Geoffrey Keating wrote:
> Stephen Farrell  writes:
> 
>> Hi Martin,
>>
>> We're trying to figure out if the mptcp API document needs
>> to say anything about tls, and if so, what. And I'd like
>> to do that so mptcp doesn't have to fall back to just tcp
>> for all cases where you need tls, if that's ok, so that
>> mptcp has a chance to get used. (I figure its hard enough
>> being a new transport these days, but being a new transport
>> that is useless under TLS seems like a bit of a killer.)
> 
>> On 11/28/2012 03:36 PM, Martin Rex wrote:
>>> The IP-address
>>> that the socket shows after connection establishment is
>>> completely irrelevant to the security of TLS, even when
>>> Server-Certificates with IP-Addresses in the SubjectAltName
>>> are used for server endpoint identification according to
>>> rfc2818 section 3.1.
>>
>> Well, 2818 is just http/tls/tcp and the context here is
>> anything/tls/mptcp so I'm not sure that solves the problem
>> of what to say.
>>
>> I think its true that there's no security issue, but there
>> might be an interop issue, if different folks implement
>> tls/mptcp differently. If the tls code just uses the normal
>> socket api then there's nothing to say, but it won't get
>> the benefit of mptcp. If the tls code uses the basic api
>> then it can see which subflows are being used and different
>> folks might do different comparisons to the certs used.
> 
> Maybe a related example will help: suppose the user is trying to
> connect to https://198.51.100.3.  There is an HTTP proxy configured,
> so what the browser actually does is make a TCP connection to
> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
> SSL negotiation.  The certificate still has to mention 198.51.100.3,
> and doesn't have to mention 192.0.2.99.
> 
> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
> whatever), then 198.51.100.3 is the address that has to appear in the
> certificate, even if the connection is redirected to some other
> endpoint, even if the redirection happens before any data is actually
> sent on the connection.

Right. And I think that ignoring excludedSubtrees that's all
fine and the right thing is to say that the TLS implementation
ought only compare the address of with which it chose to connect
for a client or the 1st subflow for a server against certs, if
it needs to bother with that.

I'm not sure what to say about excludedSubtrees though. Maybe,
given that nobody uses 'em or wants to use 'em for TLS (correct?)
we can just say its a potential problem and that you need to
use an advanced API if you care about that. (You couldn't be
sure not to have missed some IP address with the basic API I
think.)

I think that might be ok and will provide that feedback to
the mptcp folks unless someone else has more to say.

Cheers,
S.

From stephen.farrell@cs.tcd.ie  Wed Nov 28 15:27:51 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9586121F8907 for ; Wed, 28 Nov 2012 15:27:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLpvWu8M0gmf for ; Wed, 28 Nov 2012 15:27:51 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B190B21F88E9 for ; Wed, 28 Nov 2012 15:27:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E3794BE65; Wed, 28 Nov 2012 23:27:28 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ONREc-RwNjt; Wed, 28 Nov 2012 23:27:28 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.44.77.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E6C24BE4D; Wed, 28 Nov 2012 23:27:27 +0000 (GMT)
Message-ID: <50B69DDF.1070205@cs.tcd.ie>
Date: Wed, 28 Nov 2012 23:27:27 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Peter Saint-Andre 
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie>  <50B684F6.4050004@stpeter.im>
In-Reply-To: <50B684F6.4050004@stpeter.im>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Florian Weimer , Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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: Wed, 28 Nov 2012 23:27:51 -0000

On 11/28/2012 09:41 PM, Peter Saint-Andre wrote:
> On 11/28/12 12:52 PM, Geoffrey Keating wrote:
>> Stephen Farrell  writes:
> 
>>> Hi Martin,
>>>
>>> We're trying to figure out if the mptcp API document needs to say
>>> anything about tls, and if so, what. And I'd like to do that so
>>> mptcp doesn't have to fall back to just tcp for all cases where
>>> you need tls, if that's ok, so that mptcp has a chance to get
>>> used. (I figure its hard enough being a new transport these days,
>>> but being a new transport that is useless under TLS seems like a
>>> bit of a killer.)
> 
>>> On 11/28/2012 03:36 PM, Martin Rex wrote:
>>>> The IP-address that the socket shows after connection
>>>> establishment is completely irrelevant to the security of TLS,
>>>> even when Server-Certificates with IP-Addresses in the
>>>> SubjectAltName are used for server endpoint identification
>>>> according to rfc2818 section 3.1.
>>>
>>> Well, 2818 is just http/tls/tcp and the context here is 
>>> anything/tls/mptcp so I'm not sure that solves the problem of
>>> what to say.
>>>
>>> I think its true that there's no security issue, but there might
>>> be an interop issue, if different folks implement tls/mptcp
>>> differently. If the tls code just uses the normal socket api then
>>> there's nothing to say, but it won't get the benefit of mptcp. If
>>> the tls code uses the basic api then it can see which subflows
>>> are being used and different folks might do different comparisons
>>> to the certs used.
> 
>> Maybe a related example will help: suppose the user is trying to 
>> connect to https://198.51.100.3.  There is an HTTP proxy
>> configured, so what the browser actually does is make a TCP
>> connection to 192.0.2.99, send 'CONNECT https://198.51.100.3', and
>> then start the SSL negotiation.  The certificate still has to
>> mention 198.51.100.3, and doesn't have to mention 192.0.2.99.
> 
>> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or 
>> whatever), then 198.51.100.3 is the address that has to appear in
>> the certificate, even if the connection is redirected to some
>> other endpoint, even if the redirection happens before any data is
>> actually sent on the connection.
> 
> This is basically the "CertID" problem (RFC 6125). When Jeff Hodges
> and I worked on that spec, we deliberately left IP addresses out of
> scope, but if someone wants to work on a similar (though much simpler)
> document about IP addresses instead of domain names, I'm sure they
> could find quite a bit of text to borrow.

Yep, I pointed the mptcp folks at that already. I suspect they
may have found it frightening;-) X.509 PKI just has too many
twistable knobs unfortunately.

S.


> 
> Peter
> 
> 
> 

From mrex@sap.com  Wed Nov 28 16:05: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 B617C21F8952 for ; Wed, 28 Nov 2012 16:05:34 -0800 (PST)
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.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBQmIltwd-Cb for ; Wed, 28 Nov 2012 16:05:33 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 077B921F8944 for ; Wed, 28 Nov 2012 16:05:32 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qAT05MWD016395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 01:05:23 +0100 (MET)
In-Reply-To: <50B69D8E.2050309@cs.tcd.ie>
To: Stephen Farrell 
Date: Thu, 29 Nov 2012 01:05:21 +0100 (CET)
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: <20121129000521.0CF6D1A3BF@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: Florian Weimer , Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on TLS
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, 29 Nov 2012 00:05:34 -0000

> Geoffrey Keating wrote:
>> 
>> Maybe a related example will help: suppose the user is trying to
>> connect to https://198.51.100.3.  There is an HTTP proxy configured,
>> so what the browser actually does is make a TCP connection to
>> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
>> SSL negotiation.  The certificate still has to mention 198.51.100.3,
>> and doesn't have to mention 192.0.2.99.
>> 
>> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
>> whatever), then 198.51.100.3 is the address that has to appear in the
>> certificate, even if the connection is redirected to some other
>> endpoint, even if the redirection happens before any data is actually
>> sent on the connection.

Thanks for the example!
That is what I had in mind (but failed to properly explain).


Stephen Farrell wrote:
> 
> Right. And I think that ignoring excludedSubtrees that's all
> fine

HUH?

With "excludedSubtrees", are you thinking of X.509 Name Constraints
(on IP addresses as subject alt names)?

There is no such thing as an "excludedSubtrees" return parameter
defined for the PKIX "Basic Path Validation":

  http://tools.ietf.org/html/rfc5280#section-6.1.6

   6.1.6. Outputs

   If path processing succeeds, the procedure terminates, returning a
   success indication together with final value of the
   valid_policy_tree, the working_public_key, the
   working_public_key_algorithm, and the working_public_key_parameters.


Name Constraints must appear only in CA certificates, Name Constraints
are meaningful and visible exclusively to the internals of the Certificate
Path Validation function, and apply exclusively to Names that are
actually _present_ in subordinate certificates on the path and to the
value of Names _exactly_ as they appear _in_the_certificate_.


>
>        and the right thing is to say that the TLS implementation
> ought only compare the address of with which it chose to connect
> for a client or the 1st subflow for a server against certs, if
> it needs to bother with that.

I agree, a note should probably added to very very strongly discourage using
any of the characteristics from the resulting connection for performing
server endpoint identification or a real server authentication.  Only
original/trustworthy information ought to be used that existed before
trying to establish the actual network connection with the peer.

An indirection through a "trusted directory" (secure is not sufficient)
would be OK, such as a trusted local configuration, a lookup in a secure
directory (something that existed in DCE), or e.g. transformation through
a DNSSEC-protected TLSA lookup according to DANE.


> 
> I'm not sure what to say about excludedSubtrees though.

If this is about X.509 Name Constraints, then IMO nothing should be said
within mptcp.  It is a matter completely internal to PKIX certificate
path validation.


-Martin

From stephen.farrell@cs.tcd.ie  Wed Nov 28 16:17:43 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742421F889F for ; Wed, 28 Nov 2012 16:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.523
X-Spam-Level: 
X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLNiKLbF+mGc for ; Wed, 28 Nov 2012 16:17:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id AC25221F8893 for ; Wed, 28 Nov 2012 16:17:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 12970BE62; Thu, 29 Nov 2012 00:17:20 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3rfbvEzeqzo; Thu, 29 Nov 2012 00:17:13 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.44.77.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AF999BE5C; Thu, 29 Nov 2012 00:17:13 +0000 (GMT)
Message-ID: <50B6A989.50408@cs.tcd.ie>
Date: Thu, 29 Nov 2012 00:17:13 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20121129000521.0CF6D1A3BF@ld9781.wdf.sap.corp>
In-Reply-To: <20121129000521.0CF6D1A3BF@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Florian Weimer , Geoffrey Keating , tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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, 29 Nov 2012 00:17:43 -0000

Hiya,

On 11/29/2012 12:05 AM, Martin Rex wrote:
>> Geoffrey Keating wrote:
>>>
>>> Maybe a related example will help: suppose the user is trying to
>>> connect to https://198.51.100.3.  There is an HTTP proxy configured,
>>> so what the browser actually does is make a TCP connection to
>>> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
>>> SSL negotiation.  The certificate still has to mention 198.51.100.3,
>>> and doesn't have to mention 192.0.2.99.
>>>
>>> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
>>> whatever), then 198.51.100.3 is the address that has to appear in the
>>> certificate, even if the connection is redirected to some other
>>> endpoint, even if the redirection happens before any data is actually
>>> sent on the connection.
> 
> Thanks for the example!
> That is what I had in mind (but failed to properly explain).
> 
> 
> Stephen Farrell wrote:
>>
>> Right. And I think that ignoring excludedSubtrees that's all
>> fine
> 
> HUH?
> 
> With "excludedSubtrees", are you thinking of X.509 Name Constraints
> (on IP addresses as subject alt names)?
> 
> There is no such thing as an "excludedSubtrees" return parameter
> defined for the PKIX "Basic Path Validation":
> 
>   http://tools.ietf.org/html/rfc5280#section-6.1.6
> 
>    6.1.6. Outputs
> 
>    If path processing succeeds, the procedure terminates, returning a
>    success indication together with final value of the
>    valid_policy_tree, the working_public_key, the
>    working_public_key_algorithm, and the working_public_key_parameters.
> 
> 
> Name Constraints must appear only in CA certificates, Name Constraints
> are meaningful and visible exclusively to the internals of the Certificate
> Path Validation function, and apply exclusively to Names that are
> actually _present_ in subordinate certificates on the path and to the
> value of Names _exactly_ as they appear _in_the_certificate_.

Ah, you're right there, thanks. Silly me.

I think we agree about all the rest.

Thanks,
S.

> 
> 
>>
>>        and the right thing is to say that the TLS implementation
>> ought only compare the address of with which it chose to connect
>> for a client or the 1st subflow for a server against certs, if
>> it needs to bother with that.
> 
> I agree, a note should probably added to very very strongly discourage using
> any of the characteristics from the resulting connection for performing
> server endpoint identification or a real server authentication.  Only
> original/trustworthy information ought to be used that existed before
> trying to establish the actual network connection with the peer.
> 
> An indirection through a "trusted directory" (secure is not sufficient)
> would be OK, such as a trusted local configuration, a lookup in a secure
> directory (something that existed in DCE), or e.g. transformation through
> a DNSSEC-protected TLSA lookup according to DANE.
> 
> 
>>
>> I'm not sure what to say about excludedSubtrees though.
> 
> If this is about X.509 Name Constraints, then IMO nothing should be said
> within mptcp.  It is a matter completely internal to PKIX certificate
> path validation.
> 
> 
> -Martin
> 
> 

From fweimer@redhat.com  Thu Nov 29 01:21:27 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC6421F8A7B for ; Thu, 29 Nov 2012 01:21:27 -0800 (PST)
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=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4oBmBRwV+Ke for ; Thu, 29 Nov 2012 01:21:26 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id F0CA321F8773 for ; Thu, 29 Nov 2012 01:21:25 -0800 (PST)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAT9L7TG024180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 04:21:10 -0500
Received: from fweimer.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qAT9L4S9032260 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 29 Nov 2012 04:21:06 -0500
Message-ID: <50B72900.5050400@redhat.com>
Date: Thu, 29 Nov 2012 10:21:04 +0100
From: Florian Weimer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Geoffrey Keating 
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Cc: tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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, 29 Nov 2012 09:21:27 -0000

On 11/28/2012 08:52 PM, Geoffrey Keating wrote:

> Maybe a related example will help: suppose the user is trying to
> connect to https://198.51.100.3.  There is an HTTP proxy configured,
> so what the browser actually does is make a TCP connection to
> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
> SSL negotiation.  The certificate still has to mention 198.51.100.3,
> and doesn't have to mention 192.0.2.99.
>
> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
> whatever), then 198.51.100.3 is the address that has to appear in the
> certificate, even if the connection is redirected to some other
> endpoint, even if the redirection happens before any data is actually
> sent on the connection.

I suspect the confusion arises because if the interaction with 
198.51.100.3 causes another connection with a different IP address to be 
created, it hast to be verified against the IP address 198.51.100.3 as well.

This is different from HTML over HTTPS, where additional connections use 
the embedded addresses and names for endpoint verification.  This is 
possible because in the HTML/HTTPS case, these names and addresses are 
protected by the TLS channel, while in MPTCP, they are not.

-- 
Florian Weimer / Red Hat Product Security Team

From geoffk@geoffk.org  Fri Nov 30 15:05:39 2012
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00C821F8B47 for ; Fri, 30 Nov 2012 15:05:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCxgYm8X0fgk for ; Fri, 30 Nov 2012 15:05:39 -0800 (PST)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEA721F8ABB for ; Fri, 30 Nov 2012 15:05:39 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B553833D046; Fri, 30 Nov 2012 23:05:36 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Florian Weimer 
References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie>  <50B72900.5050400@redhat.com>
From: Geoffrey Keating 
Date: 30 Nov 2012 15:05:36 -0800
In-Reply-To: <50B72900.5050400@redhat.com>
Message-ID: 
Lines: 42
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: tls@ietf.org
Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on 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, 30 Nov 2012 23:05:39 -0000

Florian Weimer  writes:

> On 11/28/2012 08:52 PM, Geoffrey Keating wrote:
> 
> > Maybe a related example will help: suppose the user is trying to
> > connect to https://198.51.100.3.  There is an HTTP proxy configured,
> > so what the browser actually does is make a TCP connection to
> > 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
> > SSL negotiation.  The certificate still has to mention 198.51.100.3,
> > and doesn't have to mention 192.0.2.99.
> >
> > So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
> > whatever), then 198.51.100.3 is the address that has to appear in the
> > certificate, even if the connection is redirected to some other
> > endpoint, even if the redirection happens before any data is actually
> > sent on the connection.
> 
> I suspect the confusion arises because if the interaction with
> 198.51.100.3 causes another connection with a different IP address to
> be created, it hast to be verified against the IP address 198.51.100.3
> as well.

Do you mean what MPTCP calls a "subflow", not "connection", here?  For
example, if a web page at 198.51.100.3 contains an image tag which
causes a new MPTCP connection to be created, that isn't verified
against 198.51.100.3, it's verified against where the image's URL says
the image should be.

If you do mean 'subflow', the key thing about that is that there is no
'verification' to do.  The certificate won't be sent again, there
won't be a new TLS negotiation.

> This is different from HTML over HTTPS, where additional connections
> use the embedded addresses and names for endpoint verification.  This
> is possible because in the HTML/HTTPS case, these names and addresses
> are protected by the TLS channel, while in MPTCP, they are not.

One way to look at this is that it's an OSI layering issue.  TCP and
MPTCP are layers 4 and 5.  TLS certificate validation occurs at layer
7, the application layer, the same layer as the fetching of HTML
images or the execution of JavaScript; TLS, HTTP, and the syntax of
HTML are layer 6.