From stefan.winter@restena.lu Fri Jul 1 04:58:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F04321F8734 for ; Fri, 1 Jul 2011 04:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sjq4bC1Iz4g for ; Fri, 1 Jul 2011 04:58:27 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id A8F6321F8733 for ; Fri, 1 Jul 2011 04:58:26 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 26B7910691 for ; Fri, 1 Jul 2011 13:58:25 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1859E10590 for ; Fri, 1 Jul 2011 13:58:25 +0200 (CEST) Message-ID: <4E0DB650.5010801@restena.lu> Date: Fri, 01 Jul 2011 13:58:08 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFD5CB3075FCE05F43A5123ED" X-Virus-Scanned: ClamAV Subject: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA 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, 01 Jul 2011 11:58:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFD5CB3075FCE05F43A5123ED Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, in radiusext, I need to make an assessment whether an I-D is compliant to= a crypto-agility requirements document. The draft (still) requires at least TLS 1.1 with its mandatory-to-implemn= t cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA. The crypto-agility document requires the mandatory-to-implement algorithm= to be NIST approved, "Acceptable with no deprecation date" in NIST SP-80= 0-131A.=20 That document marks=20 * two-key Triple DES Encryption as an encryption with deprecation date * three-key Triple DES Encryption as an encryption without deprecation da= te I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a two-key or a thre= e-key 3DES algorithm. This condition would be the only one that could dow= ngrade the I-D in question from "unconditionally compliant" to "condition= ally compliant". So... would anybody have some insight which of the variant(s) is/are used= in TLS_RSA_WITH_3DES_EDE_CBC_SHA? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enigFD5CB3075FCE05F43A5123ED Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4NtlUACgkQ+jm90f8eFWbZfACaAmLZRcTOn6gaT6HZKh0eOcAR 4igAn28t8dQ2E3ntivUSe1Z1BGpYr8rz =aogr -----END PGP SIGNATURE----- --------------enigFD5CB3075FCE05F43A5123ED-- From agl@google.com Fri Jul 1 06:20:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0621D11E82CC for ; Fri, 1 Jul 2011 06:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 SIhpKzWx-8Gs for ; Fri, 1 Jul 2011 06:20:09 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 74BEA11E82EA for ; Fri, 1 Jul 2011 06:20:09 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p61DK8R9006003 for ; Fri, 1 Jul 2011 06:20:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309526408; bh=eNF7K7d+DzdN0cezdQTZICpA0yA=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kuagKSNzO1+Zc6kolYLqOqw7PKgu0aYRdlSGiwLehw1pNWBpBR/nBvWlF9LHBa3Je Ril4ayS1DQUNOwDQtsCMQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=fG+jII27WQtnu/5EQqKMxapPYpFZVciX587pk2C9b2rfgAf3dGql76aoFcmebi6RN 9AB+0Nn0IwGMWH+fOwXHA== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by kpbe19.cbf.corp.google.com with ESMTP id p61DK6Y9019341 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 1 Jul 2011 06:20:07 -0700 Received: by gyh4 with SMTP id 4so2132782gyh.22 for ; Fri, 01 Jul 2011 06:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3TizpVN092DstrHU5yKD3tn4GDQxsPuiCvt8Gan9b+A=; b=ejlf1lmZ9ajzjt8Zkgmfxg6dFvCKAPCYRL8HKrHYgbQDGaLbQljT/dU8f9lS+5bqyW fdgucvxx3N90Y0aBzZCQ== MIME-Version: 1.0 Received: by 10.151.154.8 with SMTP id g8mr3153202ybo.29.1309526406354; Fri, 01 Jul 2011 06:20:06 -0700 (PDT) Received: by 10.150.177.1 with HTTP; Fri, 1 Jul 2011 06:20:06 -0700 (PDT) In-Reply-To: <4E0DB650.5010801@restena.lu> References: <4E0DB650.5010801@restena.lu> Date: Fri, 1 Jul 2011 09:20:06 -0400 Message-ID: From: Adam Langley To: Stefan Winter Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA 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, 01 Jul 2011 13:20:10 -0000 On Fri, Jul 1, 2011 at 7:58 AM, Stefan Winter wrote: > I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a two-key or a three-key 3DES algorithm. This condition would be the only one that could downgrade the I-D in question from "unconditionally compliant" to "conditionally compliant". I believe it's the 3-key algorithm. RFC 5246, App B covers this: "DES can also be operated in a mode [3DES] where three independent keys and three encryptions are used for each block of data; this uses 168 bits of key (24 bytes in the TLS key generation method) and provides the equivalent of 112 bits of security." Cheers AGL From mrex@sap.com Fri Jul 1 12:46:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2154D9E8022 for ; Fri, 1 Jul 2011 12:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.144 X-Spam-Level: X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, 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 bq2CeoOg3oA3 for ; Fri, 1 Jul 2011 12:46:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6259C9E8024 for ; Fri, 1 Jul 2011 12:46:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p61JkKm7001941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2011 21:46:25 +0200 (MEST) From: Martin Rex Message-Id: <201107011946.p61JkK5m024466@fs4113.wdf.sap.corp> To: agl@google.com (Adam Langley) Date: Fri, 1 Jul 2011 21:46:20 +0200 (MEST) In-Reply-To: from "Adam Langley" at Jul 1, 11 09:20:06 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:46:29 -0000 Adam Langley wrote: > > Stefan Winter wrote: > > > > I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a two-key > > or a three-key 3DES algorithm. This condition would be the only > > one that could downgrade the I-D in question from > > "unconditionally compliant" to "conditionally compliant". > > I believe it's the 3-key algorithm. RFC 5246, App B covers this: > > "DES can also be operated in a mode [3DES] where three independent > keys and three encryptions are used for each block of data; this uses > 168 bits of key (24 bytes in the TLS key generation method) and > provides the equivalent of 112 bits of security." see also http://tools.ietf.org/html/rfc2246#page-21 It is a probabilistic 3-key DES-EDE (encryption-decryption-encryption), meaning that the algotihm is treated as a block cipher with a keysize of 24 octets, blocksize of 8 octets and cbc-ivsize of 8 octets (distinct keying material for direction client->server and server->client). The first 8x7 bits (sans parity) differ from the final 8x7 bits of the key on probabilistic grounds, there are no algorithmic provisions to ensure this, and neither are there algorithmic provisions to ensure that none of the 3 single-DES subkeys are weak DES keys. (you're certainly better of with AES128-CBC, in particular because it is significantly faster--on x86 and x86_64 AES128-CBC has 6x higher data encryption rate than 3DES-EDE for optimized software-implementations.) -Martin From mrex@sap.com Fri Jul 1 12:58:47 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DF79E8050 for ; Fri, 1 Jul 2011 12:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.097, 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 UDCS0byGsUaT for ; Fri, 1 Jul 2011 12:58:47 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B82E49E8038 for ; Fri, 1 Jul 2011 12:58:46 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p61JwiPF002693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2011 21:58:44 +0200 (MEST) From: Martin Rex Message-Id: <201107011958.p61Jwh3a025219@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Fri, 1 Jul 2011 21:58:43 +0200 (MEST) In-Reply-To: <201107011946.p61JkK5m024466@fs4113.wdf.sap.corp> from "Martin Rex" at Jul 1, 11 09:46:20 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHAx X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 19:58:47 -0000 Martin Rex wrote: > > Adam Langley wrote: > > > > Stefan Winter wrote: > > > > > > I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a two-key > > > or a three-key 3DES algorithm. This condition would be the only > > > one that could downgrade the I-D in question from > > > "unconditionally compliant" to "conditionally compliant". > > > > I believe it's the 3-key algorithm. RFC 5246, App B covers this: > > > > "DES can also be operated in a mode [3DES] where three independent > > keys and three encryptions are used for each block of data; this uses > > 168 bits of key (24 bytes in the TLS key generation method) and > > provides the equivalent of 112 bits of security." > > see also http://tools.ietf.org/html/rfc2246#page-21 > > It is a probabilistic 3-key DES-EDE (encryption-decryption-encryption), > meaning that the algotihm is treated as a block cipher with a > keysize of 24 octets, blocksize of 8 octets and cbc-ivsize of 8 octets > (distinct keying material for direction client->server and server->client). > > The first 8x7 bits (sans parity) differ from the final 8x7 bits of the key > on probabilistic grounds, there are no algorithmic provisions to ensure > this, and neither are there algorithmic provisions to ensure that > none of the 3 single-DES subkeys are weak DES keys. > > (you're certainly better of with AES128-CBC, in particular because it > is significantly faster--on x86 and x86_64 AES128-CBC has 6x higher > data encryption rate than 3DES-EDE for optimized software-implementations.) Thinking about it, checking whether the first 8x7 bits differ from the middle 8x7 bits, and that the middle 8x7 bits differ from the final 8x7 bits might have be even more important, because either one being equal would cause the 3DES-EDE operation to fold into a single-DES operation. :-o -Martin From marsh@extendedsubset.com Fri Jul 1 13:25:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE8111E8181 for ; Fri, 1 Jul 2011 13:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuQvRAh0nU7k for ; Fri, 1 Jul 2011 13:25:27 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9211E808A for ; Fri, 1 Jul 2011 13:25:26 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QckHG-000DYR-G7; Fri, 01 Jul 2011 20:25:26 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AE5C5606E; Fri, 1 Jul 2011 20:25:24 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX188ITbK4aNkFAOHtzaI+7ukM8s7R8v9XWk= Message-ID: <4E0E2D34.8070005@extendedsubset.com> Date: Fri, 01 Jul 2011 15:25:24 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: mrex@sap.com References: <201107011958.p61Jwh3a025219@fs4113.wdf.sap.corp> In-Reply-To: <201107011958.p61Jwh3a025219@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHAx 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, 01 Jul 2011 20:25:27 -0000 On 07/01/2011 02:58 PM, Martin Rex wrote: > Martin Rex wrote: >> >> It is a probabilistic 3-key DES-EDE (encryption-decryption-encryption), >> meaning that the algotihm is treated as a block cipher with a >> keysize of 24 octets, blocksize of 8 octets and cbc-ivsize of 8 octets >> (distinct keying material for direction client->server and server->client). >> >> The first 8x7 bits (sans parity) differ from the final 8x7 bits of the key >> on probabilistic grounds, there are no algorithmic provisions to ensure >> this, and neither are there algorithmic provisions to ensure that >> none of the 3 single-DES subkeys are weak DES keys. > > Thinking about it, checking whether the first 8x7 bits differ from > the middle 8x7 bits, and that the middle 8x7 bits differ from the final > 8x7 bits might have be even more important, because either one being > equal would cause the 3DES-EDE operation to fold into a single-DES > operation. :-o Doesn't the principle of full key space utilization require us to admit that possibility? As an analogy, TLS uses "separate" encryption keys and MAC secrets in the C->S and S->C directions. But it doesn't require an implementation to actually verify that they are different. TLS doesn't require checks against weak DES keys either which seems even a bit more likely to occur. One could imagine many ways such a check could go wrong, possibly revealing information about the secret material in the process. - Marsh From internet-drafts@ietf.org Sun Jul 3 17:54:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7AF21F85D6; Sun, 3 Jul 2011 17:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 Q0HPn9vwJ+OX; Sun, 3 Jul 2011 17:54:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8767721F85BF; Sun, 3 Jul 2011 17:54:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110704005433.3245.66186.idtracker@ietfa.amsl.com> Date: Sun, 03 Jul 2011 17:54:33 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4347-bis-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 00:54:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : Datagram Transport Layer Security version 1.2 Author(s) : Eric Rescorla Nagendra Modadugu Filename : draft-ietf-tls-rfc4347-bis-06.txt Pages : 33 Date : 2011-07-03 This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-06.txt From ekr@rtfm.com Sun Jul 3 17:58:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E229E8007 for ; Sun, 3 Jul 2011 17:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otsxkriZmZYx for ; Sun, 3 Jul 2011 17:58:06 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 574851F0C3C for ; Sun, 3 Jul 2011 17:58:02 -0700 (PDT) Received: by wwe5 with SMTP id 5so3110510wwe.13 for ; Sun, 03 Jul 2011 17:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.1.197 with SMTP id n47mr822734wes.28.1309741081231; Sun, 03 Jul 2011 17:58:01 -0700 (PDT) Received: by 10.216.175.204 with HTTP; Sun, 3 Jul 2011 17:58:01 -0700 (PDT) In-Reply-To: <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com> References: <4DF0CA9D.1030006@ieca.com> <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com> Date: Sun, 3 Jul 2011 17:58:01 -0700 Message-ID: From: Eric Rescorla To: Joe Salowey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 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, 04 Jul 2011 00:58:07 -0000 I have now submitted draft -06, which (I believe) matches Nikos's version number fix. As Nikos objected to giving the CCS a sequence number and nobody spoke up f= or it, I left it as-is and added a warning. I would mildly favor adding one, but I don't think the change is appropriate absent support from the WG which has not ye= t been observed. If people believe that this change is appropriate, please sp= eak up. Otherwise I believe we are done. Best, -Ekr On Tue, Jun 14, 2011 at 9:41 AM, Joe Salowey wrote: > The open issue is with respect to the version number that Nikos raised. = =A0Eric is working on text along the lines of Nikos' recommendation of fixi= ng the version number. > > Joe > On Jun 9, 2011, at 6:29 AM, Sean Turner wrote: > >> Does anybody else have thoughts about this? =A0I'd really like to be abl= e to put this draft to bed. >> >> spt >> >> On 5/23/11 9:19 AM, Eric Rescorla wrote: >>> Following up on Prague, here is the new text for the 2MSL and the >>> record sequence number issues: >>> >>> >>> >>> MSL: >>> 4.1. >>> =A0 =A0Note that because DTLS records may be reordered, a record from e= poch >>> =A0 =A01 may be received after epoch 2 has begun. In general, >>> =A0 =A0implementations SHOULD discard packets from earlier epochs, but = if >>> =A0 =A0packet loss causes noticeable problems MAY choose to retain keyi= ng >>> =A0 =A0material from previous epochs for up to the default MSL specifie= d for >>> =A0 =A0TCP [TCP] to allow for packet reordering. (Note: the intention h= ere >>> =A0 =A0is that implementors use the current guidance from the IETF for = MSL, >>> =A0 =A0not that they attempt to interrogate the MSL the system TCP stac= k is >>> =A0 =A0using.) =A0Until the handshake has completed, implementations MU= ST >>> =A0 =A0accept packets from the old epoch. >>> >>> =A0 =A0... >>> >>> 4.2.4. >>> =A0 =A0In addition, for at least twice the default MSL defined for [TCP= ], >>> =A0 =A0when in the FINISHED state, the node which transmits the last fl= ight >>> =A0 =A0(the server in an ordinary handshake or the client in a resumed >>> =A0 =A0handshake) MUST respond to a retransmit of the peer's last fligh= t >>> =A0 =A0with a retransmit of the last flight. This avoids deadlock condi= tions >>> >>> >>> >>> >>> Record Sequence Number: >>> =A0 =A0When responding to a HelloVerifyRequest the client MUST use the = same >>> =A0 =A0parameter values (version, random, session_id, cipher_suites, >>> =A0 =A0compression_method) as it did in the original ClientHello. =A0Th= e >>> =A0 =A0server SHOULD use those values to generate its cookie and verify= that >>> =A0 =A0they are correct upon cookie receipt. =A0The server MUST use the= same >>> =A0 =A0version number in the HelloVerifyRequest that it would use when >>> =A0 =A0sending a ServerHello. =A0Upon receipt of the ServerHello, the c= lient >>> =A0 =A0MUST verify that the server version values match. In order to av= oid >>> =A0 =A0sequence number duplication in case of multiple HelloVerifyReque= sts, >>> =A0 =A0the server MUST use the record sequence number in the ClientHell= o as >>> =A0 =A0the record sequence number in the HelloVerifyRequest. >>> >>> ... >>> >>> =A0 =A0When the second ClientHello is received, the server can verify t= hat >>> =A0 =A0the Cookie is valid and that the client can receive packets at t= he >>> =A0 =A0given IP address. =A0In order to avoid sequence number duplicati= on in >>> =A0 =A0case of multiple cookie exchanges, the server SHOULD use the rec= ord >>> =A0 =A0sequence number in the ClientHello as the record sequence number= in >>> =A0 =A0its initial ServerHello. Subsequent ServerHellos will only be se= nt >>> =A0 =A0after the server has created state and MUST increment normally. >>> >>> I believe this matches what I said in Prague, but any objections to >>> this in concept or the way I've written it up. >>> >>> >>> Finally, I've been rethinking the issue of the interaction of the >>> ChangeCipherSpec and the handshake sequence numbers. In Prague I >>> suggested not changing this and just putting a note in the spec that >>> one had to be careful, but at this point I am thinking it might be >>> better to simple suck up the change and put a message sequence number >>> in the CCS. This removes the need to consult the handshake state >>> machine in order to deal with reordering, though not in order to >>> determine whether the CCS is at the appropriate place in the handshake >>> (in order to detect misbehaving or malicious behavior early). =A0The >>> downside for this is that it's a difference from TLS, but it seems >>> like fairly easy code--though I admit I haven't tried to code it up. I >>> don't think either way represents a security issue, but doing it this >>> way means that we won't need to be as careful in the future about >>> having the state machine be completely deterministic prior to the CCS, >>> which seems like the Right Thing. Comments? >>> >>> -Ekr >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From stefan.winter@restena.lu Mon Jul 4 05:29:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11D721F8630 for ; Mon, 4 Jul 2011 05:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkbQ5UjJNdBL for ; Mon, 4 Jul 2011 05:29:12 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 58D6521F8624 for ; Mon, 4 Jul 2011 05:29:12 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C57B110584 for ; Mon, 4 Jul 2011 14:29:09 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 85C9E10582 for ; Mon, 4 Jul 2011 14:29:09 +0200 (CEST) Message-ID: <4E11B217.4060504@restena.lu> Date: Mon, 04 Jul 2011 14:29:11 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig539B81CE3760FC97ED8A89CF" X-Virus-Scanned: ClamAV Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA 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, 04 Jul 2011 12:29:13 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig539B81CE3760FC97ED8A89CF Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hello, there I was, naively hoping for a simple "Yes or No" answer :-) My hopefully acceptable takeaway of this thread is that TLS_RSA_WITH_3DES_EDE_CBC_SHA *supports* three-key operation, which would be acceptable as per NIST. I understand there is also a *risk* that if the dice fall very badly, the actual encryption strength in that specific TLS session may exhibit weaker cryptographic strength. Thanks to all who responded! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig539B81CE3760FC97ED8A89CF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4RshcACgkQ+jm90f8eFWYX3wCgga4BLDtCqxyoh5//NysnDCOY YG0An13Synapu4jEkSn/P8drLlM9NhvC =L0qg -----END PGP SIGNATURE----- --------------enig539B81CE3760FC97ED8A89CF-- From mrex@sap.com Mon Jul 4 06:12:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FA221F8666 for ; Mon, 4 Jul 2011 06:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.175 X-Spam-Level: X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=0.074, 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 w2SqOji7c0aZ for ; Mon, 4 Jul 2011 06:12:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AB21F8715 for ; Mon, 4 Jul 2011 06:12:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p64DCclW028316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Jul 2011 15:12:39 +0200 (MEST) From: Martin Rex Message-Id: <201107041312.p64DCcHr015211@fs4113.wdf.sap.corp> To: stefan.winter@restena.lu (Stefan Winter) Date: Mon, 4 Jul 2011 15:12:38 +0200 (MEST) In-Reply-To: <4E11B217.4060504@restena.lu> from "Stefan Winter" at Jul 4, 11 02:29:11 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 13:12:41 -0000 Stefan Winter wrote: > > there I was, naively hoping for a simple "Yes or No" answer :-) > > My hopefully acceptable takeaway of this thread is that > TLS_RSA_WITH_3DES_EDE_CBC_SHA *supports* three-key operation, which > would be acceptable as per NIST. > > I understand there is also a *risk* that if the dice fall very badly, > the actual encryption strength in that specific TLS session may exhibit > weaker cryptographic strength. > > Thanks to all who responded! I'm sorry for causing the confusion. In _my_ interpretation of the NIST guidance, TLS_RSA_WITH_3DES_EDE_CBC_SHA is a 3-key triple des. While they recommend weak key avoidance for DES, they do not require it. the sub-key collisions for 3-DES could be viewed as additional weak keys for 3DES compared to single-DES. Dealing with weak keys and non-dense key spaces is common for traditional key generation (assymetric and symmetric DES), but seems fairly uncommon for algorithmic key derivation of symmetric and MAC traffic keys. -Martin From turners@ieca.com Mon Jul 4 08:11:28 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D7B21F85AC for ; Mon, 4 Jul 2011 08:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 R6C2P4abaEof for ; Mon, 4 Jul 2011 08:11:27 -0700 (PDT) Received: from nm19.bullet.mail.ac4.yahoo.com (nm19.bullet.mail.ac4.yahoo.com [98.139.52.216]) by ietfa.amsl.com (Postfix) with SMTP id ADBCA21F8597 for ; Mon, 4 Jul 2011 08:11:26 -0700 (PDT) Received: from [98.139.52.189] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jul 2011 15:11:23 -0000 Received: from [98.139.52.163] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jul 2011 15:11:23 -0000 Received: from [127.0.0.1] by omp1046.mail.ac4.yahoo.com with NNFMP; 04 Jul 2011 15:11:23 -0000 X-Yahoo-Newman-Id: 696517.15269.bm@omp1046.mail.ac4.yahoo.com Received: (qmail 24803 invoked from network); 4 Jul 2011 15:11:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309792283; bh=o+T6FKnRdE9zPZ47GeUrl+x7gvmaSuItzW+GcdA4/N8=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ZP1j1ozYseknfVw8MTFQSQvag9jDqpjHEO0cOfKxfgATmNt2m9JFbXX+lru15kozy+H0xHAeOzKamDqvHgF7UjgHwDvnSuPsy+X9xNHjPPWgqnnidjs/RPiNl9jOJj7ZwCTHWUHdq8lW+tr7CZBh+0wDgIm1SEY/MMlLOWpkdBk= Received: from thunderfish.westell.com (turners@71.191.8.211 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 04 Jul 2011 08:11:21 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: u7jKjU4VM1lMo6hZxjcG6ES4cGf98ez1AW6FqjkUwyfM5us F5fgRHXQ4m8gWKxJM7IPLzwVvuq3XJyVwadmCJ8tr7yB4B7KNuJ0u29FtmHU VQOViZETA2ezJb5vmh6l4d.o8AtLuBy1n_VxATM6oaHf1cgPinS4HJr1_D4f uSEgzQqYq_6Mb6LBmhJobFAnCJgBXAsZVHL89q.pEePlll17Q6ZbTY0dRZr9 FlDSC6uh7evQz5kdeZKcugOcMCj_lz1uIqojZYz33GFZt9l2O8gzhSXqBE_A PnIiUdSIr8QQfRALlKz5AjjhXmAdwYKq7Y_H_yhq1M2EUU2jlKdfZwHvoHaF rivLMokC1oCfO1uF2nvSousbZ3oVz6NJ_yNSXUaDkKg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4E11D818.3030701@ieca.com> Date: Mon, 04 Jul 2011 11:11:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org References: <4DF0CA9D.1030006@ieca.com> <9ACC73EC-6834-465B-A5DD-A0DFAE80BD40@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Final (hopefully) issues with DTLS 1.2 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, 04 Jul 2011 15:11:28 -0000 Can we have comments back by the 8th? That way if we need to make changes we can get them in before the submission deadline on the 11th. spt On 7/3/11 8:58 PM, Eric Rescorla wrote: > I have now submitted draft -06, which (I believe) matches Nikos's > version number fix. > > As Nikos objected to giving the CCS a sequence number and nobody spoke up for > it, I left it as-is and added a warning. I would mildly favor adding > one, but I don't > think the change is appropriate absent support from the WG which has not yet > been observed. If people believe that this change is appropriate, please speak > up. Otherwise I believe we are done. > > Best, > -Ekr > > On Tue, Jun 14, 2011 at 9:41 AM, Joe Salowey wrote: >> The open issue is with respect to the version number that Nikos raised. Eric is working on text along the lines of Nikos' recommendation of fixing the version number. >> >> Joe >> On Jun 9, 2011, at 6:29 AM, Sean Turner wrote: >> >>> Does anybody else have thoughts about this? I'd really like to be able to put this draft to bed. >>> >>> spt >>> >>> On 5/23/11 9:19 AM, Eric Rescorla wrote: >>>> Following up on Prague, here is the new text for the 2MSL and the >>>> record sequence number issues: >>>> >>>> >>>> >>>> MSL: >>>> 4.1. >>>> Note that because DTLS records may be reordered, a record from epoch >>>> 1 may be received after epoch 2 has begun. In general, >>>> implementations SHOULD discard packets from earlier epochs, but if >>>> packet loss causes noticeable problems MAY choose to retain keying >>>> material from previous epochs for up to the default MSL specified for >>>> TCP [TCP] to allow for packet reordering. (Note: the intention here >>>> is that implementors use the current guidance from the IETF for MSL, >>>> not that they attempt to interrogate the MSL the system TCP stack is >>>> using.) Until the handshake has completed, implementations MUST >>>> accept packets from the old epoch. >>>> >>>> ... >>>> >>>> 4.2.4. >>>> In addition, for at least twice the default MSL defined for [TCP], >>>> when in the FINISHED state, the node which transmits the last flight >>>> (the server in an ordinary handshake or the client in a resumed >>>> handshake) MUST respond to a retransmit of the peer's last flight >>>> with a retransmit of the last flight. This avoids deadlock conditions >>>> >>>> >>>> >>>> >>>> Record Sequence Number: >>>> When responding to a HelloVerifyRequest the client MUST use the same >>>> parameter values (version, random, session_id, cipher_suites, >>>> compression_method) as it did in the original ClientHello. The >>>> server SHOULD use those values to generate its cookie and verify that >>>> they are correct upon cookie receipt. The server MUST use the same >>>> version number in the HelloVerifyRequest that it would use when >>>> sending a ServerHello. Upon receipt of the ServerHello, the client >>>> MUST verify that the server version values match. In order to avoid >>>> sequence number duplication in case of multiple HelloVerifyRequests, >>>> the server MUST use the record sequence number in the ClientHello as >>>> the record sequence number in the HelloVerifyRequest. >>>> >>>> ... >>>> >>>> When the second ClientHello is received, the server can verify that >>>> the Cookie is valid and that the client can receive packets at the >>>> given IP address. In order to avoid sequence number duplication in >>>> case of multiple cookie exchanges, the server SHOULD use the record >>>> sequence number in the ClientHello as the record sequence number in >>>> its initial ServerHello. Subsequent ServerHellos will only be sent >>>> after the server has created state and MUST increment normally. >>>> >>>> I believe this matches what I said in Prague, but any objections to >>>> this in concept or the way I've written it up. >>>> >>>> >>>> Finally, I've been rethinking the issue of the interaction of the >>>> ChangeCipherSpec and the handshake sequence numbers. In Prague I >>>> suggested not changing this and just putting a note in the spec that >>>> one had to be careful, but at this point I am thinking it might be >>>> better to simple suck up the change and put a message sequence number >>>> in the CCS. This removes the need to consult the handshake state >>>> machine in order to deal with reordering, though not in order to >>>> determine whether the CCS is at the appropriate place in the handshake >>>> (in order to detect misbehaving or malicious behavior early). The >>>> downside for this is that it's a difference from TLS, but it seems >>>> like fairly easy code--though I admit I haven't tried to code it up. I >>>> don't think either way represents a security issue, but doing it this >>>> way means that we won't need to be as careful in the future about >>>> having the state machine be completely deterministic prior to the CCS, >>>> which seems like the Right Thing. Comments? >>>> >>>> -Ekr >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > From paul@xelerance.com Mon Jul 4 14:43:52 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D2321F8784 for ; Mon, 4 Jul 2011 14:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UHPa1ffFtENb for ; Mon, 4 Jul 2011 14:43:52 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4175121F8781 for ; Mon, 4 Jul 2011 14:43:52 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2E4BCBFE0 for ; Mon, 4 Jul 2011 17:43:49 -0400 (EDT) Date: Mon, 4 Jul 2011 17:43:48 -0400 (EDT) From: Paul Wouters To: tls@ietf.org Message-ID: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-00.txt (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2011 21:43:52 -0000 I just submitted draft-wouters-tls-oob-pubkey-00.txt which documents a TLS extension for use when a TLS client has obtained a server's public key (or keys) out-of-band. It allows the suppression of sending PKIX certificates This is useful for example when obtaining the TLS server public key using DANE. I'd like the WG to consider adopting it as a WG work item. Paul ---------- Forwarded message ---------- Date: Mon, 04 Jul 2011 14:33:54 -0700 From: internet-drafts@ietf.org Cc: weiler@tislabs.com, gnu@toad.com, paul@xelerance.com To: paul@xelerance.com Subject: New Version Notification for draft-wouters-tls-oob-pubkey-00.txt A new version of I-D, draft-wouters-tls-oob-pubkey-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-tls-oob-pubkey Revision: 00 Title: TLS Extension for out-of-band public key validation Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 8 Abstract: This document specifies a new TLS extension as well as modified TLS client and TLS server behaviour when public keys are authenticated out-of-band to the current TLS connection. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The new extension specified is "oob_pubkey_list" which can be used when the TLS client is already in possession of a validated public key of the TLS server before it starts the TLS handshake. The IETF Secretariat From Masanobu.Katagi@jp.sony.com Mon Jul 4 17:32:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443E421F87AD for ; Mon, 4 Jul 2011 17:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 IwPkN8copWSL for ; Mon, 4 Jul 2011 17:32:30 -0700 (PDT) Received: from ms5.sony.co.jp (ms5.sony.co.jp [IPv6:2001:cf8:0:56::201]) by ietfa.amsl.com (Postfix) with ESMTP id B22A121F87A7 for ; Mon, 4 Jul 2011 17:32:29 -0700 (PDT) Received: from mta6.sony.co.jp (mta6.sony.co.jp [137.153.71.9]) by ms5.sony.co.jp (R8/Sony) with ESMTP id p650WQ4s014097 for ; Tue, 5 Jul 2011 09:32:26 +0900 (JST) Received: from mta6.sony.co.jp (localhost [127.0.0.1]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p650WPYw005566 for ; Tue, 5 Jul 2011 09:32:25 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p650WPm4005512 for ; Tue, 5 Jul 2011 09:32:25 +0900 (JST) Received: from jptkyxim102.jp.sony.com ([43.15.31.6]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 09:32:12 +0900 Received: from [43.11.214.84] ([43.11.214.84]) by jptkyxim102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 09:32:12 +0900 Date: Tue, 05 Jul 2011 09:33:42 +0900 From: Masanobu Katagi To: tls@ietf.org Message-Id: <20110705093341.940B.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 05 Jul 2011 00:32:12.0980 (UTC) FILETIME=[FBC5D740:01CC3AAA] Cc: shiho.moriai@jp.sony.com Subject: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 00:32:31 -0000 Dear all, We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS. http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products. The algorithm of CLEFIA was published as RFC6114 in March 2011. CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm. The security and performance of CLEFIA have been evaluated through the CRYPTREC project which evaluates and monitors the security of Japan e-Government recommended ciphers. It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, Lightweight cryptography) and it's in the Final Draft International Standard. Any comments on this draft would be appreciated. Best regards, Masanobu Katagi Sony Corporation Forwarded by Masanobu Katagi ----------------------- Original Message ----------------------- From: "internet-drafts@ietf.org" To: "Katagi, Masanobu" Cc: "Katagi, Masanobu" , "Moriai, Shiho" Date: Mon, 4 Jul 2011 17:51:44 +0900 Subject: New Version Notification for draft-katagi-tls-clefia-00.txt ---- A new version of I-D, draft-katagi-tls-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository. Filename: draft-katagi-tls-clefia Revision: 00 Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) Creation date: 2011-07-04 WG ID: Individual Submission Number of pages: 16 Abstract: This document specifies a set of cipher suites for the Transport Security Layer (TLS) protocol to support the CLEFIA encryption algorithm as a block cipher. CLEFIA is a lightweight block cipher and suitable for constrained devices. The IETF Secretariat --------------------- Original Message Ends -------------------- From kanno.satoru@po.ntts.co.jp Mon Jul 4 20:01:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935F521F86D1 for ; Mon, 4 Jul 2011 20:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 sNJP+YdqcBH5 for ; Mon, 4 Jul 2011 20:01:40 -0700 (PDT) Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 913EF21F86C7 for ; Mon, 4 Jul 2011 20:01:40 -0700 (PDT) Received: from sadoku33.silk.ntts.co.jp (sadoku33 [10.7.18.33]) by mail12.ics.ntts.co.jp (8.14.4/8.13.4/NTTSOFT) with ESMTP id p6531VUM014495; Tue, 5 Jul 2011 12:01:31 +0900 (JST) Received: (from root@localhost) by sadoku33.silk.ntts.co.jp (8.13.8/NTTSOFT) id p6531ViM027566; Tue, 5 Jul 2011 12:01:31 +0900 (JST) Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku33.silk.ntts.co.jp with SMTP id NAA27565; Tue, 5 Jul 2011 12:01:31 +0900 Received: from mail137.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id p6531U0l009736; Tue, 5 Jul 2011 12:01:30 +0900 Received: from mail137.silk.ntts.co.jp (localhost [127.0.0.1]) by mail137.silk.ntts.co.jp (8.14.4/NTTSOFT) with ESMTP id p6531Uhf018188; Tue, 5 Jul 2011 12:01:30 +0900 (JST) Received: from ccmds32 (ccmds32.silk.ntts.co.jp [10.107.0.32]) by mail137.silk.ntts.co.jp (8.14.4/NTTSOFT) with SMTP id p6531UaQ018185; Tue, 5 Jul 2011 12:01:30 +0900 (JST) Message-ID: <4E127E5E.6090409@po.ntts.co.jp> Date: Tue, 05 Jul 2011 12:00:46 +0900 From: Satoru Kanno User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Masanobu Katagi References: <20110705093341.940B.1C812BE2@jp.sony.com> In-Reply-To: <20110705093341.940B.1C812BE2@jp.sony.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ccmds32.silk.ntts.co.jp id p6531U0l009736 Cc: shiho.moriai@jp.sony.com, tls@ietf.org Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 03:01:41 -0000 Hi Masanobu, I have two comments for your draft. [For IPR statement] I can't find an IPR statement on CLEFIA for TLS when searching for that=20 draft on the IPR Disclosure search page: https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&documen= t_search=3Ddraft-katagi-tls-clefia In the case of Camellia, we submitted the IPR statement for TLS as a=20 following: https://datatracker.ietf.org/ipr/41/ Since CLEFIA is patented by SONY, I believe you need to submit an IPR=E3=80= =80=20 disclosure for this document. [For ciphersuites with SHA-1] Are you really suggesting that CLEFIA be used with SHA-1? NIST is saying not to use SHA-1 very soon. I believe these suites should=20 be removed because RFC 6209 and new I-D on Camellia are not defined on=20 these suites recently. Of course, I checked security considerations for ciphersuites with SHA-1=20 in your draft. What do you and TLS folks think of these ciphersuites? Regards, Satoru (2011/07/05 9:33), Masanobu Katagi wrote: > Dear all, > > We have submitted the Internet draft that defines cipher suites to supp= ort CLEFIA in TLS. > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt > > CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now use= d in commercial products. > The algorithm of CLEFIA was published as RFC6114 in March 2011. > CLEFIA is a lightweight block cipher compared with AES, Camellia, and S= EED. > We believe that CLEFIA will contribute to the Internet of Things as a l= ightweight cipher algorithm. > > The security and performance of CLEFIA have been evaluated through the = CRYPTREC project > which evaluates and monitors the security of Japan e-Government recomme= nded ciphers. > It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, Ligh= tweight cryptography) and it's > in the Final Draft International Standard. > > Any comments on this draft would be appreciated. > > Best regards, > Masanobu Katagi > Sony Corporation > > Forwarded by Masanobu Katagi > ----------------------- Original Message ----------------------- > From: "internet-drafts@ietf.org" > To: "Katagi, Masanobu" > Cc: "Katagi, Masanobu", > "Moriai, Shiho" > Date: Mon, 4 Jul 2011 17:51:44 +0900 > Subject: New Version Notification for draft-katagi-tls-clefia-00.txt > ---- > > A new version of I-D, draft-katagi-tls-clefia-00.txt has been successfu= lly submitted by Masanobu Katagi and posted to the IETF repository. > > Filename: draft-katagi-tls-clefia > Revision: 00 > Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) > Creation date: 2011-07-04 > WG ID: Individual Submission > Number of pages: 16 > > Abstract: > This document specifies a set of cipher suites for the Transport > Security Layer (TLS) protocol to support the CLEFIA encryption > algorithm as a block cipher. CLEFIA is a lightweight block cipher > and suitable for constrained devices. > > > > > The IETF Secretariat > > > --------------------- Original Message Ends -------------------- > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno.satoru@po.ntts.co.jp From Masanobu.Katagi@jp.sony.com Mon Jul 4 22:19:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7451211E808D for ; Mon, 4 Jul 2011 22:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.292 X-Spam-Level: X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwqMcCnl5CR8 for ; Mon, 4 Jul 2011 22:19:26 -0700 (PDT) Received: from ms6.sony.co.jp (ms6.sony.co.jp [IPv6:2001:cf8:0:56::204]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5211E8088 for ; Mon, 4 Jul 2011 22:19:25 -0700 (PDT) Received: from mta8.sony.co.jp (mta8.sony.co.jp [IPv6:2001:cf8:0:191::15]) by ms6.sony.co.jp (R8/Sony) with ESMTP id p655JNAV018255 for ; Tue, 5 Jul 2011 14:19:23 +0900 (JST) Received: from mta8.sony.co.jp (localhost [127.0.0.1]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p655JNCW017632 for ; Tue, 5 Jul 2011 14:19:23 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p655JNgo017605 for ; Tue, 5 Jul 2011 14:19:23 +0900 (JST) Received: from jptkyxim102.jp.sony.com ([43.15.31.6]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 14:19:14 +0900 Received: from [43.11.214.84] ([43.11.214.84]) by jptkyxim102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 14:19:14 +0900 Date: Tue, 05 Jul 2011 14:20:43 +0900 From: Masanobu Katagi To: Satoru Kanno In-Reply-To: <4E127E5E.6090409@po.ntts.co.jp> References: <20110705093341.940B.1C812BE2@jp.sony.com> <4E127E5E.6090409@po.ntts.co.jp> Message-Id: <20110705142043.9423.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 05 Jul 2011 05:19:14.0478 (UTC) FILETIME=[1495E4E0:01CC3AD3] Cc: "Moriai, Shiho" , "tls@ietf.org" Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 05:19:27 -0000 Hi Satoru, Thank you for your comments on our draft! We submitted our IPR disclosure related to the document, but it seems to take some time before it becomes available on the web. As you mentioned, our considerations on SHA-1 are written in Section 4 (Security Considerations) in the document. We are happy to hear comments from TLS WG experts. Best regards, Masanobu Katagi On Tue, 5 Jul 2011 12:00:46 +0900 Satoru Kanno wrote: > Hi Masanobu, > > I have two comments for your draft. > > [For IPR statement] > I can't find an IPR statement on CLEFIA for TLS when searching for that > draft on the IPR Disclosure search page: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-katagi-tls-clefia > > In the case of Camellia, we submitted the IPR statement for TLS as a > following: > > https://datatracker.ietf.org/ipr/41/ > > Since CLEFIA is patented by SONY, I believe you need to submit an IPR$B!!(B > disclosure for this document. > > > [For ciphersuites with SHA-1] > Are you really suggesting that CLEFIA be used with SHA-1? > NIST is saying not to use SHA-1 very soon. I believe these suites should > be removed because RFC 6209 and new I-D on Camellia are not defined on > these suites recently. > Of course, I checked security considerations for ciphersuites with SHA-1 > in your draft. > > What do you and TLS folks think of these ciphersuites? > > Regards, > Satoru > > (2011/07/05 9:33), Masanobu Katagi wrote: > > Dear all, > > > > We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS. > > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt > > > > CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products. > > The algorithm of CLEFIA was published as RFC6114 in March 2011. > > CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. > > We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm. > > > > The security and performance of CLEFIA have been evaluated through the CRYPTREC project > > which evaluates and monitors the security of Japan e-Government recommended ciphers. > > It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, Lightweight cryptography) and it's > > in the Final Draft International Standard. > > > > Any comments on this draft would be appreciated. > > > > Best regards, > > Masanobu Katagi > > Sony Corporation > > > > Forwarded by Masanobu Katagi > > ----------------------- Original Message ----------------------- > > From: "internet-drafts@ietf.org" > > To: "Katagi, Masanobu" > > Cc: "Katagi, Masanobu", > > "Moriai, Shiho" > > Date: Mon, 4 Jul 2011 17:51:44 +0900 > > Subject: New Version Notification for draft-katagi-tls-clefia-00.txt > > ---- > > > > A new version of I-D, draft-katagi-tls-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository. > > > > Filename: draft-katagi-tls-clefia > > Revision: 00 > > Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) > > Creation date: 2011-07-04 > > WG ID: Individual Submission > > Number of pages: 16 > > > > Abstract: > > This document specifies a set of cipher suites for the Transport > > Security Layer (TLS) protocol to support the CLEFIA encryption > > algorithm as a block cipher. CLEFIA is a lightweight block cipher > > and suitable for constrained devices. > > > > > > > > > > The IETF Secretariat > > > > > > --------------------- Original Message Ends -------------------- > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > -- > Satoru Kanno > > Security Business Unit > Mobile and Security Solution Business Group > NTT Software Corporation > > e-mail: kanno.satoru@po.ntts.co.jp > > From andre.silaghi@googlemail.com Mon Jul 4 23:19:59 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D527421F86D1 for ; Mon, 4 Jul 2011 23:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 aAiRZXB7fsq4 for ; Mon, 4 Jul 2011 23:19:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id A92BD21F86CE for ; Mon, 4 Jul 2011 23:19:58 -0700 (PDT) Received: by bwb17 with SMTP id 17so5414446bwb.31 for ; Mon, 04 Jul 2011 23:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=opzO2TAvEHOmv1Qbgqdb77bx7iSuAGuJIbgVWcoTzTw=; b=qM5epyYnHbmH6I2e7v6X1H7XZtHLE0ucr4C7bLTbprg8O8GWsLYh+sICCuqVVvcF/S 7GCWgPhs6wBp7fShJVvRF006xt/WzMgtQOml+MHcUGOzmEYgXxg7wUndWQS1ayi3n9nx kMWLfnSlqpELn27LP39QhwyG+u6ikecZ3bqOo= Received: by 10.204.80.100 with SMTP id s36mr1866384bkk.178.1309846797362; Mon, 04 Jul 2011 23:19:57 -0700 (PDT) Received: from [192.168.1.51] (g229045247.adsl.alicedsl.de [92.229.45.247]) by mx.google.com with ESMTPS id f16sm437098bke.16.2011.07.04.23.19.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jul 2011 23:19:56 -0700 (PDT) Message-ID: <4E12ACF4.2020002@googlemail.com> Date: Tue, 05 Jul 2011 08:19:32 +0200 From: Andre Silaghi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: tls@ietf.org References: <20110705093341.940B.1C812BE2@jp.sony.com> <4E127E5E.6090409@po.ntts.co.jp> In-Reply-To: <4E127E5E.6090409@po.ntts.co.jp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 06:24:07 -0000 Hi there, [For ciphersuites with SHA-1] I also would suggest to think again about using SHA-1. There has been one theoretical attack on it in 2008: http://eprint.iacr.org/2008/469.pdf What about SHA-2 (256/512)? Regards, Andre Am 05.07.2011 05:00, schrieb Satoru Kanno: > Hi Masanobu, > > I have two comments for your draft. > > [For IPR statement] > I can't find an IPR statement on CLEFIA for TLS when searching for > that draft on the IPR Disclosure search page: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-katagi-tls-clefia > > > In the case of Camellia, we submitted the IPR statement for TLS as a > following: > > https://datatracker.ietf.org/ipr/41/ > > Since CLEFIA is patented by SONY, I believe you need to submit an IPR > 　 disclosure for this document. > > > [For ciphersuites with SHA-1] > Are you really suggesting that CLEFIA be used with SHA-1? > NIST is saying not to use SHA-1 very soon. I believe these suites > should be removed because RFC 6209 and new I-D on Camellia are not > defined on these suites recently. > Of course, I checked security considerations for ciphersuites with > SHA-1 in your draft. > > What do you and TLS folks think of these ciphersuites? > > Regards, > Satoru > > (2011/07/05 9:33), Masanobu Katagi wrote: >> Dear all, >> >> We have submitted the Internet draft that defines cipher suites to >> support CLEFIA in TLS. >> http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt >> >> CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now >> used in commercial products. >> The algorithm of CLEFIA was published as RFC6114 in March 2011. >> CLEFIA is a lightweight block cipher compared with AES, Camellia, and >> SEED. >> We believe that CLEFIA will contribute to the Internet of Things as a >> lightweight cipher algorithm. >> >> The security and performance of CLEFIA have been evaluated through >> the CRYPTREC project >> which evaluates and monitors the security of Japan e-Government >> recommended ciphers. >> It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, >> Lightweight cryptography) and it's >> in the Final Draft International Standard. >> >> Any comments on this draft would be appreciated. >> >> Best regards, >> Masanobu Katagi >> Sony Corporation >> >> Forwarded by Masanobu Katagi >> ----------------------- Original Message ----------------------- >> From: "internet-drafts@ietf.org" >> To: "Katagi, Masanobu" >> Cc: "Katagi, Masanobu", >> "Moriai, Shiho" >> Date: Mon, 4 Jul 2011 17:51:44 +0900 >> Subject: New Version Notification for draft-katagi-tls-clefia-00.txt >> ---- >> >> A new version of I-D, draft-katagi-tls-clefia-00.txt has been >> successfully submitted by Masanobu Katagi and posted to the IETF >> repository. >> >> Filename: draft-katagi-tls-clefia >> Revision: 00 >> Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) >> Creation date: 2011-07-04 >> WG ID: Individual Submission >> Number of pages: 16 >> >> Abstract: >> This document specifies a set of cipher suites for the Transport >> Security Layer (TLS) protocol to support the CLEFIA encryption >> algorithm as a block cipher. CLEFIA is a lightweight block cipher >> and suitable for constrained devices. >> >> >> >> >> The IETF Secretariat >> >> >> --------------------- Original Message Ends -------------------- >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From n.mavrogiannopoulos@gmail.com Tue Jul 5 00:46:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7097521F8559 for ; Tue, 5 Jul 2011 00:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ4Fw7YaxXhU for ; Tue, 5 Jul 2011 00:46:24 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC47821F8558 for ; Tue, 5 Jul 2011 00:46:24 -0700 (PDT) Received: by pzk5 with SMTP id 5so1761955pzk.31 for ; Tue, 05 Jul 2011 00:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=PQ0FUEx2BVkzl69OgP9tJC5DCFjqIEv6m9uaxmtQkiQ=; b=Q/wx7PStytDjgbSJNEnj56r5+Eyhs2lXhOEKfbbMVMXYDFvBPYgnnwP9VClOA88Vu+ ivLdqPtRwMl+20x58b9gcIp+ZV2gW/+TbFLZ1bckTi2rKMPh/0BiUasbGS5L85wDioPG XXHUENSybl2eDJSB1TxIB4fbQViSDxzUwT9nw= MIME-Version: 1.0 Received: by 10.142.250.9 with SMTP id x9mr3397241wfh.178.1309851984012; Tue, 05 Jul 2011 00:46:24 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.142.156.12 with HTTP; Tue, 5 Jul 2011 00:46:23 -0700 (PDT) In-Reply-To: <20110705093341.940B.1C812BE2@jp.sony.com> References: <20110705093341.940B.1C812BE2@jp.sony.com> Date: Tue, 5 Jul 2011 10:46:23 +0300 X-Google-Sender-Auth: Lda8I-n2-q6S_Kj7uP1hKd4tGLE Message-ID: From: Nikos Mavrogiannopoulos To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 07:46:25 -0000 On Tue, Jul 5, 2011 at 3:33 AM, Masanobu Katagi wrote: > Dear all, > We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS. > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt > CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products. > The algorithm of CLEFIA was published as RFC6114 in March 2011. > CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. > We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm. Hello, What is the use-case of this cipher in TLS? In particular what is the point of having a lightweight cipher combined with non-lightweight primitives such as RSA and Diffie Hellman key exchange, and SHA MACs? regards, Nikos From pgut001@login01.cs.auckland.ac.nz Tue Jul 5 05:25:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832F621F872F for ; Tue, 5 Jul 2011 05:25:56 -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 QSrZ1ZbozYaU for ; Tue, 5 Jul 2011 05:25:53 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6C36C21F872A for ; Tue, 5 Jul 2011 05:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1309868754; x=1341404754; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nmav@gnutls.org,=20tls@ietf.org|Subject:=20Re:=20[ TLS]=20Fw:=20New=20Version=20Notification=20for=20draft-k atagi-tls-clefia-00.txt|In-Reply-To:=20 |Message-Id:=20|Date:=20Wed,=2006=20Jul=202011=2000:25:50=20+1200; bh=6/hDX9F7lnLcvmvHO+9Gy2IXw3cLkJZfZY2E93XjKt8=; b=H3Chk/nc1kdig7TTtKVrWtiVpkVGN+G0dn5MlznH0CWyFw2i1ZoO9T6q adzEg6hhYw35xbkks3vIzIx33fq0ZUszvdPCIYs+GRRoLjzmJ4nhJqItn UCfBhLd3zw+5NCb1/kyIQT5C7eSWZehXYUnLn2Gh0LNhrkTlX1kWMilMK w=; X-IronPort-AV: E=Sophos;i="4.65,478,1304251200"; d="scan'208";a="70342060" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Jul 2011 00:25:50 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qe4hK-0002AC-GW; Wed, 06 Jul 2011 00:25:50 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qe4hK-0008GE-2j; Wed, 06 Jul 2011 00:25:50 +1200 From: Peter Gutmann To: nmav@gnutls.org, tls@ietf.org In-Reply-To: Message-Id: Date: Wed, 06 Jul 2011 00:25:50 +1200 Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 12:25:56 -0000 Nikos Mavrogiannopoulos writes: >What is the use-case of this cipher in TLS? In particular what is the point >of having a lightweight cipher combined with non-lightweight primitives such >as RSA and Diffie Hellman key exchange, and SHA MACs? The use case is "It's a Sony!". Peter. From andre.silaghi@googlemail.com Tue Jul 5 07:21:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBE921F8552 for ; Tue, 5 Jul 2011 07:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enD+2hpB0RYK for ; Tue, 5 Jul 2011 07:21:10 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2DA21F8539 for ; Tue, 5 Jul 2011 07:21:08 -0700 (PDT) Received: by bwb17 with SMTP id 17so5769665bwb.31 for ; Tue, 05 Jul 2011 07:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=uF8FF7uJnZl8FNc7KxnV0Z4+TDEvkws4f1yMNKbzTQ0=; b=GlRsydTB+IYgNI13oobSNgE1XPwIXSM7veZ87NI/dAvLUA3r9/zBkMWMdrG4rDJ1UO 4lIaGoVNyD00J3Ci3otKVvVnxgLKubYapLatGzYyx4O98NHikJxST78pooHQ+3ANpjgr EWRfIuu/9crzBJz7qSaQmRTvpi8TKsqukfSsU= Received: by 10.204.101.10 with SMTP id a10mr7069386bko.183.1309875667663; Tue, 05 Jul 2011 07:21:07 -0700 (PDT) Received: from [192.168.1.51] (g225006049.adsl.alicedsl.de [92.225.6.49]) by mx.google.com with ESMTPS id k5sm6595112bka.5.2011.07.05.07.21.04 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Jul 2011 07:21:05 -0700 (PDT) Message-ID: <4E131DBB.3060402@googlemail.com> Date: Tue, 05 Jul 2011 16:20:43 +0200 From: Andre Silaghi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: tls@ietf.org References: <20110705093341.940B.1C812BE2@jp.sony.com> <4E127E5E.6090409@po.ntts.co.jp> In-Reply-To: <4E127E5E.6090409@po.ntts.co.jp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 14:21:12 -0000 Hi there, I would suggest to think about another hashing algorithm because there is at least one theoretical attack on SHA-1. What about SHA-2 (256 or eve 512)? Regards, Andre Am 05.07.2011 05:00, schrieb Satoru Kanno: > Hi Masanobu, > > I have two comments for your draft. > > [For IPR statement] > I can't find an IPR statement on CLEFIA for TLS when searching for > that draft on the IPR Disclosure search page: > > https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-katagi-tls-clefia > > > In the case of Camellia, we submitted the IPR statement for TLS as a > following: > > https://datatracker.ietf.org/ipr/41/ > > Since CLEFIA is patented by SONY, I believe you need to submit an IPR > 　 disclosure for this document. > > > [For ciphersuites with SHA-1] > Are you really suggesting that CLEFIA be used with SHA-1? > NIST is saying not to use SHA-1 very soon. I believe these suites > should be removed because RFC 6209 and new I-D on Camellia are not > defined on these suites recently. > Of course, I checked security considerations for ciphersuites with > SHA-1 in your draft. > > What do you and TLS folks think of these ciphersuites? > > Regards, > Satoru > > (2011/07/05 9:33), Masanobu Katagi wrote: >> Dear all, >> >> We have submitted the Internet draft that defines cipher suites to >> support CLEFIA in TLS. >> http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt >> >> CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now >> used in commercial products. >> The algorithm of CLEFIA was published as RFC6114 in March 2011. >> CLEFIA is a lightweight block cipher compared with AES, Camellia, and >> SEED. >> We believe that CLEFIA will contribute to the Internet of Things as a >> lightweight cipher algorithm. >> >> The security and performance of CLEFIA have been evaluated through >> the CRYPTREC project >> which evaluates and monitors the security of Japan e-Government >> recommended ciphers. >> It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, >> Lightweight cryptography) and it's >> in the Final Draft International Standard. >> >> Any comments on this draft would be appreciated. >> >> Best regards, >> Masanobu Katagi >> Sony Corporation >> >> Forwarded by Masanobu Katagi >> ----------------------- Original Message ----------------------- >> From: "internet-drafts@ietf.org" >> To: "Katagi, Masanobu" >> Cc: "Katagi, Masanobu", >> "Moriai, Shiho" >> Date: Mon, 4 Jul 2011 17:51:44 +0900 >> Subject: New Version Notification for draft-katagi-tls-clefia-00.txt >> ---- >> >> A new version of I-D, draft-katagi-tls-clefia-00.txt has been >> successfully submitted by Masanobu Katagi and posted to the IETF >> repository. >> >> Filename: draft-katagi-tls-clefia >> Revision: 00 >> Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) >> Creation date: 2011-07-04 >> WG ID: Individual Submission >> Number of pages: 16 >> >> Abstract: >> This document specifies a set of cipher suites for the Transport >> Security Layer (TLS) protocol to support the CLEFIA encryption >> algorithm as a block cipher. CLEFIA is a lightweight block cipher >> and suitable for constrained devices. >> >> >> >> >> The IETF Secretariat >> >> >> --------------------- Original Message Ends -------------------- >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > From geoffk@geoffk.org Tue Jul 5 11:42:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC5E21F88F4 for ; Tue, 5 Jul 2011 11:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ58z9t1giju for ; Tue, 5 Jul 2011 11:42:02 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2498921F8832 for ; Tue, 5 Jul 2011 11:41:58 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 9569633D17C; Tue, 5 Jul 2011 18:41:50 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Masanobu Katagi References: <20110705093341.940B.1C812BE2@jp.sony.com> From: Geoffrey Keating Date: 05 Jul 2011 11:41:50 -0700 In-Reply-To: <20110705093341.940B.1C812BE2@jp.sony.com> Message-ID: Lines: 36 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: shiho.moriai@jp.sony.com, tls@ietf.org Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 18:42:03 -0000 The draft seems to be heavily based off existing ciphersuite definitions for other ciphers. This is good, but it means that it also propagates many of the deficencies in those RFCs. Here are the ones I noticed: 1. It appears a cipher suite is defined for every combination of CLEFIA with a hash algorithm and key exchange algorithm. I suggest that many of these combinations will never be used. As this is a new cipher, I don't see any reason to define ciphersuites for backwards compatibility with old versions of TLS or old implementations. 2. I would suggest removing at least: - All combinations involving SHA-1 - All combinations involving DSS - All combinations involving DH keys or ECDH keys as these are obsolete, are not commonly used even with AES, or both. 3. If TLS is faster with this cipher in GCM, and this cipher is considered to be secure in GCM, I would suggest only defining GCM ciphersuites; otherwise, I would suggest not defining any GCM ciphersuites. Given that this cipher is targeted at hardware implementations where the gate count of AES is a limiting factor on performance, it seems like GCM should be strongly recommended, to avoid needing to implement SHA256 in fast hardware. 4. I don't see anywhere in the draft where the mac_length and mac_key_length is defined for these ciphersuites. This is especially important for SHA-384 since RFC 5246 does not mention it. 5. Why SHA-384 and not SHA-512, especially when using GCM? 6. The security considerations section should point out that CLEFIA is a 128-bit block cipher and so unsuitable for transmission of very large amounts of data (on the order of 2^64 bytes), the same as AES. From Masanobu.Katagi@jp.sony.com Wed Jul 6 02:46:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6421F860A for ; Wed, 6 Jul 2011 02:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.394 X-Spam-Level: X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctQ0t6BNy001 for ; Wed, 6 Jul 2011 02:46:50 -0700 (PDT) Received: from ms5.sony.co.jp (ms5.sony.co.jp [IPv6:2001:cf8:0:56::201]) by ietfa.amsl.com (Postfix) with ESMTP id 6343C21F860E for ; Wed, 6 Jul 2011 02:46:48 -0700 (PDT) Received: from mta8.sony.co.jp (mta8.sony.co.jp [IPv6:2001:cf8:0:191::15]) by ms5.sony.co.jp (R8/Sony) with ESMTP id p669kjYc003299 for ; Wed, 6 Jul 2011 18:46:45 +0900 (JST) Received: from mta8.sony.co.jp (localhost [127.0.0.1]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p669kjqm021983 for ; Wed, 6 Jul 2011 18:46:45 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p669kjb6021894 for ; Wed, 6 Jul 2011 18:46:45 +0900 (JST) Received: from jptkyxim102.jp.sony.com ([43.15.31.6]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 18:46:32 +0900 Received: from [43.11.214.84] ([43.11.214.84]) by jptkyxim102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Jul 2011 18:46:32 +0900 Date: Wed, 06 Jul 2011 18:48:01 +0900 From: Masanobu Katagi To: Nikos Mavrogiannopoulos In-Reply-To: References: <20110705093341.940B.1C812BE2@jp.sony.com> Message-Id: <20110706184758.A3B8.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 06 Jul 2011 09:46:32.0124 (UTC) FILETIME=[962E37C0:01CC3BC1] Cc: shiho.moriai@jp.sony.com, "tls@ietf.org" Subject: Re: [TLS] Fw: New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 09:46:51 -0000 Hi Nikos, Our point is that lightweight ciphers contribute to efficient implementations and lower energy consumption in total because, even if combined with non-lightweight primitives such as RSA and DH, they are effective for encryption and MAC in TLS communication. Best regards, Masanobu Katagi On Tue, 5 Jul 2011 16:46:23 +0900 Nikos Mavrogiannopoulos wrote: > On Tue, Jul 5, 2011 at 3:33 AM, Masanobu Katagi > wrote: > > Dear all, > > We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS. > > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt > > CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products. > > The algorithm of CLEFIA was published as RFC6114 in March 2011. > > CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. > > We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm. > > Hello, > What is the use-case of this cipher in TLS? In particular what is the > point of having a lightweight > cipher combined with non-lightweight primitives such as RSA and Diffie > Hellman key exchange, > and SHA MACs? > > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Wed Jul 6 16:44:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BDE21F8ABC for ; Wed, 6 Jul 2011 16:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71V26cBW0yup for ; Wed, 6 Jul 2011 16:44:50 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id B2A9B21F8948 for ; Wed, 6 Jul 2011 16:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=157; q=dns/txt; s=iport; t=1309995890; x=1311205490; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=f1AgZtD3C4moWAUSgP3VETjddl/5YRfLXOWu+w+45Jc=; b=WAIxQvKIl6rB12Jcm1JjMg7gPvRmt1vqmIISajULx3BkaLc3H3iQ2sfq pwXbpL6Htg6t5uOkobvpflah661qFs9PU3OkFo1IrBOrzYFLC/UtgigF1 2vFOeg9m18s0isul8gx/5WTcGLCMRuAeuRzxih/ysE3Yiyhdubx8nyxgL U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQHAOnyFE6rRDoI/2dsb2JhbABTmR6ObXesPIEinXyGNwSHRop7hHqLYw X-IronPort-AV: E=Sophos;i="4.65,489,1304294400"; d="scan'208";a="291733353" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-4.cisco.com with ESMTP; 06 Jul 2011 23:44:50 +0000 Received: from [10.33.251.182] ([10.33.251.182]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p66NinZ2026172 for ; Wed, 6 Jul 2011 23:44:50 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jul 2011 16:45:14 -0700 Message-Id: <7FCF1B1F-4132-489E-BC1E-A69805372C25@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Agenda items for IETF 81 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, 06 Jul 2011 23:44:51 -0000 TLS has been granted a 2 hour slot on Thursday, 7/28 from 1520 to 1720. = Please send any requests for agenda slots to the chairs. =20 Thanks, Joe= From Masanobu.Katagi@jp.sony.com Thu Jul 7 03:31:07 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CE121F868D for ; Thu, 7 Jul 2011 03:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.173 X-Spam-Level: X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RDNS_NONE=0.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 W0eb9saTBGnF for ; Thu, 7 Jul 2011 03:31:06 -0700 (PDT) Received: from ms4.sony.co.jp (ms4.sony.co.jp [IPv6:2001:cf8:0:56::198]) by ietfa.amsl.com (Postfix) with ESMTP id EF50C21F867C for ; Thu, 7 Jul 2011 03:31:04 -0700 (PDT) Received: from mta7.sony.co.jp (mta7.sony.co.jp [IPv6:2001:cf8:0:191::12]) by ms4.sony.co.jp (R8/Sony) with ESMTP id p67AV1XL013461 for ; Thu, 7 Jul 2011 19:31:01 +0900 (JST) Received: from mta7.sony.co.jp (localhost [127.0.0.1]) by mta7.sony.co.jp (R8/Sony) with ESMTP id p67AV1qp019357 for ; Thu, 7 Jul 2011 19:31:01 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta7.sony.co.jp (R8/Sony) with ESMTP id p67AV1UI019332 for ; Thu, 7 Jul 2011 19:31:01 +0900 (JST) Received: from jptkyxim102.jp.sony.com ([43.15.31.6]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:30:59 +0900 Received: from [43.11.214.84] ([43.11.214.84]) by jptkyxim102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jul 2011 19:30:59 +0900 Date: Thu, 07 Jul 2011 19:32:28 +0900 From: Masanobu Katagi To: Geoffrey Keating , "tls@ietf.org" In-Reply-To: References: <20110705093341.940B.1C812BE2@jp.sony.com> Message-Id: <20110707193227.A3D2.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 07 Jul 2011 10:30:59.0197 (UTC) FILETIME=[F64B02D0:01CC3C90] Cc: "Moriai, Shiho" Subject: Re: [TLS] New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 10:31:07 -0000 Hi Geoffrey and all, Thank you for your comments on our draft. 1. ciphersuites with SHA-1 According to the following information, http://www9.atwiki.jp/kurushima/pub/pkimisc/SSLTLS_CipherSuite_Support_Table_.html the SHA-2 family has not been supported by major SSL Servers and Web Browsers. Our concern is that if we define new ciphersuites without SHA-1, these ciphersuites cannot be used now. Does somebody know when the SHA-2 family will be supported by Apache, IE, and Firefox? 2. GCM The efficiency of hardware implementation is one of the advantages of CLEFIA. There is no security concern known in using CLEFIA in GCM. We'd like to define the ciphersuites with GCM. 3. mac_length for SHA-384, choice of SHA-384/512 Are these new topics to be discussed in TLS ML? Both suggestions seem to be applicable to other block ciphers: AES(RFC 5288, 5289), Camellia(draft-kanno-tls-camellia-03), and ARIA(RFC 6209). These ciphersuites also use SHA-384, not SHA-512. Please let me know whether there have been similar discussions before. We'd like to follow the TLS WG's consensus. 4. transmission of very large amounts of data This issue belongs to a limitation of using a 128-bit block cipher under a single key. For n-bit block ciphers, encryption more than 2^(n/2) blocks by a single key should be banned in most modes of operations. Regards, Masanobu Katagi On Wed, 6 Jul 2011 03:41:50 +0900 Geoffrey Keating wrote: > The draft seems to be heavily based off existing ciphersuite > definitions for other ciphers. This is good, but it means that it > also propagates many of the deficencies in those RFCs. Here are the > ones I noticed: > > 1. It appears a cipher suite is defined for every combination of CLEFIA > with a hash algorithm and key exchange algorithm. I suggest that many > of these combinations will never be used. > > As this is a new cipher, I don't see any reason to define ciphersuites > for backwards compatibility with old versions of TLS or old > implementations. > > 2. I would suggest removing at least: > - All combinations involving SHA-1 > - All combinations involving DSS > - All combinations involving DH keys or ECDH keys > as these are obsolete, are not commonly used even with AES, or both. > > 3. If TLS is faster with this cipher in GCM, and this cipher is > considered to be secure in GCM, I would suggest only defining GCM > ciphersuites; otherwise, I would suggest not defining any GCM > ciphersuites. Given that this cipher is targeted at hardware > implementations where the gate count of AES is a limiting factor on > performance, it seems like GCM should be strongly recommended, to > avoid needing to implement SHA256 in fast hardware. > > 4. I don't see anywhere in the draft where the mac_length and > mac_key_length is defined for these ciphersuites. This is especially > important for SHA-384 since RFC 5246 does not mention it. > > 5. Why SHA-384 and not SHA-512, especially when using GCM? > > 6. The security considerations section should point out that CLEFIA is a > 128-bit block cipher and so unsuitable for transmission of very large > amounts of data (on the order of 2^64 bytes), the same as AES. From Michael.Tuexen@lurchi.franken.de Sat Jul 9 13:38:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4B721F89E9; Sat, 9 Jul 2011 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 o4cBg75xJp8u; Sat, 9 Jul 2011 13:38:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id ABE5A21F89BC; Sat, 9 Jul 2011 13:38:27 -0700 (PDT) Received: from [192.168.1.195] (p508FBCD1.dip.t-dialin.net [80.143.188.209]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BC4361C0B4611; Sat, 9 Jul 2011 22:38:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi> Date: Sat, 9 Jul 2011 22:38:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90CF1CC0-75A0-42FC-ADCA-57A25FD5DAC4@iki.fi> To: Pasi Sarolahti X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-tls-dtls-heartbeat@tools.ietf.org, tsv-ads@tools.ietf.org, tls@ietf.org, tsv-dir@ietf.org Subject: Re: [TLS] tsv-dir review of draft-ietf-tls-dtls-heartbeat-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: Sat, 09 Jul 2011 20:38:29 -0000 Hi Pasi, thank you very much for the review. Please see my comments in-line. Best regards Michael On Mar 22, 2011, at 10:01 AM, Pasi Sarolahti wrote: > Hi, >=20 > I've reviewed this document as part of the transport area = directorate's ongoing effort to review key IETF documents. These = comments were written primarily for the transport area directors, but = are copied to the document's authors for their information and to allow = them to address any issues raised. Please always CC tsv-dir@ietf.org if = you reply to or forward this review. >=20 >=20 > Path MTU discovery: >=20 > There should be more about how PMTUD is done than the one sentence in = the Intro, probably somewhere near section 4 (about when to send the = padded packets, how to set the DF bit in HeartbeatRequest packets with = padding, probably also mentioning about handling the possibly resulting = ICMP, etc.). You could also refer to the appropriate section in the main = DTLS spec. I don't think this spec should specify how PMTU discovery should be performed, since this is described in RFC 4821 in detail. The HB mechanism just provides the probe packets. However, this should be described in a better place than just the = introduction. So I have added a section "5 Use cases" which contains a subsection "5.1 = PMTU Discovery" and "5.2 Liveliness check":
DTLS performs path MTU discovery as described in Section 4.1.1.1 of . A detailed description how to perform path MTU discovery is given in . The necessary probe packets are the HeartbeatRequest messages. This method using HeartbeatRequest messages for DTLS is similar to the one for the Stream Control Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) defined in .
Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive. Even in case of TLS/TCP this allows this check at a much higher rate than the TCP keepalive feature would allow. Besides making sure that the peer is still reachable, sending HeartbeatRequest messages refreshes the NAT state of all involved NATs. HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round trip times long.
>=20 >=20 > Reliability & congestion control: >=20 > Using DTLS' simple timeout scheme seems ok here (but it would be = additional help for the reader to give exact reference, e.g., [RFC 4347, = Section 4.2.4]) The reference has been added. >=20 > With TLS there shouldn't be any congestion control issues, but you = might want to discuss the relationship of this mechanism and TCP's = keepalive messages. Is TCP's mechanism sufficient, and if not, why not? I added text for this in section 5.2. >=20 > If DTLS is used over a congestion controlled transport protocol, there = shouldn't be any issues for congestion control. >=20 > Also DTLS/UDP seems ok from congestion control viewpoint, because the = document allows at most one HeartbeatRequest message to be in flight at = a (round-trip) time, and for unacknowledged Heartbeats it mandates the = use of the timeout algorithm that applies exponential backoff. (You = might want to use an extra sentence mentioning that for these reasons = the scheme handles congestion control appropriately) OK. I added: The retransmission scheme in combination with the restriction that only one HeartbeatRequest is allowed to be in flight ensures that the congestion control is handled appropriately in case of the transport protocol not providing one, like in the case of DTLS over = UDP. >=20 > For clarity, the document could say a bit more about when the = HeartbeatRequest is in flight, for example: > "There MUST NOT be more than one HeartbeatRequest message in flight = at > a time." > =3D=3D> > "There MUST NOT be more than one HeartbeatRequest message in flight = at > a time. HeartbeatRequest message is considered to be in flight until > HeartbeatResponse is received, or until the retransmit timer = expires" Added. Thanks. >=20 > I think an additional guideline about how often to send keepalive = packets would be useful. The intent hardly is to send a heartbeat every = round-trip time, even if that is given as the upper bound, right? = Perhaps something like: >=20 > * SHOULD only be sent after an idle period (that is at least multiple = RTTs long), AND >=20 > * MUST NOT be sent if there are pending unacknowledged data in flight. = (If the HeartbeatRequest is the only message type expected to generate = response, this would just restate what was already said above. But if = there are also other packets waiting to be replied, then this might be = useful clarification.) Added to the text in section 5.2 >=20 > - Pasi >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From internet-drafts@ietf.org Mon Jul 11 02:34:11 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE91D21F89FA; Mon, 11 Jul 2011 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCJ+XZ8Qp7Iw; Mon, 11 Jul 2011 02:34:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A14A21F8995; Mon, 11 Jul 2011 02:34:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711093411.18294.295.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 02:34:11 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-dtls-heartbeat-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 09:34:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : Transport Layer Security (TLS) and Datagram Transport La= yer Security (DTLS) Heartbeat Extension Author(s) : Robin Seggelmann Michael Tuexen Michael Williams Filename : draft-ietf-tls-dtls-heartbeat-02.txt Pages : 9 Date : 2011-07-11 This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path maximum transmission unit (PMTU) discovery for DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-02.txt From iesg-secretary@ietf.org Fri Jul 15 06:20:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDEC21F865D; Fri, 15 Jul 2011 06:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrsZefzekM9Y; Fri, 15 Jul 2011 06:20:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668521F865F; Fri, 15 Jul 2011 06:20:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110715132035.7594.9543.idtracker@ietfa.amsl.com> Date: Fri, 15 Jul 2011 06:20:35 -0700 Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Datagram Transport Layer Security version 1.2' to Proposed Standard (draft-ietf-tls-rfc4347-bis-06.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2011 13:20:36 -0000 The IESG has approved the following document: - 'Datagram Transport Layer Security version 1.2' (draft-ietf-tls-rfc4347-bis-06.txt) as a Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4347-bis/ Technical Summary This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. Working Group Summary This document has been extensively reviewed int he working group. There is strong consensus to move the document forward. The document completed working group last call last year, but was delayed during the discussion of other higher priority documents. Document Quality There are several vendors who implement DTLS 1.1. Vendors have indicated they would support DTLS 1.2 to take advantage of AEAD cipher suites. The document has ve reviewed by security and transport experts. The document has been reviewed by implementers. Personnel Joe Salowey is the Document Shepherd. Sean Turner is the Responsible Area Director. From gswaru@rediffmail.com Mon Jul 18 00:54:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5921F8B5E for ; Mon, 18 Jul 2011 00:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.715 X-Spam-Level: *** X-Spam-Status: No, score=3.715 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_50=0.001, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MANGLED_YOUR=2.3, SARE_SUB_ENC_UTF8=0.152, SARE_SUB_OBFU_Q0=0.303, SARE_SUB_OBFU_Q1=0.227, UNPARSEABLE_RELAY=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 FFoWn9YRlraW for ; Mon, 18 Jul 2011 00:54:33 -0700 (PDT) Received: from rediffmail.com (f4mail-235-120.rediffmail.com [202.137.235.120]) by ietfa.amsl.com (Postfix) with SMTP id 69E6621F8B4D for ; Mon, 18 Jul 2011 00:54:31 -0700 (PDT) Received: (qmail 46687 invoked by uid 510); 18 Jul 2011 07:54:27 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=BwjPcGU9284Tp57AtvIzUrVnLAskm4EwIyYfNuyCiILIhTOsE1YniWyghEn2g9EDAQeADPC/ONym+t4SUiouC41x2B+iY7cEO/HcJM7k86yl0XZtLAZo/1vaWIlc8OtA5zzdykAAqf58/D1AfxQzUIrmzuEiRwKy9DMmClBo7AE= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: CTASD-ERR-Rsp X-CTCH-VOD: CTASD-ERR-Rsp X-CTCH-Flags: CTASD-ERR-Rsp X-CTCH-RefID: CTASD-ERR-Rsp Date: 18 Jul 2011 07:54:27 -0000 MIME-Version: 1.0 To: "tls@ietfa.amsl.com" Received: from unknown 115.242.204.34 by rediffmail.com via HTTP; 18 Jul 2011 07:54:26 -0000 Message-ID: <1310970973.S.3019.13738.F.H.TnRsc0BpZXRmYS5hbXNsLmNvbQBDb25maXJtOiB0bHNAaWV0ZmEuYW1zbC5jb206OVZGUk9LVGlQUW1BOlk_.f4-235-127.old.1310975666.37329@webmail.rediffmail.com> Sender: gswaru@rediffmail.com From: gswaru@rediffmail.com Content-Type: multipart/alternative; boundary="=_2855839a6c4fd9d322e7896c1263b768" Subject: Re: [TLS] =?utf-8?q?Confirm=3A_tls=40ietfa=2Eamsl=2Ecom=3A9VFROKTiPQm?= =?utf-8?q?A=3AYEPD4fRxw3gfL0HXLKroenvSsVNfG1x9YHOaPw?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gswaru@rediffmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 07:54:37 -0000 --=_2855839a6c4fd9d322e7896c1263b768 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" From: tls@ietfa.amsl.comSent: Mon, 18 Jul 2011 12:06:13 +0530To: gswaru@rediffmail.comSubject: Confirm: tls@ietfa.amsl.com:9VFROKTiPQmA:YEPD4fRxw3gfL0HXLKroenvSsVNfG1x9YHOaPw>Confirmation of list posting -- confirmation ID: 9VFROKTiPQmA>>The ietf.org mailing-list server has received a list posting from >gswaru@rediffmail.com to tls@ietfa.amsl.com with the subject >'=?utf-8?B?UmU6IENvbmZpcm06IHRsc0BpZXRmYS5hbXNsLmNvbTpqQ1pHaUFUaVBDV0E6Y2dzY1Z4VFZiTkwyR3kxRV9TeWl5TXlwUC15ak0xR3E2V3duSXc=?='>>As the sender address isn't subscribed to the list, and has not been>confirmed earlier, we have to request a confirmation of the address.>To confirm the address, send a message to tls@ietfa.amsl.com,>with the same subject line as this message.>>(Simply sending a 'reply' to this message should work from most email>interfaces, since that usually leaves the subject line in the right>form. The reply's additional "Re:" is ok.)>>If you do not wish y our posting to the list to go through, simply>disregard this message. Questions to postmaster@ietf.org.>> --=_2855839a6c4fd9d322e7896c1263b768 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"




From: tls@ietfa.amsl.com
Sent: Mon, 1= 8 Jul 2011 12:06:13 +0530
To: gswaru@rediffmail.com
Subject: Confirm:= tls@ietfa.amsl.com:9VFROKTiPQmA:YEPD4fRxw3gfL0HXLKroenvSsVNfG1x9YHOaPw
=

>Confirmation of list posting -- confirmation ID: 9VFROKTiPQmA>
>The ietf.org mailing-list ser= ver has received a list posting from
>gswaru@rediffmail.com to tls@ietfa.ams= l.com with the subject
>'=3D?utf-8?B?UmU6IENvbmZpcm06IHRsc0BpZXR= mYS5hbXNsLmNvbTpqQ1pHaUFUaVBDV0E6Y2dzY1Z4VFZiTkwyR3kxRV9TeWl5TXlwUC15ak0xR3= E2V3duSXc=3D?=3D'
>
>As the sender address isn't subscribed to = the list, and has not been
>confirmed earlier, we have to request a c= onfirmation of the address.
>To confirm the address, send a message t= o tls@ie= tfa.amsl.com,
>with the same subject line as this message.
>= ;
>(Simply sending a 'reply' to this message should work from most em= ail
>interfaces, since that usually leaves the subject line in the ri= ght
>form. The reply's additional "Re:" is ok.)
>
>If you= do not wish your posting to the list to go through, simply
>disregar= d this message. Questions to postmaster@ietf.org.
>
>



Treat yourself at a restaurant, spa, resort and much mo= re with Rediff Deal ho jaye! --=_2855839a6c4fd9d322e7896c1263b768-- From gswaru@rediffmail.com Mon Jul 18 05:23:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F33021F8BA1 for ; Mon, 18 Jul 2011 05:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.263 X-Spam-Level: *** X-Spam-Status: No, score=3.263 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_50=0.001, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, J_CHICKENPOX_65=0.6, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=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 H-fRuKe+8mih for ; Mon, 18 Jul 2011 05:23:04 -0700 (PDT) Received: from rediffmail.com (f4mail-235-121.rediffmail.com [202.137.235.121]) by ietfa.amsl.com (Postfix) with SMTP id F1F9C21F8686 for ; Mon, 18 Jul 2011 05:23:03 -0700 (PDT) Received: (qmail 9005 invoked by uid 510); 18 Jul 2011 12:22:59 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=M01PS7uAz27toRU4A+Ay/f5CpDYGBA7f7lt6wow/xaPzO4LtNgZxbnD30qZQTW4GCy1vp1OJafDgr/kPIvGvqODj8DhaC8TW0bzBnEmBnfblyoG71sRE7HY6UI9QMdKT0tLsdu5v11LZRcS6RFjJXpYEw6WGSlFuplxF1SmY/Tg= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: CTASD-ERR-Rsp X-CTCH-VOD: CTASD-ERR-Rsp X-CTCH-Flags: CTASD-ERR-Rsp X-CTCH-RefID: CTASD-ERR-Rsp Date: 18 Jul 2011 12:22:59 -0000 Message-ID: <20110718122259.8995.qmail@f4mail-235-121.rediffmail.com> MIME-Version: 1.0 To: "tls " Received: from unknown 115.252.157.156 by rediffmail.com via HTTP; 18 Jul 2011 12:22:59 -0000 Sender: gswaru@rediffmail.com From: gswaru@rediffmail.com Content-Type: multipart/alternative; boundary="=_2f247820b0f58a8402c34f75cb15e683" Subject: [TLS] =?utf-8?q?TLS_Next_Proto_negotiation?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gswaru@rediffmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 12:23:09 -0000 --=_2f247820b0f58a8402c34f75cb15e683 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, I have gone the TLS NPN draft, it talks about the new handshake message Next Protocol handshake message which is sent from Client to server after Change cipher spec and before Finish. But when I capture the packet with NPN enable(using google chrome to browse google web services), I find NULL NPN extnesion is sent from client to server and server is responding back with NPN extension with the protocol. But there is no next protocol handshake message sent by client after change cipher spec, instead I see a strange encrypted packet from Server side even before server is sending change cipher spec, this is on new session.   Can some one help me on understanding the next protocol handshake message, the format and other details, of whether it is encrypted/decrypted. or provide me a packet cpature with has these details.   Thanks and Regards, Swarupa --=_2f247820b0f58a8402c34f75cb15e683 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
Hi,
I have gone the TLS NPN draft, it talks about the new handshake messag= e Next Protocol handshake message which is sent from Client to server after= Change cipher spec and before Finish. But when I capture the packet with N= PN enable(using google chrome to browse google web services), I find NULL N= PN extnesion is sent from client to server and server is responding back wi= th NPN extension with the protocol. But there is no next protocol handshake= message sent by client after change cipher spec, instead I see a strange e= ncrypted packet from Server side even before server is sending change ciphe= r spec, this is on new session.
 
Can some one help me on understanding the next protocol handshake mess= age, the format and other details, of whether it is encrypted/decrypted. or= provide me a packet cpature with has these details.
 
Thanks and Regards,
Swarupa



Treat yourself at a restaur= ant, spa, resort and much more with Re= diff Deal ho jaye! --=_2f247820b0f58a8402c34f75cb15e683-- From agl@google.com Mon Jul 18 05:43:36 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9ACF21F8BE8 for ; Mon, 18 Jul 2011 05:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4, 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 CXrbG8xOCRc9 for ; Mon, 18 Jul 2011 05:43:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1A93421F8BEA for ; Mon, 18 Jul 2011 05:43:35 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p6IChYOo012500 for ; Mon, 18 Jul 2011 05:43:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310993014; bh=wayzFTIOF1p8sRMWpnZMonb+V0s=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=dH+E90IOntZpk/s03S0X/A/jirHORCJJCu+Bvv4K6bTkb3M3Z3vHXo3wH8s2tty6j My0N1OPSaumsoq0LLxtsA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=ax+LVUhkYgyalH8uuG4T87550no5XRk+vA+XzuVhz1ayGehsGj3LHH9SL8q79C92A KViSKm3VB9Lbt3rfdxrLw== Received: from ywb6 (ywb6.prod.google.com [10.192.2.6]) by kpbe20.cbf.corp.google.com with ESMTP id p6IChW8P007792 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Jul 2011 05:43:33 -0700 Received: by ywb6 with SMTP id 6so2282759ywb.1 for ; Mon, 18 Jul 2011 05:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=opdAfPRHnWeoPIsLQB6H3jPM/lCnuW9tdEI2HQRDftU=; b=GmJpR1yq7NB20gXACQko4bR0OuHqQl/KAwhT0O+wczC6xVVPwPrHEOLvVeLougRx8x 0YwzdS9N+O5RVjZbcPcg== MIME-Version: 1.0 Received: by 10.150.67.17 with SMTP id p17mr875869yba.29.1310993011128; Mon, 18 Jul 2011 05:43:31 -0700 (PDT) Received: by 10.150.196.12 with HTTP; Mon, 18 Jul 2011 05:43:30 -0700 (PDT) In-Reply-To: <20110718122259.8995.qmail@f4mail-235-121.rediffmail.com> References: <20110718122259.8995.qmail@f4mail-235-121.rediffmail.com> Date: Mon, 18 Jul 2011 08:43:30 -0400 Message-ID: From: Adam Langley To: gswaru@rediffmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls Subject: Re: [TLS] TLS Next Proto negotiation 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, 18 Jul 2011 12:43:37 -0000 On Mon, Jul 18, 2011 at 8:22 AM, wrote: > I have gone the TLS NPN draft, it talks about the new handshake message N= ext Protocol handshake message which is sent from Client to server after Ch= ange cipher spec and before Finish. But when I capture the packet with NPN = enable(using google chrome to browse google web services), I find NULL NPN = extnesion is sent from client to server and server is responding back with = NPN extension with the protocol. But there is no next protocol handshake me= ssage sent by client after change cipher spec, instead I see a strange encr= ypted packet from Server side even before server is sending change cipher s= pec, this is on new session. Make sure that you're looking at the draft which reflects the current implementation: http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02 The strange, encrypted message from the server is probably a session ticket. Wireshark, at least in some versions, doesn't understand it and incorrectly describes it as encrypted. If the NPN extension exchange happened then the NextProtocol message will be sent. Again, Wireshark doesn't dissect it very well and may believe that it was merged into the Finished message; you'll have to look at the bytes yourself. In the particular Chrome implementation, the NextProtocol message is sent in its own record, so you can see the framing without having to decrypt anything. Cheers AGL From agl@google.com Mon Jul 18 06:46:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC3221F8BB1 for ; Mon, 18 Jul 2011 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 5BT053swv-Py for ; Mon, 18 Jul 2011 06:46:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0472021F8BAF for ; Mon, 18 Jul 2011 06:46:45 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p6IDkiR8003990 for ; Mon, 18 Jul 2011 06:46:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310996805; bh=j45FY/UvMHTEqmUZy30ofIJ8Xww=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=jvEkLTbXgClAhfymBVsn4mAFko51TwoHOrvs6H7cfDFjZyQiQ0Zq+kx0Juf8OgvHU hAZZ0llit3c+sIlt+CXNg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=irehKL/hDCl9pRdFlmzq/+EqRY/5ZkM0KF4q8pyGLKYyWJMR2qcR6Gx4SdH/n0Qs7 EbLO0UMn9R/cykZaPHKew== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by hpaq6.eem.corp.google.com with ESMTP id p6IDkATI015846 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 18 Jul 2011 06:46:43 -0700 Received: by gwaa12 with SMTP id a12so1266616gwa.28 for ; Mon, 18 Jul 2011 06:46:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aPIOCsaajTPvD/aduFrd6/XTw6KXnf66iZBI6yfrYEM=; b=YrnkWg2nG1IJCvNx2bXx1jhYJ6SnlbUzE8x7x3VA6XxThHfqpBDjhreqkIr6DOvkkp y5C5Gnyb9fSmEHdPeX8A== MIME-Version: 1.0 Received: by 10.151.117.17 with SMTP id u17mr1097610ybm.143.1310996802151; Mon, 18 Jul 2011 06:46:42 -0700 (PDT) Received: by 10.150.196.12 with HTTP; Mon, 18 Jul 2011 06:46:42 -0700 (PDT) In-Reply-To: <1310993062.S.6925.17374.F.H.TkFkYW0gTGFuZ2xleQBSZTogW1RMU10gVExTIE5leHQgUHJvdG8gbmVnb3RpYXRpb24_.f4-235-196.old.1310996335.33728@webmail.rediffmail.com> References: <1310993062.S.6925.17374.F.H.TkFkYW0gTGFuZ2xleQBSZTogW1RMU10gVExTIE5leHQgUHJvdG8gbmVnb3RpYXRpb24_.f4-235-196.old.1310996335.33728@webmail.rediffmail.com> Date: Mon, 18 Jul 2011 09:46:42 -0400 Message-ID: From: Adam Langley To: gswaru@rediffmail.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls Subject: Re: [TLS] TLS Next Proto negotiation 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, 18 Jul 2011 13:46:46 -0000 On Mon, Jul 18, 2011 at 9:38 AM, wrote: > I thought http://tools.ietf.org/id/draft-agl-tls-nextproto-00.txt=C2=A0is= the latest draft, the date is may 14 2011 which is latest than the draft y= ou specified. It is the latest draft, but it doesn't reflect the implementation. > And also find attached the capture where I dont find the Next Protocol me= ssage, google chrome being used here. See packet 56 in that trace. There's an encrypted handshake record after the ChangeCipherSpec. It's 72 bytes long, which is too large for just the Finished message, but it's the correct size for the NextProtocol + Finished messages. (It appears that I was wrong when I said that the NextProtocol message gets its own record; maybe I fixed that.) Cheers AGL From jsalowey@cisco.com Tue Jul 19 13:27:06 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D622521F8B16 for ; Tue, 19 Jul 2011 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=-3.333, 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 kdd-+IXHW8u8 for ; Tue, 19 Jul 2011 13:27:03 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E497221F8B17 for ; Tue, 19 Jul 2011 13:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=662; q=dns/txt; s=iport; t=1311107223; x=1312316823; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=lPS2w7D60Eefo41flhdzquHRHX0PmIQGACqnrjSmaH0=; b=So8CEJSKJ/ZxPQmGc/GUIaIG10DxQyVVPsAnJk4AoSSUFMJI2kXP5Omc U0/kUU8Q8d+rrtMYcFT1v0D2X0/Wu5v5GjeksIWHQH9lA1IRhu7bpRgsu PS8c21vbruZe9n6OzEjjp9PkelVsyTOptMue7rkyJUmFrX7oQsQPWCs9k c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8HAIHnJU6rRDoJ/2dsb2JhbABUmE+PAnesYIEjnkmFXV8Eh1SLE4UEi3Y X-IronPort-AV: E=Sophos;i="4.67,230,1309737600"; d="scan'208";a="4482383" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 19 Jul 2011 20:27:02 +0000 Received: from [10.33.251.182] ([10.33.251.182]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6JKR1DT012924 for ; Tue, 19 Jul 2011 20:27:01 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 19 Jul 2011 13:27:23 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Agenda for TLS meeting at IETF 81 is posted 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, 19 Jul 2011 20:27:06 -0000 Below is the current agenda for the TLS meeting in Quebec City. TLS Working Group Agenda IETF 81 Thursday, July 28 1520-1720 --------------------------------------- 1. Administrivia (5 min) Note takes, blue sheets, Note Well, Agenda 2. DTLS Heartbeat (10 Min) - Tuexen draft-ietf-tls-dtls-heartbeat-02 3. Working Group Handling for Extensions to TLS (45 min) - Chairs 4. TLS Origin-Bound Certificates (15 min) - Balfranz http://balfanz.github.com/tls-obc-spec/draft-balfanz-tls-obc-00.txt 5. TLS Extension for out-of-band public key validation (10 min) - Wouters draft-wouters-tls-oob-pubkey-00 6. DNSSEC-stapling (15 min) - Hoffman From Masanobu.Katagi@jp.sony.com Wed Jul 20 03:37:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9557621F86D7 for ; Wed, 20 Jul 2011 03:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.294 X-Spam-Level: X-Spam-Status: No, score=-0.294 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta4CvNCo6-XF for ; Wed, 20 Jul 2011 03:37:25 -0700 (PDT) Received: from ms5.sony.co.jp (ms5.sony.co.jp [IPv6:2001:cf8:0:56::201]) by ietfa.amsl.com (Postfix) with ESMTP id 14EE521F84CA for ; Wed, 20 Jul 2011 03:37:23 -0700 (PDT) Received: from mta5.sony.co.jp (mta5.sony.co.jp [IPv6:2001:cf8:0:191::6]) by ms5.sony.co.jp (R8/Sony) with ESMTP id p6KAbKxw010398 for ; Wed, 20 Jul 2011 19:37:20 +0900 (JST) Received: from mta5.sony.co.jp (localhost [127.0.0.1]) by mta5.sony.co.jp (R8/Sony) with ESMTP id p6KAbJDx028316 for ; Wed, 20 Jul 2011 19:37:19 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta5.sony.co.jp (R8/Sony) with ESMTP id p6KAbJ5Z028248 for ; Wed, 20 Jul 2011 19:37:19 +0900 (JST) Received: from jptkyxim102.jp.sony.com ([43.15.31.6]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 19:37:10 +0900 Received: from [43.11.214.84] ([43.11.214.84]) by jptkyxim102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 19:37:10 +0900 Date: Wed, 20 Jul 2011 19:38:45 +0900 From: Masanobu Katagi To: "tls@ietf.org" In-Reply-To: <20110705093341.940B.1C812BE2@jp.sony.com> References: <20110705093341.940B.1C812BE2@jp.sony.com> Message-Id: <20110720193845.B694.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 20 Jul 2011 10:37:10.0136 (UTC) FILETIME=[FAC28F80:01CC46C8] Cc: shiho.moriai@jp.sony.com Subject: Re: [TLS] New Version Notification for draft-katagi-tls-clefia-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:37:25 -0000 Hi all, Thank you for valuable comments on our proposal of CLEFIA ciphersuites: http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt. In our draft above, we proposed a lot of combinations with SHA-1. In response to the comments from the TLS working group, we would like to remove the following sets of SHA-1 based ciphersuites: - All combinations involving CLEFIA_256 (from viewpoint of equivalent security to SHA-1) - Combinations involving not commonly used public key primitives Our updated proposal of SHA-1 based ciphersuites is as follows. CipherSuite TLS_RSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_DHE_DSS_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_DHE_RSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_DH_anon_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_ECDHE_ECDSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_ECDHE_RSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_PSK_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; CipherSuite TLS_DHE_PSK_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; We are going to update this change in the next version of our draft. Best regards, Masanobu Katagi Sony Corporation On Tue, 5 Jul 2011 09:33:42 +0900 "Katagi, Masanobu" wrote: > Dear all, > > We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS. > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt > > CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products. > The algorithm of CLEFIA was published as RFC6114 in March 2011. > CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. > We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm. > > The security and performance of CLEFIA have been evaluated through the CRYPTREC project > which evaluates and monitors the security of Japan e-Government recommended ciphers. > It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, Lightweight cryptography) and it's > in the Final Draft International Standard. > > Any comments on this draft would be appreciated. > > Best regards, > Masanobu Katagi > Sony Corporation > > Forwarded by Masanobu Katagi > ----------------------- Original Message ----------------------- > From: "internet-drafts@ietf.org" > To: "Katagi, Masanobu" > Cc: "Katagi, Masanobu" , > "Moriai, Shiho" > Date: Mon, 4 Jul 2011 17:51:44 +0900 > Subject: New Version Notification for draft-katagi-tls-clefia-00.txt > ---- > > A new version of I-D, draft-katagi-tls-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository. > > Filename: draft-katagi-tls-clefia > Revision: 00 > Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) > Creation date: 2011-07-04 > WG ID: Individual Submission > Number of pages: 16 > > Abstract: > This document specifies a set of cipher suites for the Transport > Security Layer (TLS) protocol to support the CLEFIA encryption > algorithm as a block cipher. CLEFIA is a lightweight block cipher > and suitable for constrained devices. > > > > > The IETF Secretariat > > > --------------------- Original Message Ends -------------------- > > From wwwrun@rfc-editor.org Tue Jul 19 02:17:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB97121F86D7 for ; Tue, 19 Jul 2011 02:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, NO_RELAYS=-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 yQdX7xAHYhzJ for ; Tue, 19 Jul 2011 02:17:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E121F86BB for ; Tue, 19 Jul 2011 02:17:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1765898C4EF; Tue, 19 Jul 2011 02:17:40 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20110719091740.1765898C4EF@rfc-editor.org> Date: Tue, 19 Jul 2011 02:17:40 -0700 (PDT) X-Mailman-Approved-At: Thu, 21 Jul 2011 09:56:16 -0700 Cc: rfc-editor@rfc-editor.org, alfredo.pironti@inria.fr, tls@ietf.org Subject: [TLS] [Technical Errata Reported] RFC5246 (2864) 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, 19 Jul 2011 09:17:44 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2864 -------------------------------------- Type: Technical Reported by: Alfredo Pironti Section: A.4.2 Original Text ------------- struct { ClientCertificateType certificate_types<1..2^8-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; --- Fixed by errata 1585 to struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; Corrected Text -------------- struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<2..2^16-2>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; Notes ----- The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Tue Jul 19 02:20:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7138121F876A for ; Tue, 19 Jul 2011 02:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, NO_RELAYS=-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 t7URPPr0lzpA for ; Tue, 19 Jul 2011 02:19:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 180EC21F8764 for ; Tue, 19 Jul 2011 02:19:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F39B598C4EF; Tue, 19 Jul 2011 02:19:57 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20110719091957.F39B598C4EF@rfc-editor.org> Date: Tue, 19 Jul 2011 02:19:57 -0700 (PDT) X-Mailman-Approved-At: Thu, 21 Jul 2011 09:56:16 -0700 Cc: rfc-editor@rfc-editor.org, alfredo.pironti@inria.fr, tls@ietf.org Subject: [TLS] [Technical Errata Reported] RFC5246 (2865) 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, 19 Jul 2011 09:20:02 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=2865 -------------------------------------- Type: Technical Reported by: Alfredo Pironti Section: 7.4.4 Original Text ------------- struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; Corrected Text -------------- struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<2..2^16-2>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; Notes ----- The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From marsh@extendedsubset.com Thu Jul 21 15:06:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9C921F8579 for ; Thu, 21 Jul 2011 15:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEv+r5Rq6tF1 for ; Thu, 21 Jul 2011 15:06:23 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 17D4021F8576 for ; Thu, 21 Jul 2011 15:06:23 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Qk1Nu-000GKU-Lj; Thu, 21 Jul 2011 22:06:22 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 293EC6073; Thu, 21 Jul 2011 22:06:21 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX184VltCkkMv40a8478i96BoATtilY5fdB4= Message-ID: <4E28A2D5.6000907@extendedsubset.com> Date: Thu, 21 Jul 2011 17:06:13 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Adam Langley References: <20110718122259.8995.qmail@f4mail-235-121.rediffmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls Subject: Re: [TLS] TLS Next Proto negotiation 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, 21 Jul 2011 22:06:23 -0000 On 07/18/2011 07:43 AM, Adam Langley wrote: > > http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-02 The server needs to see the client's NextProtocol message to know what protocol will be in use. But when a session is resumed, the server sends the Finished message before the client. Some app protocols have the server send the first application data, e.g., "username: ". If such an app protocol is a possibility, doesn't the use of NPN introduce an extra round-trip delay in case of session resumption? Also, since the semantics of NPN apply explicitly to the connection (rather than the session or connection state), perhaps the use of NPN ought to be contingent on the successful negotiation of RFC 5746 Renegotiation Indication. Multiplexing multiple protocols from same server port are likely to provide additional opportunities for an attacker to put the server in a state where it is willing to accept a renegotiating ClientHello. It will also provide more ways for an attacker to have the server echo back chosen plaintext to be interpreted as HTTP response headers (or other protocols could be attacked). - Marsh From agl@google.com Thu Jul 21 15:11:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E2B21F84DB for ; Thu, 21 Jul 2011 15:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.677 X-Spam-Level: X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 ZGIHsPy-1cEo for ; Thu, 21 Jul 2011 15:11:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6683E21F8509 for ; Thu, 21 Jul 2011 15:11:11 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p6LMB9RV027224 for ; Thu, 21 Jul 2011 15:11:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311286270; bh=X8wu2UrIJBQYGh4vWez2wNDIeq0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=MspaWg4ZUhp+BR1lJt61JVMN7zD8N+ivvr30GalXu2ezFNec78cDmi6JhOTbeDWLs bWE2QJk50UDohGoI6UWMA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=V8Bdb/1EFrAiXQ9gtHGstU3XMWYRCyzoQIpeoywa9IC1lhK9hjxosRrNJ7aA3mLDv 9Roq6cooHwotivntXiN1A== Received: from iyb14 (iyb14.prod.google.com [10.241.49.78]) by kpbe19.cbf.corp.google.com with ESMTP id p6LMB8IK016983 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 21 Jul 2011 15:11:08 -0700 Received: by iyb14 with SMTP id 14so1766068iyb.14 for ; Thu, 21 Jul 2011 15:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p64hnp32CzdqHKc2e74wJkBiHiHP6Ua7kCyQJE9juBo=; b=lSWVKwYAfzyTrp+JPDmTxW3eVE9s6rL0AQpaFLcsrxTM995q5fFJI8KoHnvBERb1Dg Lf4DBynIDNY6lhSKV6Wg== MIME-Version: 1.0 Received: by 10.231.114.86 with SMTP id d22mr655540ibq.45.1311286268175; Thu, 21 Jul 2011 15:11:08 -0700 (PDT) Received: by 10.231.17.2 with HTTP; Thu, 21 Jul 2011 15:11:08 -0700 (PDT) In-Reply-To: <4E28A2D5.6000907@extendedsubset.com> References: <20110718122259.8995.qmail@f4mail-235-121.rediffmail.com> <4E28A2D5.6000907@extendedsubset.com> Date: Thu, 21 Jul 2011 18:11:08 -0400 Message-ID: From: Adam Langley To: Marsh Ray Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: tls Subject: Re: [TLS] TLS Next Proto negotiation 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, 21 Jul 2011 22:11:15 -0000 On Thu, Jul 21, 2011 at 6:06 PM, Marsh Ray wrote: > The server needs to see the client's NextProtocol message to know what > protocol will be in use. But when a session is resumed, the server sends the > Finished message before the client. Some app protocols have the server send > the first application data, e.g., "username: ". If such an app protocol is a > possibility, doesn't the use of NPN introduce an extra round-trip delay in > case of session resumption? Yes, NPN precludes the possibility of a server-side False Start. > Also, since the semantics of NPN apply explicitly to the connection (rather > than the session or connection state), perhaps the use of NPN ought to be > contingent on the successful negotiation of RFC 5746 Renegotiation > Indication. Multiplexing multiple protocols from same server port are likely > to provide additional opportunities for an attacker to put the server in a > state where it is willing to accept a renegotiating ClientHello. It will > also provide more ways for an attacker to have the server echo back chosen > plaintext to be interpreted as HTTP response headers (or other protocols > could be attacked). That sounds quite sensible to me. I'm happy to include such a requirement. Cheers AGL From anders.rundgren@telia.com Mon Jul 25 05:07:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E7B21F84D4 for ; Mon, 25 Jul 2011 05:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 ypNcTn2IyI5J for ; Mon, 25 Jul 2011 05:07:15 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1691421F84D7 for ; Mon, 25 Jul 2011 05:07:11 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA034AD355 for tls@ietf.org; Mon, 25 Jul 2011 14:07:09 +0200 Message-ID: <4E2D5C63.3000408@telia.com> Date: Mon, 25 Jul 2011 14:06:59 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: tls@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 12:07:16 -0000 Hi Guys, I don't really know who "owns" this question but presumably you do... HTTPS client-certificate-authentication in browsers =================================================== I don't believe that TLS CCA (Client Certificate Authentication) in the form of HTTPS as implemented in current browsers has much of a future. In fact, quite a bunch of the entities in the EU working with consumer PKI have replaced HTTPS CCA with an application level scheme which wasn't such a big deal since they anyway were forced writing a browser PKI client more or less from scratch since the ones shipped with browsers doesn't support PKI as defined by banks and government (like mandatory PIN codes also for on-line enrolled keys). That the TLS CCA protocol doesn't even support "Logout" haven't made it a logical choice for web developers either. Well, there are some workarounds but they are by no means straightforward, supported out-of-the-box by server authentication schemes, and are (of course) entirely undocumented. The button "Clear SSL state" in MSIE is an indication how horribly bad it can go when security experts design systems for "people". There's no way you can hide the fact that TLS CCA is only truly useful securing tunnels between "boxes". Anders From henry.story@bblfish.net Mon Jul 25 05:32:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AEE21F88DD for ; Mon, 25 Jul 2011 05:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vua2M-kVeTXw for ; Mon, 25 Jul 2011 05:32:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7281921F88DC for ; Mon, 25 Jul 2011 05:32:00 -0700 (PDT) Received: by wyj26 with SMTP id 26so3145163wyj.31 for ; Mon, 25 Jul 2011 05:31:55 -0700 (PDT) Received: by 10.216.80.14 with SMTP id j14mr2244708wee.9.1311597115641; Mon, 25 Jul 2011 05:31:55 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id k9sm3376094weq.3.2011.07.25.05.31.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 05:31:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4E2D5C63.3000408@telia.com> Date: Mon, 25 Jul 2011 14:31:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2D5C63.3000408@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 12:32:02 -0000 Hi Anders, I kind of lurk here, but I don't think that client side CAs are impossible to get right in the browsers. They are pretty close to doing things right. Logout from the browsers would not be that = difficult to do. I kept thinking that the W3C project http://webid.info/ could = stimulate the improvement of these pieces. But I would be interested in feedback from this list on the subject. Henry On 25 Jul 2011, at 14:06, Anders Rundgren wrote: > Hi Guys, > I don't really know who "owns" this question but presumably you do... >=20 > HTTPS client-certificate-authentication in browsers > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > I don't believe that TLS CCA (Client Certificate Authentication) in = the > form of HTTPS as implemented in current browsers has much of a future. >=20 > In fact, quite a bunch of the entities in the EU working with consumer = PKI > have replaced HTTPS CCA with an application level scheme which wasn't = such > a big deal since they anyway were forced writing a browser PKI client = more > or less from scratch since the ones shipped with browsers doesn't = support > PKI as defined by banks and government (like mandatory PIN codes also > for on-line enrolled keys). >=20 > That the TLS CCA protocol doesn't even support "Logout" haven't made > it a logical choice for web developers either. Well, there are some > workarounds but they are by no means straightforward, supported > out-of-the-box by server authentication schemes, and are (of course) > entirely undocumented. >=20 > The button "Clear SSL state" in MSIE is an indication how horribly bad = it > can go when security experts design systems for "people". >=20 > There's no way you can hide the fact that TLS CCA is only truly useful > securing tunnels between "boxes". >=20 > Anders >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From anders.rundgren@telia.com Mon Jul 25 05:59:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2370A21F88E5 for ; Mon, 25 Jul 2011 05:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 0kKnVPJahqR6 for ; Mon, 25 Jul 2011 05:59:06 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 9989C21F8834 for ; Mon, 25 Jul 2011 05:59:06 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0079C13B; Mon, 25 Jul 2011 14:59:04 +0200 Message-ID: <4E2D688E.5030509@telia.com> Date: Mon, 25 Jul 2011 14:58:54 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Henry Story References: <4E2D5C63.3000408@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 12:59:08 -0000 On 2011-07-25 14:31, Henry Story wrote: > Hi Anders, I kind of lurk here, but I don't think that client side > CAs are impossible to get right in the browsers. They are pretty close > to doing things right. Logout from the browsers would not be that difficult > to do. I kept thinking that the W3C project http://webid.info/ could stimulate > the improvement of these pieces. > > But I would be interested in feedback from this list on the subject. Hi Henry, If there had been a *single* mainstream service of US origin who used HTTPS CCA this would be fixed in record time. The tenths of millions of users of "homegrown" PKI authentication schemes in the EU and Asia apparently don't think HTTPS CCA is particularly useful, neither do I. TLS' session context is incompatible with web sessions. For our mutual interest, PKI for consumers, it doesn't really matter what the end-solution will be, but an educated guess is that will not build on HTTPS CCA, but on HTTPS with + an application. This is BTW pretty much what has happened with HTTP auth versus form-based auth. Fortunately this can be introduced without redeploying PKI so it is a true "migration solution". Anders > > Henry > > On 25 Jul 2011, at 14:06, Anders Rundgren wrote: > >> Hi Guys, >> I don't really know who "owns" this question but presumably you do... >> >> HTTPS client-certificate-authentication in browsers >> =================================================== >> I don't believe that TLS CCA (Client Certificate Authentication) in the >> form of HTTPS as implemented in current browsers has much of a future. >> >> In fact, quite a bunch of the entities in the EU working with consumer PKI >> have replaced HTTPS CCA with an application level scheme which wasn't such >> a big deal since they anyway were forced writing a browser PKI client more >> or less from scratch since the ones shipped with browsers doesn't support >> PKI as defined by banks and government (like mandatory PIN codes also >> for on-line enrolled keys). >> >> That the TLS CCA protocol doesn't even support "Logout" haven't made >> it a logical choice for web developers either. Well, there are some >> workarounds but they are by no means straightforward, supported >> out-of-the-box by server authentication schemes, and are (of course) >> entirely undocumented. >> >> The button "Clear SSL state" in MSIE is an indication how horribly bad it >> can go when security experts design systems for "people". >> >> There's no way you can hide the fact that TLS CCA is only truly useful >> securing tunnels between "boxes". >> >> Anders >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > Social Web Architect > http://bblfish.net/ > > From henry.story@bblfish.net Mon Jul 25 06:05:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1305421F89BE for ; Mon, 25 Jul 2011 06:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 8ru4VVYDNOzN for ; Mon, 25 Jul 2011 06:05:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 152B721F89A7 for ; Mon, 25 Jul 2011 06:05:55 -0700 (PDT) Received: by wwe5 with SMTP id 5so2727858wwe.13 for ; Mon, 25 Jul 2011 06:05:55 -0700 (PDT) Received: by 10.216.38.77 with SMTP id z55mr3557822wea.105.1311599154657; Mon, 25 Jul 2011 06:05:54 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id l55sm2153829wed.41.2011.07.25.06.05.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 06:05:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <4E2D688E.5030509@telia.com> Date: Mon, 25 Jul 2011 15:05:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2D5C63.3000408@telia.com> <4E2D688E.5030509@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 13:05:57 -0000 On 25 Jul 2011, at 14:58, Anders Rundgren wrote: > On 2011-07-25 14:31, Henry Story wrote: >> Hi Anders, I kind of lurk here, but I don't think that client side >> CAs are impossible to get right in the browsers. They are pretty = close >> to doing things right. Logout from the browsers would not be that = difficult >> to do. I kept thinking that the W3C project http://webid.info/ could = stimulate >> the improvement of these pieces. >>=20 >> But I would be interested in feedback from this list on the subject. >=20 > Hi Henry, >=20 > If there had been a *single* mainstream service of US origin who used > HTTPS CCA this would be fixed in record time. What about the army? They are pretty big in the US, representing a huge = portion of the budget I believe. >=20 > The tenths of millions of users of "homegrown" PKI authentication = schemes > in the EU and Asia apparently don't think HTTPS CCA is particularly = useful, > neither do I. =20 I believe that is only because of the naming problem. Distinguished = Names of companies don't scale to the world. > TLS' session context is incompatible with web sessions. Why? A TLS Session can work very well with web sessions. You can=20 just make your TLS session be a web session. >=20 > For our mutual interest, PKI for consumers, it doesn't really matter = what > the end-solution will be, but an educated guess is that will not build > on HTTPS CCA, but on HTTPS with + an application. This is BTW pretty > much what has happened with HTTP auth versus form-based auth. yes, but there is no argument for why this is the case. And you don't=20 even consider http://webid.info/ >=20 > Fortunately this can be introduced without redeploying PKI so it is a > true "migration solution". IT's odd that people want to move away from something that is close to = working. I wonder why... What is the agenda? Henry >=20 > Anders >=20 >>=20 >> Henry >>=20 >> On 25 Jul 2011, at 14:06, Anders Rundgren wrote: >>=20 >>> Hi Guys, >>> I don't really know who "owns" this question but presumably you = do... >>>=20 >>> HTTPS client-certificate-authentication in browsers >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>> I don't believe that TLS CCA (Client Certificate Authentication) in = the >>> form of HTTPS as implemented in current browsers has much of a = future. >>>=20 >>> In fact, quite a bunch of the entities in the EU working with = consumer PKI >>> have replaced HTTPS CCA with an application level scheme which = wasn't such >>> a big deal since they anyway were forced writing a browser PKI = client more >>> or less from scratch since the ones shipped with browsers doesn't = support >>> PKI as defined by banks and government (like mandatory PIN codes = also >>> for on-line enrolled keys). >>>=20 >>> That the TLS CCA protocol doesn't even support "Logout" haven't made >>> it a logical choice for web developers either. Well, there are some >>> workarounds but they are by no means straightforward, supported >>> out-of-the-box by server authentication schemes, and are (of course) >>> entirely undocumented. >>>=20 >>> The button "Clear SSL state" in MSIE is an indication how horribly = bad it >>> can go when security experts design systems for "people". >>>=20 >>> There's no way you can hide the fact that TLS CCA is only truly = useful >>> securing tunnels between "boxes". >>>=20 >>> Anders >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >>=20 >=20 Social Web Architect http://bblfish.net/ From stpeter@stpeter.im Mon Jul 25 06:37:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7A421F8AF4 for ; Mon, 25 Jul 2011 06:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.132, 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 Up7R3jvuRbYs for ; Mon, 25 Jul 2011 06:37:09 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 03EAB21F86B9 for ; Mon, 25 Jul 2011 06:37:09 -0700 (PDT) Received: from squire.local (unknown [198.135.0.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C477411C7; Mon, 25 Jul 2011 07:38:04 -0600 (MDT) Message-ID: <4E2D7183.10009@stpeter.im> Date: Mon, 25 Jul 2011 09:37:07 -0400 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Anders Rundgren References: <4E2D5C63.3000408@telia.com> In-Reply-To: <4E2D5C63.3000408@telia.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 13:37:09 -0000 On 7/25/11 8:06 AM, Anders Rundgren wrote: > Hi Guys, > I don't really know who "owns" this question but presumably you do... I've forwarded your message to the http-auth@ietf.org list because folks there might also be interested. https://www.ietf.org/mailman/listinfo/http-auth Peter -- Peter Saint-Andre https://stpeter.im/ From anders.rundgren@telia.com Mon Jul 25 06:38:47 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F8C21F8B0C for ; Mon, 25 Jul 2011 06:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 Nb1RfIRxicDM for ; Mon, 25 Jul 2011 06:38:47 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id B81C821F8B15 for ; Mon, 25 Jul 2011 06:38:46 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00DAF446; Mon, 25 Jul 2011 15:38:45 +0200 Message-ID: <4E2D71DB.6020604@telia.com> Date: Mon, 25 Jul 2011 15:38:35 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Henry Story References: <4E2D5C63.3000408@telia.com> <4E2D688E.5030509@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 13:38:48 -0000 On 2011-07-25 15:05, Henry Story wrote: >> If there had been a *single* mainstream service of US origin who used >> HTTPS CCA this would be fixed in record time. > > What about the army? They are pretty big in the US, representing a huge portion > of the budget I believe. Yes, but the army has IT-staff that takes care of "issues", consumers do not. The army is also much less fuzzy about inconvenience. >> The tenths of millions of users of "homegrown" PKI authentication schemes >> in the EU and Asia apparently don't think HTTPS CCA is particularly useful, >> neither do I. > I believe that is only because of the naming problem. Distinguished Names of companies > don't scale to the world. There are actually several other problems that are much worse. On my wife's firefox the bank have deployed two certs and both of the show up when she is going to login. If she takes the one marked "non-repudiation" you get a security error that only experts understand. >> TLS' session context is incompatible with web sessions. > Why? A TLS Session can work very well with web sessions. You can > just make your TLS session be a web session. AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever on a TLS session. >> For our mutual interest, PKI for consumers, it doesn't really matter what >> the end-solution will be, but an educated guess is that will not build >> on HTTPS CCA, but on HTTPS with + an application. This is BTW pretty >> much what has happened with HTTP auth versus form-based auth. > > yes, but there is no argument for why this is the case. And you don't > even consider http://webid.info/ WebID isn't diminished by this. It just gets better :-) >> Fortunately this can be introduced without redeploying PKI so it is a >> true "migration solution". > IT's odd that people want to move away from something that is close to working. > I wonder why... What is the agenda? They have given up on this. "Close to working" isn't good enough. Anders > > > Henry >> >> Anders >> >>> >>> Henry >>> >>> On 25 Jul 2011, at 14:06, Anders Rundgren wrote: >>> >>>> Hi Guys, >>>> I don't really know who "owns" this question but presumably you do... >>>> >>>> HTTPS client-certificate-authentication in browsers >>>> =================================================== >>>> I don't believe that TLS CCA (Client Certificate Authentication) in the >>>> form of HTTPS as implemented in current browsers has much of a future. >>>> >>>> In fact, quite a bunch of the entities in the EU working with consumer PKI >>>> have replaced HTTPS CCA with an application level scheme which wasn't such >>>> a big deal since they anyway were forced writing a browser PKI client more >>>> or less from scratch since the ones shipped with browsers doesn't support >>>> PKI as defined by banks and government (like mandatory PIN codes also >>>> for on-line enrolled keys). >>>> >>>> That the TLS CCA protocol doesn't even support "Logout" haven't made >>>> it a logical choice for web developers either. Well, there are some >>>> workarounds but they are by no means straightforward, supported >>>> out-of-the-box by server authentication schemes, and are (of course) >>>> entirely undocumented. >>>> >>>> The button "Clear SSL state" in MSIE is an indication how horribly bad it >>>> can go when security experts design systems for "people". >>>> >>>> There's no way you can hide the fact that TLS CCA is only truly useful >>>> securing tunnels between "boxes". >>>> >>>> Anders >>>> >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> >>> Social Web Architect >>> http://bblfish.net/ >>> >>> >> > > Social Web Architect > http://bblfish.net/ > > From henry.story@bblfish.net Mon Jul 25 09:09:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866F121F8748 for ; Mon, 25 Jul 2011 09:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.014 X-Spam-Level: X-Spam-Status: No, score=-3.014 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 z6Fr+1Wew+lM for ; Mon, 25 Jul 2011 09:09:22 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C71B21F8754 for ; Mon, 25 Jul 2011 07:18:13 -0700 (PDT) Received: by wyj26 with SMTP id 26so3226511wyj.31 for ; Mon, 25 Jul 2011 07:18:12 -0700 (PDT) Received: by 10.217.6.194 with SMTP id y44mr544073wes.74.1311603492226; Mon, 25 Jul 2011 07:18:12 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id b13sm4360254wbh.41.2011.07.25.07.18.10 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 07:18:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <4E2D71DB.6020604@telia.com> Date: Mon, 25 Jul 2011 16:18:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E2D5C63.3000408@telia.com> <4E2D688E.5030509@telia.com> <4E2D71DB.6020604@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 16:09:23 -0000 On 25 Jul 2011, at 15:38, Anders Rundgren wrote: > On 2011-07-25 15:05, Henry Story wrote: >=20 >>> If there had been a *single* mainstream service of US origin who = used >>> HTTPS CCA this would be fixed in record time. >>=20 >> What about the army? They are pretty big in the US, representing a = huge portion >> of the budget I believe. >=20 > Yes, but the army has IT-staff that takes care of "issues", consumers > do not. The army is also much less fuzzy about inconvenience. Most of all the army have a huge namespace, so that one certificate can = do a lot of work. This proves that if one can grow the user of a = certificate the benefits will grow too. So the first issue to solve with certs is to make them useful across the whole internet. That then changes the = game. If you look at what Facebook connect is doing you will see how that = works. And it also proves that the attempt to be completely anonymous is not = what people are looking for. >=20 >>> The tenths of millions of users of "homegrown" PKI authentication = schemes >>> in the EU and Asia apparently don't think HTTPS CCA is particularly = useful, >>> neither do I. =20 >=20 >=20 >> I believe that is only because of the naming problem. Distinguished = Names of companies >> don't scale to the world. >=20 > There are actually several other problems that are much worse. > On my wife's firefox the bank have deployed two certs and > both of the show up when she is going to login. If she > takes the one marked "non-repudiation" you get a security > error that only experts understand. Firefox has the worst UI of all. Banks should set up incentives for people to move to more secure browsers. They also have enough money to pay for the changes directly. The bank should probably have signed those certificates with different distinguished names, then it could have asked for the right one. Does the bank also really have to throw such an ugly exception? Could it not be more intelligent in the web server on how that is processed? >=20 >=20 >>> TLS' session context is incompatible with web sessions. >=20 >> Why? A TLS Session can work very well with web sessions. You can=20 >> just make your TLS session be a web session. >=20 > AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever > on a TLS session. They are two different things. I think you cannot logout the client = from the server, though recently you pointed to some javascript that could = allow that. This may be something the server vendors need to work on. The question = first has to be asked: is this a necessary limitation, or is it just not = implemented well? >=20 >=20 >>> For our mutual interest, PKI for consumers, it doesn't really matter = what >>> the end-solution will be, but an educated guess is that will not = build >>> on HTTPS CCA, but on HTTPS with + an application. This is BTW = pretty >>> much what has happened with HTTP auth versus form-based auth. >>=20 >> yes, but there is no argument for why this is the case. And you don't=20= >> even consider http://webid.info/ >=20 > WebID isn't diminished by this. It just gets better :-) Well WebID type auth can be used in BrowserId, as I explained in detail=20= = http://security.stackexchange.com/questions/5406/what-are-the-main-advanta= ges-and-disadvantages-of-webid-compared-to-browserid/5424#5424 But TLS client certs have a very nice advantage is that they are very = efficient, and work in many other areas too, especially server to server. So other means are good, = but don't give up TLS - well improve it. >=20 >=20 >>> Fortunately this can be introduced without redeploying PKI so it is = a >>> true "migration solution". >=20 >> IT's odd that people want to move away from something that is close = to working. >> I wonder why... What is the agenda? >=20 > They have given up on this. > "Close to working" isn't good enough. I agree. They need to finish the job. But they won't do it unless it is = shown why it is useful. And there it just needs a few companies to make a good demo. Henry >=20 > Anders >=20 >>=20 >>=20 >> Henry >>>=20 >>> Anders >>>=20 >>>>=20 >>>> Henry >>>>=20 >>>> On 25 Jul 2011, at 14:06, Anders Rundgren wrote: >>>>=20 >>>>> Hi Guys, >>>>> I don't really know who "owns" this question but presumably you = do... >>>>>=20 >>>>> HTTPS client-certificate-authentication in browsers >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>>>> I don't believe that TLS CCA (Client Certificate Authentication) = in the >>>>> form of HTTPS as implemented in current browsers has much of a = future. >>>>>=20 >>>>> In fact, quite a bunch of the entities in the EU working with = consumer PKI >>>>> have replaced HTTPS CCA with an application level scheme which = wasn't such >>>>> a big deal since they anyway were forced writing a browser PKI = client more >>>>> or less from scratch since the ones shipped with browsers doesn't = support >>>>> PKI as defined by banks and government (like mandatory PIN codes = also >>>>> for on-line enrolled keys). >>>>>=20 >>>>> That the TLS CCA protocol doesn't even support "Logout" haven't = made >>>>> it a logical choice for web developers either. Well, there are = some >>>>> workarounds but they are by no means straightforward, supported >>>>> out-of-the-box by server authentication schemes, and are (of = course) >>>>> entirely undocumented. >>>>>=20 >>>>> The button "Clear SSL state" in MSIE is an indication how horribly = bad it >>>>> can go when security experts design systems for "people". >>>>>=20 >>>>> There's no way you can hide the fact that TLS CCA is only truly = useful >>>>> securing tunnels between "boxes". >>>>>=20 >>>>> Anders >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>> Social Web Architect >>>> http://bblfish.net/ >>>>=20 >>>>=20 >>>=20 >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >>=20 >=20 Social Web Architect http://bblfish.net/ From anders.rundgren@telia.com Mon Jul 25 09:11:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911FD11E80A4 for ; Mon, 25 Jul 2011 09:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 qMFQuAz8Cpdq for ; Mon, 25 Jul 2011 09:11:18 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id BED2521F8C30 for ; Mon, 25 Jul 2011 07:34:07 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA034B6E85; Mon, 25 Jul 2011 16:34:00 +0200 Message-ID: <4E2D7ECD.1040505@telia.com> Date: Mon, 25 Jul 2011 16:33:49 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E2D5C63.3000408@telia.com> <4E2D7183.10009@stpeter.im> In-Reply-To: <4E2D7183.10009@stpeter.im> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 16:11:20 -0000 On 2011-07-25 15:37, Peter Saint-Andre wrote: > On 7/25/11 8:06 AM, Anders Rundgren wrote: >> Hi Guys, >> I don't really know who "owns" this question but presumably you do... > > I've forwarded your message to the http-auth@ietf.org list because folks > there might also be interested. > > https://www.ietf.org/mailman/listinfo/http-auth Thanx Peter, I'm a bit of a skeptic when it comes to new or extended auth protocols based on the transport layer, for usage in browsers. It seems more flexible supplying meta-data at the app-level. "Web Programmers" do not really understand TLS and that is also a factor to consider. I agree that this may be "unclean" but HTTPS CCA has been neglected, and there are alternatives already in production that looks much "prettier". There is another issue that is related. In the EU web signing is fairly popular but not supported at all by for example Microsoft. Regards, Anders From anders.rundgren@telia.com Mon Jul 25 09:11:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B038111E8115 for ; Mon, 25 Jul 2011 09:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 vwVQW0M6pU4H for ; Mon, 25 Jul 2011 09:11:53 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7939421F8C8F for ; Mon, 25 Jul 2011 07:43:27 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA034B776B; Mon, 25 Jul 2011 16:43:26 +0200 Message-ID: <4E2D8104.3080309@telia.com> Date: Mon, 25 Jul 2011 16:43:16 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Henry Story References: <4E2D5C63.3000408@telia.com> <4E2D688E.5030509@telia.com> <4E2D71DB.6020604@telia.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 16:11:54 -0000 On 2011-07-25 16:18, Henry Story wrote: >>>> TLS' session context is incompatible with web sessions. >> >>> Why? A TLS Session can work very well with web sessions. You can >>> just make your TLS session be a web session. >> >> AFAIK HttpSession.invalidate in Tomcat/JBoss has no effect whatsoever >> on a TLS session. > > They are two different things. I think you cannot logout the client from > the server, though recently you pointed to some javascript that could allow that. I did but I also used a scheme where I had a login site on one port and the rest on another port. I found this working more by accident. It may be security-broken and browser-incompatible etc. > This may be something the server vendors need to work on. The question first has > to be asked: is this a necessary limitation, or is it just not implemented well? This may be above my knowledge but I think it is impossible to do this on the server only. Why? Otherwise it had already been done. Anders From paul@xelerance.com Mon Jul 25 09:15:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7316D21F8B6C for ; Mon, 25 Jul 2011 09:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 mc85O3YdeWGV for ; Mon, 25 Jul 2011 09:15:27 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id BD29821F8B83 for ; Mon, 25 Jul 2011 08:24:39 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id B200F57124; Mon, 25 Jul 2011 11:25:27 -0400 (EDT) Date: Mon, 25 Jul 2011 11:25:27 -0400 (EDT) From: Paul Wouters To: Anders Rundgren In-Reply-To: <4E2D5C63.3000408@telia.com> Message-ID: References: <4E2D5C63.3000408@telia.com> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 25 Jul 2011 16:15:27 -0000 On Mon, 25 Jul 2011, Anders Rundgren wrote: > I don't believe that TLS CCA (Client Certificate Authentication) in the > form of HTTPS as implemented in current browsers has much of a future. I have been thinking of a "SNI" for the client side, and then decoupling PKIX from the TLS auth to allow other forms of TLS server/client authentication: http://www.ietf.org/internet-drafts/draft-wouters-tls-oob-pubkey-00.txt I actually had the CNI as part of the draft first. I'll do a quick 10 minute talk on Thursday on this. A client name identifier would allow mutual identification with an authentication scheme picked by each end based on a qualifier. Paul From ekr@rtfm.com Mon Jul 25 10:19:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D100721F8BC5 for ; Mon, 25 Jul 2011 10:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRv13KGN07lD for ; Mon, 25 Jul 2011 10:19:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E498721F8BC3 for ; Mon, 25 Jul 2011 10:19:01 -0700 (PDT) Received: by wwe5 with SMTP id 5so2896720wwe.13 for ; Mon, 25 Jul 2011 10:19:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.32.136 with SMTP id c8mr4102341wbd.7.1311614340969; Mon, 25 Jul 2011 10:19:00 -0700 (PDT) Received: by 10.227.145.209 with HTTP; Mon, 25 Jul 2011 10:19:00 -0700 (PDT) Date: Mon, 25 Jul 2011 13:19:00 -0400 Message-ID: From: Eric Rescorla To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 17:19:02 -0000 This document describes a mechanism for allowing the client to indicate to the server that he has cached the server's TLS public key. The server then omits the key from the handshake and the client relies on the cached value. OVERALL Section 1.1 appears to describe two primary motivations for this extension: - It saves the cost of transmitting the certificate over the network to the client. - It potentially conflicts with other validation mechanisms which the client may have for checking the server cert. In support of these motivations it lists the following use cases (numbered by me): 1. The TLS server public key is obtained from a [PKIX] certificate chain from an [LDAP] server 2. The TLS server public key is obtained from a DNSSEC secured RRset using [DANE] 3. The TLS server public key is provisioned by the operating system and updated via software updates 4. A TLS client has connected to the TLS server before and has cached the TLS server certificate chain or TLS server public key for re- use The second motivation does not apply to use cases (1) and (4): The server's credentials are already phrased as PKIX credentials and client can validatte them however it wishes, the only need is for the server and client to assure themselves that they have the same set of validated credentials. Thus, the only issue here is bandwidth; the TLS WG already has a (dormant) work item on caching certificate messages, draft-ietf-tls-cached-info. That item is dormant due primarily to lack of energy. To the extent to which we are dealing with certs phrased as PKIX credentials, then energy should be applied to that document. The second motivation is more convincing for cases (2) and (3) [though in truth it is IMO still more likely that in case 3 the credential will be phrased as a cert.] However, it's not really that convincing to me: TLS stacks already have X.509 parsing, and pulling the public key out is a fairly straightforward task. I don't see any reason why it's troublesome to ignore the rest of the certificate; indeed this is a quite common practice when self-signed certs are in use. So, I don't see this as that troublesome. As above, the bandwidth issue can be dealt with by draft-ietf-tls-cached-info. In summary, I don't see a lot of use for this extension. However, if there is real demand for it, the right approach would be to resurrect draft-ietf-tls-cached-info and add a new cache type for the EE public key. OTHER COMMENTS What's the reason why you would want to send the server the SPKI instead of the hash? opaque SHA256Hash<32>; You probably want [32] here. From mrex@sap.com Mon Jul 25 16:51:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8AA21F86C2 for ; Mon, 25 Jul 2011 16:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.835 X-Spam-Level: X-Spam-Status: No, score=-9.835 tagged_above=-999 required=5 tests=[AWL=0.414, 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 7CinkjrOjYvC for ; Mon, 25 Jul 2011 16:51:45 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8808521F86CA for ; Mon, 25 Jul 2011 16:51:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6PNpheO007127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 01:51:43 +0200 (MEST) From: Martin Rex Message-Id: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Tue, 26 Jul 2011 01:51:43 +0200 (MEST) In-Reply-To: <4E2D5C63.3000408@telia.com> from "Anders Rundgren" at Jul 25, 11 02:06:59 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 23:51:46 -0000 Anders Rundgren wrote: > > I don't believe that TLS CCA (Client Certificate Authentication) in the > form of HTTPS as implemented in current browsers has much of a future. It works perfectly fine and we've been using it >10 years for all of our intranet (50.000 employees these days) web servers accessed via HTTPS, using TLS client certs for Single Sign-On. (similar to how Kerberos is used by others). > > In fact, quite a bunch of the entities in the EU working with consumer PKI > have replaced HTTPS CCA with an application level scheme which wasn't such > a big deal since they anyway were forced writing a browser PKI client more > or less from scratch since the ones shipped with browsers doesn't support > PKI as defined by banks and government (like mandatory PIN codes also > for on-line enrolled keys). I think you're confusing things. What you're looking at here is scenarios for individually authenticated transactions. That is an entirely different problem domain and not addressed by TLS at all. You would have to address that with a browser plugin that accesses a completely different PKI credential that has signature qualities, with a clearly defined protocol that describes what data gets signed, and which requires seperate per-transaction authorization for every signature operation. > > That the TLS CCA protocol doesn't even support "Logout" haven't made > it a logical choice for web developers either. Huh? I have no clue what you're talking about. If the server wants to perform a logout operation, it can delete the TLS session cache entry on the server. But the Single Sign-On capability of the TLS client cert means that as long as the client credential is still available to the TLS client, the client will perform "transparent" reauthentication. > > The button "Clear SSL state" in MSIE is an indication how horribly bad it > can go when security experts design systems for "people". Is your intention to get prompted again? >From a usability standpoint, we prefer the "select automatically" setting and spare our users the client certificate selection popup. > > There's no way you can hide the fact that TLS CCA is only truly useful > securing tunnels between "boxes". The purpose of the TLS CCA is the same as the purpose of Kerberos, to provide a non-disclosing Single Sign-On convenience. -Martin From henry.story@bblfish.net Mon Jul 25 19:34:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9010A21F8C19 for ; Mon, 25 Jul 2011 19:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.261 X-Spam-Level: X-Spam-Status: No, score=-3.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 alBkLPp9S99K for ; Mon, 25 Jul 2011 19:34:15 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6349A21F8C15 for ; Mon, 25 Jul 2011 19:34:15 -0700 (PDT) Received: by wwe5 with SMTP id 5so14124wwe.13 for ; Mon, 25 Jul 2011 19:34:14 -0700 (PDT) Received: by 10.227.173.201 with SMTP id q9mr4571625wbz.92.1311647652757; Mon, 25 Jul 2011 19:34:12 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id b13sm19770wbh.7.2011.07.25.19.34.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jul 2011 19:34:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp> Date: Tue, 26 Jul 2011 04:34:09 +0200 Content-Transfer-Encoding: 7bit Message-Id: <13CDC8F7-572C-43C6-9123-29E291B4132B@bblfish.net> References: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 02:34:16 -0000 On 26 Jul 2011, at 01:51, Martin Rex wrote: > Anders Rundgren wrote: >> [snip] >> That the TLS CCA protocol doesn't even support "Logout" haven't made >> it a logical choice for web developers either. > > Huh? I have no clue what you're talking about. > > If the server wants to perform a logout operation, > it can delete the TLS session cache entry on the server. > > But the Single Sign-On capability of the TLS client cert means > that as long as the client credential is still available to the > TLS client, the client will perform "transparent" reauthentication. > >> The button "Clear SSL state" in MSIE is an indication how horribly bad it >> can go when security experts design systems for "people". > > Is your intention to get prompted again? > From a usability standpoint, we prefer the "select automatically" > setting and spare our users the client certificate selection popup. The way to solve both of those issues is just a better User Interface. At the Identity in the Browser W3C Workshop earlier this year [1] we pointed to the work of Aza Raskin who showed very simply and clearly what needed to be done: http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ The user in the browser should be aware for ever tab what client certificate he is using for the content he is seeing, just as he is aware of the server identity. This would make logging out, a one click affair controlled from the browser - the only place where that can be done correctly. Is there anything we can do to persuade browser vendors to put more energy into solving this issue? Henry [1] http://bblfish.net/blog/2011/05/25/ Social Web Architect http://bblfish.net/ From pgut001@login01.cs.auckland.ac.nz Mon Jul 25 20:17:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A92421F8AC3 for ; Mon, 25 Jul 2011 20:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 GiurtHrdE-Dq for ; Mon, 25 Jul 2011 20:17:34 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8C78621F86E6 for ; Mon, 25 Jul 2011 20:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311650255; x=1343186255; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20henry.story@bblfish.net,=20mrex@sap.com|Subject: =20Re:=20[TLS]=20HTTPS=20client-certificate-authenticatio n=20in=20browsers|Cc:=20tls@ietf.org|In-Reply-To:=20<13CD C8F7-572C-43C6-9123-29E291B4132B@bblfish.net>|Message-Id: =20|Date: =20Tue,=2026=20Jul=202011=2015:17:33=20+1200; bh=CdZ4q/5ouD1DIjFoytRqYHO71lGfv5QYDaN67phtOxw=; b=FnsoNX7VX0BHf+g2JMerBaO7hNkyiFIAOJ2DwC6uAr5Q+CwXrRONp9Fe ORwpIf3VPgcmzWW1IWUifLW39zJlp5PuJUB9R3LD2Y6eJ+NGsj5FAgBLM 6CfUiNvP5DI0lxZMeEUke6lPBzx3d3Dqb14ZeoQLhDGZJvEt9QWEu3bSF g=; X-IronPort-AV: E=Sophos;i="4.67,266,1309694400"; d="scan'208";a="74086387" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 26 Jul 2011 15:17:34 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QlY9F-0005M1-Hv; Tue, 26 Jul 2011 15:17:33 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QlY9F-0000I9-GL; Tue, 26 Jul 2011 15:17:33 +1200 From: Peter Gutmann To: henry.story@bblfish.net, mrex@sap.com In-Reply-To: <13CDC8F7-572C-43C6-9123-29E291B4132B@bblfish.net> Message-Id: Date: Tue, 26 Jul 2011 15:17:33 +1200 Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 03:17:35 -0000 Henry Story writes: >Is there anything we can do to persuade browser vendors to put more energy >into solving this issue? A number of HCI people have been trying this for years and years. After years of nothing happening, the only answer appears to be "fork the browser and do it yourself". Peter. From anders.rundgren@telia.com Mon Jul 25 21:16:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2D21F8B0F for ; Mon, 25 Jul 2011 21:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 4r8Wv7hK5cnZ for ; Mon, 25 Jul 2011 21:16:12 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5311D21F8AD8 for ; Mon, 25 Jul 2011 21:16:12 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00DCF529; Tue, 26 Jul 2011 06:16:10 +0200 Message-ID: <4E2E3F7E.30506@telia.com> Date: Tue, 26 Jul 2011 06:15:58 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp> In-Reply-To: <201107252351.p6PNphFS006385@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 04:16:13 -0000 On 2011-07-26 01:51, Martin Rex wrote: > Anders Rundgren wrote: >> >> I don't believe that TLS CCA (Client Certificate Authentication) in the >> form of HTTPS as implemented in current browsers has much of a future. > > It works perfectly fine and we've been using it >10 years for > all of our intranet (50.000 employees these days) web servers > accessed via HTTPS, using TLS client certs for Single Sign-On. > (similar to how Kerberos is used by others). I'm sure about that. My perspective are consumers. >> In fact, quite a bunch of the entities in the EU working with consumer PKI >> have replaced HTTPS CCA with an application level scheme which wasn't such >> a big deal since they anyway were forced writing a browser PKI client more >> or less from scratch since the ones shipped with browsers doesn't support >> PKI as defined by banks and government (like mandatory PIN codes also >> for on-line enrolled keys). > > I think you're confusing things. > > What you're looking at here is scenarios for individually authenticated > transactions. That is an entirely different problem domain and not > addressed by TLS at all. You would have to address that with > a browser plugin that accesses a completely different PKI credential > that has signature qualities, with a clearly defined protocol that > describes what data gets signed, and which requires seperate per-transaction > authorization for every signature operation. There was even a Danish e-government standard for PKI authentication that rides on top of server-auth-only HTTPS. They also have a companion scheme doing web signatures which indeed uses another key. There are lots of similar systems out there. Are all these guys morons? I believe they are rather dissatisfied with how HTTPS CCA works. So am I. >> That the TLS CCA protocol doesn't even support "Logout" haven't made >> it a logical choice for web developers either. > > Huh? I have no clue what you're talking about. > > If the server wants to perform a logout operation, > it can delete the TLS session cache entry on the server. > > But the Single Sign-On capability of the TLS client cert means > that as long as the client credential is still available to the > TLS client, the client will perform "transparent" reauthentication. Doesn't this actually lead to what I'm saying from a practical point of view? What you can do at the TLS layer is BTW very little at least if you are using Servlets. For other authentication methods logout (HttpSession.invalidate) works as expected. There is nothing authoritative to read either on this subject that works for all browsers and servers. Unless you are a MOD-SSL hacker you probably get nowhere. >> The button "Clear SSL state" in MSIE is an indication how horribly bad it >> can go when security experts design systems for "people". > > Is your intention to get prompted again? >>From a usability standpoint, we prefer the "select automatically" > setting and spare our users the client certificate selection popup. I don't really want to know what it does actually. The mere existence of such a button signals that something is terribly wrong :-) >> There's no way you can hide the fact that TLS CCA is only truly useful >> securing tunnels between "boxes". > > The purpose of the TLS CCA is the same as the purpose of Kerberos, > to provide a non-disclosing Single Sign-On convenience. But Kerberos is built on using a ticket after primary auth and that's exactly what most "Web Programmers" would like to do because then you just have to invalidate the ticket to force reauth. Services should time-out but most HTTPS CCA- based services do not. I noted this first when logging in to the Swedish Tax authority. They are all morons? Maybe. But the TLS WG has nothing to offer AFAICT. Anders "Web Programmer" and some more... From mcgrew@cisco.com Tue Jul 26 08:01:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E559821F85A1 for ; Tue, 26 Jul 2011 08:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.241 X-Spam-Level: X-Spam-Status: No, score=-103.241 tagged_above=-999 required=5 tests=[AWL=-0.642, 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 WCUyJZWwiT6M for ; Tue, 26 Jul 2011 08:01:34 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3A27B21F8582 for ; Tue, 26 Jul 2011 08:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=689; q=dns/txt; s=iport; t=1311692494; x=1312902094; h=message-id:from:to:content-transfer-encoding: mime-version:subject:date:cc; bh=RExFT+OITsw5xWnyVKkLkZtdXPior5JQbxBf2m4WLmE=; b=S/BlbCoC7uXjqmCKxvIR+4eBmhJjzsxHVbj7/4+xUEU5wQBgE1P4qMud x7pvPdIxr2YcaOi2nPUyA89LrvATVLttmIAMHxDbgG7M38YEY7xbk8EOW GEBWVjzEWHWiUxKt5qBCW7lT9MUZcuQe2yz0neLbF1aJOPmFfRZKxx2Ms s=; X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6518588" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2011 15:01:33 +0000 Received: from [130.129.23.131] ([10.86.246.150]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6QF1WDU017049; Tue, 26 Jul 2011 15:01:33 GMT Message-Id: From: David McGrew To: tls@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jul 2011 08:01:31 -0700 X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone Subject: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 15:01:35 -0000 Hi, I would like to request feedback on a new draft that Philip Gladstone and I put together, which aims to solve some of the security problems that happen when there is a (HTTP) proxy present and TLS is in use. The approach is to require the proxy to provide the client with additional information that the client can use to make a well-informed decision about the security of the session. This draft was put together too late to request a slot at the WG meeting this week, but if you have thoughts on either the goals or the mechanism, we can discuss either in person or on the list. David http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 From mrex@sap.com Tue Jul 26 08:10:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F2C21F84B6 for ; Tue, 26 Jul 2011 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.85 X-Spam-Level: X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=0.399, 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 D9HWSCn0Tlb5 for ; Tue, 26 Jul 2011 08:10:32 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C682021F8BEB for ; Tue, 26 Jul 2011 08:10:11 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6QFA5NU018371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 17:10:05 +0200 (MEST) From: Martin Rex Message-Id: <201107261510.p6QFA4JH027491@fs4113.wdf.sap.corp> To: henry.story@bblfish.net (Henry Story) Date: Tue, 26 Jul 2011 17:10:04 +0200 (MEST) In-Reply-To: <13CDC8F7-572C-43C6-9123-29E291B4132B@bblfish.net> from "Henry Story" at Jul 26, 11 04:34:09 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 15:10:34 -0000 Henry Story wrote: > > On 26 Jul 2011, at 01:51, Martin Rex wrote: > > > > If the server wants to perform a logout operation, > > it can delete the TLS session cache entry on the server. > > > > But the Single Sign-On capability of the TLS client cert means > > that as long as the client credential is still available to the > > TLS client, the client will perform "transparent" reauthentication. > > > > > The button "Clear SSL state" in MSIE is an indication how horribly bad > > > it can go when security experts design systems for "people". > > > > Is your intention to get prompted again? > > From a usability standpoint, we prefer the "select automatically" > > setting and spare our users the client certificate selection popup. > > The way to solve both of those issues is just a better User Interface. > At the Identity in the Browser W3C Workshop earlier this year [1] > we pointed to the work of Aza Raskin who showed very simply and clearly > what needed to be done: > > http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ > > The user in the browser should be aware for ever tab what client certificate > he is using for the content he is seeing, just as he is aware of the server > identity. This would make logging out, a one click affair controlled from > the browser - the only place where that can be done correctly. You're just scratching the surface of the problem. Browsers have just one address bar and one chrome element to signal about the servers and your identity _per_window_. The only sensible approach to obtain a secure browser would be to strictly enforce a single-source policy, i.e. when https:// is used, *ALL* resources must be served from the exact same server. That is not currently done, your page may contain resources from 20 different servers and could be using 20 different client certs, and it is not obvious for the end user which elements on the page are from which of the servers. -Martin From yngve@opera.com Tue Jul 26 08:23:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBD211E812C for ; Tue, 26 Jul 2011 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wl3Vg8OMFIVQ for ; Tue, 26 Jul 2011 08:23:13 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B204811E811C for ; Tue, 26 Jul 2011 08:23:11 -0700 (PDT) Received: from lessa-ii.oslo.os (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6QFN2Cd013110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jul 2011 15:23:05 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "David McGrew" References: Date: Tue, 26 Jul 2011 17:23:12 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: User-Agent: Opera Mail/10.62 (Win32) Cc: Philip Gladstone Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 15:23:13 -0000 Hi, I just skimmed the start of the document I assume, from context, that your use case is for proxies that perform an authorized MITM "attack" on the TLS connection by issuing specific "fake" certificates for the site you are connecting to, decrypting/re-encrypting the encrypted data, and not a proxy that uses the normal HTTP CONNECT request and just passes packets back and forth and the TLS connection is end-to-end. Right? If so, that should perhaps be made clearer in the introduction and abstract, possibly by using a different term for the proxy? My association with "proxy" is generally the ordinary CONNECT packet forwarding proxy, not the MITM proxy. IMO, when you authorize a proxy to MITM your connections, you also implicitly accept the security policies of the proxy, and whatever encryption and certificate it trusts. As an alternative way forward, might it not be an equally good way forward to require the proxy to either negotiate the same encryption methods with the client as it negotiated with the server, or alternatively, only offer the mutually acceptable set of cipher suites for the client and proxy (perhaps with an addition for better suites, allowing an encryption upgrade)? On Tue, 26 Jul 2011 17:01:31 +0200, David McGrew wrote: > Hi, > > I would like to request feedback on a new draft that Philip Gladstone > and I put together, which aims to solve some of the security problems > that happen when there is a (HTTP) proxy present and TLS is in use. > The approach is to require the proxy to provide the client with > additional information that the client can use to make a well-informed > decision about the security of the session. This draft was put together > too late to request a slot at the WG meeting this week, but if you have > thoughts on either the goals or the mechanism, we can discuss either in > person or on the list. > > David > > http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From henry.story@bblfish.net Tue Jul 26 09:46:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46CC11E80EC for ; Tue, 26 Jul 2011 09:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.346 X-Spam-Level: X-Spam-Status: No, score=-3.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 Ik+7Zs26BvWk for ; Tue, 26 Jul 2011 09:46:40 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 7223221F8ADE for ; Tue, 26 Jul 2011 09:46:40 -0700 (PDT) Received: by wwg11 with SMTP id 11so2505214wwg.1 for ; Tue, 26 Jul 2011 09:46:39 -0700 (PDT) Received: by 10.216.160.68 with SMTP id t46mr5158194wek.5.1311698799480; Tue, 26 Jul 2011 09:46:39 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id k9sm473870weq.27.2011.07.26.09.46.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jul 2011 09:46:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <201107261510.p6QFA4JH027491@fs4113.wdf.sap.corp> Date: Tue, 26 Jul 2011 18:46:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107261510.p6QFA4JH027491@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 16:46:41 -0000 On 26 Jul 2011, at 17:10, Martin Rex wrote: > Henry Story wrote: >>=20 >> On 26 Jul 2011, at 01:51, Martin Rex wrote: >>>=20 >>> If the server wants to perform a logout operation, >>> it can delete the TLS session cache entry on the server. >>>=20 >>> But the Single Sign-On capability of the TLS client cert means >>> that as long as the client credential is still available to the >>> TLS client, the client will perform "transparent" reauthentication. >>>=20 >>>> The button "Clear SSL state" in MSIE is an indication how horribly = bad >>>> it can go when security experts design systems for "people". >>>=20 >>> Is your intention to get prompted again? >>> =46rom a usability standpoint, we prefer the "select automatically" >>> setting and spare our users the client certificate selection popup. >>=20 >> The way to solve both of those issues is just a better User = Interface. >> At the Identity in the Browser W3C Workshop earlier this year [1] >> we pointed to the work of Aza Raskin who showed very simply and = clearly >> what needed to be done: >>=20 >> http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ >>=20 >> The user in the browser should be aware for ever tab what client = certificate >> he is using for the content he is seeing, just as he is aware of the = server=20 >> identity. This would make logging out, a one click affair controlled = from >> the browser - the only place where that can be done correctly. >=20 >=20 > You're just scratching the surface of the problem. >=20 > Browsers have just one address bar and one chrome element to signal > about the servers and your identity _per_window_.=20 >=20 > The only sensible approach to obtain a secure browser would be to > strictly enforce a single-source policy, i.e. when https:// is used, > *ALL* resources must be served from the exact same server. > That is not currently done, your page may contain resources from > 20 different servers and could be using 20 different client certs, > and it is not obvious for the end user which elements on the > page are from which of the servers. Yes, I see, that is a good idea. Start by cutting down complexity. Start = by making it obvious and simple when all your info comes from one server = only. Make responses of that type easy to understand and give them a = positive interface. Then work with artists to see how to present things in more complicated = cases, after finding good examples of those, and by seeing how the user = would like to be alerted to them. In any case the same is true with cookies. We should be alerted on where = we are leaking information to.=20 Henry >=20 >=20 > -Martin Social Web Architect http://bblfish.net/ From mcgrew@cisco.com Tue Jul 26 10:38:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5565211E80EC for ; Tue, 26 Jul 2011 10:38: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 Of1aNelv2zt0 for ; Tue, 26 Jul 2011 10:38:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA0811E8073 for ; Tue, 26 Jul 2011 10:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3877; q=dns/txt; s=iport; t=1311701921; x=1312911521; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=ab1F44YxC3HLmPP89wiwRTR8HEtAvNj4RpHw3Dv0ALc=; b=mV1d6Wh4H33idzBfcn/kbrFoRmuEkqz1rzvglpyjvkUcqjpoVSkL5amx oFU0m3uJXWfdvGsoKT5J9Nkbo0fTyGEyyEh4rQXoZDreVabBmhxRTtpUg OD0bUbvvFdIOWWNCByJa56AWCkbLC8dhzXL6m69bRAsp2laaMaDQrKRQ7 I=; X-IronPort-AV: E=Sophos;i="4.67,270,1309737600"; d="scan'208";a="6571450" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jul 2011 17:38:41 +0000 Received: from [130.129.23.131] ([10.86.245.219]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6QHcd8i004161; Tue, 26 Jul 2011 17:38:40 GMT Message-Id: <99392979-0293-4EAA-BF8A-EE1F7588CC04@cisco.com> From: David McGrew To: "Yngve N. Pettersen" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jul 2011 10:38:39 -0700 References: X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 17:38:42 -0000 Hi Yngve, On Jul 26, 2011, at 8:23 AM, Yngve N. Pettersen wrote: > Hi, > > I just skimmed the start of the document > > I assume, from context, that your use case is for proxies that > perform an authorized MITM "attack" on the TLS connection by issuing > specific "fake" certificates for the site you are connecting to, > decrypting/re-encrypting the encrypted data, and not a proxy that > uses the normal HTTP CONNECT request and just passes packets back > and forth and the TLS connection is end-to-end. Right? > right. > If so, that should perhaps be made clearer in the introduction and > abstract, possibly by using a different term for the proxy? My > association with "proxy" is generally the ordinary CONNECT packet > forwarding proxy, not the MITM proxy. Yes, I think so. > > IMO, when you authorize a proxy to MITM your connections, you also > implicitly accept the security policies of the proxy, and whatever > encryption and certificate it trusts. > Right, this is what happens at present. > As an alternative way forward, might it not be an equally good way > forward to require the proxy to either negotiate the same encryption > methods with the client as it negotiated with the server, or > alternatively, only offer the mutually acceptable set of cipher > suites for the client and proxy (perhaps with an addition for better > suites, allowing an encryption upgrade)? Agreed that it is a good idea for the proxy to offer a subset of the ciphersuites offered by the client. But this only covers the crypto policy - it doesn't address the problem of how the client can decide whether or not it trusts the server on the other side of the proxy, for the particular application in use. Section 2 of the draft outlines this in some more detail. As a side note, I think that for almost all purposes, the ciphersuites offered by the proxy should be a subset of those offered by the client. The one scenario where we might decide that it is a good idea to allow the proxy to offer other ciphersuites is the case in which the client and server do not have a mutually acceptable ciphersuite; in this case the proxy is acting like a translator. I am not thrilled about this scenario, because it implies that there is lack of interoperability which I think should be avoided if/when possible, but I do not think that it would make sense to exclude the scenario. thanks, David > > > On Tue, 26 Jul 2011 17:01:31 +0200, David McGrew > wrote: > >> Hi, >> >> I would like to request feedback on a new draft that Philip >> Gladstone and I put together, which aims to solve some of the >> security problems that happen when there is a (HTTP) proxy present >> and TLS is in use. The approach is to require the proxy to >> provide the client with additional information that the client can >> use to make a well-informed decision about the security of the >> session. This draft was put together too late to request a slot at >> the WG meeting this week, but if you have thoughts on either the >> goals or the mechanism, we can discuss either in person or on the >> list. >> >> David >> >> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > -- > Sincerely, > Yngve N. Pettersen > > ******************************************************************** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 > ******************************************************************** From mrex@sap.com Tue Jul 26 12:11:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109865E8002 for ; Tue, 26 Jul 2011 12:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.556 X-Spam-Level: X-Spam-Status: No, score=-9.556 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_62=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 pP8pUlhorXKu for ; Tue, 26 Jul 2011 12:11:10 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6084D5E8001 for ; Tue, 26 Jul 2011 12:11:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6QJB40R022729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 21:11:04 +0200 (MEST) From: Martin Rex Message-Id: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Tue, 26 Jul 2011 21:11:03 +0200 (MEST) In-Reply-To: <4E2E3F7E.30506@telia.com> from "Anders Rundgren" at Jul 26, 11 06:15:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 19:11:12 -0000 Anders Rundgren wrote: > > On 2011-07-26 01:51, Martin Rex wrote: > > > > Anders Rundgren wrote: > > > > > > I don't believe that TLS CCA (Client Certificate Authentication) in the > > > form of HTTPS as implemented in current browsers has much of a future. > > > > It works perfectly fine and we've been using it >10 years for > > all of our intranet (50.000 employees these days) web servers > > accessed via HTTPS, using TLS client certs for Single Sign-On. > > (similar to how Kerberos is used by others). > > I'm sure about that. My perspective are consumers. My perspective is also consumers. TLS client authentication is about Single Sign-On. http://en.wikipedia.org/wiki/Single_sign-on And the most convenient incarnation of it is popup-free single sign-on. > > > > > What you're looking at here is scenarios for individually authenticated > > transactions. That is an entirely different problem domain and not > > addressed by TLS at all. You would have to address that with > > a browser plugin that accesses a completely different PKI credential > > that has signature qualities, with a clearly defined protocol that > > describes what data gets signed, and which requires seperate per-transaction > > authorization for every signature operation. > > There was even a Danish e-government standard for PKI authentication > that rides on top of server-auth-only HTTPS. They also have a > companion scheme doing web signatures which indeed uses another > key. There are lots of similar systems out there. > > Are all these guys morons? I believe they are rather dissatisfied > with how HTTPS CCA works. So am I. Not understanding the underlying technology at all and not discussing with software suppliers how a standardized but hardly used protocol option works is more than a little naive on my scorecard. Microsoft foobar'ed client certs in WinHTTP (a component distinct from MSIE) and fixed it here http://support.microsoft.com/kb/909425 when we asked them to. When Apple shipped Safari for Windows they did not find that winhttp fix and made their browser exhibit the exact same bugs. We told them in January 2009, but they were still shipping defective Safaris for Windows in April 2010... Google Chrome used WinHTTP only for a short time and got rid of the problem when it dumped WinHTTP. > > > > > If the server wants to perform a logout operation, > > it can delete the TLS session cache entry on the server. > > > > But the Single Sign-On capability of the TLS client cert means > > that as long as the client credential is still available to the > > TLS client, the client will perform "transparent" reauthentication. > > Doesn't this actually lead to what I'm saying from a practical > point of view? No. It doesn't make any flawed assumptions less flawed, of course. > > What you can do at the TLS layer is BTW very little > at least if you are using Servlets. For other authentication > methods logout (HttpSession.invalidate) works as expected. You misunderstand the concept of "Single Sign-On" as offered by TLS. > > >> The button "Clear SSL state" in MSIE is an indication how horribly bad it > >> can go when security experts design systems for "people". > > > > Is your intention to get prompted again? > >>From a usability standpoint, we prefer the "select automatically" > > setting and spare our users the client certificate selection popup. > > I don't really want to know what it does actually. The mere existence > of such a button signals that something is terribly wrong :-) The equivalent for Kerberos (win7 in a windows domain) is "klist purge". (Although the Kerberos ticket purge does _NOT_ result in the prompting when new TGTs and new tickets are acquired. > > >> There's no way you can hide the fact that TLS CCA is only truly useful > >> securing tunnels between "boxes". > > > > The purpose of the TLS CCA is the same as the purpose of Kerberos, > > to provide a non-disclosing Single Sign-On convenience. > > But Kerberos is built on using a ticket after primary auth and > that's exactly what most "Web Programmers" would like to do > because then you just have to invalidate the ticket to force > reauth. Huh? That is not how Kerberos works. Kerberos tickets are not invalidated at all. And with Kerberos, you get even less prompting (more seamless Single Sign-On) than with TLS client certs. > > Services should time-out but most HTTPS CCA-based services do not. > I noted this first when logging in to the Swedish Tax authority. > They are all morons? Maybe. > But the TLS WG has nothing to offer AFAICT. What you are looking for is for a completely different protocol layer than TLS. If you want application level session management, you have to do application level session management. TLS provides you a secure tunnel with Single Sign-On and fast session resumption over later transport connections to the same target (to better match the connection characteristics of HTTP). -Martin From anders.rundgren@telia.com Tue Jul 26 12:54:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB56311E80A6 for ; Tue, 26 Jul 2011 12:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.28 X-Spam-Level: X-Spam-Status: No, score=-3.28 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, 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 EW1cWQk-1-sF for ; Tue, 26 Jul 2011 12:54:30 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4C211E8094 for ; Tue, 26 Jul 2011 12:54:30 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4D6512CA035070FF; Tue, 26 Jul 2011 21:54:28 +0200 Message-ID: <4E2F1B65.2080404@telia.com> Date: Tue, 26 Jul 2011 21:54:13 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> In-Reply-To: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 19:54:31 -0000 Martin, You have a rather elitist way of discussing things. It actually quite hard writing an HTTPS CCA based web app that has similar login and session characteristics as one using password authentication. In your opinion this is an advantage; in my world it represents a hurdle for adoption. Anyway, banks are investing huge in app-level PKI authentication so there is apparently a huge ignorant crow out there. The there are some really interesting differences in path building (which of course is NOT specified at all by TLS) that for example have forced people importing immediate CAs to PC before being able to login using a smart card. It is absolutely clear that the browser and server vendors have no intention whatsoever cooperating. Anders On 2011-07-26 21:11, Martin Rex wrote: > Anders Rundgren wrote: >> >> On 2011-07-26 01:51, Martin Rex wrote: >>> >>> Anders Rundgren wrote: >>>> >>>> I don't believe that TLS CCA (Client Certificate Authentication) in the >>>> form of HTTPS as implemented in current browsers has much of a future. >>> >>> It works perfectly fine and we've been using it >10 years for >>> all of our intranet (50.000 employees these days) web servers >>> accessed via HTTPS, using TLS client certs for Single Sign-On. >>> (similar to how Kerberos is used by others). >> >> I'm sure about that. My perspective are consumers. > > My perspective is also consumers. > TLS client authentication is about Single Sign-On. > http://en.wikipedia.org/wiki/Single_sign-on > > And the most convenient incarnation of it is popup-free single sign-on. > > >> >>> >>> What you're looking at here is scenarios for individually authenticated >>> transactions. That is an entirely different problem domain and not >>> addressed by TLS at all. You would have to address that with >>> a browser plugin that accesses a completely different PKI credential >>> that has signature qualities, with a clearly defined protocol that >>> describes what data gets signed, and which requires seperate per-transaction >>> authorization for every signature operation. >> >> There was even a Danish e-government standard for PKI authentication >> that rides on top of server-auth-only HTTPS. They also have a >> companion scheme doing web signatures which indeed uses another >> key. There are lots of similar systems out there. >> >> Are all these guys morons? I believe they are rather dissatisfied >> with how HTTPS CCA works. So am I. > > > Not understanding the underlying technology at all and not discussing > with software suppliers how a standardized but hardly used protocol > option works is more than a little naive on my scorecard. > > > Microsoft foobar'ed client certs in WinHTTP (a component distinct > from MSIE) and fixed it here http://support.microsoft.com/kb/909425 > when we asked them to. > > > When Apple shipped Safari for Windows they did not find that winhttp > fix and made their browser exhibit the exact same bugs. We told > them in January 2009, but they were still shipping defective > Safaris for Windows in April 2010... > > Google Chrome used WinHTTP only for a short time and got rid of the > problem when it dumped WinHTTP. > > >> >>> >>> If the server wants to perform a logout operation, >>> it can delete the TLS session cache entry on the server. >>> >>> But the Single Sign-On capability of the TLS client cert means >>> that as long as the client credential is still available to the >>> TLS client, the client will perform "transparent" reauthentication. >> >> Doesn't this actually lead to what I'm saying from a practical >> point of view? > > No. > > It doesn't make any flawed assumptions less flawed, of course. > > >> >> What you can do at the TLS layer is BTW very little >> at least if you are using Servlets. For other authentication >> methods logout (HttpSession.invalidate) works as expected. > > You misunderstand the concept of "Single Sign-On" as offered by TLS. > > >> >>>> The button "Clear SSL state" in MSIE is an indication how horribly bad it >>>> can go when security experts design systems for "people". >>> >>> Is your intention to get prompted again? >>> >From a usability standpoint, we prefer the "select automatically" >>> setting and spare our users the client certificate selection popup. >> >> I don't really want to know what it does actually. The mere existence >> of such a button signals that something is terribly wrong :-) > > > The equivalent for Kerberos (win7 in a windows domain) is "klist purge". > (Although the Kerberos ticket purge does _NOT_ result in the prompting > when new TGTs and new tickets are acquired. > > >> >>>> There's no way you can hide the fact that TLS CCA is only truly useful >>>> securing tunnels between "boxes". >>> >>> The purpose of the TLS CCA is the same as the purpose of Kerberos, >>> to provide a non-disclosing Single Sign-On convenience. >> >> But Kerberos is built on using a ticket after primary auth and >> that's exactly what most "Web Programmers" would like to do >> because then you just have to invalidate the ticket to force >> reauth. > > Huh? That is not how Kerberos works. Kerberos tickets are > not invalidated at all. And with Kerberos, you get even less > prompting (more seamless Single Sign-On) than with TLS client certs. > > >> >> Services should time-out but most HTTPS CCA-based services do not. >> I noted this first when logging in to the Swedish Tax authority. >> They are all morons? Maybe. >> But the TLS WG has nothing to offer AFAICT. > > > What you are looking for is for a completely different protocol > layer than TLS. If you want application level session management, > you have to do application level session management. TLS provides > you a secure tunnel with Single Sign-On and fast session resumption > over later transport connections to the same target (to better match > the connection characteristics of HTTP). > > > -Martin > > From mrex@sap.com Tue Jul 26 13:52:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693B21F8A55 for ; Tue, 26 Jul 2011 13:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.858 X-Spam-Level: X-Spam-Status: No, score=-9.858 tagged_above=-999 required=5 tests=[AWL=0.391, 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 gNQ0+spt-KAe for ; Tue, 26 Jul 2011 13:52:02 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id BE43821F8A4D for ; Tue, 26 Jul 2011 13:52:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6QKq0TP003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jul 2011 22:52:00 +0200 (MEST) From: Martin Rex Message-Id: <201107262051.p6QKpxAd017550@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Tue, 26 Jul 2011 22:51:59 +0200 (MEST) In-Reply-To: <4E2F1B65.2080404@telia.com> from "Anders Rundgren" at Jul 26, 11 09:54:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 26 Jul 2011 20:52:02 -0000 Anders Rundgren wrote: > > You have a rather elitist way of discussing things. > > It actually quite hard writing an HTTPS CCA based web app that > has similar login and session characteristics as one using password > authentication. But that is a clear abuse of the TLS client certificate technology and _not_ supposed to be usable in this fashion. > > In your opinion this is an advantage; in my world it represents a > hurdle for adoption. If you are _not_ looking for seamless single Sign-On, then TLS client certs are not the right tool for what you want to accomplish (square peg, round hole). > > Anyway, banks are investing huge in app-level PKI authentication > so there is apparently a huge ignorant crow out there. But if the "frontend" they are using something as security-broken as a plain web browser, then the technology they would need is a "frontend signing" browser plugin to produce PKCS#7/CMS signed data over well-definied application protocol units. > > The there are some really interesting differences in path building > (which of course is NOT specified at all by TLS) that for example > have forced people importing immediate CAs to PC before being able > to login using a smart card. What particular problem are you facing? The TLS protocol is _very_ clear that a Certificate message must contain a FULL path, omitting _at_most_ the self-signed certificate at the end. There are several TLS implementations out there with significant brokeness with respect to the Certificate handshke message (e.g. OpenSSL) which will omit more than just the self-signed certificate at the end of the certification path, send certificates out-of-order and even include arbitrary non-path certificates. Things that could be trivially checked and reported as configuration errors on the server side upfront, instead of dumping garbage on communication peers in clear violation of the specification. -Martin From ynir@checkpoint.com Tue Jul 26 14:17:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B3B21F86AE for ; Tue, 26 Jul 2011 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.487 X-Spam-Level: X-Spam-Status: No, score=-10.487 tagged_above=-999 required=5 tests=[AWL=0.112, 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 9VbXZvWkggUS for ; Tue, 26 Jul 2011 14:17:18 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7AE21F86AD for ; Tue, 26 Jul 2011 14:17:17 -0700 (PDT) X-CheckPoint: {4E2F3C70-13-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6QLHCqW000814; Wed, 27 Jul 2011 00:17:12 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 27 Jul 2011 00:17:12 +0300 From: Yoav Nir To: David McGrew Date: Wed, 27 Jul 2011 00:17:09 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxL2WKNf4brhlL3QUOImYCn/izXYA== Message-ID: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-1-547864708"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Philip Gladstone , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 21:17:19 -0000 --Apple-Mail-1-547864708 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 26, 2011, at 11:01 AM, David McGrew wrote: > Hi, >=20 > I would like to request feedback on a new draft that Philip Gladstone =20= > and I put together, which aims to solve some of the security problems =20= > that happen when there is a (HTTP) proxy present and TLS is in use. =20= > The approach is to require the proxy to provide the client with =20 > additional information that the client can use to make a well-informed = =20 > decision about the security of the session. This draft was put =20 > together too late to request a slot at the WG meeting this week, but =20= > if you have thoughts on either the goals or the mechanism, we can =20 > discuss either in person or on the list. >=20 > David >=20 > http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 Hi Dave. I like this draft. TLS proxies are becoming a fact of life. They still = have significant drawbacks in that the "fake" certificates that they = generate are not identical to the original certificates. For example, = the fake certificates cannot be EV certificates, and therefore the users = lose the "green-bar" indication. I don't know if you're following the LockFoo discussion on WebSec, but = all of those locks would cause a hard-fail for clients connecting to = sites that have specified them. As security people we might think = "good!", but that would actually be a bar to implementations of LockFoo = more than it would be a bar to deployment of TLS proxies. Giving the = client access to the original certificates would allow the browser to = overcome this limitation. A similar argument also applies to DANE. If the DNS entry identifies the = key, the certificate or the CA, then the "fake" certificate would cause = an error. Access to the original certificate chain allows the client to = eliminate the error message, although I am not sure how the browser UI = would indicate an EV certificate proxied through a non-EV proxy. I am wondering why you would need the ConnectionSecurityParameters = structure. Wouldn't the 2-byte ciphersuite be a more compact way to = represent this information? Also I would add text about EV certificates (and maybe also the LockFoo = cases of DANE and WebSec) to the motivation section. Yoav --Apple-Mail-1-547864708 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNjIxMTcxMFowIwYJKoZIhvcNAQkEMRYEFH07r/5xXX7qRQD04ope 2fH8gVPKMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBAAWO5YAX38tPVJOze4JOsd32i2gOXJciLQwO/6D3iaJo/uJTCYXI9fRivB1M7lUSTOB3KSQF c7/HKiX/URHaRYr1Y5E9Z3UCxWzYcrO9K1oWceuRh6rDLlT4LQKADH9cufj5QzAE1EWX6LTvNJit a9Wfh0a0tsn/WRWYH37vCvFDTw4pZ/kwaXpJIQziGZidQlOLYe//g1133v7yMqWXoFSauOWIqnTP AkFI/jJuuYYfQ5W/pdoYpsSGM2SzTUqhqIKIHHoAz33w8MNBr3PEVHbIlQcB2fazi9MUFd9sHGx2 1BTxC7uHqR90X1LboiOU7wTjwdPO/gNtGJp6aQfjdN4AAAAAAAA= --Apple-Mail-1-547864708-- From ynir@checkpoint.com Tue Jul 26 14:20:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2F21F888A for ; Tue, 26 Jul 2011 14:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 W19-4pOyGTGa for ; Tue, 26 Jul 2011 14:20:48 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 06DF721F856B for ; Tue, 26 Jul 2011 14:20:46 -0700 (PDT) X-CheckPoint: {4E2F3D42-9-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6QLKgsR001319; Wed, 27 Jul 2011 00:20:42 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 27 Jul 2011 00:20:42 +0300 From: Yoav Nir To: David McGrew Date: Wed, 27 Jul 2011 00:20:40 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxL2d92M4NsQp0EQQmaKlhg2ovHuw== Message-ID: References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> In-Reply-To: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-2-548075153"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Philip Gladstone , "tls@ietf.org List" Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 21:20:48 -0000 --Apple-Mail-2-548075153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Also, I'd lose section 3.2. It doesn't add much :-) On Jul 26, 2011, at 5:17 PM, Yoav Nir wrote: >=20 > On Jul 26, 2011, at 11:01 AM, David McGrew wrote: >=20 >> Hi, >>=20 >> I would like to request feedback on a new draft that Philip Gladstone = =20 >> and I put together, which aims to solve some of the security problems = =20 >> that happen when there is a (HTTP) proxy present and TLS is in use. = =20 >> The approach is to require the proxy to provide the client with =20 >> additional information that the client can use to make a = well-informed =20 >> decision about the security of the session. This draft was put =20 >> together too late to request a slot at the WG meeting this week, but =20= >> if you have thoughts on either the goals or the mechanism, we can =20 >> discuss either in person or on the list. >>=20 >> David >>=20 >> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 >=20 > Hi Dave. >=20 > I like this draft. TLS proxies are becoming a fact of life. They still = have significant drawbacks in that the "fake" certificates that they = generate are not identical to the original certificates. For example, = the fake certificates cannot be EV certificates, and therefore the users = lose the "green-bar" indication. >=20 > I don't know if you're following the LockFoo discussion on WebSec, but = all of those locks would cause a hard-fail for clients connecting to = sites that have specified them. As security people we might think = "good!", but that would actually be a bar to implementations of LockFoo = more than it would be a bar to deployment of TLS proxies. Giving the = client access to the original certificates would allow the browser to = overcome this limitation. >=20 > A similar argument also applies to DANE. If the DNS entry identifies = the key, the certificate or the CA, then the "fake" certificate would = cause an error. Access to the original certificate chain allows the = client to eliminate the error message, although I am not sure how the = browser UI would indicate an EV certificate proxied through a non-EV = proxy. >=20 > I am wondering why you would need the ConnectionSecurityParameters = structure. Wouldn't the 2-byte ciphersuite be a more compact way to = represent this information? >=20 > Also I would add text about EV certificates (and maybe also the = LockFoo cases of DANE and WebSec) to the motivation section. >=20 > Yoav >=20 >=20 >=20 >=20 > Scanned by Check Point Total Security Gateway. >=20 > --Apple-Mail-2-548075153 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNjIxMjA0MFowIwYJKoZIhvcNAQkEMRYEFJdloGCAm1/DnVNjUp+U LrE+LMuNMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBAGF33/n69HXvtVH9vQhAvxNvf2y0Neh1D7mQtmd9hQNuz0kW5oIFEbMlFh3i7wJZ9Ps7VKNN sBKBtlgskyRuXlpBeKhdq25Y45QOUcSkSEhsbmIZ3VLe7e5fA3L2EeHAFln0mGwnJ7ckUaJ/DEip P4e9LExyNFZ1auDRUe8EjdTihrs+7sV9b/SV60CnLysSsEfKISKrleqYKxLDhzlQZiuLeF/uJVzB snibP7WVJSy94NMKadXlAWOAPo+MutzF410ULUP4FdUsmhHf4Gn2W5UyM+r4gxboO54xQ1STPKyA 1LSyDrojr6K/m8omCfS/6zN56cfL2ipTnbhu+F1Fts4AAAAAAAA= --Apple-Mail-2-548075153-- From agl@google.com Tue Jul 26 14:26:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7266D21F8A62 for ; Tue, 26 Jul 2011 14:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.877 X-Spam-Level: X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 bKD2TbYVIP5q for ; Tue, 26 Jul 2011 14:26:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B29E121F8A4E for ; Tue, 26 Jul 2011 14:26:02 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p6QLQ0Gq020034 for ; Tue, 26 Jul 2011 14:26:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311715561; bh=ygHTqGTXajzVH4yohmrJCq/zlLc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=RiSWbbYlJS0y4w3OHzrVDAkbfRqP1mo3GqoIWDbnS+yrmyOaZIb+pRBwuazVzSWZY lkXljVJNxuAJTsG4028Kw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=oFBHYVyCyqZdtI3YsTF/TcoZNHPvE+PIphRE5IXfPehlWkjFjkNvXVus9cQSlSEdM Clqh8rn268f9/GULCxxpQ== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by wpaz33.hot.corp.google.com with ESMTP id p6QLO2cQ026827 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 14:25:59 -0700 Received: by gxk2 with SMTP id 2so881617gxk.22 for ; Tue, 26 Jul 2011 14:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IriizJGxntQnMangpykZVHXZyJxu19rzOP+/OVkC35Y=; b=jZB1iR8MAUy5wxDvENlpckqNW9BWCr+wNnVORbY45MmVYctEG1vmJ6U/4RwikYsTtl kkEMVsHxH3serM86jEAg== MIME-Version: 1.0 Received: by 10.151.7.8 with SMTP id k8mr4162419ybi.34.1311715559626; Tue, 26 Jul 2011 14:25:59 -0700 (PDT) Received: by 10.151.47.19 with HTTP; Tue, 26 Jul 2011 14:25:59 -0700 (PDT) In-Reply-To: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> Date: Tue, 26 Jul 2011 17:25:59 -0400 Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 21:26:03 -0000 On Tue, Jul 26, 2011 at 5:17 PM, Yoav Nir wrote: > I don't know if you're following the LockFoo discussion on WebSec, but al= l of those locks would cause a hard-fail for clients connecting to sites th= at have specified them. As security people we might think "good!", but that= would actually be a bar to implementations of LockFoo more than it would b= e a bar to deployment of TLS proxies. Giving the client access to the origi= nal certificates would allow the browser to overcome this limitation. At least in Chrome, user installed root CAs can override certificate pins. Thus MITM proxies aren't broken and nor will they be by any of the various pinning proposals in websec. Cheers AGL From ynir@checkpoint.com Tue Jul 26 14:41:40 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFD021F8713 for ; Tue, 26 Jul 2011 14:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.496 X-Spam-Level: X-Spam-Status: No, score=-10.496 tagged_above=-999 required=5 tests=[AWL=0.103, 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 fFINbYLFVmbP for ; Tue, 26 Jul 2011 14:41:40 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4921F8700 for ; Tue, 26 Jul 2011 14:41:38 -0700 (PDT) X-CheckPoint: {4E2F4226-11-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6QLfV7S004651; Wed, 27 Jul 2011 00:41:31 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 27 Jul 2011 00:41:31 +0300 From: Yoav Nir To: Adam Langley Date: Wed, 27 Jul 2011 00:41:28 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxL3MgPoZ/RpCpmQM2dTtb2KbJVDg== Message-ID: References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-3-549322869"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 21:41:40 -0000 --Apple-Mail-3-549322869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 26, 2011, at 5:25 PM, Adam Langley wrote: > On Tue, Jul 26, 2011 at 5:17 PM, Yoav Nir wrote: >> I don't know if you're following the LockFoo discussion on WebSec, = but all of those locks would cause a hard-fail for clients connecting to = sites that have specified them. As security people we might think = "good!", but that would actually be a bar to implementations of LockFoo = more than it would be a bar to deployment of TLS proxies. Giving the = client access to the original certificates would allow the browser to = overcome this limitation. >=20 > At least in Chrome, user installed root CAs can override certificate > pins. Thus MITM proxies aren't broken and nor will they be by any of > the various pinning proposals in websec. Really? I thought Chrome used the operating system TA store. How can it = tell the difference between a trust anchor that was installed by = Microsoft and one that was installed by the user? But I know that the EV indication goes away behind a proxy, and there's = no way to make your CA certificate "EV" to the browser. Dave's proposal = allows the green label to come back. Yoav= --Apple-Mail-3-549322869 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPKjCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBScwggQPoAMC AQICEBW9tBlVg9WZf9zHij2h3zMwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwNzIxMDAwMDAwWhcNMTIwNzIwMjM1OTU5WjAkMSIwIAYJKoZI hvcNAQkBFhN5bmlyQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxha8w2xboHPbsj9HBz/1LdG2kwp++sXC5I0izECjJRravnWdnlDqTSRx7outPOk4zkfP/jtO ZiFl35/W/ZgiVilKNrCAcIk4J4VYdbhUItos2Z1ydt1JcY6F24faWNNns2hV/cF6pNELNTxPYIsY HrVy7Cq7/oywfHQimKbL4cVZvUF34P57gZKrxKBEkw3cUAzch7bQ8pTtewjvFW+cjpDqPaFSZyGJ VfbBtAg3RBjlOolfp2VlTmLGW3gRxg9hi7XAxjJf417I9b1hz0NpTnhSr7n38zMEyUdhqr2Wb37b yFNmhF+dWeBUX/RzgdIeqO/whtI1+gH8ZNuzpAV1UQIDAQABo4IB4zCCAd8wHwYDVR0jBBgwFoAU ehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFPzBjRi9Qe40hv+WSad/Om18V8HmMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNvbW9k b2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETeW5pckBjaGVj a3BvaW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAkLgfz4ztXKON97ZHaqFhBfxO3QGPhx76iB1U 9LevFF/AsfS0ap2IWzGDocGJze17FZTjM41vCpRORCKCAdek+u+6RO95zx8VQaZybicBNCGBb4LP 1h8GvtmrT/+JpdtETJp9i1KIEwn8hn9Q4aMdkk8S2QkemBmhzGXdcQ5nCxyCQHk1hcRSDhC1qfME DPGlKMxqDpMHrFmiI6vdCVBhufX7xECsGXOJDqMWMPg7YE0fubg50T8ehNHJ2Mvm8JpYIGwTIC3v V9egV4ghYxHXm6u1zbXZUD+3pV9cNKbboB1FjuVqzKIiuNnzsZ3StcasZRYaxlwaHAU4uAuNyzbN 3jGCA6swggOnAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UE AxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZ VYPVmX/cx4o9od8zMAkGBSsOAwIaBQCgggHXMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTExMDcyNjIxNDEyOFowIwYJKoZIhvcNAQkEMRYEFBQh6ctwfo3PNJiRr+Mq 8TqaMV9bMIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVh dGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEBW9tBlVg9WZf9zHij2h3zMwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAVvbQZVYPVmX/cx4o9od8zMA0GCSqGSIb3DQEBAQUA BIIBAJpMljrIk7NUAC7gmEmRh5EfZhOvsuOZwevMyECeyFm0qM12R6I+JiYV8no6ChdQ21PKhF70 0yStNceb2G1vVbAW1o6eU9aze7ByScz3te/+R6VNaHIDe2oDmpCFt/l/BeaR3Njy0pa/kZrtShW4 Hoap3ns/qkYI+iz3x/ywk6o1dFflRXGmqYimEh38tCvabkoHOBliUy2UDjDvSeoaCfnB/cMx5wIB LrFXFYolF0petRAFugAbz9nx50+dpPqBS3rChJuf4n7CxY1TIUgs7ZT9fxUOeSjVofpHaEi85HPu 9iGRpqOlB1ohS3rb7fLi+WpMAFAyZPNgHgr8Moi6ZowAAAAAAAA= --Apple-Mail-3-549322869-- From agl@google.com Tue Jul 26 14:52:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121E15E800F for ; Tue, 26 Jul 2011 14:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 kzHFAaQdNJvQ for ; Tue, 26 Jul 2011 14:52:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 339AC5E8008 for ; Tue, 26 Jul 2011 14:52:00 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p6QLpw66015437 for ; Tue, 26 Jul 2011 14:51:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311717119; bh=4o7DQRwJf5JlOxnfWrOjF+1c2co=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Eltn3GsAb9g9n5+jMSUXUXih3YOK3H0Sj2LzduAxGaXHvyG+CB5YWm/wZIANqe5kQ U5eGNxU5m9xTa17YAnRcQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=ElsF61ESmqYff16+iQ8nMzABS11rWYujg5upPrxOY2h6Dwu7OVlZ7D7O8VwbJRmQU Kzkl/vdsK+t7a6UczH9IA== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by kpbe12.cbf.corp.google.com with ESMTP id p6QLpvIE006148 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 26 Jul 2011 14:51:57 -0700 Received: by gyc15 with SMTP id 15so681823gyc.38 for ; Tue, 26 Jul 2011 14:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=72bTU8t5oFgwipyVft2LJSm9kjyhHgInBYcdYRfYatI=; b=t2Pz0JVSAi0RT7Phk1zYFb7reX7gn1AvvvprnxySVFV+xiJPaN9lqsg4tm3SsrIvl0 4DUH1AEFgD7MVMl4cx7g== MIME-Version: 1.0 Received: by 10.150.254.20 with SMTP id b20mr6407441ybi.91.1311717116816; Tue, 26 Jul 2011 14:51:56 -0700 (PDT) Received: by 10.151.47.19 with HTTP; Tue, 26 Jul 2011 14:51:56 -0700 (PDT) In-Reply-To: References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> Date: Tue, 26 Jul 2011 17:51:56 -0400 Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 26 Jul 2011 21:52:01 -0000 On Tue, Jul 26, 2011 at 5:41 PM, Yoav Nir wrote: > Really? =C2=A0I thought Chrome used the operating system TA store. How ca= n it tell the difference between a trust anchor that was installed by Micro= soft and one that was installed by the user? Not in any very clean way I'm afraid: http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_k= nown_roots_win.h?revision=3D80765&view=3Dmarkup > But I know that the EV indication goes away behind a proxy, and there's n= o way to make your CA certificate "EV" to the browser. Dave's proposal allo= ws the green label to come back. I've poked BlueCoat at least about this problem in the past and they didn't appear to be too exercised by it. It's really the MITM folks who need to figure out if this address their needs or not. I simply don't know the requirements in this space well enough to know if the draft meets them. From my point of view, we keep MITM in the back of our minds but otherwise mostly ignore them except to ban certain troublesome vendors from time to time. Cheers AGL From yngve@opera.com Tue Jul 26 16:55:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8305C11E80D6 for ; Tue, 26 Jul 2011 16:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DOLsPAkPLnH3 for ; Tue, 26 Jul 2011 16:55:00 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 458C111E80D4 for ; Tue, 26 Jul 2011 16:55:00 -0700 (PDT) Received: from lessa-ii.oslo.os (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6QNstag001638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 26 Jul 2011 23:54:58 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org Date: Wed, 27 Jul 2011 01:55:05 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: User-Agent: Opera Mail/10.62 (Win32) Subject: [TLS] Request for mail testserver with TLS accepting renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2011 23:55:01 -0000 Hello all, I have recently upgraded my TLS Prober to test email servers (IMAP, POP, SMTP). However, I am uncertain about whether the test for testing client initiated renegotiation works properly, particularly since a test of 300000+ servers failed to detect a single email server that accepted it (or requested it). It might of course be that all email servers have this functionality disabled, but for now I am assuming something is wrong about how the test itself works. If anyone have an email server that is configured to accept client initiated renegotiation that I could test, I would appreciate it. Thanks in advance. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From matt@mattmccutchen.net Tue Jul 26 17:05:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC88621F84DE for ; Tue, 26 Jul 2011 17:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 tFgwpn2sVGBH for ; Tue, 26 Jul 2011 17:05:25 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 47FA821F84A1 for ; Tue, 26 Jul 2011 17:05:25 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 074E359806C; Tue, 26 Jul 2011 17:05:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=ZsoioKSfl+APjYpnOcUVWl2swe7wYwu8QBbknS3XAUF DYnWMDWa2eDGdHi+PVqX6+/HtKUn6flRz/vbiaSa3gb50snBplnuDP/FmyNISp9C o1Ror3l6boTDPHZbKHl0cLqWaB2roq0jTvQ4S5eG2eUJQeBqM8UMDvIEn99dBwGs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=lUd7UFr+B9o4ikM7NkWjwNr4rkU=; b=A+TVsJmZ+B f87zYB8ZZOCelK4Cc6VBGYKA39zf6Ri/c9wqd5advNSfrQUVrtIL4dL1WRtJhZK+ GwfSYZWJiD/W4yvqm+2zvnXPmdkZNXHuVbnLSF9Z6BL16A5TqB8skGdD4DG0LcOK n1UzU4JNlS+GS4O3ducULfPYj5ACqC+j0= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 82CD1598069; Tue, 26 Jul 2011 17:05:24 -0700 (PDT) From: Matt McCutchen To: "Yngve N. Pettersen" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 26 Jul 2011 20:05:22 -0400 Message-ID: <1311725122.7071.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Request for mail testserver with TLS accepting renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 00:05:25 -0000 On Wed, 2011-07-27 at 01:55 +0200, Yngve N. Pettersen wrote: > I have recently upgraded my TLS Prober to test email servers (IMAP, POP, > SMTP). > > However, I am uncertain about whether the test for testing client > initiated renegotiation works properly, particularly since a test of > 300000+ servers failed to detect a single email server that accepted it > (or requested it). > > It might of course be that all email servers have this functionality > disabled, but for now I am assuming something is wrong about how the test > itself works. > > If anyone have an email server that is configured to accept client > initiated renegotiation that I could test, I would appreciate it. Is your test in any way specific to email protocols? If you just run "openssl s_server" interactively, it seems to accept all client-initiated renegotiation by default (at least when renegotiation indication is used). -- Matt From dkg@fifthhorseman.net Tue Jul 26 17:28:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0C11E80BE for ; Tue, 26 Jul 2011 17:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 guyNC8Z9Knbz for ; Tue, 26 Jul 2011 17:28:32 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 422B811E809E for ; Tue, 26 Jul 2011 17:28:32 -0700 (PDT) Received: from [192.168.1.140] (static-50-142-241-92.customer.blic.net [92.241.142.50]) by che.mayfirst.org (Postfix) with ESMTPSA id 7AB0BF970 for ; Tue, 26 Jul 2011 20:28:28 -0400 (EDT) Message-ID: <4E2F5BA0.4020507@fifthhorseman.net> Date: Wed, 27 Jul 2011 02:28:16 +0200 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 MIME-Version: 1.0 To: tls@ietf.org References: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> <4E2F1B65.2080404@telia.com> In-Reply-To: <4E2F1B65.2080404@telia.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig60127966FB3522E428BF2D2B" Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 27 Jul 2011 00:28:32 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig60127966FB3522E428BF2D2B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 07/26/2011 09:54 PM, Anders Rundgren wrote: > It actually quite hard writing an HTTPS CCA based web app that > has similar login and session characteristics as one using password > authentication. What's so hard about it? Designate a URL (e.g. http://example.com/login) that triggers a request for client-side certificates. When the user visits that URL with an acceptable client-side certificate, set a session cookie, and redirect them back to the page they were coming from. When the user is not logged in, show them a login link that points to the designated URL. When they are logged in, show them a logout link that takes them to a URL that clears the session cookie. Am i missing something that makes this approach difficult or wrong? --dkg --------------enig60127966FB3522E428BF2D2B 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.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJOL1ugXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznp6iwP/3R3SdAUbgnGqox+OuA3x2uO 3HRapGWYkRMVYl313J5cwpKg5RjcTVlpyEkvbGlrbwhcGMd1TZED9zbi5CiGMPlJ NpTM2nxfj+FxwS2Csn1mLkU7V+sQIsbL9rD+RVtx/45HPbFAAVyGWHKLwJ/WbFJl wSIXG9LH2H51ReyCVTiJFbly9L/VYZW6lPq2BN/IgACrlyUKF0MdDmORqm3R5mgG U5ugcCbShTHTZqHQ1Y0UZbo90MODm03jUvFWjic43RKb5WQan078wbd2VPze3MZv jeROweiqDYVbt3GV5UIln04fVCohJD0AIFzY57Pjlpniwpeibhtmycoq9X63bvxe 92m3pe3L6Inid9fnZEgHDqzF0fuZ/Ls9ARPPkoITO4EHhsyJ/fBFU464VngbDKJP TbKZFG6qUoVfHIV4bOYvIvwq+7WM3A5vh7nBmnmH1tb1CtJu5hLzU5XrtzSozQ19 dIMXjgMyqiIh9/l7R+2TNHGOkVbH6/0DmyewyLown+ujXaLviD3oehWvbjnr5iDU O2VOmdsKl3IsIr99zrwGIcgPU6ZX3JkB3BeMWnW8+/K/LvaNT+PDgFkI23Fu+pRj Oa3RwtuzOOZhhHGr3omEcGpZunoEesl9m5TOKXFFopFBHON1h+DlXQQEql5NBVPO xgAWX7Bc3NMnXTneMuzz =WKIg -----END PGP SIGNATURE----- --------------enig60127966FB3522E428BF2D2B-- From mcgrew@cisco.com Tue Jul 26 18:51:00 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC55211E8090 for ; Tue, 26 Jul 2011 18:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 TYaNE5cooDmk for ; Tue, 26 Jul 2011 18:51:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 156F011E8086 for ; Tue, 26 Jul 2011 18:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=747; q=dns/txt; s=iport; t=1311731460; x=1312941060; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=/7h77j64qyVr5C8lDFaGtVyjKuDYw2AdePSUtOcmaKQ=; b=fjxXu0lAQz0bQlVp2FrPzmfEE9UUi2vpcGkGyQO7EGAgpeZZzq0ZK8Gy 1QORyDVG7UEQ/G8HfAgscIIYTs85DXLQTD/e1lYbcH262Yoc13kr9gdFW 2agAXgLhLAi3mYpc9qpoRCjGdqpjZxqc5Bbl2QVkAc6VVaFI2NP481hob Y=; X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="6745805" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-8.cisco.com with ESMTP; 27 Jul 2011 01:50:59 +0000 Received: from dhcp-1783.meeting.ietf.org (bxb-vpn3-810.cisco.com [10.86.251.42]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R1owps002005; Wed, 27 Jul 2011 01:50:58 GMT Message-Id: From: David McGrew To: Philip Gladstone In-Reply-To: <4E2F38EE.2030401@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jul 2011 18:50:57 -0700 References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> <4E2F38EE.2030401@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 27 Jul 2011 01:51:00 -0000 On Jul 26, 2011, at 3:00 PM, Philip Gladstone wrote: > > > On 7/26/2011 5:17 PM, Yoav Nir wrote: >> >> I am wondering why you would need the ConnectionSecurityParameters >> structure. Wouldn't the 2-byte ciphersuite be a more compact way to >> represent this information? >> > Yes it would. Thank you for that comment! Agreed that much of the info is redundant with the ciphersuite, but there are some info that might be worth reporting on, such as the key sizes and the truncated HMAC extension. David > > Philip > > -- > Philip Gladstone > Distinguished Engineer > Product Development > pgladstone@cisco.com > Phone: +1 978-ZEN-TOAD (+1 978 936 8623) > Google: +1 978 800 1010 > Ham radio: N1DQ > > From mcgrew@cisco.com Tue Jul 26 18:54:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C011E8093 for ; Tue, 26 Jul 2011 18:54:13 -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 oiMFK1MzwpPC for ; Tue, 26 Jul 2011 18:54:13 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83111E8090 for ; Tue, 26 Jul 2011 18:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2432; q=dns/txt; s=iport; t=1311731653; x=1312941253; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=2YvS45ToNxpb9hMTD1/h9NC8upVF4t4hwUePhGBDcwc=; b=ZtO9DBSQ5GKOr3CN59CV6Az+JbmgM/cge8xjy6oZzAbRxl7u5K9C0q0X yqx6hHGpCnOSBi5qTjk29FcDqnpyzV8tuLxfHb4WFbivPbHDU/VtiSKcZ +SoDF3SPS89noCX00m/SC2iQ9ML4yLvfrpKlh3FZJVAVvLBFgpIV+TWP6 s=; X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="6745180" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 27 Jul 2011 01:54:13 +0000 Received: from dhcp-1783.meeting.ietf.org (bxb-vpn3-810.cisco.com [10.86.251.42]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6R1sCTK007396; Wed, 27 Jul 2011 01:54:12 GMT Message-Id: <404C4877-EEAC-44F3-BFCD-401919B09A66@cisco.com> From: David McGrew To: Yoav Nir In-Reply-To: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jul 2011 18:54:11 -0700 References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 27 Jul 2011 01:54:14 -0000 Hi Yoav, thanks for the good suggestions. David On Jul 26, 2011, at 2:17 PM, Yoav Nir wrote: > > On Jul 26, 2011, at 11:01 AM, David McGrew wrote: > >> Hi, >> >> I would like to request feedback on a new draft that Philip Gladstone >> and I put together, which aims to solve some of the security problems >> that happen when there is a (HTTP) proxy present and TLS is in use. >> The approach is to require the proxy to provide the client with >> additional information that the client can use to make a well- >> informed >> decision about the security of the session. This draft was put >> together too late to request a slot at the WG meeting this week, but >> if you have thoughts on either the goals or the mechanism, we can >> discuss either in person or on the list. >> >> David >> >> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 > > Hi Dave. > > I like this draft. TLS proxies are becoming a fact of life. They > still have significant drawbacks in that the "fake" certificates > that they generate are not identical to the original certificates. > For example, the fake certificates cannot be EV certificates, and > therefore the users lose the "green-bar" indication. > > I don't know if you're following the LockFoo discussion on WebSec, > but all of those locks would cause a hard-fail for clients > connecting to sites that have specified them. As security people we > might think "good!", but that would actually be a bar to > implementations of LockFoo more than it would be a bar to deployment > of TLS proxies. Giving the client access to the original > certificates would allow the browser to overcome this limitation. > > A similar argument also applies to DANE. If the DNS entry identifies > the key, the certificate or the CA, then the "fake" certificate > would cause an error. Access to the original certificate chain > allows the client to eliminate the error message, although I am not > sure how the browser UI would indicate an EV certificate proxied > through a non-EV proxy. > > I am wondering why you would need the ConnectionSecurityParameters > structure. Wouldn't the 2-byte ciphersuite be a more compact way to > represent this information? > > Also I would add text about EV certificates (and maybe also the > LockFoo cases of DANE and WebSec) to the motivation section. > > Yoav > From yngve@opera.com Tue Jul 26 19:04:14 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E166811E8086 for ; Tue, 26 Jul 2011 19:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.885 X-Spam-Level: X-Spam-Status: No, score=-6.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 WcVEcQr0ILex for ; Tue, 26 Jul 2011 19:04:14 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B969A11E80CB for ; Tue, 26 Jul 2011 19:04:13 -0700 (PDT) Received: from lessa-ii.oslo.os (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6R248CT023441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Jul 2011 02:04:10 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Matt McCutchen" References: <1311725122.7071.23.camel@localhost> Date: Wed, 27 Jul 2011 04:04:15 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <1311725122.7071.23.camel@localhost> User-Agent: Opera Mail/10.62 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] Request for mail testserver with TLS accepting renegotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 02:04:15 -0000 On Wed, 27 Jul 2011 02:05:22 +0200, Matt McCutchen wrote: > On Wed, 2011-07-27 at 01:55 +0200, Yngve N. Pettersen wrote: >> I have recently upgraded my TLS Prober to test email servers (IMAP, POP, >> SMTP). >> >> However, I am uncertain about whether the test for testing client >> initiated renegotiation works properly, particularly since a test of >> 300000+ servers failed to detect a single email server that accepted it >> (or requested it). >> >> It might of course be that all email servers have this functionality >> disabled, but for now I am assuming something is wrong about how the >> test >> itself works. >> >> If anyone have an email server that is configured to accept client >> initiated renegotiation that I could test, I would appreciate it. > > Is your test in any way specific to email protocols? If you just run > "openssl s_server" interactively, it seems to accept all > client-initiated renegotiation by default (at least when renegotiation > indication is used). I already know it works against HTTPS servers (which gives some problematic statistics for unpatched servers), but the tests against email servers follow a different pattern, since the email servers send content before the client send data, so there could be a difference in behavior. Possibilities include having to get the start line from the server before trying renegotiation, rather than try immediately. While I might try configuring a OpenSSL testserver, I would prefer to test against the "real thing". -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** From mcgrew@cisco.com Tue Jul 26 19:04:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004555E8012 for ; Tue, 26 Jul 2011 19:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oc8Nkm6DkVnz for ; Tue, 26 Jul 2011 19:04:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C1E4F5E8018 for ; Tue, 26 Jul 2011 19:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1825; q=dns/txt; s=iport; t=1311732268; x=1312941868; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=r6FvzGKqQ0xhG9pzJozgKdXoTIutFyzmdgRgwDpJAgo=; b=UNJIoY7uZ443KDBmR7uzpgaxKozHciC+kJfZSjxNGEu/7K1rwPlEx8GS gEOXnWhTsRluqp8bmhZNuFYls3EBvHWAVQ/zL1c/btIRqnTpj9oVtFe+i O9OGugzrZlo1m4NWHpSUmRpWf6PJaN0+9fL1xKJwzCWfS72STzgaWnMQ+ A=; X-IronPort-AV: E=Sophos;i="4.67,272,1309737600"; d="scan'208";a="104522010" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2011 02:04:26 +0000 Received: from dhcp-1783.meeting.ietf.org (bxb-vpn3-810.cisco.com [10.86.251.42]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6R24Pxq009125; Wed, 27 Jul 2011 02:04:25 GMT Message-Id: <8D96B7EB-4A2E-4EC8-8BF4-FF272C50C838@cisco.com> From: David McGrew To: Adam Langley In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 26 Jul 2011 19:04:24 -0700 References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 27 Jul 2011 02:04:30 -0000 Hi Adam and Yoav, On Jul 26, 2011, at 2:51 PM, Adam Langley wrote: > On Tue, Jul 26, 2011 at 5:41 PM, Yoav Nir wrote: >> Really? I thought Chrome used the operating system TA store. How >> can it tell the difference between a trust anchor that was >> installed by Microsoft and one that was installed by the user? > > Not in any very clean way I'm afraid: > > http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_known_roots_win.h?revision=80765&view=markup > >> But I know that the EV indication goes away behind a proxy, and >> there's no way to make your CA certificate "EV" to the browser. >> Dave's proposal allows the green label to come back. > I like the succinct way that you put it. > I've poked BlueCoat at least about this problem in the past and they > didn't appear to be too exercised by it. It's really the MITM folks > who need to figure out if this address their needs or not. I simply > don't know the requirements in this space well enough to know if the > draft meets them. From my point of view, we keep MITM in the back of > our minds but otherwise mostly ignore them except to ban certain > troublesome vendors from time to time. > I believe that the approach in the draft meets the broad requirements of many MITM devices and services: it doesn't require much new session state, or new policy that would need to be coordinated or managed, and there is not too much additional computation. That plus it adds back security, which is important in general and is especially important for proxy devices that are providing security services. But I can't claim to have broad knowledge of all such devices, so it will be useful to hear from others in this space. David > > Cheers > > AGL From matt@mattmccutchen.net Tue Jul 26 19:42:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C5E11E80CB for ; Tue, 26 Jul 2011 19:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 b+ZXpR0CCOLf for ; Tue, 26 Jul 2011 19:42:34 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7917211E80A5 for ; Tue, 26 Jul 2011 19:42:34 -0700 (PDT) Received: from homiemail-a37.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTP id 263D820806B; Tue, 26 Jul 2011 19:42:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=X7/0tjCVhhvosw0agIQoh3+P6cofvN5E/lb5yREamTy fJh7JcDhBu/Q5dxTEDNji62ku0odr1VRbmh7pROQfqyHUBoYyNHXixqKdTpvCx7K tzFVTX4bsPaHk9zTjR+KW2KF6xMMhV+qV5HsbXnNXkjPr0umtcYLmVHZi7kPWMUo = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=8oyKKW4gFlEwrT981FZkBpLo4nM=; b=VLmpqB21pY oXRyqRs74in+w/v59DsRYlzxnjPbYpxdhfSEXNz9iQttUIREXuBUjnpfNuftSnf7 r+H+yNmOuwkQWlJc8rLXsaIDq2h3unYfc7uzEXkNyK1R7qQbNK73aC6EMNbAEOmJ OQGU2O9aXLOCohUPK2kg628vB/cd/iG0k= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a37.g.dreamhost.com (Postfix) with ESMTPSA id 8969D208069; Tue, 26 Jul 2011 19:42:33 -0700 (PDT) From: Matt McCutchen To: David McGrew In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 26 Jul 2011 22:42:30 -0400 Message-ID: <1311734551.7071.72.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 27 Jul 2011 02:42:35 -0000 On Tue, 2011-07-26 at 08:01 -0700, David McGrew wrote: > I would like to request feedback on a new draft that Philip Gladstone > and I put together, which aims to solve some of the security problems > that happen when there is a (HTTP) proxy present and TLS is in use. It doesn't seem that this work is in any way specific to HTTP. Suggestions: - If you're going to require support from the client, you might as well do something to support client authentication on the server-side connection, e.g., tunnel the PKCS#11 protocol back to the client. - You could bundle the whole sequence of handshake messages from the server-side connection in the ProxyInfo and let the client deal with it rather than muck about with the ConnectionSecurityParameters here. This would include any further ProxyInfos without making a special case. - It would be better design to put the whole certificate acceptance test (trust anchor validation + server name check) on the client. Schemes such as DANE replace the certificate acceptance test as a whole. - One approach would be to do a real escrowed TLS where the client negotiates directly with the server but releases the confidentiality key and optionally also the integrity key to the proxy. This subsumes all of the above concerns but doesn't allow the proxy to manipulate the handshake in any finer way than blocking the connection if it doesn't like the outcome. -- Matt From matt@mattmccutchen.net Tue Jul 26 20:07:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6183011E80DE for ; Tue, 26 Jul 2011 20:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lipynjknt4Yw for ; Tue, 26 Jul 2011 20:07:20 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50D11E80CB for ; Tue, 26 Jul 2011 20:07:20 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 57356280071; Tue, 26 Jul 2011 20:07:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=qi5Tg5YRVAw+S9+ehQzt/IKauakU3fBOYgwtfX3k+r5 15OXiY/NXi4G9ldRy6yQ2VCmr18YHsHhSh36BOaUyhC5Y2qt7vUf0v5rbg3jfm8I G5ExGOHfb4YLmSCX536Z1vbykiiO4QoTmvCGI+8Ai+fu2A4Pdz1BEGgAJFR9XBV8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=qv0NF0zrlkNdVtgEmcaRJ7r6nIM=; b=Q2MbPQta55 /UeAinWusxsj7eKFHEhEYZWsrJRYNHdSmEH1y4KEqz5tvybmJq759WP4qXNeCEGR 6FlQieaPOwnIrWfLWGoCk6zizkCHL6C1YhGGA77P4/BzEqh/Abpx0/xjfDHvKR2f 6m+IOdkspl/XyaZD9efILUz+xUlFZAx4g= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id CD88E280069; Tue, 26 Jul 2011 20:07:19 -0700 (PDT) From: Matt McCutchen To: Adam Langley In-Reply-To: References: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 26 Jul 2011 23:07:17 -0400 Message-ID: <1311736037.7071.81.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: [TLS] Certificate pins vs. MITM proxies X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 03:07:21 -0000 On Tue, 2011-07-26 at 17:51 -0400, Adam Langley wrote: > On Tue, Jul 26, 2011 at 5:41 PM, Yoav Nir wrote: > > Really? I thought Chrome used the operating system TA store. How can it tell the difference between a trust anchor that was installed by Microsoft and one that was installed by the user? > > Not in any very clean way I'm afraid: > > http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_known_roots_win.h?revision=80765&view=markup Yeah, that approach ensures that the pins you ship by default do not break MITM proxies (since public CAs are bound not to support MITM proxies, or at least we have no sympathy for them if they do), but it also (arguably) negates their promised benefits in environments with custom CAs, a superset of those with MITM proxies. That choice of trade-off is understandable but pretty disappointing. Power users will want to designate MITM-proxy CAs explicitly. I guess I could file an enhancement request... -- Matt From pgut001@login01.cs.auckland.ac.nz Tue Jul 26 20:51:35 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F37721F84A1 for ; Tue, 26 Jul 2011 20:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 0euxzXB08Crq for ; Tue, 26 Jul 2011 20:51:34 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7B78721F849F for ; Tue, 26 Jul 2011 20:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311738695; x=1343274695; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20tls@ietf.org|Subject:=20Re:=20[TLS]=20HTTPS=20clie nt-certificate-authentication=20in=20browsers |In-Reply-To:=20<4E2F5BA0.4020507@fifthhorseman.net> |Message-Id:=20|Date:=20Wed,=2027=20Jul=202011=2015:51:20=20+1200; bh=9VRW2igjliYnyQ3ui65jvJKqqdnZ2gTuuzgkbC+ZnpE=; b=EuXky1YX2N5/EvnQ4JYrqHJjZaJbLe3MFjYRFqib8u3yg7qsbUYhpgK+ AX9ACgxXzHb0R5hFMQKvbrnm6htjaBEizg3BG3T2uiyvDjnDNZJ2XJyoR GjfJOFyuHpg1KUBO6rfTdGcTWQD4P4eY5roQjeEHaEX5JHBhj7hrnpw4j s=; X-IronPort-AV: E=Sophos;i="4.67,273,1309694400"; d="scan'208";a="74323957" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jul 2011 15:51:21 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qlv9U-0006uP-Iy for tls@ietf.org; Wed, 27 Jul 2011 15:51:20 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qlv9U-0005Gx-RA for tls@ietf.org; Wed, 27 Jul 2011 15:51:20 +1200 From: Peter Gutmann To: tls@ietf.org In-Reply-To: <4E2F5BA0.4020507@fifthhorseman.net> Message-Id: Date: Wed, 27 Jul 2011 15:51:20 +1200 Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 03:51:35 -0000 Daniel Kahn Gillmor writes: >Am i missing something that makes this approach difficult or wrong? See the reference to the study I posted earlier (one of numerous studies with similar results) that found that people with PhDs in computer science took over two hours just to configure a cert for use on their machine, and rated it as the hardest computer task they'd ever been asked to perform. You've looked at the trivial part and completely missed the real problem, which is: When the user visits that URL with an acceptable client-side certificate You're not starting with "a user visiting a URL with an acceptable client-side certificate", you're starting with "Joe Sixpack sitting in front of a PC (that has no certificates)". Your challenge is to design, implement, and demonstrate successful use of, a mechanism to get from "Joe Sixpack in front of his computer" to "a user visiting a URL with an acceptable client-side certificate". All the evidence we have so far for this, from real-world evaluations, is that it can't be done except in carefully-controlled environments, at enormous cost and effort. Peter. From matt@mattmccutchen.net Tue Jul 26 21:16:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE9C21F8A30 for ; Tue, 26 Jul 2011 21:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bLJv7rdb2cy for ; Tue, 26 Jul 2011 21:16:50 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2189921F89A1 for ; Tue, 26 Jul 2011 21:16:50 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id E101D57806E; Tue, 26 Jul 2011 21:16:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=GeS9nH5W4rGmV/pPYVB2mj/9XeKBk/m8qmxjBJWX3XE EgZdGoc4EN76T00TnpZynBi4jKmXglxuLutOvBdiTeQx+JfQdUlrqIeoO0W0hkLg vaRMsRAppzz1e5IDj9eyDGNLfdHnrxnUjI2TLEQvLyrsOnJ9UR7SXq4QhhrdvxY0 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=IeKwWMfyJPGgi5JxT9AQUVqsJHo=; b=glaDj9y3qh 7rML7cQxeKuBsEj80Ztd939VpGL/WSTMK/Uk27UFAd41VxfjO5aZs4iQWAWmUM4V hEyFCbL9+h1OaRaxFMkgrC7grJS2F+7rFK9hW+80ACCrpQwm07788ryFXcmowYQs HIAffnT9OoN3o2nhVoR8+YX/+gcdiiOv0= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 73BAD57806C; Tue, 26 Jul 2011 21:16:49 -0700 (PDT) From: Matt McCutchen To: Peter Gutmann In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 27 Jul 2011 00:16:46 -0400 Message-ID: <1311740206.7071.87.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 04:16:51 -0000 On Wed, 2011-07-27 at 15:51 +1200, Peter Gutmann wrote: > See the reference to the study I posted earlier (one of numerous studies with > similar results) that found that people with PhDs in computer science took > over two hours just to configure a cert for use on their machine, and rated it > as the hardest computer task they'd ever been asked to perform. Your reference to people with PhDs in computer science is misleading: a PhD is a highly specialized degree that does not necessarily imply broad computing ability. The point that certificate enrollment is a pain stands. -- Matt From anders.rundgren@telia.com Tue Jul 26 21:22:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45EE11E8079 for ; Tue, 26 Jul 2011 21:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 y++hNqyb+VJJ for ; Tue, 26 Jul 2011 21:22:57 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id DCEA511E8074 for ; Tue, 26 Jul 2011 21:22:56 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00E0E364; Wed, 27 Jul 2011 06:22:55 +0200 Message-ID: <4E2F928E.7060106@telia.com> Date: Wed, 27 Jul 2011 06:22:38 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: tls@ietf.org References: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> <4E2F1B65.2080404@telia.com> <4E2F5BA0.4020507@fifthhorseman.net> In-Reply-To: <4E2F5BA0.4020507@fifthhorseman.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 04:22:57 -0000 On 2011-07-27 02:28, Daniel Kahn Gillmor wrote: > On 07/26/2011 09:54 PM, Anders Rundgren wrote: >> It actually quite hard writing an HTTPS CCA based web app that >> has similar login and session characteristics as one using password >> authentication. > > What's so hard about it? Designate a URL (e.g. > http://example.com/login) that triggers a request for client-side > certificates. When the user visits that URL with an acceptable > client-side certificate, set a session cookie, and redirect them back to > the page they were coming from. > > When the user is not logged in, show them a login link that points to > the designated URL. > > When they are logged in, show them a logout link that takes them to a > URL that clears the session cookie. > > Am i missing something that makes this approach difficult or wrong? Unlike a web application using passwords as authentication method, you must run the HTTPS login on another port (which typically conflicts with standard firwewall settings), and if you want logout to work you need to kill the TLS cache in the client using methods that at best 1 out of 100 000 "Web Programmers" have ever heard about: Extract from a web-app of mine: if (document.all == null) // FF, Opera, etc { if (window.crypto) window.crypto.logout(); } else // MSIE 6+ { document.execCommand('ClearAuthenticationCache'); }; We are (de-facto) stuck with stuff that (from this perspective NB) hasn't progressed much since Netscape introduced SSL back in 1995. Anders From pgut001@login01.cs.auckland.ac.nz Tue Jul 26 22:34:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18335E801D for ; Tue, 26 Jul 2011 22:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.621 X-Spam-Level: X-Spam-Status: No, score=-3.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 l1RPhIUr3Iy5 for ; Tue, 26 Jul 2011 22:34:22 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id BC96221F8B99 for ; Tue, 26 Jul 2011 22:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311744862; x=1343280862; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20matt@mattmccutchen.net,=20pgut001@cs.auckland.ac.n z|Subject:=20Re:=20[TLS]=20HTTPS=20client-certificate-aut hentication=20in=20browsers|Cc:=20tls@ietf.org |In-Reply-To:=20<1311740206.7071.87.camel@localhost> |Message-Id:=20|Date:=20Wed,=2027=20Jul=202011=2017:34:11=20+1200; bh=3EsHSgHsP2YxBbhCzkwGjg6kKPRGgVzE/3IsAXOqu0E=; b=K32TJbITGd3sFyZFuc/KawTpLnA8ej9DNwLbP7LrWyB47ullzUqk2gfS iD+pX8FAr9zS6gqGhcP3jg25f5NlfhvnKAOE9SElZrCcQXiEIaRhHU+Dj NkTyrmJUzDYVC5ao6plJETUQ8ixHZ/zTrxvWS6jftPj1OYCJjN1iFAjxf c=; X-IronPort-AV: E=Sophos;i="4.67,274,1309694400"; d="scan'208";a="74355184" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 27 Jul 2011 17:34:11 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qlwl1-0003FA-HR; Wed, 27 Jul 2011 17:34:11 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qlwl1-0003tZ-Bf; Wed, 27 Jul 2011 17:34:11 +1200 From: Peter Gutmann To: matt@mattmccutchen.net, pgut001@cs.auckland.ac.nz In-Reply-To: <1311740206.7071.87.camel@localhost> Message-Id: Date: Wed, 27 Jul 2011 17:34:11 +1200 Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 05:34:22 -0000 Matt McCutchen writes: >Your reference to people with PhDs in computer science is misleading: a PhD >is a highly specialized degree that does not necessarily imply broad computing >ability. "OK, so you have a PhD. Just don't touch anything" :-). That was just the first study, and I mentioned the PhD thing to avoid the "it was carried out on students, they're not representative" criticism. Other studies were carried out on IT students (which I'd say is actually a good sample of very tech-savvy users, so they'd be non-representative in being too good a fit rather than too bad a fit), and possibly on random samples of people (I'd have to trawl through the refs again to see who all the subjects were). From memory I don't think any were done on the Joe-Sixpack demographic, probably because the outcome would be a foregone conclusion ("Failure to enrol: 100%"). Peter. From henry.story@bblfish.net Wed Jul 27 00:23:40 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204C721F8AA8 for ; Wed, 27 Jul 2011 00:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 yEDSyZTWycFP for ; Wed, 27 Jul 2011 00:23:39 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E32D621F8AAC for ; Wed, 27 Jul 2011 00:23:38 -0700 (PDT) Received: by wwe5 with SMTP id 5so720231wwe.13 for ; Wed, 27 Jul 2011 00:23:37 -0700 (PDT) Received: by 10.217.6.81 with SMTP id x59mr5751845wes.50.1311751417618; Wed, 27 Jul 2011 00:23:37 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id k9sm840211weq.3.2011.07.27.00.23.34 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 00:23:36 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Henry Story In-Reply-To: <4E2F5BA0.4020507@fifthhorseman.net> Date: Wed, 27 Jul 2011 09:23:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3553F681-866E-4068-A4C9-C205529E4328@bblfish.net> References: <201107261911.p6QJB3Dv011457@fs4113.wdf.sap.corp> <4E2F1B65.2080404@telia.com> <4E2F5BA0.4020507@fifthhorseman.net> To: tls@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 07:23:40 -0000 On 27 Jul 2011, at 02:28, Daniel Kahn Gillmor wrote: > On 07/26/2011 09:54 PM, Anders Rundgren wrote: >> It actually quite hard writing an HTTPS CCA based web app that >> has similar login and session characteristics as one using password >> authentication. >=20 > What's so hard about it? Designate a URL (e.g. > http://example.com/login) that triggers a request for client-side > certificates. When the user visits that URL with an acceptable > client-side certificate, set a session cookie, and redirect them back = to > the page they were coming from. >=20 > When the user is not logged in, show them a login link that points to > the designated URL. >=20 > When they are logged in, show them a logout link that takes them to a > URL that clears the session cookie. >=20 > Am i missing something that makes this approach difficult or wrong? I think the logout piece is not very well known. I only just discovered = it a few weeks ago, and have not tried it yet. Anders pointed this out to = me that the following works in browsers for logout. if (document.all =3D=3D null) // FF, Opera, etc { if (window.crypto) window.crypto.logout(); } else // MSIE 6+ { document.execCommand('ClearAuthenticationCache'); }; ( I spent a lot of time looking to see what could be done with throwing=20= error conditions on the TLS level, and there most browsers don't seem to respond correctly ) But apart from that, you are right it is not very complex. Perhaps what = slows=20 things down a lot are server side certificates, which need to be bought=20= (though there is a free CA), are more complex to set-up. But this kind = of=20 thing could be automated easily as soon as the usefulness of this method = of authentication=20 were demonstrated by some large services. Also DNSsec and DANE will = remove some obstacles described by Dan Kaminsky presented by having CAs in the first place. So things will in fact get simpler from now on. Even creation of client side certificates is really easy, once one has located the client libraries, one knows about keygen and one has the javascript for the IE version. Client side certificates is a one = click of a=20 button affair in fact. So there is a big part of eduction that is the issue in the so called complexity of CCA. There are much more complex things out there, with thousands of engineers finding no trouble learning those. ----------------------------- What is missing: the use case ----------------------------- But what is missing in CCA is the use case. The problem is that if you use CCA then you can also use password authentication. And because for the most part CCA only logs you into *one* server - the one that gave = you the Certificate - you gain little advantage over password authentication. = And where there is no benefit to be gained, it is very difficult to explain something to people - both end users and developers of the feature. Take this together with the confusion about the idea that one has to keep one's certificate secure and one has created a huge amount of confusion. So the important thing is to create a use case that takes client = certificates from where they are, to being one million times more valuable, while = remaining zero cost. This is what http://webid.info/ - a W3C project - allows. By = placing a WebID into the subject alternative name of the X509 we get the following = advantages: - the same certificate could then be used to login to every site on the = web - attributes about the user need not be placed in the certificate but = can be placed=20 on the web, where they can be access controlled - it is dead easy to do certificate revocation: just remove the public = key from the profile document. Here the value of certificates really starts to shine. But we need to = bootstrap this to make the point clearly. So please help us by developing more fun = usages of WebID. Here is the simplest paper: = http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webi= d.html Henry >=20 > --dkg >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From henry.story@bblfish.net Wed Jul 27 00:46:47 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59421F8666 for ; Wed, 27 Jul 2011 00:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.43 X-Spam-Level: X-Spam-Status: No, score=-3.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 0KJYldYf+CxH for ; Wed, 27 Jul 2011 00:46:46 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AE66221F85B2 for ; Wed, 27 Jul 2011 00:46:45 -0700 (PDT) Received: by wwe5 with SMTP id 5so731905wwe.13 for ; Wed, 27 Jul 2011 00:46:44 -0700 (PDT) Received: by 10.216.14.85 with SMTP id c63mr54259wec.67.1311752804670; Wed, 27 Jul 2011 00:46:44 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id k84sm847953weq.46.2011.07.27.00.46.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 00:46:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Wed, 27 Jul 2011 09:46:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0ACE11A7-2DF7-4658-8E4D-79E25DBDBFDA@bblfish.net> References: To: Peter Gutmann , tls@ietf.org X-Mailer: Apple Mail (2.1244.3) Cc: WebID XG Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 07:46:47 -0000 On 27 Jul 2011, at 07:34, Peter Gutmann wrote: > Matt McCutchen writes: >=20 >> Your reference to people with PhDs in computer science is misleading: = a PhD >> is a highly specialized degree that does not necessarily imply broad = computing >> ability. >=20 > "OK, so you have a PhD. Just don't touch anything" :-). That was just = the > first study, and I mentioned the PhD thing to avoid the "it was = carried out on > students, they're not representative" criticism. Other studies were = carried > out on IT students (which I'd say is actually a good sample of very = tech-savvy > users, so they'd be non-representative in being too good a fit rather = than too > bad a fit), and possibly on random samples of people (I'd have to = trawl > through the refs again to see who all the subjects were). =46rom = memory I don't > think any were done on the Joe-Sixpack demographic, probably because = the > outcome would be a foregone conclusion ("Failure to enrol: 100%"). Yes, and the reason for this is very simple: every Joe six-pack is = intelligent enough to see that client side certificates gives him no advantage over=20= username passwords! Why? For two reasons: - Most client side certificates only work only with one site (unless = you are in the army, or a few places like that) - For that site you need a password anyway - in case you loose your = certificate Joe Six Pack has a lot of work, following what's going on TV and = following complex scores between football teams to be bothered learning something that = gives no advantage. ( And here we are assuming that the testers would have understood how to = make it easy=20 to do 1 click certificate creation, how to do logout properly, and how = to develop a=20 web site that takes into account the special features of TLS - which = I highly doubt. ) OpenId has the same problem: most sites ask you to login with an OpenID = and then once you have ask you for a username and password! Well how is anyone going to = get the point of OpenId if that is going to be the way they are introduced to it?=20 Notice that Facebook Connect by giving access to a social graph provides = in their=20 authentication system an advantage that cannot be simply bypassed by the = Relying Party: no relying party is going to ask all the logged in users to enter all = their social network right after authentication.=20 So this is where WebIDs advantage is: it decentralised Facebook Connect = by tying it to Client Side Certificates - removing one of its most problematic = features. But http://webid.info/ ties an identity into the social web. WebID allows = the same CCA to be used on ANY webiste that implements it, and at the same time to = help that site ( the Relying Party as they are known in this ugly jargon ) to get = access to the social graph of the user - if that user is interested in presenting = it. No as soon as you have those advantages, then the benefit to Joe Sixpack = becomes obvious. He can now login as a fan to any of the football league sites in one = click, and comment on discussions, play games, organise meetings, order tickets for = football matches and=20 so on. He can create a football social network that is not centralised = in one country or by one organisation. He can use his football fan credentials to login = to a football producer site - in one click - to explain what is wrong with the = football they are making. And if there is a beer advert on TV with a special offer for Fans he can = get that in=20 one click.=20 That is how you convince football fans. Once you have convinced them, = you can convince the developers who are also football fans, because you have convinced their = managers who=20 can see the point in this. And you also convince the EFF because = otherwise Facebook is going to completely take over all authentication on the web and we = really have a big=20 brother situation. WebID is Freedom Box friendly. Henry - http://webid.info/ - http://www.freedomboxfoundation.org/ >=20 > Peter. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From anders.rundgren@telia.com Wed Jul 27 01:19:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C0421F8B6E for ; Wed, 27 Jul 2011 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 Y3wu4ugi+eso for ; Wed, 27 Jul 2011 01:19:17 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 3170A21F852C for ; Wed, 27 Jul 2011 01:19:17 -0700 (PDT) Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F007E1C9B; Wed, 27 Jul 2011 10:19:12 +0200 Message-ID: <4E2FC9F3.10205@telia.com> Date: Wed, 27 Jul 2011 10:18:59 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107262051.p6QKpxAd017550@fs4113.wdf.sap.corp> In-Reply-To: <201107262051.p6QKpxAd017550@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 08:19:18 -0000 Martin, AFAICT you indirectly say that the de-facto standard for maintaining (note, not creating) secure sessions on the web, i.e. server-side HTTPS + session cookies is inferior. The fact is that exactly $0 has been spent by the people building and defining the TLS/HTTPS platforms on *researching* the issues I mentioned, while *hundreds of millions of dollars* has been spent on *code* that merges client-side PKI and the web in other ways than using HTTPS CCA. FWIW, InformationCards (now close to an OASIS standard), do not use HTTPS CCA for authentication to the IDP, but server-side HTTPS and client-side signed request data. Anders On 2011-07-26 22:51, Martin Rex wrote: > Anders Rundgren wrote: >> >> You have a rather elitist way of discussing things. >> >> It actually quite hard writing an HTTPS CCA based web app that >> has similar login and session characteristics as one using password >> authentication. > > But that is a clear abuse of the TLS client certificate technology > and _not_ supposed to be usable in this fashion. > > >> >> In your opinion this is an advantage; in my world it represents a >> hurdle for adoption. > > If you are _not_ looking for seamless single Sign-On, then > TLS client certs are not the right tool for what you want to > accomplish (square peg, round hole). > > >> >> Anyway, banks are investing huge in app-level PKI authentication >> so there is apparently a huge ignorant crow out there. > > But if the "frontend" they are using something as security-broken > as a plain web browser, then the technology they would need > is a "frontend signing" browser plugin to produce PKCS#7/CMS signed data > over well-definied application protocol units. > > >> >> The there are some really interesting differences in path building >> (which of course is NOT specified at all by TLS) that for example >> have forced people importing immediate CAs to PC before being able >> to login using a smart card. > > What particular problem are you facing? > > > The TLS protocol is _very_ clear that a Certificate message must > contain a FULL path, omitting _at_most_ the self-signed certificate > at the end. There are several TLS implementations out there with > significant brokeness with respect to the Certificate handshke > message (e.g. OpenSSL) which will omit more than just the > self-signed certificate at the end of the certification path, > send certificates out-of-order and even include arbitrary > non-path certificates. Things that could be trivially checked > and reported as configuration errors on the server side upfront, > instead of dumping garbage on communication peers in clear > violation of the specification. > > > -Martin > From ekr@rtfm.com Wed Jul 27 07:33:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4B21F8574 for ; Wed, 27 Jul 2011 07:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9DPvApK4yQ0 for ; Wed, 27 Jul 2011 07:33:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id E11DA21F8551 for ; Wed, 27 Jul 2011 07:33:36 -0700 (PDT) Received: by wwe5 with SMTP id 5so975937wwe.13 for ; Wed, 27 Jul 2011 07:33:35 -0700 (PDT) Received: by 10.227.58.74 with SMTP id f10mr128049wbh.22.1311777215123; Wed, 27 Jul 2011 07:33:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Wed, 27 Jul 2011 07:33:15 -0700 (PDT) From: Eric Rescorla Date: Wed, 27 Jul 2011 10:33:15 -0400 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Setting Policy for Extensions 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, 27 Jul 2011 14:33:37 -0000 TLS WG members, The WG is starting to see an increasing number of proposals for new extensions, and it seems like it would be good to have a consistent policy for how to handle these. The chairs have gotten together with our AD and converged on the following draft policy, which we plan to discuss in the " Working Group Handling for Extensions to TLS" slot. Comments? -Ekr [For Joe and Eric] RFC 5246 defines an extensibility mechanism for TLS based on extensions signaled in the ClientHello and ServerHello. With TLS 1.2 and DTLS 1.2 being relatively stable, we are starting to see more proposed extensions, some of which, if used, represent significant changes to the TLS state machine. RFC 5246 requires IETF consensus for any extension. As there is an active TLS WG, this implies that extensions must be vetted with that WG. The following policy describes the level of review necessary for various types of proposed extension: 1. All extensions to TLS (including AD sponsored extensions) must minimally be sent explicitly to the TLS WG prior to or during IETF LC. If that process surfaces significant objections, then these objections should be resolved prior to publication. For trivial extensions, this process is sufficient. An example of a trivial extension would be signaling for a new TLS Exporter (RFC 5705), as this has no impact on TLS proper. 2. All non-trivial extensions (i.e., anything which alters TLS processing in some way) must be presented to the TLS WG and at least be considered unobjectionable. They need not be WG items. Extensions in this category can proceed without widespread WG support, but must either have no significant objections or achieve WG consensus to proceed. An example of a non-trivial extension would be one that defined a new form of MAC truncation. This alters TLS processing but not the state machine. 3. Extensions which which involve significant changes to the TLS model/state machine, adds new messages, etc. must be TLS WG work items, or, if primarily designed for some other WG, must be work items of that WG and developed in collaboration with the TLS WG and subject to the WG consensus process. Extensions in this category will generally need to show significant amounts of non-author support in order to proceed. Particular attention will be paid to the impact of such extensions on the TLS architecture and the impact on potential future extensions. An example of such an extension would be TLS Tickets (RFC 4507), because it involved redoing the resumption state machine and adding a new TLS message. The WG considers it an important objective to to provide timely, clear dispositions of new efforts. Work will be taken on when there is consensus and based on the WG's estimate of the level of interest and the size and priority of the current workload. Reconsideration of proposals which have failed to gather consensus will be prioritized behind proposals for new work which have not yet been considered. In general, requests for reconsideration should only be made once a proposal has been significantly revised and there is evidence of substantial level of community support. Best, -Ekr From n.mavrogiannopoulos@gmail.com Wed Jul 27 09:03:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5511E80DA for ; Wed, 27 Jul 2011 09:03:31 -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 P8VTdQ57Td+E for ; Wed, 27 Jul 2011 09:03:31 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C007211E80B1 for ; Wed, 27 Jul 2011 09:03:30 -0700 (PDT) Received: by wwe5 with SMTP id 5so1042900wwe.13 for ; Wed, 27 Jul 2011 09:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=xUkMfw2wwrbyNtWNzb2FsAP+hEP8l30Y3wV2zops3X8=; b=b4D+NlQ8sQenRMUt8uUoEiIlWLInJuswG3EsMLflQ0rvLHVBqu52zQB8tK4YyS6Ojs 8JAs7XeC9LmM5PdUl8QmXeLvP6XkQXep0Mep09u8O9k2olyJSmP1MiyCQe16jwML4uYr Qwg+GkHhAYy6n2hP0X7EInb96ddltfkqRycF4= Received: by 10.227.181.9 with SMTP id bw9mr3580654wbb.38.1311782609822; Wed, 27 Jul 2011 09:03:29 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id 20sm20578wbw.2.2011.07.27.09.03.27 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 09:03:28 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E3036CE.6080901@gnutls.org> Date: Wed, 27 Jul 2011 18:03:26 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 27 Jul 2011 16:03:31 -0000 On 07/27/2011 04:33 PM, Eric Rescorla wrote: Hello, > 1. All extensions to TLS (including AD sponsored extensions) must > minimally be sent explicitly to the TLS WG prior to or during IETF > LC. If that process surfaces significant objections, then these > objections should be resolved prior to publication. For trivial > extensions, this process is sufficient. An example of a trivial > extension would be signaling for a new TLS Exporter (RFC 5705), as > this has no impact on TLS proper. How can that be enforced? In general I see little point of TLS-relevant documents being processed outside the TLS WG. > 3. Extensions which which involve significant changes to the TLS > model/state machine, adds new messages, etc. must be TLS WG work > items, or, if primarily designed for some other WG, must be work > items of that WG and developed in collaboration with the TLS WG and > subject to the WG consensus process. Extensions in this category will > generally need to show significant amounts of non-author support in > order to proceed. Particular attention will be paid to the impact of > such extensions on the TLS architecture and the impact on potential > future extensions. An example of such an extension would be TLS > Tickets (RFC 4507), because it involved redoing the resumption state > machine and adding a new TLS message. This is a significant barrier to publish a TLS WG draft. Even the current ones do not fulfill this requirement. Questions: 1. How to show significant amount of non-author support? 2. Who will pay attention to the impact of those extensions? In general it is not clear what the requirements of (3) are. Requiring significant amount of non-author support sounds like an author has to convince 30 reviewers to read and agree with his document. This is not going to happen. I think having a concrete requirement, such as review and positive opinion by 1-2 wg members set by the chair should be enough to be adopted as WG draft (not that a WG draft does not imply publication as RFC). regards, Nikos From henry.story@bblfish.net Wed Jul 27 09:15:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27B221F877D for ; Wed, 27 Jul 2011 09:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, 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 SA5pScQRyfJQ for ; Wed, 27 Jul 2011 09:15:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADA721F84BF for ; Wed, 27 Jul 2011 09:15:25 -0700 (PDT) Received: by wyj26 with SMTP id 26so1078477wyj.31 for ; Wed, 27 Jul 2011 09:15:13 -0700 (PDT) Received: by 10.216.134.82 with SMTP id r60mr4877wei.13.1311783312014; Wed, 27 Jul 2011 09:15:12 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id l68sm23869weq.10.2011.07.27.09.15.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 09:15:10 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_E1CBF6AD-EADA-483D-9071-57EC6285E4C4" From: Henry Story In-Reply-To: Date: Wed, 27 Jul 2011 18:15:08 +0200 Message-Id: <3BD3E194-FD9E-4BC8-B7A6-E291DA22A895@bblfish.net> References: <4E09BC6A.80004@telia.com> <7F6C35A3-09F5-4E98-BE83-C45235E14669@bblfish.net> <4E09D19A.6010802@telia.com> <4E0EB967.6050503@telia.com> <4E0F24C1.7020806@telia.com> To: "public-xg-webid@w3.org XG" , public-identity@w3.org, tls@ietf.org X-Mailer: Apple Mail (2.1244.3) Subject: Re: [TLS] SSL Logout possibility in Javascript 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, 27 Jul 2011 16:15:42 -0000 --Apple-Mail=_E1CBF6AD-EADA-483D-9071-57EC6285E4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have just played around with the javascript login/logout possibilities = mentioned by Anders Rundgren. The javascript I am using is that the end. = Note that I am using xhtml currently, so that may have its own side = effects - i.e., perhaps things work better in plain html... I am trying = to see if login also works with javascript. That would be very useful, = because people can easily click on the cancel button of a certificate, = and the browser then remembers that decision. So I am looking to see if = one can then force a login again... Here are some temporary conclusions with browsers I tried on OSX Firefox 5.0.1 - logout works - login works if clicking the cancel button. One has to go to a new web = page though. Safari 5.1 - logout does not work with javascript (but Safari does recognise TLS error codes sent, so that those can be = used to logout - I have not tested this version though) Chrome 13.0.782.99 - logout does not work and neither does login Opera 11.50 =20 - login, logout: does not recognise the window.crypto object =20 So that is good news. I guess that means we have Internet Explorer and = Firefox we can easily=20 logout with. Being able to log-in again as with Firefox in case a = mistake is made is also very helpful. Are there some other tricks one can use perhaps? //this is for xhtml //these functions are described here = http://html5.creation.net/webcrypto-api/ Social Web Architect http://bblfish.net/ --Apple-Mail=_E1CBF6AD-EADA-483D-9071-57EC6285E4C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://html5.creation.ne= t/webcrypto-api/
<script language=3D"JavaScript" = type=3D"text/javascript">
 <![CDATA[
 =    function logout() {
     if = (document.all =3D=3D null) // FF, Opera, etc
    =     {      
      =      alert('logout in ff,opera...')
  =          if (window.crypto) = window.crypto.logout();
          =  else alert('no window.crypto')
      =   }      
      else // = MSIE 6+
        {     =  
           alert('logout = in msie') 
          =  document.execCommand('ClearAuthenticationCache');
  =       };     
    =  }
     function login() = {
     if (document.all =3D=3D null) // FF, = Opera, etc
        {     =  
           alert('login = in ff,opera...')
           if = (window.crypto) window.crypto.logout();
      =       else alert('no window.crypto')
  =       }      
    =   else // MSIE 6+
        {   =    
          =  alert('login in msie') 
        =   =  document.execCommand('ClearAuthenticationCache');
  =       };     
    =  }
 ]]>
 </script>
<= br>
Social = Web Architect
http://bblfish.net/
= --Apple-Mail=_E1CBF6AD-EADA-483D-9071-57EC6285E4C4-- From mrex@sap.com Wed Jul 27 11:17:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9E021F8BB9 for ; Wed, 27 Jul 2011 11:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.871 X-Spam-Level: X-Spam-Status: No, score=-9.871 tagged_above=-999 required=5 tests=[AWL=0.378, 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 kBUL5WmYCu17 for ; Wed, 27 Jul 2011 11:17:29 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB95921F8867 for ; Wed, 27 Jul 2011 11:17:28 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6RIHIZj023253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 20:17:23 +0200 (MEST) From: Martin Rex Message-Id: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Wed, 27 Jul 2011 20:17:17 +0200 (MEST) In-Reply-To: <1311734551.7071.72.camel@localhost> from "Matt McCutchen" at Jul 26, 11 10:42:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pgladstone@cisco.com, mcgrew@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 27 Jul 2011 18:17:29 -0000 Matt McCutchen wrote: > > On Tue, 2011-07-26 at 08:01 -0700, David McGrew wrote: > > I would like to request feedback on a new draft that Philip Gladstone > > and I put together, which aims to solve some of the security problems > > that happen when there is a (HTTP) proxy present and TLS is in use. > > It doesn't seem that this work is in any way specific to HTTP. Only for Web-Browser scenario can I personally see a very limited value that does not amount to 100% wiretapping. Are you aware of rfc2804 "IETF Policy on Wiretapping"? http://tools.ietf.org/html/rfc2804 Standardizing MITM attacks on TLS-protected communication ("lawful intercept?") seems like an extremely bad idea to me. Checking whether some data conforms to a certain company policy will almost always be illegal in European countries, where we have sensible data protection laws. > > - One approach would be to do a real escrowed TLS where the client > negotiates directly with the server but releases the confidentiality key > and optionally also the integrity key to the proxy. This subsumes all > of the above concerns but doesn't allow the proxy to manipulate the > handshake in any finer way than blocking the connection if it doesn't > like the outcome. For the purpose of "centralized malware screening", for the incoming Web traffic of Web Browsers that are well known to interpret such data in arbitrarily stupid ways (such as active content, img src, (i)frame, javascript, css), sharing the encryption traffic keys with the Proxy would be perfectly sufficient, and that also enables the clients to clearly limit who is able to read the traffic. No super-CA-equivalent keys would need to be on the malware-scanning Proxy. -Martin From mrex@sap.com Wed Jul 27 11:34:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982ED11E8123 for ; Wed, 27 Jul 2011 11:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.719 X-Spam-Level: X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 HZhRczxk3J68 for ; Wed, 27 Jul 2011 11:34:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id CAE2D11E8084 for ; Wed, 27 Jul 2011 11:34:44 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6RIYgDT016976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 20:34:42 +0200 (MEST) From: Martin Rex Message-Id: <201107271834.p6RIYfjB001802@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Wed, 27 Jul 2011 20:34:41 +0200 (MEST) In-Reply-To: <4E2FC9F3.10205@telia.com> from "Anders Rundgren" at Jul 27, 11 10:18:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 18:34:45 -0000 Anders Rundgren wrote: > > AFAICT you indirectly say that the de-facto standard for maintaining > (note, not creating) secure sessions on the web, i.e. server-side > HTTPS + session cookies is inferior. Huh? I'm completely lost. If you want to do application-level session management, then you ought to do application level session management, and NOT try to mess around and interfere with Single Sign-On functionality at the transport layer. Even in closed environments, where TLS client certificates are used for Single Sign-On, there usually is a fallback capability to use passwords as well as support for migration from pure-password-based logons to cert-based logons, and during the transition, both authentication schemes must be supported in parallel. So the only sensible application level session management is doing it uniformly at the application level independent of whether the user authenticated via password (which he may have to re-enter occasionally), or via some Single Sign-On functionality -- be it TLS client certs or HTTP Negotiate, or potentially other schemes (saml, oauth). You really don't want having to redesign & update the installed base whenever you're adding support for a new authentication scheme, therefore messing around with authentication scheme internals when all you want to do is application level session management seems to be an unconditionally bad idea. > > The fact is that exactly $0 has been spent by the people building and > defining the TLS/HTTPS platforms on *researching* the issues I mentioned, > while *hundreds of millions of dollars* has been spent on *code* that > merges client-side PKI and the web in other ways than using HTTPS CCA. HTTPS CCA is a means to use Single Sign-On (using X.509 certs for online authentication) and equivalent to using Kerberos with HTTP Negotiate or Kerberos with other protocols. You seem to be entirely mislead about the purpose and usage constraints of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On. It has _NOTHING_ to do with digital signatures and can not be used to authorize individual transactions. The only reliably means to ensure that a "proof of identity" can NEVER be confused (or maliciously abused) with an explicit authorization for some transaction is to use distinct PKI credentials, distinct protocols and distinct credentials management functions. If PKI credentials, protocols or credentials management for these completely distinct purposes are conflated, huge risks and damages will ensue, and people will get hurt badly. -Martin From paul@xelerance.com Wed Jul 27 12:22:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D5221F8BB7 for ; Wed, 27 Jul 2011 12:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XN4pbDBok-3y for ; Wed, 27 Jul 2011 12:22:54 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id E484D21F8BB4 for ; Wed, 27 Jul 2011 12:22:49 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 180D757124; Wed, 27 Jul 2011 15:23:46 -0400 (EDT) Date: Wed, 27 Jul 2011 15:23:45 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 27 Jul 2011 19:22:56 -0000 On Wed, 27 Jul 2011, Eric Rescorla wrote: > The WG is starting to see an increasing number of proposals for new > extensions, and it seems like it would be good to have a consistent > policy for how to handle these. The chairs have gotten together with > our AD and converged on the following draft policy, which we plan > to discuss in the " Working Group Handling for Extensions to TLS" > slot. > > Comments? Overal I agree with the document, though I'd like to point out that someones important use case can be totally irrelevant to someone elses set of use cases, and the TLS group should try to be accomodating, providing the proper security considerations are complied with. It is very easy to say "I do not see a use for this new extension" which does run the risk of stiffling new technologies. Though I also understand the need for being conservative with a security protocol. I do think this document balances the two properly. So I agree with the document as proposed. But I do have some questions, partially based on my own recent submission of a TLS extension draft. > 2. All non-trivial extensions (i.e., anything which alters TLS > processing in some way) must be presented to the TLS WG and at least > be considered unobjectionable. They need not be WG items. I was under the impression that any standards document should have TLS WG consensus and that extensions could not be an Informational? In which case they can only be WG items. (note: this is one of the reasons I brought my draft to the TLS WG instead of continuing for an Individual / Informational RFC) Would this document change that? I am not sure how relevant this really is. When I started looking at TLS in more detail in the last six months, I was pretty disappointed at the implementation of certain TLS extensions. It seemed even a TLS 1.2 specification was not really deployed anywhere, and neither were for example parts of RFC 6066. (based on checking various apache and openssl code/sites) > Extensions > in this category can proceed without widespread WG support, but must > either have no significant objections or achieve WG consensus to > proceed. An example of a non-trivial extension would be one that > defined a new form of MAC truncation. This alters TLS processing but > not the state machine. I am not entirely sure if my draft would fall under this category, but I think it does? > 3. Extensions which which involve significant changes to the TLS > model/state machine, adds new messages, etc. must be TLS WG work > items, or, if primarily designed for some other WG, must be work items > of that WG and developed in collaboration with the TLS WG and subject > to the WG consensus process. If it is really so intrusive to the TLS protocol, I would say it has to be more then an item for another WG. It is also a bit of a catch22. In my case, DANE awaits me to go to TLS, and this paragraph would have TLS sent me back to DANE. > The WG considers it an important objective to to provide timely, > clear dispositions of new efforts. Work will be taken on when there is > consensus and based on the WG's estimate of the level of interest and > the size and priority of the current workload. Reconsideration of > proposals which have failed to gather consensus will be prioritized > behind proposals for new work which have not yet been considered. > In general, requests for reconsideration should only be made once a > proposal has been significantly revised and there is evidence of > substantial level of community support. +1 Paul From anders.rundgren@telia.com Wed Jul 27 12:33:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CFF11E80F2 for ; Wed, 27 Jul 2011 12:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 FqekiEY59+af for ; Wed, 27 Jul 2011 12:33:04 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF2711E80AD for ; Wed, 27 Jul 2011 12:33:04 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E9700002421; Wed, 27 Jul 2011 21:33:02 +0200 Message-ID: <4E3067DD.7020209@telia.com> Date: Wed, 27 Jul 2011 21:32:45 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107271834.p6RIYfjB001802@fs4113.wdf.sap.corp> In-Reply-To: <201107271834.p6RIYfjB001802@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 19:33:05 -0000 On 2011-07-27 20:34, Martin Rex wrote: > Anders Rundgren wrote: >> >> AFAICT you indirectly say that the de-facto standard for maintaining >> (note, not creating) secure sessions on the web, i.e. server-side >> HTTPS + session cookies is inferior. > > Huh? I'm completely lost. Pardon me if I read too much into your response. > If you want to do application-level session management, then you > ought to do application level session management, and NOT try to > mess around and interfere with Single Sign-On functionality at the > transport layer. Sure, but the question was to use client-side PKI in such an application. And most of all, how to do it in a such way the the applications doesn't get affected. > Even in closed environments, where TLS client certificates are used > for Single Sign-On, there usually is a fallback capability to use > passwords as well as support for migration from pure-password-based > logons to cert-based logons, and during the transition, both > authentication schemes must be supported in parallel. See previous section. > So the only sensible application level session management is doing > it uniformly at the application level independent of whether the > user authenticated via password (which he may have to re-enter > occasionally), or via some Single Sign-On functionality -- be it > TLS client certs or HTTP Negotiate, or potentially other schemes > (saml, oauth). This is exactly what I want. Unfortunately as I have described earlier, this is easier said than done using the currently only standardized CCA method. Without a server-initiated "logout" added to TLS it can never be done in a portable way. But as we (all) know the vendors doesn't care **** about CCA on the web. > You really don't want having to redesign & update the installed base > whenever you're adding support for a new authentication scheme, > therefore messing around with authentication scheme internals > when all you want to do is application level session management > seems to be an unconditionally bad idea. Of course nobody wants to redesign the applications. >> The fact is that exactly $0 has been spent by the people building and >> defining the TLS/HTTPS platforms on *researching* the issues I mentioned, >> while *hundreds of millions of dollars* has been spent on *code* that >> merges client-side PKI and the web in other ways than using HTTPS CCA. > > HTTPS CCA is a means to use Single Sign-On (using X.509 certs for > online authentication) and equivalent to using Kerberos with > HTTP Negotiate or Kerberos with other protocols. > > You seem to be entirely mislead about the purpose and usage constraints > of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On. Purpose is an opinion. IMO, HTTPS CCA as an enterprise SSO-solution sucks ***. As a one-to-many-independent-RP-sign-in it does OK. > It has _NOTHING_ to do with digital signatures and can not be used > to authorize individual transactions. We are not talking about me; we are talking about hundreds of banks. > The only reliably means to ensure that a "proof of identity" can NEVER > be confused (or maliciously abused) with an explicit authorization > for some transaction is to use distinct PKI credentials, distinct > protocols and distinct credentials management functions. > > If PKI credentials, protocols or credentials management for these > completely distinct purposes are conflated, huge risks and damages > will ensue, and people will get hurt badly. They typically use the same certificate for app-level auth as for HTTPS CCA. They do (in the rare case specific signature applications are supported), provide certificate with the NR bit set for those. Anders From paul@xelerance.com Wed Jul 27 13:13:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3475E802A for ; Wed, 27 Jul 2011 13:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Zm6aIPN2BUYL for ; Wed, 27 Jul 2011 13:13:49 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 078FD5E8028 for ; Wed, 27 Jul 2011 13:13:45 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id C9B0057124; Wed, 27 Jul 2011 16:14:40 -0400 (EDT) Date: Wed, 27 Jul 2011 16:14:40 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:13:50 -0000 On Mon, 25 Jul 2011, Eric Rescorla wrote: Thank you for your review Eric. > This document describes a mechanism for allowing the client to > indicate to the server that he has cached the server's TLS > public key. The server then omits the key from the handshake > and the client relies on the cached value. Not entirely. The TLS server never omits sending its public key. It only omits sending it in a PKIX container. The TLS client indicates that it has authenticated the key out of band, not neccessarilly only when it cached it from a previous session. In fact, the primary use case intended here is out of band public key validation. Reusing a cached key is just a bonus effect of the more modular authentication mechanism. > OVERALL > Section 1.1 appears to describe two primary motivations for this > extension: > > - It saves the cost of transmitting the certificate over the network > to the client. > - It potentially conflicts with other validation mechanisms which > the client may have for checking the server cert. Perhaps we were not clear enough in section 1.1. The primary motivation is to allow decoupling of TLS server public key authentication from PKIX validation, allowing TLS clients to determine their own authentication scheme to apply for talking to the TLS Server. > In support of these motivations it lists the following use cases > (numbered by me): > > 1. The TLS server public key is obtained from a [PKIX] certificate > chain from an [LDAP] server > > 2. The TLS server public key is obtained from a DNSSEC secured RRset > using [DANE] > > 3. The TLS server public key is provisioned by the operating system > and updated via software updates > > 4. A TLS client has connected to the TLS server before and has cached > the TLS server certificate chain or TLS server public key for re- > use > > The second motivation does not apply to use cases (1) and (4): The > server's credentials are already phrased as PKIX credentials This is part of the current problem we are trying to solve. Currently, there is no choice but to wrap the TLS Server public key into a PKIX container that necessitates specifying certain information that can be problematic for some reasons: - Conflicts with the actual TLS client authentication scheme - PKIX mandated data that cannot be processed by the TLS client for non-PKIX authentication. One example given were the conflicts of TLSA/HASTLS data with PKIX data when using DANE. Another one we did not mention is, and which we should probably add, is that some applications (eg browsers) cannot store PKIX received information for non-PKIX authentication methods. In other words, a browser cannot store a certificate used as packaging container for a DANE TLS server public key, because it contains a made up, unvalidatable, CN= which cannot be left out of a PKIX cert. Think of my DANE certificate specifying CN=paypal.com for the host dane.xelerance.com. The browser is forced to maintain an internal list of what information inside the PKIX container has been properly validated with a non-PKIX method (eg DANE) > client can validatte them however it wishes While that is true, it is a weak argument for necessitating sending cruft in the TLS protocol forever after. I would say especially so, since this TLS extension is a pretty trivial change, both in specification and implementation. Especially on the TLS server side. Additionally, asking to send PKIX freeform data inside a crypto protocol does make me nervous from a security point of view. We've seen issues in the past of PKIX certificates with mangled data and pre-image attacks by using various PKIX fields. TLS clients that would only need to support something like DANE, would not even need an ASN.1 parser anymore if the TLS server supports this new TLS extension. > TLS stacks already have X.509 parsing, That might be considered a security problem instead of an asset. > I don't see any reason why it's troublesome to ignore the rest of > the certificate; indeed this is a quite common practice when > self-signed certs are in use. And what did that ignoring get us? Massive amounts of popups and security warnings to click away. The idea is that we cannot receive a TLS public key for "dane.xelerance.com" that pretends to be "paypal.com". Saying that it is easy to ignore is not a strong argument for trying to ensure no one has to make the ignore/not ignore decision by a proper design. > OTHER COMMENTS > What's the reason why you would want to send the server the > SPKI instead of the hash? Originally, we put it in as SPKI because we were envisioning that the TLS server could just respond with the extension containing an empty list, as the client already has knows (and authenticated) the public key out of band, and we wanted at least one full copy of the TLS server key covered by the Finished Message. In response to talking to some people, it was deemed more orthogonal to the current TLS protocol to have the TLS server send a copy of its public key (as it does so in the regular PKIX case inside the container) With the TLS server sending the full public key, we can indeed remove it from the TLS client side. > opaque SHA256Hash<32>; > > You probably want [32] here. Thanks. I've updated it in my copy. Paul From mrex@sap.com Wed Jul 27 13:29:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6819611E8149 for ; Wed, 27 Jul 2011 13:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.88 X-Spam-Level: X-Spam-Status: No, score=-9.88 tagged_above=-999 required=5 tests=[AWL=0.369, 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 oN2U1ktzgiqL for ; Wed, 27 Jul 2011 13:29:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1B211E8092 for ; Wed, 27 Jul 2011 13:29:18 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6RKTG8V007982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 22:29:16 +0200 (MEST) From: Martin Rex Message-Id: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Wed, 27 Jul 2011 22:29:15 +0200 (MEST) In-Reply-To: <4E3067DD.7020209@telia.com> from "Anders Rundgren" at Jul 27, 11 09:32:45 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 20:29:19 -0000 Anders Rundgren wrote: > > > If you want to do application-level session management, then you > > ought to do application level session management, and NOT try to > > mess around and interfere with Single Sign-On functionality at the > > transport layer. > > Sure, but the question was to use client-side PKI in such an application. TLS does *NOT* provide any PKI functionality to applications, never did, never will. If you need that, you'll have to newly build it form ground up, potentially re-using existing technologies and protocols (such as PKCS#7/CMS). > > And most of all, how to do it in a such way the the applications > doesn't get affected. That is a non sequitur. "Wash me, but don't get me wet". > > > So the only sensible application level session management is doing > > it uniformly at the application level independent of whether the > > user authenticated via password (which he may have to re-enter > > occasionally), or via some Single Sign-On functionality -- be it > > TLS client certs or HTTP Negotiate, or potentially other schemes > > (saml, oauth). > > This is exactly what I want. Unfortunately as I have described > earlier, this is easier said than done using the currently only > standardized CCA method. I'm having serious difficulties to understand what you want, because you constantly intermix two completely distinct things. On the one hand, you talk about application level session management, which has nothing to do with PKI whatsoever. And on the other hand you're talking about using PKI functionality from within the application, which has nothing to do whatsoever with transport-level protection of the communication and Single Sign-On. Just because both, PKI/X.509-based Single Sign-On and application-level use of PKI for digital signatures both use some common pieces of technology (X.509), does not make these to issues fall into an even remotely related problem space. > > Without a server-initiated "logout" added to TLS it can never > be done in a portable way. But as we (all) know the vendors > doesn't care **** about CCA on the web. In Single Sign-On scenarios, there is _NO_SUCH_THING_ as a server logout with respect to the authentication. The very purpose of Single Sign-On is that the authentication will be automatically performed should that be necessary. What you refer to with "server(-initiated) logout" looks like very misleading terminology to me. Any server that is not operating state-less, can decide at any point in time, at his very own discretion, to forget/flush that backend state. That is completely independent from what any clients do and works even if the network connection of the client breaks down or the client is inadvertently powered off. In pre-HTTP legacy protocols, servers used to keep backend state for as long as the network connection was active. When using connection-less transports, such as performing communication over short-lived request&response HTTP connections, the server needs to come up with some alternative means to determine when to delete/flush backend state associated with particular clients. And seriously, any such replacement backend-state management logic needs to work completely independent of the client's behaviour. Robust traditional client-server scenarios with persistent network connections also had provisions to terminate the network connection on the server end according to locally configured policy (idle timeouts, connection time limits, hours of operation, etc.) and without cooperation from the client. > > > > > HTTPS CCA is a means to use Single Sign-On (using X.509 certs for > > online authentication) and equivalent to using Kerberos with > > HTTP Negotiate or Kerberos with other protocols. > > > > You seem to be entirely mislead about the purpose and usage constraints > > of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On. > > Purpose is an opinion. > IMO, HTTPS CCA as an enterprise SSO-solution sucks ***. If you're doing it _correctly_, it works remarkably smooth. As I've mentioned it before, we've been doing it for like 12 years for all employees and pretty much all intranet server/services. We started out with X.509/PKI-based Single Sign-On for legacy, persistent connection client-server communication with GSS-API based Single Sign-On, and it was natural and straightforward to extend this to TLS CCA for Server/Services accessed through HTTPS. And from the abstraction standpoint, the applications, both legacy and HTTP-based, should NEVER bother whether the transport was connection oriented legacy or HTTPS, and neither should the application bother whether Single Sign-On was provided through X.509 certs (what we prefer and have been using since 1996) or through Kerberos (what some others prefer). btw. certificate enrollment in Browsers hardly works, e.g. Windows 7 was shipped with broken certificate enrollment last bullet "issues fixed" of http://support.microsoft.com/kb/974431 we've been distributing client certs to MSIE through Crypto-API exclusively. For all other browsers, its manual pkcs#12 import. > As a one-to-many-independent-RP-sign-in it does OK. > > > It has _NOTHING_ to do with digital signatures and can not be used > > to authorize individual transactions. > > We are not talking about me; we are talking about hundreds of banks. It is extremely unlikely that banks want Single Sign-On, because that would shift the entire responsibility for fraud on their very own shoulders. Therefore I consider HTTPS CCA completely irrelevant to banks. And anyone who talks about using HTTPS CCA for banks likely has little clue about the technology of TLS and Web Browsers. > > > The only reliably means to ensure that a "proof of identity" can NEVER > > be confused (or maliciously abused) with an explicit authorization > > for some transaction is to use distinct PKI credentials, distinct > > protocols and distinct credentials management functions. > > > > If PKI credentials, protocols or credentials management for these > > completely distinct purposes are conflated, huge risks and damages > > will ensue, and people will get hurt badly. > > They typically use the same certificate for app-level auth as for > HTTPS CCA. They do (in the rare case specific signature applications > are supported), provide certificate with the NR bit set for those. Using the same cert for Single Sign-On as for transaction based authorization would be braindead and irresponsible. The key usage bits in a certificate become completely meaningless if a certificate is being used for Single Sign-On. Single Sign-On reduces the value of any credential to at most "credential present". Attributing any kind of intent to Single Sign-On authentication is technically and legally impossible. And anyone who claims otherwise lacks technical and legal understanding of the issues. -Martin From ekr@rtfm.com Wed Jul 27 13:46:38 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A756011E8092 for ; Wed, 27 Jul 2011 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT1edt818ttg for ; Wed, 27 Jul 2011 13:46:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 956D711E8082 for ; Wed, 27 Jul 2011 13:46:37 -0700 (PDT) Received: by wwe5 with SMTP id 5so1223035wwe.13 for ; Wed, 27 Jul 2011 13:46:36 -0700 (PDT) Received: by 10.227.200.210 with SMTP id ex18mr6656123wbb.7.1311799596129; Wed, 27 Jul 2011 13:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Wed, 27 Jul 2011 13:46:16 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 27 Jul 2011 16:46:16 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 20:46:38 -0000 On Wed, Jul 27, 2011 at 4:14 PM, Paul Wouters wrote: > On Mon, 25 Jul 2011, Eric Rescorla wrote: > > Thank you for your review Eric. > >> This document describes a mechanism for allowing the client to >> indicate to the server that he has cached the server's TLS >> public key. The server then omits the key from the handshake >> and the client relies on the cached value. > > Not entirely. > > The TLS server never omits sending its public key. It only omits sending > it in a PKIX container. I don't get this from the draft. It says: The TLS server MAY respond with an extension of type "oob_pubkey_list" in the (extended) server hello. The "extension_data" field of this extension SHALL contain "PublicKeyList" containing exactly one of the "PublicKey" identifiers used in the received client hello message. It SHALL use the same IdentifierType as the TLS client used to send the identifier to the TLS server. It MUST NOT send and empty PublicKeyList. If the TLS server responds with an extension of type "oob_pubkey_list", it SHOULD omit sending a "Server Certificate" message. If the client sends a hash, then I read this as saying the server also says a hash. where does the server send it's public key? >> OVERALL >> Section 1.1 appears to describe two primary motivations for this >> extension: >> >> - It saves the cost of transmitting the certificate over the network >> =A0to the client. >> - It potentially conflicts with other validation mechanisms which >> =A0the client may have for checking the server cert. > > Perhaps we were not clear enough in section 1.1. The primary motivation > is to allow decoupling of TLS server public key authentication from PKIX > validation, allowing TLS clients to determine their own authentication > scheme to apply for talking to the TLS Server. Yes, but that's not an argument against using the PKIX container. The argum= ent you offer against that is that there are conflicting semantics. > One example given were the conflicts of TLSA/HASTLS data with PKIX data > when using DANE. > > Another one we did not mention is, and which we should probably add, > is that some applications (eg browsers) cannot store PKIX received > information for non-PKIX authentication methods. In other words, a browse= r > cannot store a certificate used as packaging container for a DANE TLS > server public key, because it contains a made up, unvalidatable, CN=3D > which cannot be left out of a PKIX cert. Think of my DANE certificate > specifying CN=3Dpaypal.com for the host dane.xelerance.com. The browser i= s > forced to maintain an internal list of what information inside the PKIX > container has been properly validated with a non-PKIX method (eg DANE) I don't see that this is a big deal. > > TLS clients that would only need to support something like DANE, would no= t > even > need an ASN.1 parser anymore if the TLS server supports this new TLS > extension. Except, you know, to talk to the 99.99999% of the universe that uses PKIX c= erts. Oh, and to parse the SPKI, which is in BER. >> I don't see any reason why it's troublesome to ignore the rest of >> the certificate; indeed this is a quite common practice when >> self-signed certs are in use. > > And what did that ignoring get us? Massive amounts of popups and security > warnings to click away. The idea is that we cannot receive a TLS public > key for "dane.xelerance.com" that pretends to be "paypal.com". Saying > that it is easy to ignore is not a strong argument for trying to ensure > no one has to make the ignore/not ignore decision by a proper design. I think you misunderstand my point, which is that if the implementation has= some other mechanism for validating the cert it can ignore the rest of it. I'm not talking about the user ignoring it. -Ekr From henry.story@bblfish.net Wed Jul 27 14:02:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7CD11E80DD for ; Wed, 27 Jul 2011 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 T1K-n9Y8Lxg5 for ; Wed, 27 Jul 2011 14:02:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9B59C11E8082 for ; Wed, 27 Jul 2011 14:02:37 -0700 (PDT) Received: by wyj26 with SMTP id 26so1274329wyj.31 for ; Wed, 27 Jul 2011 14:02:29 -0700 (PDT) Received: by 10.227.173.204 with SMTP id q12mr213855wbz.86.1311800549744; Wed, 27 Jul 2011 14:02:29 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id gd1sm230132wbb.10.2011.07.27.14.02.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 14:02:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp> Date: Wed, 27 Jul 2011 23:02:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 21:02:39 -0000 On 27 Jul 2011, at 22:29, Martin Rex wrote: > Anders Rundgren wrote: >>=20 >>> If you want to do application-level session management, then you >>> ought to do application level session management, and NOT try to >>> mess around and interfere with Single Sign-On functionality at the >>> transport layer. >>=20 >> Sure, but the question was to use client-side PKI in such an = application. >=20 > TLS does *NOT* provide any PKI functionality to applications, > never did, never will. >=20 > If you need that, you'll have to newly build it form ground up, > potentially re-using existing technologies and protocols > (such as PKCS#7/CMS). Yes, you can for example use X509 as such legacy technology, and with simple WebArchitecture build a distributed public key infrastructure. You do this by tying public keys to URIs and building a web of trust = through links between documents, using insights from the work done around the = world in the semantic web space. When this is done it turns out that one can magically re-use all the existing technology, including Client = Certificates to ones advantage. All that is explained quickly at http://webid.info/=20= Though if you want the philosophical background to this in detail you = can see the third presentation on my home page. Henry Social Web Architect http://bblfish.net/ From anders.rundgren@telia.com Wed Jul 27 14:03:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E8511E8152 for ; Wed, 27 Jul 2011 14:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 iLW1JW2xvPg8 for ; Wed, 27 Jul 2011 14:03:00 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id C7A7911E814F for ; Wed, 27 Jul 2011 14:02:59 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E970000728C; Wed, 27 Jul 2011 23:02:55 +0200 Message-ID: <4E307CF1.60105@telia.com> Date: Wed, 27 Jul 2011 23:02:41 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp> In-Reply-To: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 21:03:01 -0000 Martin, Lots of banks wants to use CCA for their users. They find HTTPS' way of doing that intrusive. On the web you logoff from (or by) the server. Naturally logoffs must trickle down to clients if they have logged-in using HTTPS CCA otherwise they are de-facto logged-in due to the TLS caching. There are really ugly workarounds but you should not build secure services based on moderately understood fixes. That's all. Anders On 2011-07-27 22:29, Martin Rex wrote: > Anders Rundgren wrote: >> >>> If you want to do application-level session management, then you >>> ought to do application level session management, and NOT try to >>> mess around and interfere with Single Sign-On functionality at the >>> transport layer. >> >> Sure, but the question was to use client-side PKI in such an application. > > TLS does *NOT* provide any PKI functionality to applications, > never did, never will. > > If you need that, you'll have to newly build it form ground up, > potentially re-using existing technologies and protocols > (such as PKCS#7/CMS). > > >> >> And most of all, how to do it in a such way the the applications >> doesn't get affected. > > That is a non sequitur. "Wash me, but don't get me wet". > > >> >>> So the only sensible application level session management is doing >>> it uniformly at the application level independent of whether the >>> user authenticated via password (which he may have to re-enter >>> occasionally), or via some Single Sign-On functionality -- be it >>> TLS client certs or HTTP Negotiate, or potentially other schemes >>> (saml, oauth). >> >> This is exactly what I want. Unfortunately as I have described >> earlier, this is easier said than done using the currently only >> standardized CCA method. > > I'm having serious difficulties to understand what you want, because > you constantly intermix two completely distinct things. > > On the one hand, you talk about application level session management, > which has nothing to do with PKI whatsoever. > > And on the other hand you're talking about using PKI functionality > from within the application, which has nothing to do whatsoever > with transport-level protection of the communication and > Single Sign-On. > > Just because both, PKI/X.509-based Single Sign-On and application-level > use of PKI for digital signatures both use some common pieces of > technology (X.509), does not make these to issues fall into an > even remotely related problem space. > > >> >> Without a server-initiated "logout" added to TLS it can never >> be done in a portable way. But as we (all) know the vendors >> doesn't care **** about CCA on the web. > > In Single Sign-On scenarios, there is _NO_SUCH_THING_ as a > server logout with respect to the authentication. The very purpose > of Single Sign-On is that the authentication will be automatically > performed should that be necessary. > > > What you refer to with "server(-initiated) logout" looks like > very misleading terminology to me. > > Any server that is not operating state-less, can decide at any point > in time, at his very own discretion, to forget/flush that backend > state. That is completely independent from what any clients do > and works even if the network connection of the client breaks down > or the client is inadvertently powered off. > > > In pre-HTTP legacy protocols, servers used to keep backend state > for as long as the network connection was active. When using > connection-less transports, such as performing communication > over short-lived request&response HTTP connections, the server > needs to come up with some alternative means to determine > when to delete/flush backend state associated with particular > clients. And seriously, any such replacement backend-state > management logic needs to work completely independent of the > client's behaviour. Robust traditional client-server scenarios > with persistent network connections also had provisions to > terminate the network connection on the server end according > to locally configured policy (idle timeouts, connection time limits, > hours of operation, etc.) and without cooperation from the client. > > >> >>> >>> HTTPS CCA is a means to use Single Sign-On (using X.509 certs for >>> online authentication) and equivalent to using Kerberos with >>> HTTP Negotiate or Kerberos with other protocols. >>> >>> You seem to be entirely mislead about the purpose and usage constraints >>> of X.509 when used for GSS-API based Single Sign-On or TLS Single Sign-On. >> >> Purpose is an opinion. >> IMO, HTTPS CCA as an enterprise SSO-solution sucks ***. > > If you're doing it _correctly_, it works remarkably smooth. > As I've mentioned it before, we've been doing it for like 12 years > for all employees and pretty much all intranet server/services. > > We started out with X.509/PKI-based Single Sign-On for legacy, > persistent connection client-server communication with GSS-API > based Single Sign-On, and it was natural and straightforward to > extend this to TLS CCA for Server/Services accessed through HTTPS. > > And from the abstraction standpoint, the applications, both legacy > and HTTP-based, should NEVER bother whether the transport > was connection oriented legacy or HTTPS, and neither should the > application bother whether Single Sign-On was provided through > X.509 certs (what we prefer and have been using since 1996) > or through Kerberos (what some others prefer). > > btw. certificate enrollment in Browsers hardly works, > e.g. Windows 7 was shipped with broken certificate enrollment > last bullet "issues fixed" of http://support.microsoft.com/kb/974431 > > we've been distributing client certs to MSIE through Crypto-API > exclusively. For all other browsers, its manual pkcs#12 import. > > >> As a one-to-many-independent-RP-sign-in it does OK. >> >>> It has _NOTHING_ to do with digital signatures and can not be used >>> to authorize individual transactions. >> >> We are not talking about me; we are talking about hundreds of banks. > > It is extremely unlikely that banks want Single Sign-On, because that would > shift the entire responsibility for fraud on their very own shoulders. > > Therefore I consider HTTPS CCA completely irrelevant to banks. > > And anyone who talks about using HTTPS CCA for banks likely has > little clue about the technology of TLS and Web Browsers. > > >> >>> The only reliably means to ensure that a "proof of identity" can NEVER >>> be confused (or maliciously abused) with an explicit authorization >>> for some transaction is to use distinct PKI credentials, distinct >>> protocols and distinct credentials management functions. >>> >>> If PKI credentials, protocols or credentials management for these >>> completely distinct purposes are conflated, huge risks and damages >>> will ensue, and people will get hurt badly. >> >> They typically use the same certificate for app-level auth as for >> HTTPS CCA. They do (in the rare case specific signature applications >> are supported), provide certificate with the NR bit set for those. > > > Using the same cert for Single Sign-On as for transaction based > authorization would be braindead and irresponsible. The key usage > bits in a certificate become completely meaningless if a certificate > is being used for Single Sign-On. Single Sign-On reduces the > value of any credential to at most "credential present". > Attributing any kind of intent to Single Sign-On authentication > is technically and legally impossible. And anyone who claims > otherwise lacks technical and legal understanding of the issues. > > > -Martin > From paul@xelerance.com Wed Jul 27 14:13:26 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0065521F89A7 for ; Wed, 27 Jul 2011 14:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 lO4RyU1FoEIn for ; Wed, 27 Jul 2011 14:13:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 457B021F8853 for ; Wed, 27 Jul 2011 14:13:24 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 7C14257124; Wed, 27 Jul 2011 17:14:20 -0400 (EDT) Date: Wed, 27 Jul 2011 17:14:20 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:13:26 -0000 On Wed, 27 Jul 2011, Eric Rescorla wrote: >> The TLS server never omits sending its public key. It only omits sending >> it in a PKIX container. > > I don't get this from the draft. Sorry for the confusion. I meant "an identifier of the key (full or hash)". Previously, we thought about completely omitting the seerver from sending its key (or hash thereof). If sending hashes makes people uncomfortable, we could look at insisting the full public key is sent. But that has its disadvantages (requiring an ASN.1 parser) >> Perhaps we were not clear enough in section 1.1. The primary motivation >> is to allow decoupling of TLS server public key authentication from PKIX >> validation, allowing TLS clients to determine their own authentication >> scheme to apply for talking to the TLS Server. > > Yes, but that's not an argument against using the PKIX container. In my opinion, it is. [ PKIX wrapping ] > I don't see that this is a big deal. Yes, I understood that's your view. >> TLS clients that would only need to support something like DANE, would not >> even >> need an ASN.1 parser anymore if the TLS server supports this new TLS >> extension. > > Except, you know, to talk to the 99.99999% of the universe that uses PKIX certs. With that reasoning, we'd all be riding horses still. The extension offers a way out of some overly complex outdated overkill technology, with no impact on people who wish to remain using horses. > Oh, and to parse the SPKI, which is in BER. Not if you use the hashed public key variant :) >> And what did that ignoring get us? Massive amounts of popups and security >> warnings to click away. The idea is that we cannot receive a TLS public >> key for "dane.xelerance.com" that pretends to be "paypal.com". Saying >> that it is easy to ignore is not a strong argument for trying to ensure >> no one has to make the ignore/not ignore decision by a proper design. > > I think you misunderstand my point, which is that if the implementation has some > other mechanism for validating the cert it can ignore the rest of it. > I'm not talking about the user ignoring it. The two are coupled., if the browser needs to store the incoming PKIX for its own administration. If using DANE only the pubkey is authenticated, it cannot ever display the CN= to the user if the user requests to see more info on the security status of its connection. Paul From mrex@sap.com Wed Jul 27 14:29:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279CF11E80A1 for ; Wed, 27 Jul 2011 14:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.886 X-Spam-Level: X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=0.363, 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 6R4nI2JlDj53 for ; Wed, 27 Jul 2011 14:29:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D173811E813C for ; Wed, 27 Jul 2011 14:29:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6RLTdXN011658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 27 Jul 2011 23:29:39 +0200 (MEST) From: Martin Rex Message-Id: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Wed, 27 Jul 2011 23:29:38 +0200 (MEST) In-Reply-To: <4E307CF1.60105@telia.com> from "Anders Rundgren" at Jul 27, 11 11:02:41 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 21:29:42 -0000 Anders Rundgren wrote: > > Lots of banks wants to use CCA for their users. That is a non sequitur. Banks (here in Germany) have abandoned tradtional TANs based on the unconditional presumption that client PCs are infested with malware, and most banks in Germany are currently replacing indexed TANs (iTAN) presumably based on the perception that malware on clients (trojans/phishing) has caught up with iTAN procedure complexity. At this point, with the presumption that all client PCs are thoroughly infested with malware, going for a Single Sign-On mechanism would be completely braindead and irresponsible. > > They find HTTPS' way of doing that intrusive. > > On the web you logoff from (or by) the server. > > Naturally logoffs must trickle down to clients > if they have logged-in using HTTPS CCA otherwise > they are de-facto logged-in due to the TLS caching. "Logoff" is a pure server-side concept with respect to server-side state. A logoff concept that requires cooperation from the client is technical nonsense. Any server-side destruction of backend-state associated with particular clients must work completely independent of what the client does. Early consensual destruction of backend state if the client explicitly asks for it is OK. But any server-initiated "logoff" concept that involves the client amounts to technical cluelessness. And application level state management ought to be ***completely*** independent from the TLS session cache management. The server side TLS session cache management must be completely independent from application level backend state management when you're using a transport with non-persistent connections (such as HTTPS). The lower protocol levels of the server must be free to manage TLS session cache lifetime based on resource availability and administrative or operational requirements, and short server-side TLS session lifetimes (several minutes absolute lifetime), server-side TLS session cache flushing (when performing debugging on an otherwise productive system, or when updating the server certificate or changing the list of trusted client cert signers), as well as temporarily completely disabling server side TLS session caching MUST NOT interfere with application level session management. Any application that suffers from such server side TLS session cache characertistics is seriously and thoroughly broken (lack of abstraction and invalid protocol layering). -Martin From henry.story@bblfish.net Wed Jul 27 14:35:12 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE9228014 for ; Wed, 27 Jul 2011 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.453 X-Spam-Level: X-Spam-Status: No, score=-3.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 EZOWzCAXCnAT for ; Wed, 27 Jul 2011 14:35:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2235122800D for ; Wed, 27 Jul 2011 14:35:10 -0700 (PDT) Received: by wyj26 with SMTP id 26so1290887wyj.31 for ; Wed, 27 Jul 2011 14:35:10 -0700 (PDT) Received: by 10.227.175.1 with SMTP id v1mr238701wbz.114.1311802510193; Wed, 27 Jul 2011 14:35:10 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id em16sm239310wbb.67.2011.07.27.14.35.08 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 14:35:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=windows-1252 From: Henry Story In-Reply-To: <4E307CF1.60105@telia.com> Date: Wed, 27 Jul 2011 23:35:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4095E7C3-6BC3-4954-906E-B0832B9713DF@bblfish.net> References: <201107272029.p6RKTFNA008101@fs4113.wdf.sap.corp> <4E307CF1.60105@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 21:35:12 -0000 Anders, can you vote and get others to vote for the following issues =20 Chrome =95 "User Interface Improvement for Client Certificate Usage"=20 http://code.google.com/p/chromium/issues/detail?id=3D29784 =95 "window.crypto.logout() and login() don't work." http://code.google.com/p/chromium/issues/detail?id=3D90676 =20 Firefox =95 "Improve SSL client-authentication UI" https://bugzilla.mozilla.org/show_bug.cgi?id=3D396441 Henry On 27 Jul 2011, at 23:02, Anders Rundgren wrote: > Martin, > Lots of banks wants to use CCA for their users. >=20 > They find HTTPS' way of doing that intrusive. >=20 > On the web you logoff from (or by) the server. >=20 > Naturally logoffs must trickle down to clients > if they have logged-in using HTTPS CCA otherwise > they are de-facto logged-in due to the TLS caching. >=20 > There are really ugly workarounds but you should not build > secure services based on moderately understood fixes. the problem is that even cookie and password based login suffer form the same problems. Currently you have to trust the server to have logged you off. You can't be sure yourself. Henry >=20 > That's all. >=20 > Anders >=20 >=20 > On 2011-07-27 22:29, Martin Rex wrote: >> Anders Rundgren wrote: >>>=20 >>>> If you want to do application-level session management, then you >>>> ought to do application level session management, and NOT try to >>>> mess around and interfere with Single Sign-On functionality at the >>>> transport layer. >>>=20 >>> Sure, but the question was to use client-side PKI in such an = application. >>=20 >> TLS does *NOT* provide any PKI functionality to applications, >> never did, never will. >>=20 >> If you need that, you'll have to newly build it form ground up, >> potentially re-using existing technologies and protocols >> (such as PKCS#7/CMS). >>=20 >>=20 >>>=20 >>> And most of all, how to do it in a such way the the applications >>> doesn't get affected. >>=20 >> That is a non sequitur. "Wash me, but don't get me wet". >>=20 >>=20 >>>=20 >>>> So the only sensible application level session management is doing >>>> it uniformly at the application level independent of whether the >>>> user authenticated via password (which he may have to re-enter >>>> occasionally), or via some Single Sign-On functionality -- be it >>>> TLS client certs or HTTP Negotiate, or potentially other schemes >>>> (saml, oauth). >>>=20 >>> This is exactly what I want. Unfortunately as I have described >>> earlier, this is easier said than done using the currently only >>> standardized CCA method. >>=20 >> I'm having serious difficulties to understand what you want, because >> you constantly intermix two completely distinct things. >>=20 >> On the one hand, you talk about application level session management, >> which has nothing to do with PKI whatsoever. >>=20 >> And on the other hand you're talking about using PKI functionality >> from within the application, which has nothing to do whatsoever >> with transport-level protection of the communication and=20 >> Single Sign-On. >>=20 >> Just because both, PKI/X.509-based Single Sign-On and = application-level >> use of PKI for digital signatures both use some common pieces of >> technology (X.509), does not make these to issues fall into an >> even remotely related problem space. >>=20 >>=20 >>>=20 >>> Without a server-initiated "logout" added to TLS it can never >>> be done in a portable way. But as we (all) know the vendors >>> doesn't care **** about CCA on the web. >>=20 >> In Single Sign-On scenarios, there is _NO_SUCH_THING_ as a >> server logout with respect to the authentication. The very purpose >> of Single Sign-On is that the authentication will be automatically >> performed should that be necessary. >>=20 >>=20 >> What you refer to with "server(-initiated) logout" looks like >> very misleading terminology to me. >>=20 >> Any server that is not operating state-less, can decide at any point >> in time, at his very own discretion, to forget/flush that backend >> state. That is completely independent from what any clients do >> and works even if the network connection of the client breaks down >> or the client is inadvertently powered off. >>=20 >>=20 >> In pre-HTTP legacy protocols, servers used to keep backend state >> for as long as the network connection was active. When using >> connection-less transports, such as performing communication >> over short-lived request&response HTTP connections, the server >> needs to come up with some alternative means to determine >> when to delete/flush backend state associated with particular >> clients. And seriously, any such replacement backend-state >> management logic needs to work completely independent of the >> client's behaviour. Robust traditional client-server scenarios >> with persistent network connections also had provisions to >> terminate the network connection on the server end according >> to locally configured policy (idle timeouts, connection time limits, >> hours of operation, etc.) and without cooperation from the client. >>=20 >>=20 >>>=20 >>>>=20 >>>> HTTPS CCA is a means to use Single Sign-On (using X.509 certs for >>>> online authentication) and equivalent to using Kerberos with >>>> HTTP Negotiate or Kerberos with other protocols. >>>>=20 >>>> You seem to be entirely mislead about the purpose and usage = constraints >>>> of X.509 when used for GSS-API based Single Sign-On or TLS Single = Sign-On. >>>=20 >>> Purpose is an opinion. >>> IMO, HTTPS CCA as an enterprise SSO-solution sucks ***. >>=20 >> If you're doing it _correctly_, it works remarkably smooth. >> As I've mentioned it before, we've been doing it for like 12 years >> for all employees and pretty much all intranet server/services. >>=20 >> We started out with X.509/PKI-based Single Sign-On for legacy, >> persistent connection client-server communication with GSS-API >> based Single Sign-On, and it was natural and straightforward to >> extend this to TLS CCA for Server/Services accessed through HTTPS. >>=20 >> And from the abstraction standpoint, the applications, both legacy >> and HTTP-based, should NEVER bother whether the transport >> was connection oriented legacy or HTTPS, and neither should the >> application bother whether Single Sign-On was provided through >> X.509 certs (what we prefer and have been using since 1996) >> or through Kerberos (what some others prefer). >>=20 >> btw. certificate enrollment in Browsers hardly works, >> e.g. Windows 7 was shipped with broken certificate enrollment >> last bullet "issues fixed" of = http://support.microsoft.com/kb/974431 >>=20 >> we've been distributing client certs to MSIE through Crypto-API >> exclusively. For all other browsers, its manual pkcs#12 import. >>=20 >>=20 >>> As a one-to-many-independent-RP-sign-in it does OK. >>>=20 >>>> It has _NOTHING_ to do with digital signatures and can not be used >>>> to authorize individual transactions. >>>=20 >>> We are not talking about me; we are talking about hundreds of banks. >>=20 >> It is extremely unlikely that banks want Single Sign-On, because that = would >> shift the entire responsibility for fraud on their very own = shoulders. >>=20 >> Therefore I consider HTTPS CCA completely irrelevant to banks. >>=20 >> And anyone who talks about using HTTPS CCA for banks likely has=20 >> little clue about the technology of TLS and Web Browsers. >>=20 >>=20 >>>=20 >>>> The only reliably means to ensure that a "proof of identity" can = NEVER >>>> be confused (or maliciously abused) with an explicit authorization >>>> for some transaction is to use distinct PKI credentials, distinct >>>> protocols and distinct credentials management functions. >>>>=20 >>>> If PKI credentials, protocols or credentials management for these >>>> completely distinct purposes are conflated, huge risks and damages >>>> will ensue, and people will get hurt badly. >>>=20 >>> They typically use the same certificate for app-level auth as for >>> HTTPS CCA. They do (in the rare case specific signature = applications >>> are supported), provide certificate with the NR bit set for those. >>=20 >>=20 >> Using the same cert for Single Sign-On as for transaction based >> authorization would be braindead and irresponsible. The key usage >> bits in a certificate become completely meaningless if a certificate >> is being used for Single Sign-On. Single Sign-On reduces the >> value of any credential to at most "credential present". >> Attributing any kind of intent to Single Sign-On authentication >> is technically and legally impossible. And anyone who claims >> otherwise lacks technical and legal understanding of the issues. >>=20 >>=20 >> -Martin >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From ekr@rtfm.com Wed Jul 27 14:37:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5648821F8426 for ; Wed, 27 Jul 2011 14:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkG5aFmlDICx for ; Wed, 27 Jul 2011 14:37:00 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2193921F8BEA for ; Wed, 27 Jul 2011 14:36:59 -0700 (PDT) Received: by wyj26 with SMTP id 26so1292387wyj.31 for ; Wed, 27 Jul 2011 14:36:59 -0700 (PDT) Received: by 10.227.39.154 with SMTP id g26mr284566wbe.37.1311802619082; Wed, 27 Jul 2011 14:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Wed, 27 Jul 2011 14:36:39 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 27 Jul 2011 17:36:39 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 21:37:01 -0000 On Wed, Jul 27, 2011 at 5:14 PM, Paul Wouters wrote: > On Wed, 27 Jul 2011, Eric Rescorla wrote: >> Except, you know, to talk to the 99.99999% of the universe that uses PKIX >> certs. > > With that reasoning, we'd all be riding horses still. The extension offers a > way > out of some overly complex outdated overkill technology, with no impact on > people > who wish to remain using horses. For some reason this argument is not exactly convincing. >>> And what did that ignoring get us? Massive amounts of popups and security >>> warnings to click away. The idea is that we cannot receive a TLS public >>> key for "dane.xelerance.com" that pretends to be "paypal.com". Saying >>> that it is easy to ignore is not a strong argument for trying to ensure >>> no one has to make the ignore/not ignore decision by a proper design. >> >> I think you misunderstand my point, which is that if the implementation >> has some >> other mechanism for validating the cert it can ignore the rest of it. >> I'm not talking about the user ignoring it. > > The two are coupled., if the browser needs to store the incoming PKIX for > its > own administration. If using DANE only the pubkey is authenticated, it > cannot > ever display the CN= to the user if the user requests to see more info on > the > security status of its connection. I have no idea why this would be true. Regardless, as I said in my review, this seems like it's largely duplicative of cached info (and in fact, rather clumsier). Is there something here that couldn't be accomplished by a SPKI cache type in cached-info? -Ekr From henry.story@bblfish.net Wed Jul 27 14:56:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8B55E8004 for ; Wed, 27 Jul 2011 14:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 a7txhmpmPXZa for ; Wed, 27 Jul 2011 14:56:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8F85E8001 for ; Wed, 27 Jul 2011 14:56:53 -0700 (PDT) Received: by wyj26 with SMTP id 26so1304113wyj.31 for ; Wed, 27 Jul 2011 14:56:52 -0700 (PDT) Received: by 10.227.55.67 with SMTP id t3mr269230wbg.90.1311803812412; Wed, 27 Jul 2011 14:56:52 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id fn12sm257642wbb.38.2011.07.27.14.56.50 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 14:56:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp> Date: Wed, 27 Jul 2011 23:56:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6030F823-5D49-40FD-B619-3C9FCF9E2260@bblfish.net> References: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 21:56:54 -0000 On 27 Jul 2011, at 23:29, Martin Rex wrote: >>=20 >>=20 >> They find HTTPS' way of doing that intrusive. >>=20 >> On the web you logoff from (or by) the server. >>=20 >> Naturally logoffs must trickle down to clients >> if they have logged-in using HTTPS CCA otherwise >> they are de-facto logged-in due to the TLS caching. >=20 > "Logoff" is a pure server-side concept with respect to server-side > state. A logoff concept that requires cooperation from the client > is technical nonsense. Any server-side destruction of backend-state > associated with particular clients must work completely independent > of what the client does. Early consensual destruction of backend > state if the client explicitly asks for it is OK. But any > server-initiated "logoff" concept that involves the client > amounts to technical cluelessness. why is that? Why can't the client log itself off. That would be much = better for the user, as he would be in control of his identity. This could be done easily by a browser both with cookies and with TLS: - with cookies: the browser should tie every cookie and state to a user = identity. When the user switches identity, the cookies stop getting sent. For the = server that ends up being the equivalent of a log-off. - with TLS the client breaks the connection, and re-established a = completely new one. Henry Social Web Architect http://bblfish.net/ From mrex@sap.com Wed Jul 27 15:38:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31E11E8092 for ; Wed, 27 Jul 2011 15:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_48=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 7JAhnAcotkJO for ; Wed, 27 Jul 2011 15:38:02 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6C41711E8084 for ; Wed, 27 Jul 2011 15:38:02 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6RMbsSs017504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 00:37:59 +0200 (MEST) From: Martin Rex Message-Id: <201107272237.p6RMbr7r015848@fs4113.wdf.sap.corp> To: henry.story@bblfish.net (Henry Story) Date: Thu, 28 Jul 2011 00:37:53 +0200 (MEST) In-Reply-To: <6030F823-5D49-40FD-B619-3C9FCF9E2260@bblfish.net> from "Henry Story" at Jul 27, 11 11:56:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 22:38:03 -0000 Henry Story wrote: > > On 27 Jul 2011, at 23:29, Martin Rex wrote: > > > > "Logoff" is a pure server-side concept with respect to server-side > > state. A logoff concept that requires cooperation from the client > > is technical nonsense. Any server-side destruction of backend-state > > associated with particular clients must work completely independent > > of what the client does. Early consensual destruction of backend > > state if the client explicitly asks for it is OK. But any > > server-initiated "logoff" concept that involves the client > > amounts to technical cluelessness. > > why is that? Why can't the client log itself off. That falls under "Early consensual destruction of backend state if the client explicitly asks for it is OK" above. > That would be much better for the user, as he would be > in control of his identity. The user is _always_ in control of his identity. But you can never get virginity back once you give it up. Once you revealed your identity to a server, you can not undo it. > > This could be done easily by a browser both with cookies and with TLS: > - with cookies: the browser should tie every cookie and state > to a user identity. When the user switches identity, the cookies > stop getting sent. > - with TLS the client breaks the connection, > and re-established a completely new one. If you're wondering whether there should be a standard where a Web Browser should offer a context-specific, easily accessible button to the user to make the Browser _prompt_ on the next connect to the server before providing any of the integrated "single Sign-on" functionality (be it cookies, WWW-Authenticate: headers, HTTP Negotiate, or TLS CCA or automatic user&password fill-in to forms). Making such a functionality accessible to the server probably would not hurt. Preferably _without_ javascript or other active content, and instead controls similar to (e.g. META) for page refresh and client-side cache flushing. > > For the server that ends up being the equivalent of a log-off. If a user wants to perform a "logoff", he might be interested in _both_ happening: - the server side backend state getting flushed along with client-side state (so that no-one with a copy of the server application sessionid can resume the session from elsewhere without having to perform an authentcation step). - the browser suspending _IN_A_CONTEXT/TARGET_SPECIFIC_FASHION_ any single Sign-On functionality (Cookies,WWW-Authenticate,HTTP Negotiate, TLS CCA, automatic user&password fill-in) until it is interactively reconfirmed to continue It may be more difficult to standardize a client-side "button" and the signaling of the "logoff" to the server application so that it can clean up, than to require the application to offer a "logoff" button and tell the browser to suspend Single Sign-On for this context/target. Closing of a browser window does not necessarily imply a "logoff" for apps that allow for several parallel and independent workflows. The server app usually knows more about the application architecture than the user does (and whether to warn the user about unsaved date that will get purged by logoff) -Martin From henry.story@bblfish.net Wed Jul 27 15:54:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41AD11E80AB for ; Wed, 27 Jul 2011 15:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_48=0.6, 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 YXfZreW5w2Is for ; Wed, 27 Jul 2011 15:54:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B688211E8084 for ; Wed, 27 Jul 2011 15:54:28 -0700 (PDT) Received: by wyj26 with SMTP id 26so1328067wyj.31 for ; Wed, 27 Jul 2011 15:54:27 -0700 (PDT) Received: by 10.227.160.140 with SMTP id n12mr343530wbx.69.1311807267749; Wed, 27 Jul 2011 15:54:27 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-201-28.w83-114.abo.wanadoo.fr [83.114.32.28]) by mx.google.com with ESMTPS id t46sm246425wec.38.2011.07.27.15.54.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jul 2011 15:54:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <201107272237.p6RMbr7r015848@fs4113.wdf.sap.corp> Date: Thu, 28 Jul 2011 00:54:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EDE3DAC-59A0-492F-A354-02CF472FC5AB@bblfish.net> References: <201107272237.p6RMbr7r015848@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1244.3) Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 27 Jul 2011 22:54:32 -0000 On 28 Jul 2011, at 00:37, Martin Rex wrote: > Henry Story wrote: >>=20 >> On 27 Jul 2011, at 23:29, Martin Rex wrote: >>>=20 >>> "Logoff" is a pure server-side concept with respect to server-side >>> state. A logoff concept that requires cooperation from the client >>> is technical nonsense. Any server-side destruction of backend-state >>> associated with particular clients must work completely independent >>> of what the client does. Early consensual destruction of backend >>> state if the client explicitly asks for it is OK. But any >>> server-initiated "logoff" concept that involves the client >>> amounts to technical cluelessness. >>=20 >> why is that? Why can't the client log itself off. >=20 > That falls under "Early consensual destruction of backend state if > the client explicitly asks for it is OK" above. >=20 >> That would be much better for the user, as he would be >> in control of his identity. >=20 > The user is _always_ in control of his identity. > But you can never get virginity back once you give it up. >=20 > Once you revealed your identity to a server, you can not > undo it. Well if you break the connection, and you reconnect without leaking=20 any of the previous session information - ignoring the tricky ip address issue - the server can't know you are the same person, and so you are a virgin once more. (Which means of course that you loose all the built up trust you may have worked on before. ) But of course you may wish to login to the site with a different = personality. A lot of people have done this by opening a number of Facebook accounts = in order to understand how that system works. >> This could be done easily by a browser both with cookies and with = TLS: >> - with cookies: the browser should tie every cookie and state >> to a user identity. When the user switches identity, the cookies >> stop getting sent. >> - with TLS the client breaks the connection, >> and re-established a completely new one. >=20 > If you're wondering whether there should be a standard where > a Web Browser should offer a context-specific, easily accessible = button > to the user to make the Browser _prompt_ on the next connect to the = server > before providing any of the integrated "single Sign-on" functionality > (be it cookies, WWW-Authenticate: headers, HTTP Negotiate, or TLS CCA > or automatic user&password fill-in to forms). This is what Aza Raskin at Mozilla Labs demonstrated with his Weave = project. http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ I don't think this requires a standard here. It requires the browser to be able to keep track of different user personas, be able to remember = which persona the user has on different sites, and make it easy for him/her to logout or change persona on any of these sites. This could mean just = sending different cookies at the next connection (when changing persona) or = sending none - when becoming anonymous again. >=20 > Making such a functionality accessible to the server probably would > not hurt. Preferably _without_ javascript or other active content, > and instead controls similar to (e.g. META) for page refresh and > client-side cache flushing. So as I see it the client does not need to do any of that. He can just stop using the cookie information.=20 Of course it could be nice if he browser could also send a polite logout=20= message on a cookie or a TLS session before doing that. But I think it=20= would already be a big step forward without this. >=20 >=20 >>=20 >> For the server that ends up being the equivalent of a log-off. >=20 > If a user wants to perform a "logoff", he might be interested in > _both_ happening: >=20 > - the server side backend state getting flushed along with = client-side > state (so that no-one with a copy of the server application = sessionid > can resume the session from elsewhere without having to perform > an authentcation step). >=20 > - the browser suspending _IN_A_CONTEXT/TARGET_SPECIFIC_FASHION_ any > single Sign-On functionality (Cookies,WWW-Authenticate,HTTP = Negotiate, > TLS CCA, automatic user&password fill-in) until it is interactively > reconfirmed to continue agree.=20 I just think the second one could be done without the first one being = finished. >=20 > It may be more difficult to standardize a client-side "button" and > the signaling of the "logoff" to the server application so that it > can clean up, than to require the application to offer a "logoff" > button and tell the browser to suspend Single Sign-On for this > context/target. I don't think you need to standardise the client. Aza Raskin showed a very appealing UI it seems to me. Others could do that in different = ways. > Closing of a browser window does not necessarily > imply a "logoff" for apps that allow for several parallel and > independent workflows. The server app usually knows more about > the application architecture than the user does (and whether to > warn the user about unsaved date that will get purged by logoff) well login/logoff is perhaps the wrong terms. Authentication and = recognition of a user is what counts.=20 >=20 >=20 > -Martin Social Web Architect http://bblfish.net/ From paul@xelerance.com Wed Jul 27 17:17:11 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A069D21F86C2 for ; Wed, 27 Jul 2011 17:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 FMRMzObczDBJ for ; Wed, 27 Jul 2011 17:17:10 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id C0C0B21F86C1 for ; Wed, 27 Jul 2011 17:17:09 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BDA6357124; Wed, 27 Jul 2011 20:18:05 -0400 (EDT) Date: Wed, 27 Jul 2011 20:18:05 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 00:17:11 -0000 On Wed, 27 Jul 2011, Eric Rescorla wrote: >> With that reasoning, we'd all be riding horses still. The extension offers a >> way >> out of some overly complex outdated overkill technology, with no impact on >> people >> who wish to remain using horses. > > For some reason this argument is not exactly convincing. Funny, this exact topic came up today at the Privacy Enhancing Technology conference in Waterloo today (that I'm sadly missing because it conflicted with IETF). Do you trust Peter Gutmann's research more? http://www.nspw.org/papers/2006/nspw2006-gutmann.pdf Dealing with X.509 is hard, even for CS people. It might not seem logical to you or anyone else skilled enough to participate with the IETF, but it is true nonetheless. > Regardless, as I said in my review, this seems like it's largely > duplicative of cached info (and in fact, rather clumsier). I'm interested in knowing why you consider it "clumsy". Especially because it closely follows the RFC 6066 section 6 extension for supressing of sending CA bundles with "trusted_ca_keys". That apparent clumsiness passed WGLC and IESG. This extension basically lets the client say "I have trust for this key, no need to send it in PKIX" and the server to simply suppress that message. It's not like this is something complicated as writing up some 80's container format from hell, add an arbitrary inception and expiry date, some magical key purpose bits that will not get used, property bits to be ignored, and some made up conflicting identity for us to later ignore and then grab all of that and wrap it up by signing itself. Seriously, what is "clumsy" is saying "Just make up some unvalidatable data for the PKIX container and then have the client ignore it later". > Is there something here that couldn't be accomplished > by a SPKI cache type in cached-info? You mean apart from dragging in less then just the subjectPublicKeyInfo from ASN.1? Yes we could use a side effect of "caching" or "trusted_ca_keys", though they "MAY" would force every new TLS client to still drag in all of PKIX. I see value in a clear and unambiguous method for a TLS client to say "I am not going to use PKIX validation - do not send me PKIX". As for your 99.99999% figure - if you don't have a technical method to opt out of PKIX validation, then sure, 99.9999% of TLS in 20 years will use PKIX. But it would not proof your point. instead, you would made it happen. I for one hope to see that in 20 years people can just use a "generate key" and "generate TLSA" command, and put that in their DNS zone - even without a CS PHD. Paul From paul.hoffman@vpnc.org Wed Jul 27 17:49:06 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847B321F8B2D for ; Wed, 27 Jul 2011 17:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 sQ6IZj77XWrD for ; Wed, 27 Jul 2011 17:49:06 -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 A952F21F8B2B for ; Wed, 27 Jul 2011 17:49:05 -0700 (PDT) Received: from dhcp-2121.meeting.ietf.org (dhcp-2121.meeting.ietf.org [130.129.33.33]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6S0mk4p099424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Jul 2011 17:48:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Paul Hoffman In-Reply-To: Date: Wed, 27 Jul 2011 20:49:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6965DB76-72C3-4AC1-92F5-699B8A2E4337@vpnc.org> References: To: tls@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 00:49:06 -0000 On Jul 27, 2011, at 10:33 AM, Eric Rescorla wrote: > 1. All extensions to TLS (including AD sponsored extensions) must > minimally be sent explicitly to the TLS WG prior to or during IETF LC. > If that process surfaces significant objections, then these objections > should be resolved prior to publication. For trivial extensions, this > process is sufficient. An example of a trivial extension would be > signaling for a new TLS Exporter (RFC 5705), as this has no impact on > TLS proper. The person who gets to define "significant" and "resolved" controls all = extensions, then. It would be better if they were defined more fully = here. > 2. All non-trivial extensions (i.e., anything which alters TLS > processing in some way) must be presented to the TLS WG and at least > be considered unobjectionable. OK, add "unobjectionable" to the list above. > They need not be WG items. Extensions > in this category can proceed without widespread WG support, but must > either have no significant objections or achieve WG consensus to > proceed. An example of a non-trivial extension would be one that > defined a new form of MAC truncation. This alters TLS processing but > not the state machine. >=20 > 3. Extensions which which involve significant changes to the TLS > model/state machine, adds new messages, etc. must be TLS WG work > items, or, if primarily designed for some other WG, must be work items > of that WG and developed in collaboration with the TLS WG and subject > to the WG consensus process. Why is adding a message so important here? Who defines what changes the = "TLS model" or "TLS state machine? > Extensions in this category will > generally need to show significant amounts of non-author support in > order to proceed. Particular attention will be paid to the impact of > such extensions on the TLS architecture and the impact on potential > future extensions. An example of such an extension would be TLS > Tickets (RFC 4507), because it involved redoing the resumption state > machine and adding a new TLS message. >=20 >=20 > The WG considers it an important objective to to provide timely, > clear dispositions of new efforts. Work will be taken on when there is > consensus and based on the WG's estimate of the level of interest and > the size and priority of the current workload. Who defines "level of interest"? If there is a document that is fairly = trivial and also gets little interest, is it prohibited from progressing = by this rule? > Reconsideration of > proposals which have failed to gather consensus will be prioritized > behind proposals for new work which have not yet been considered. > In general, requests for reconsideration should only be made once a > proposal has been significantly revised and there is evidence of > substantial level of community support. Overall: The proposed rules above seem to be about the same as the = unspoken rules today, with the difference being that they are stated but = completely unclear. It doesn't feel like this is an improvement over the = current situation. --Paul Hoffman From nico@cryptonector.com Wed Jul 27 19:18:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B326F11E8129 for ; Wed, 27 Jul 2011 19:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.808 X-Spam-Level: X-Spam-Status: No, score=-2.808 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qcEB9AKegOl3 for ; Wed, 27 Jul 2011 19:18:31 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1611E8118 for ; Wed, 27 Jul 2011 19:18:31 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id B803421DE59 for ; Wed, 27 Jul 2011 19:18:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nUiWZtjpDORG00uLVYa3P OspbMOY0y/kJWi2U03iO5ioxqa6Tzz9JsbBFTnbY8wpoZOdthPaj1lO0mUXWC+QL exBoKlHqsrFqSaQcyeTWwosWhtXx+gqGWKIHIiPfzkiVg20SqYJgR7YFjy6ECvXS ozazv4MGAN3T9JnK3wCtfQ= 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=O7rOR/t1Z3sToUah1yQ3 h8aMtd4=; b=SoFtRX1hTr4ns/ogpSdfrdKSTsau9OnUjFJ/hDtpFooRyDSBttm1 9dOGzkM7wtqgN9aXFU1h52Oen6KhDrR3sRdLeBn2M8mZGEAub8vFaP94Y/f0QGBk /yll+UC944pX3cBTBN5JrjMOTr2EEoaGzyTo/CATmPc4kzqUbBXoo74= Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9B69E21DE58 for ; Wed, 27 Jul 2011 19:18:22 -0700 (PDT) Received: by pzk6 with SMTP id 6so3457923pzk.26 for ; Wed, 27 Jul 2011 19:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.26.68 with SMTP id j4mr739447pbg.307.1311819502139; Wed, 27 Jul 2011 19:18:22 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Wed, 27 Jul 2011 19:18:22 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Wed, 27 Jul 2011 19:18:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 27 Jul 2011 21:18:22 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec52155716f3ac004a917c775 Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 02:18:31 -0000 --bcaec52155716f3ac004a917c775 Content-Type: text/plain; charset=UTF-8 The TLS WG need not be around forever, so this WG-consensus-on-non-objectionability concept has at least that problem. Beyond that, do we have precedent for requiring that there be WG consensus that a proposal is not objectionable? (As opposed to WG consensus that the proposal should progress.) I would rather say that the IESG can require review in a then-appropriate WG (i.e., WG LC) in addition to IETF LC. Nico -- --bcaec52155716f3ac004a917c775 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The TLS WG need not be around forever, so this WG-consensus-on-non-objec= tionability concept has at least that problem.=C2=A0=C2=A0 Beyond that, do = we have precedent for requiring that there be WG consensus that a proposal = is not objectionable?=C2=A0 (As opposed to WG consensus that the proposal s= hould progress.)

I would rather say that the IESG can require review in a then-appropriat= e WG=C2=A0 (i.e., WG LC) in addition to IETF LC.

Nico
--

--bcaec52155716f3ac004a917c775-- From mrex@sap.com Wed Jul 27 19:48:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D017C11E8173 for ; Wed, 27 Jul 2011 19:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.912 X-Spam-Level: X-Spam-Status: No, score=-9.912 tagged_above=-999 required=5 tests=[AWL=0.337, 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 HbeUthbCnrmT for ; Wed, 27 Jul 2011 19:48:37 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81411E807F for ; Wed, 27 Jul 2011 19:48:36 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6S2mY8W007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 04:48:34 +0200 (MEST) From: Martin Rex Message-Id: <201107280248.p6S2mY16000185@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 28 Jul 2011 04:48:34 +0200 (MEST) In-Reply-To: <6965DB76-72C3-4AC1-92F5-699B8A2E4337@vpnc.org> from "Paul Hoffman" at Jul 27, 11 08:49:03 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 02:48:37 -0000 Overall I'm OK with Erics message. I did not notice anything unusual, unexpected or objectionable, but things that I silently assumed or consider a reasonable approach. Paul Hoffman wrote: > > On Jul 27, 2011, at 10:33 AM, Eric Rescorla wrote: > > > 1. All extensions to TLS (including AD sponsored extensions) must > > minimally be sent explicitly to the TLS WG prior to or during IETF LC. > > If that process surfaces significant objections, then these objections > > should be resolved prior to publication. For trivial extensions, this > > process is sufficient. An example of a trivial extension would be > > signaling for a new TLS Exporter (RFC 5705), as this has no impact on > > TLS proper. > > The person who gets to define "significant" and "resolved" controls all > extensions, then. It would be better if they were defined more fully here. The description in (1) sound like WG review and WG consensus process in case that objections are raised. "A person" would probably more apply to "expert review" situations. What exactly are you looking for? That the TLS WG should come up with a more narrow "consensus" than used in the rest of the IETF? > > > 2. All non-trivial extensions (i.e., anything which alters TLS > > processing in some way) must be presented to the TLS WG and at least > > be considered unobjectionable. > > OK, add "unobjectionable" to the list above. I believe "unobjectionable" (should) refer to a clean issue resolution and WG consensus procedure. > > Why is adding a message so important here? > Who defines what changes the "TLS model" or "TLS state machine? Because new TLS handshake messages, and the exact ordering of the handshake messages have a significant impact on the TLS state machine, and the insertion or ommission of messages might have non-obvious consequences for the security properties of the protocol. The ordering of TLS extensions in Client and Server Hello handshake messages is well defined (=arbitrary/unordered) -- unless there are competing or conflicting extensions. competing=diffing preference/ordering about the same characteristic conflicting=different specificiation of the same characteristic > > Overall: The proposed rules above seem to be about the same as the > unspoken rules today, with the difference being that they are stated > but completely unclear. It doesn't feel like this is an improvement > over the current situation. I did not conceive it as an attempt to change the situation, but more likely to summarize customs in writing, in face of the recent flood of TLS-related documents, and where at least some of the authors are not recognized as active TLS WG participants which could be expected to know how things work around here. Do you remember the discussion on these two proposals? http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 http://tools.ietf.org/html/draft-housley-evidence-extns-01 -Martin From anders.rundgren@telia.com Wed Jul 27 21:51:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED70A21F8B15 for ; Wed, 27 Jul 2011 21:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 VnMTTHsPGgqN for ; Wed, 27 Jul 2011 21:51:20 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1390C21F8B12 for ; Wed, 27 Jul 2011 21:51:20 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F008006EF; Thu, 28 Jul 2011 06:51:18 +0200 Message-ID: <4E30EAB7.8030406@telia.com> Date: Thu, 28 Jul 2011 06:51:03 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: mrex@sap.com References: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp> In-Reply-To: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 04:51:21 -0000 On 2011-07-27 23:29, Martin Rex wrote: > Anders Rundgren wrote: >> >> Lots of banks wants to use CCA for their users. > > That is a non sequitur. > > Banks (here in Germany) have abandoned tradtional TANs based on > the unconditional presumption that client PCs are infested with > malware, and most banks in Germany are currently replacing indexed TANs (iTAN) > presumably based on the perception that malware on clients (trojans/phishing) > has caught up with iTAN procedure complexity. > > At this point, with the presumption that all client PCs are > thoroughly infested with malware, going for a Single Sign-On > mechanism would be completely braindead and irresponsible. So using client certificates for authentication is such a bad idea that there is no point in looking into issues on how to make it better? How is the German e-card supposed work then? When it comes to malware the situation in most cases is that the PKI underpinnings featured in modern computers haven't progressed a single step since 1995 when it was introduced. Elementary (in principle at least) stuff like putting ACLs on keys so that only granted applications which has been known for decades is still considered a research topic. Leaving this thread, continuing with making PKI for banks and other a better solution than passwords. Anders > > >> >> They find HTTPS' way of doing that intrusive. >> >> On the web you logoff from (or by) the server. >> >> Naturally logoffs must trickle down to clients >> if they have logged-in using HTTPS CCA otherwise >> they are de-facto logged-in due to the TLS caching. > > "Logoff" is a pure server-side concept with respect to server-side > state. A logoff concept that requires cooperation from the client > is technical nonsense. Any server-side destruction of backend-state > associated with particular clients must work completely independent > of what the client does. Early consensual destruction of backend > state if the client explicitly asks for it is OK. But any > server-initiated "logoff" concept that involves the client > amounts to technical cluelessness. > > And application level state management ought to be ***completely*** > independent from the TLS session cache management. The server > side TLS session cache management must be completely independent > from application level backend state management when you're > using a transport with non-persistent connections (such as HTTPS). > > The lower protocol levels of the server must be free to manage > TLS session cache lifetime based on resource availability > and administrative or operational requirements, and short > server-side TLS session lifetimes (several minutes absolute lifetime), > server-side TLS session cache flushing (when performing > debugging on an otherwise productive system, or when updating > the server certificate or changing the list of trusted > client cert signers), as well as temporarily completely > disabling server side TLS session caching MUST NOT interfere > with application level session management. Any application > that suffers from such server side TLS session cache > characertistics is seriously and thoroughly broken > (lack of abstraction and invalid protocol layering). > > > -Martin > From pgut001@login01.cs.auckland.ac.nz Wed Jul 27 23:11:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46621F8BF2 for ; Wed, 27 Jul 2011 23:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 1rbXHKJydqT7 for ; Wed, 27 Jul 2011 23:11:14 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6453221F8BF0 for ; Wed, 27 Jul 2011 23:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311833474; x=1343369474; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20HTTPS=20clie nt-certificate-authentication=20in=20browsers|Cc:=20tls@i etf.org|In-Reply-To:=20<201107272129.p6RLTcIm011843@fs411 3.wdf.sap.corp>|Message-Id:=20|Date:=20Thu,=2028=20Jul=202011=2018:1 1:03=20+1200; bh=Xaz7yXUeyk29zwLL+dzv2kMxRWPYwRT4MABHO1S6Y8k=; b=FOJPnuTo4cWdxaxkCtF3PWk4EqS3VMwSZDdOFpyMVblfzWHmXDkDpR4e 2M0UdLKTErwa7bPvJX3iZO+cKfKpjDVO/gU7URzP9Ge8iAxUj8Jg7SXt1 eigjuXtbrflogNUtiV7RNLWrwizZ+kH3jZarFhp/i6+5WBmeE4f5vnFiS M=; X-IronPort-AV: E=Sophos;i="4.67,280,1309694400"; d="scan'208";a="74570277" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 28 Jul 2011 18:11:03 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QmJoF-0006I7-IX; Thu, 28 Jul 2011 18:11:03 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QmJoF-0004YD-Mk; Thu, 28 Jul 2011 18:11:03 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201107272129.p6RLTcIm011843@fs4113.wdf.sap.corp> Message-Id: Date: Thu, 28 Jul 2011 18:11:03 +1200 Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 06:11:15 -0000 Martin Rex writes: >Anders Rundgren wrote: >> Lots of banks wants to use CCA for their users. > >That is a non sequitur. > >Banks (here in Germany) have abandoned tradtional TANs based on the >unconditional presumption that client PCs are infested with malware, and >most banks in Germany are currently replacing indexed TANs (iTAN) presumably >based on the perception that malware on clients (trojans/phishing) has caught >up with iTAN procedure complexity. > >At this point, with the presumption that all client PCs are thoroughly >infested with malware, going for a Single Sign-On mechanism would be >completely braindead and irresponsible. That was my feeling as well. Moving from TANs (or plain passwords if you're a US bank) to client certs is at best pointless and at worst a step backwards in security. Even if you could overcome the monumental usability problems (and there's no evidence that we can do this), you end up with a mechanism that's even less secure than basic TANs because use of a TAN requires human intervention while a MITB (man-in-the-browser) can use your private key to sign whatever they want as often as they want without your knowledge. Client- side PKI was designed for an attack model invented by cryptographers to justify the use of fun crypto stuff, but it has little (if anything) to do with the threats that we're actually facing today. Peter. From henry.story@bblfish.net Thu Jul 28 01:13:58 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF3721F8793 for ; Thu, 28 Jul 2011 01:13:58 -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 gJhzRDu+Sx2r for ; Thu, 28 Jul 2011 01:13:57 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACD7B21F876A for ; Thu, 28 Jul 2011 01:13:56 -0700 (PDT) Received: by wwe5 with SMTP id 5so1463778wwe.13 for ; Thu, 28 Jul 2011 01:13:55 -0700 (PDT) Received: by 10.227.42.131 with SMTP id s3mr7425836wbe.104.1311840834426; Thu, 28 Jul 2011 01:13:54 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id eo18sm614807wbb.12.2011.07.28.01.13.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 01:13:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Thu, 28 Jul 2011 10:13:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Gutmann , tls@ietf.org X-Mailer: Apple Mail (2.1244.3) Cc: "public-xg-webid@w3.org XG" Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 08:13:59 -0000 On 28 Jul 2011, at 08:11, Peter Gutmann wrote: > Martin Rex writes: >> Anders Rundgren wrote: >>> Lots of banks wants to use CCA for their users. >>=20 >> That is a non sequitur. >>=20 >> Banks (here in Germany) have abandoned tradtional TANs based on the=20= >> unconditional presumption that client PCs are infested with malware, = and=20 >> most banks in Germany are currently replacing indexed TANs (iTAN) = presumably=20 >> based on the perception that malware on clients (trojans/phishing) = has caught=20 >> up with iTAN procedure complexity. >>=20 >> At this point, with the presumption that all client PCs are = thoroughly=20 >> infested with malware, going for a Single Sign-On mechanism would be=20= >> completely braindead and irresponsible. >=20 > That was my feeling as well. Moving from TANs (or plain passwords if = you're a=20 > US bank) to client certs is at best pointless and at worst a step = backwards in=20 > security. Even if you could overcome the monumental usability = problems (and=20 > there's no evidence that we can do this), you end up with a mechanism = that's=20 > even less secure than basic TANs because use of a TAN requires human=20= > intervention while a MITB (man-in-the-browser) can use your private = key to=20 > sign whatever they want as often as they want without your knowledge. = Client-=20 > side PKI was designed for an attack model invented by cryptographers = to=20 > justify the use of fun crypto stuff, but it has little (if anything) = to do=20 > with the threats that we're actually facing today. Security like knowledge is not absolute. It is a context relative, modal = notion. Above you sound very much like the skeptic, who argues that = since we don't know we were not captured by some Alpha Centaurians, who = took our brain, put it in a vat, and started feeding us perceptions of = the way the world is to make it look like what we see, since we don't = know that, we don't and can't know anything. The answer to that is to = see that skeptical claims are not transitive on our claims to knowledge. = Just as hopeless security scenarios are not a proof that we are not = secure. "A gang of thieves could torture me until I reveal the TAN = (Transaction authentication number), so TANs are not secure" would be an = example of such reasoning. So I think we should look at where we are now. Currently the biggest = security problem is people using passwords for everything, and often = using the same password for every site. One time passwords can work for = banks but not for most other applications. Imagine one time passwords = for every site you go into. What would happen? You would end up with one = massive site controlling the whole internet, because the biggest site = with the most content, would be the only one people would bother having = passwords for (sound familiar?) And having one site - or just a few of = them - provide all the content, is the beginning of a modern = dictatorship, since that site will inevitably be taken over by the most = power hungry interests. So I am weary of arguments that proceed from = fear, to denying us technology that can help us bypass monopolies of = information. There are huge interests at stake to make us believe those = types of arguments, and so we should analyse each one very carefully = looking for flaws. Of course the solution to man in the browser scenarios is keys built in = hardware that cannot be read by any application, and also notifications = or log files for how and when they are used. Furthermore in higher = security contexts they can be combined with other authentication = techniques, such as TANs. But as you point out, it is difficult to get = those deployed and useable if one does not first start with less secure = but easier to deploy solutions: like software based keychains. This is = not such a problem anyway. Operating systems are getting more and more = secure. Compare the latest windows, with Windows95 when the web started. = So man in the browser is less of a problem for the moment. By the time = it is we will have proven the value of these technologies and have = methods for placing the keys into hardware, be it on our computer or in = our watch speaking to our computer wirelessly. So client certs can be used with TANs. Would that make client certs for = banks useless? Not necessarily. Not if the client cert can be used to = connect to other web sites too (as http://webid.info/ allows you to do) = - say shopping web sites. You could use your regularly TAN verified = certificate to set up payments quickly on shopping sites. That is the = argument that Client certificates are useless is correct only on the = assumption that it is used by one web site only: the web site that gave = you the certificate. But that need not be the case. The web site that = gave you the certificate should be the one you use one time passwords = and certificates on, all the others you would use certificates only. = Monetary transactions could be initiated using certificates, but should = be finalised only with a TAN transaction at your banking web site. (Or = your bank could just send you an SMS, when such a transaction occurs to = notify you, and give you some time to deny it, though that would require = you to create a new certificate. A one click operation ) If you look at = it this way, and you use the network, you can see that this can in fact = help improve computer security, since viruses can be detected in many = more ways. Similar verification procedures could be set up in social web examples. = Your Freedom box would ask you more regularly for one time passwords - = though we can assume it has a hardware based private key. You use a = certificate to log into other sites. If messages that other sites send = you are done via an HTTP POST to your freedom box, then the damage a = virus who has stolen your key can do is going to be limited.=20 Those are the types of things should can look into, before shouting all = too easily about the death of client side certificates. Henry >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From anders.rundgren@telia.com Thu Jul 28 01:42:27 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1ED21F8C56 for ; Thu, 28 Jul 2011 01:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 FKX7sttXcW5h for ; Thu, 28 Jul 2011 01:42:27 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1125921F8C4A for ; Thu, 28 Jul 2011 01:42:27 -0700 (PDT) Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F00807BA0; Thu, 28 Jul 2011 10:42:21 +0200 Message-ID: <4E3120DD.7090306@telia.com> Date: Thu, 28 Jul 2011 10:42:05 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 08:42:28 -0000 So now we have come to the point where all forms of client- hosted keys used for authentication must die. Maybe you guys should join forces with Microsoft who after completely screwing up PKI and InformationCards, now turn their hope (and money) to putting all your keys in the "Cloud"? Platform security is a journey and it is by no means finished. Mobile phones that are less plagued by legacy and backward compatibility issues, will meet "the market's" security needs. Well, I excluded the 0.01% that for unknown reasons believe that security is more important than "getting the job done". Anders A really bad guy :-) On 2011-07-28 08:11, Peter Gutmann wrote: > Martin Rex writes: >> Anders Rundgren wrote: >>> Lots of banks wants to use CCA for their users. >> >> That is a non sequitur. >> >> Banks (here in Germany) have abandoned tradtional TANs based on the >> unconditional presumption that client PCs are infested with malware, and >> most banks in Germany are currently replacing indexed TANs (iTAN) presumably >> based on the perception that malware on clients (trojans/phishing) has caught >> up with iTAN procedure complexity. >> >> At this point, with the presumption that all client PCs are thoroughly >> infested with malware, going for a Single Sign-On mechanism would be >> completely braindead and irresponsible. > > That was my feeling as well. Moving from TANs (or plain passwords if you're a > US bank) to client certs is at best pointless and at worst a step backwards in > security. Even if you could overcome the monumental usability problems (and > there's no evidence that we can do this), you end up with a mechanism that's > even less secure than basic TANs because use of a TAN requires human > intervention while a MITB (man-in-the-browser) can use your private key to > sign whatever they want as often as they want without your knowledge. Client- > side PKI was designed for an attack model invented by cryptographers to > justify the use of fun crypto stuff, but it has little (if anything) to do > with the threats that we're actually facing today. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From stefan.winter@restena.lu Thu Jul 28 02:19:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4A621F8C79 for ; Thu, 28 Jul 2011 02:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.451 X-Spam-Level: X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, GB_ABOUTYOU=0.5, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6] 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 A3iH227MkUu9 for ; Thu, 28 Jul 2011 02:19:30 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A521F8C71 for ; Thu, 28 Jul 2011 02:19:29 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4BD19109FC for ; Thu, 28 Jul 2011 11:19:28 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2EEFF107C2 for ; Thu, 28 Jul 2011 11:19:28 +0200 (CEST) Message-ID: <4E31299F.6060400@restena.lu> Date: Thu, 28 Jul 2011 11:19:27 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B113A623DF3CA2908555D93" X-Virus-Scanned: ClamAV Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 09:19:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B113A623DF3CA2908555D93 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >>> Lots of banks wants to use CCA for their users. >> >=20 >> > That is a non sequitur. >> >=20 >> > Banks (here in Germany) have abandoned tradtional TANs based on >> > the unconditional presumption that client PCs are infested with >> > malware, and most banks in Germany are currently replacing indexed T= ANs (iTAN) >> > presumably based on the perception that malware on clients (trojans/= phishing) >> > has caught up with iTAN procedure complexity. >> >=20 >> > At this point, with the presumption that all client PCs are >> > thoroughly infested with malware, going for a Single Sign-On >> > mechanism would be completely braindead and irresponsible. > So using client certificates for authentication is such a bad idea that= > there is no point in looking into issues on how to make it better? > > How is the German e-card supposed work then? Just trolling around on this list every now and then, but can't resist to comment because I got my new eID card and also HBCI access recently. eID: The electronic identity card contains lots of personal details about you in some credential storage. It must be put into a whitelisted, EAL-whatever certified hardware device, connected via USB. There is one well-defined application on your computer which can ask the reader to retrieve a *subset* of the personal information stored. Other applications on the computer talk to this one application via an API. Your card reader will present the name of the application which wants the data, the pieces of data it wants to have from your card, and will ask for your authorisation to reveal that personal data. That is done via display+PIN directly on the card reader; no secret information ever leaks the card reader unless authorized directly on the device by the user. [1] This exhibits a property of the system which plain presentation of a X.509 certs won't allow: send only a subset of the stored information. It was refreshing to see this in action when I got my reader last week: my car insurance website signalled they need my real name, birthdate and birthplace to log me in to manage my insurance contract - not the rest of "me" that the card stores as well. Did that, logged into their website, no need to even create a username/password combo. Note that I didn't use the term "client certificate" at all - the system does involve PKI, but it's invisible to the user; all he has is a hardware token and a PIN. Sure: you need the card reader. Joe Sixpack can manage to go to a shop and put money on the shelf to get it, I assume - he does that same thing when buying a TV. Joe doesn't even have to know or care about how to get a "certificate" - he just gets all the stuff piggybacked on his usual plastic ID card. Banking: These days, TAN lists are going away. Alternatively, several approaches come into use: a) cell phone transaction numbers: enter transaction details on website, website generates a TAN for this very transaction, sends it along with the input it received from you to your (pre-registered) cell phone, you enter the number from the cell phone into the website. - A second, independent channel makes sure that even if the PC's comms channel is compromised, harm is prevented. b) offline generated transaction numbers. You get a hardware device, branded to your bank account (provisioned secrets). Its only interface to the outside world is a black&white camera to read a bar code; and a display to show a resulting TAN. Workflow is: you enter your transaction details on the web site, they generate $SOMEDATA from it (which includes the transaction details). $SOMEDATA is signalled to the hardware device via barcode scan, which uses it to generate a TAN based on the pre-provisioned secrets and $SOMEDATA. Bank does the same computation, TANs must match. Again, a second channel comes to the rescue even if the PC is compromised. c) HBCI - Home Banking Computer Interface. There is no browser at all(!). An application uses the HBCI API to talk to bank servers. Client authenticates with a smart card to be put into a card reader. All crypto again happens on the card reader. Joe sixpack gets the smart card+PIN by checking a box on his bank acocunt application and doesn't need to know anything more. None of these use Client Certificates in a browser. All of them survive if the PC is malware-infested. But yes, there are still attacks on these - they are not the cure-all. Greetings, Stefan Winter [1] There are also readers without a keyboard. If you use these, too bad for you, because then your infested PC will log your PIN and so on. Because of that, the system got quite some beating when introduced. --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig8B113A623DF3CA2908555D93 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4xKaMACgkQ+jm90f8eFWZQPgCcCqDxOr815xaLnLONNutilUA1 Ve0AmgIV75l1CEmebupNimxXr8P+ePLp =m1rv -----END PGP SIGNATURE----- --------------enig8B113A623DF3CA2908555D93-- From anders.rundgren@telia.com Thu Jul 28 02:54:04 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB4821F8C66 for ; Thu, 28 Jul 2011 02:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, 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 23+6IhZ6H5D6 for ; Thu, 28 Jul 2011 02:54:03 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8952121F8C63 for ; Thu, 28 Jul 2011 02:54:03 -0700 (PDT) Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0080B529; Thu, 28 Jul 2011 11:54:01 +0200 Message-ID: <4E3131AA.5010703@telia.com> Date: Thu, 28 Jul 2011 11:53:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Stefan Winter References: <4E31299F.6060400@restena.lu> In-Reply-To: <4E31299F.6060400@restena.lu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 09:54:04 -0000 http://www.hbci-kernel.de/fints.htm I'm happy that none the banks I have talked have any interests in such crap. The usage level of the German eID is hardly measurable either. /A On 2011-07-28 11:19, Stefan Winter wrote: > Hi, > >>>> Lots of banks wants to use CCA for their users. >>>> >>>> That is a non sequitur. >>>> >>>> Banks (here in Germany) have abandoned tradtional TANs based on >>>> the unconditional presumption that client PCs are infested with >>>> malware, and most banks in Germany are currently replacing indexed TANs (iTAN) >>>> presumably based on the perception that malware on clients (trojans/phishing) >>>> has caught up with iTAN procedure complexity. >>>> >>>> At this point, with the presumption that all client PCs are >>>> thoroughly infested with malware, going for a Single Sign-On >>>> mechanism would be completely braindead and irresponsible. >> So using client certificates for authentication is such a bad idea that >> there is no point in looking into issues on how to make it better? >> >> How is the German e-card supposed work then? > > Just trolling around on this list every now and then, but can't resist > to comment because I got my new eID card and also HBCI access recently. > > eID: The electronic identity card contains lots of personal details > about you in some credential storage. It must be put into a whitelisted, > EAL-whatever certified hardware device, connected via USB. There is one > well-defined application on your computer which can ask the reader to > retrieve a *subset* of the personal information stored. Other > applications on the computer talk to this one application via an API. > Your card reader will present the name of the application which wants > the data, the pieces of data it wants to have from your card, and will > ask for your authorisation to reveal that personal data. That is done > via display+PIN directly on the card reader; no secret information ever > leaks the card reader unless authorized directly on the device by the > user. [1] > > This exhibits a property of the system which plain presentation of a > X.509 certs won't allow: send only a subset of the stored information. > > It was refreshing to see this in action when I got my reader last week: > my car insurance website signalled they need my real name, birthdate and > birthplace to log me in to manage my insurance contract - not the rest > of "me" that the card stores as well. Did that, logged into their > website, no need to even create a username/password combo. > > Note that I didn't use the term "client certificate" at all - the system > does involve PKI, but it's invisible to the user; all he has is a > hardware token and a PIN. > > Sure: you need the card reader. Joe Sixpack can manage to go to a shop > and put money on the shelf to get it, I assume - he does that same thing > when buying a TV. Joe doesn't even have to know or care about how to get > a "certificate" - he just gets all the stuff piggybacked on his usual > plastic ID card. > > Banking: These days, TAN lists are going away. Alternatively, several > approaches come into use: > > a) cell phone transaction numbers: enter transaction details on website, > website generates a TAN for this very transaction, sends it along with > the input it received from you to your (pre-registered) cell phone, you > enter the number from the cell phone into the website. - A second, > independent channel makes sure that even if the PC's comms channel is > compromised, harm is prevented. > > b) offline generated transaction numbers. You get a hardware device, > branded to your bank account (provisioned secrets). Its only interface > to the outside world is a black&white camera to read a bar code; and a > display to show a resulting TAN. Workflow is: you enter your transaction > details on the web site, they generate $SOMEDATA from it (which includes > the transaction details). $SOMEDATA is signalled to the hardware device > via barcode scan, which uses it to generate a TAN based on the > pre-provisioned secrets and $SOMEDATA. Bank does the same computation, > TANs must match. Again, a second channel comes to the rescue even if the > PC is compromised. > > c) HBCI - Home Banking Computer Interface. There is no browser at > all(!). An application uses the HBCI API to talk to bank servers. Client > authenticates with a smart card to be put into a card reader. All crypto > again happens on the card reader. Joe sixpack gets the smart card+PIN by > checking a box on his bank acocunt application and doesn't need to know > anything more. > > None of these use Client Certificates in a browser. All of them survive > if the PC is malware-infested. But yes, there are still attacks on these > - they are not the cure-all. > > Greetings, > > Stefan Winter > > [1] There are also readers without a keyboard. If you use these, too bad > for you, because then your infested PC will log your PIN and so on. > Because of that, the system got quite some beating when introduced. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From henry.story@bblfish.net Thu Jul 28 03:08:58 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A943621F8BE8 for ; Thu, 28 Jul 2011 03:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=-1.678, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, 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 kQ0sS0RYBCho for ; Thu, 28 Jul 2011 03:08:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7121F8BE4 for ; Thu, 28 Jul 2011 03:08:57 -0700 (PDT) Received: by wyj26 with SMTP id 26so32495wyj.31 for ; Thu, 28 Jul 2011 03:08:56 -0700 (PDT) Received: by 10.227.24.18 with SMTP id t18mr7416454wbb.101.1311847736011; Thu, 28 Jul 2011 03:08:56 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id fx12sm701073wbb.8.2011.07.28.03.08.54 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 03:08:55 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: <4E3131AA.5010703@telia.com> Date: Thu, 28 Jul 2011 12:08:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54838E8A-26D3-4B8E-9F0E-F03C3CF3AA86@bblfish.net> References: <4E31299F.6060400@restena.lu> <4E3131AA.5010703@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: Stefan Winter , tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 10:08:58 -0000 On 28 Jul 2011, at 11:53, Anders Rundgren wrote: > http://www.hbci-kernel.de/fints.htm >=20 > I'm happy that none the banks I have talked have any interests > in such crap. >=20 > The usage level of the German eID is hardly measurable either. >=20 > /A >=20 > On 2011-07-28 11:19, Stefan Winter wrote: >> Hi, >>=20 >>>>> Lots of banks wants to use CCA for their users. >>>>>=20 >>>>> That is a non sequitur. >>>>>=20 >>>>> Banks (here in Germany) have abandoned tradtional TANs based on >>>>> the unconditional presumption that client PCs are infested with >>>>> malware, and most banks in Germany are currently replacing indexed = TANs (iTAN) >>>>> presumably based on the perception that malware on clients = (trojans/phishing) >>>>> has caught up with iTAN procedure complexity. >>>>>=20 >>>>> At this point, with the presumption that all client PCs are >>>>> thoroughly infested with malware, going for a Single Sign-On >>>>> mechanism would be completely braindead and irresponsible. >>> So using client certificates for authentication is such a bad idea = that >>> there is no point in looking into issues on how to make it better? >>>=20 >>> How is the German e-card supposed work then? >>=20 >> Just trolling around on this list every now and then, but can't = resist >> to comment because I got my new eID card and also HBCI access = recently. >>=20 >> eID: The electronic identity card contains lots of personal details >> about you in some credential storage. It must be put into a = whitelisted, >> EAL-whatever certified hardware device, connected via USB. There is = one >> well-defined application on your computer which can ask the reader to >> retrieve a *subset* of the personal information stored. Other >> applications on the computer talk to this one application via an API. >> Your card reader will present the name of the application which wants >> the data, the pieces of data it wants to have from your card, and = will >> ask for your authorisation to reveal that personal data. That is done >> via display+PIN directly on the card reader; no secret information = ever >> leaks the card reader unless authorized directly on the device by the >> user. [1] >>=20 >> This exhibits a property of the system which plain presentation of a >> X.509 certs won't allow: send only a subset of the stored = information. Here I disagree. A system build with WebID enabled X509 certificates = should be able to release subsets of information too. But instead of = having the information come from your device, or be locked in the = certificate, the information can come from RESTful access to your = profile, or to related resources. Here is one way to do this: http://blogs.oracle.com/bblfish/entry/sketch_of_a_restful_photo This is just a generalisation of what your devices do. Think of adding a = web server to the device in question. Then give profiles a URL, and then = only show parts of the information to the authentified service = requesting them. Now there is no reason to put a web server on that = device, you might as well have it wherever you think is best. If you do = that, you are starting to see how http://webid.info can work. Henry >>=20 >> It was refreshing to see this in action when I got my reader last = week: >> my car insurance website signalled they need my real name, birthdate = and >> birthplace to log me in to manage my insurance contract - not the = rest >> of "me" that the card stores as well. Did that, logged into their >> website, no need to even create a username/password combo. >>=20 >> Note that I didn't use the term "client certificate" at all - the = system >> does involve PKI, but it's invisible to the user; all he has is a >> hardware token and a PIN. >>=20 >> Sure: you need the card reader. Joe Sixpack can manage to go to a = shop >> and put money on the shelf to get it, I assume - he does that same = thing >> when buying a TV. Joe doesn't even have to know or care about how to = get >> a "certificate" - he just gets all the stuff piggybacked on his usual >> plastic ID card. >>=20 >> Banking: These days, TAN lists are going away. Alternatively, several >> approaches come into use: >>=20 >> a) cell phone transaction numbers: enter transaction details on = website, >> website generates a TAN for this very transaction, sends it along = with >> the input it received from you to your (pre-registered) cell phone, = you >> enter the number from the cell phone into the website. - A second, >> independent channel makes sure that even if the PC's comms channel is >> compromised, harm is prevented. >>=20 >> b) offline generated transaction numbers. You get a hardware device, >> branded to your bank account (provisioned secrets). Its only = interface >> to the outside world is a black&white camera to read a bar code; and = a >> display to show a resulting TAN. Workflow is: you enter your = transaction >> details on the web site, they generate $SOMEDATA from it (which = includes >> the transaction details). $SOMEDATA is signalled to the hardware = device >> via barcode scan, which uses it to generate a TAN based on the >> pre-provisioned secrets and $SOMEDATA. Bank does the same = computation, >> TANs must match. Again, a second channel comes to the rescue even if = the >> PC is compromised. >>=20 >> c) HBCI - Home Banking Computer Interface. There is no browser at >> all(!). An application uses the HBCI API to talk to bank servers. = Client >> authenticates with a smart card to be put into a card reader. All = crypto >> again happens on the card reader. Joe sixpack gets the smart card+PIN = by >> checking a box on his bank acocunt application and doesn't need to = know >> anything more. >>=20 >> None of these use Client Certificates in a browser. All of them = survive >> if the PC is malware-infested. But yes, there are still attacks on = these >> - they are not the cure-all. >>=20 >> Greetings, >>=20 >> Stefan Winter >>=20 >> [1] There are also readers without a keyboard. If you use these, too = bad >> for you, because then your infested PC will log your PIN and so on. >> Because of that, the system got quite some beating when introduced. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From anders.rundgren@telia.com Thu Jul 28 03:36:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF2C21F8B3F for ; Thu, 28 Jul 2011 03:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, 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 HbvXAYzUTM6o for ; Thu, 28 Jul 2011 03:36:32 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id B537F21F8B39 for ; Thu, 28 Jul 2011 03:36:31 -0700 (PDT) Received: from [192.168.3.119] (193.12.106.2) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E9700024582; Thu, 28 Jul 2011 12:36:29 +0200 Message-ID: <4E313B9C.3040104@telia.com> Date: Thu, 28 Jul 2011 12:36:12 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Henry Story References: <4E31299F.6060400@restena.lu> <4E3131AA.5010703@telia.com> <54838E8A-26D3-4B8E-9F0E-F03C3CF3AA86@bblfish.net> In-Reply-To: <54838E8A-26D3-4B8E-9F0E-F03C3CF3AA86@bblfish.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 10:36:33 -0000 Henry, You're missing the point. These two guys says that having a key in the PC is braindead, particularly if you use it from a browser. Based on 15 years of experience of s.c. "security experts" we can safely drop this thread; it won't go anywhere. This attitude was OK before we entered the "Google- and Apple-age". It's an entirely different ball-game now! Anders On 2011-07-28 12:08, Henry Story wrote: > > On 28 Jul 2011, at 11:53, Anders Rundgren wrote: > >> http://www.hbci-kernel.de/fints.htm >> >> I'm happy that none the banks I have talked have any interests >> in such crap. >> >> The usage level of the German eID is hardly measurable either. >> >> /A >> >> On 2011-07-28 11:19, Stefan Winter wrote: >>> Hi, >>> >>>>>> Lots of banks wants to use CCA for their users. >>>>>> >>>>>> That is a non sequitur. >>>>>> >>>>>> Banks (here in Germany) have abandoned tradtional TANs based on >>>>>> the unconditional presumption that client PCs are infested with >>>>>> malware, and most banks in Germany are currently replacing indexed TANs (iTAN) >>>>>> presumably based on the perception that malware on clients (trojans/phishing) >>>>>> has caught up with iTAN procedure complexity. >>>>>> >>>>>> At this point, with the presumption that all client PCs are >>>>>> thoroughly infested with malware, going for a Single Sign-On >>>>>> mechanism would be completely braindead and irresponsible. >>>> So using client certificates for authentication is such a bad idea that >>>> there is no point in looking into issues on how to make it better? >>>> >>>> How is the German e-card supposed work then? >>> >>> Just trolling around on this list every now and then, but can't resist >>> to comment because I got my new eID card and also HBCI access recently. >>> >>> eID: The electronic identity card contains lots of personal details >>> about you in some credential storage. It must be put into a whitelisted, >>> EAL-whatever certified hardware device, connected via USB. There is one >>> well-defined application on your computer which can ask the reader to >>> retrieve a *subset* of the personal information stored. Other >>> applications on the computer talk to this one application via an API. >>> Your card reader will present the name of the application which wants >>> the data, the pieces of data it wants to have from your card, and will >>> ask for your authorisation to reveal that personal data. That is done >>> via display+PIN directly on the card reader; no secret information ever >>> leaks the card reader unless authorized directly on the device by the >>> user. [1] >>> >>> This exhibits a property of the system which plain presentation of a >>> X.509 certs won't allow: send only a subset of the stored information. > > Here I disagree. A system build with WebID enabled X509 certificates should be able to release subsets of information too. But instead of having the information come from your device, or be locked in the certificate, the information can come from RESTful access to your profile, or to related resources. > > Here is one way to do this: > > http://blogs.oracle.com/bblfish/entry/sketch_of_a_restful_photo > > This is just a generalisation of what your devices do. Think of adding a web server to the device in question. Then give profiles a URL, and then only show parts of the information to the authentified service requesting them. Now there is no reason to put a web server on that device, you might as well have it wherever you think is best. If you do that, you are starting to see how http://webid.info can work. > > Henry > > >>> >>> It was refreshing to see this in action when I got my reader last week: >>> my car insurance website signalled they need my real name, birthdate and >>> birthplace to log me in to manage my insurance contract - not the rest >>> of "me" that the card stores as well. Did that, logged into their >>> website, no need to even create a username/password combo. >>> >>> Note that I didn't use the term "client certificate" at all - the system >>> does involve PKI, but it's invisible to the user; all he has is a >>> hardware token and a PIN. >>> >>> Sure: you need the card reader. Joe Sixpack can manage to go to a shop >>> and put money on the shelf to get it, I assume - he does that same thing >>> when buying a TV. Joe doesn't even have to know or care about how to get >>> a "certificate" - he just gets all the stuff piggybacked on his usual >>> plastic ID card. >>> >>> Banking: These days, TAN lists are going away. Alternatively, several >>> approaches come into use: >>> >>> a) cell phone transaction numbers: enter transaction details on website, >>> website generates a TAN for this very transaction, sends it along with >>> the input it received from you to your (pre-registered) cell phone, you >>> enter the number from the cell phone into the website. - A second, >>> independent channel makes sure that even if the PC's comms channel is >>> compromised, harm is prevented. >>> >>> b) offline generated transaction numbers. You get a hardware device, >>> branded to your bank account (provisioned secrets). Its only interface >>> to the outside world is a black&white camera to read a bar code; and a >>> display to show a resulting TAN. Workflow is: you enter your transaction >>> details on the web site, they generate $SOMEDATA from it (which includes >>> the transaction details). $SOMEDATA is signalled to the hardware device >>> via barcode scan, which uses it to generate a TAN based on the >>> pre-provisioned secrets and $SOMEDATA. Bank does the same computation, >>> TANs must match. Again, a second channel comes to the rescue even if the >>> PC is compromised. >>> >>> c) HBCI - Home Banking Computer Interface. There is no browser at >>> all(!). An application uses the HBCI API to talk to bank servers. Client >>> authenticates with a smart card to be put into a card reader. All crypto >>> again happens on the card reader. Joe sixpack gets the smart card+PIN by >>> checking a box on his bank acocunt application and doesn't need to know >>> anything more. >>> >>> None of these use Client Certificates in a browser. All of them survive >>> if the PC is malware-infested. But yes, there are still attacks on these >>> - they are not the cure-all. >>> >>> Greetings, >>> >>> Stefan Winter >>> >>> [1] There are also readers without a keyboard. If you use these, too bad >>> for you, because then your infested PC will log your PIN and so on. >>> Because of that, the system got quite some beating when introduced. >>> >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > Social Web Architect > http://bblfish.net/ > > From henry.story@bblfish.net Thu Jul 28 04:12:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93221F8AD8 for ; Thu, 28 Jul 2011 04:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.083 X-Spam-Level: X-Spam-Status: No, score=-1.083 tagged_above=-999 required=5 tests=[AWL=-0.839, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, 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 SvNzXey5RTpt for ; Thu, 28 Jul 2011 04:12:19 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC3AD21F8AFA for ; Thu, 28 Jul 2011 04:12:18 -0700 (PDT) Received: by wwe5 with SMTP id 5so1557445wwe.13 for ; Thu, 28 Jul 2011 04:12:16 -0700 (PDT) Received: by 10.227.178.203 with SMTP id bn11mr7484817wbb.51.1311851536667; Thu, 28 Jul 2011 04:12:16 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id s12sm595585wec.32.2011.07.28.04.12.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 04:12:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <4E313B9C.3040104@telia.com> Date: Thu, 28 Jul 2011 13:12:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E31299F.6060400@restena.lu> <4E3131AA.5010703@telia.com> <54838E8A-26D3-4B8E-9F0E-F03C3CF3AA86@bblfish.net> <4E313B9C.3040104@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: Stefan Winter , tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 11:12:20 -0000 On 28 Jul 2011, at 12:36, Anders Rundgren wrote: > Henry, > You're missing the point. >=20 > These two guys says that having a key in the PC is braindead, > particularly if you use it from a browser. > Based on 15 years of experience of s.c. "security experts" we > can safely drop this thread; it won't go anywhere. >=20 > This attitude was OK before we entered the "Google- and Apple-age". > It's an entirely different ball-game now! I hear different voices in this conversation. But the best thing will be to build examples that can show how this technology can be used in new ways. All good technology is like that: it escapes the initial ideas of its creators. >=20 > Anders >=20 > On 2011-07-28 12:08, Henry Story wrote: >>=20 >> On 28 Jul 2011, at 11:53, Anders Rundgren wrote: >>=20 >>> http://www.hbci-kernel.de/fints.htm >>>=20 >>> I'm happy that none the banks I have talked have any interests >>> in such crap. >>>=20 >>> The usage level of the German eID is hardly measurable either. >>>=20 >>> /A >>>=20 >>> On 2011-07-28 11:19, Stefan Winter wrote: >>>> Hi, >>>>=20 >>>>>>> Lots of banks wants to use CCA for their users. >>>>>>>=20 >>>>>>> That is a non sequitur. >>>>>>>=20 >>>>>>> Banks (here in Germany) have abandoned tradtional TANs based on >>>>>>> the unconditional presumption that client PCs are infested with >>>>>>> malware, and most banks in Germany are currently replacing = indexed TANs (iTAN) >>>>>>> presumably based on the perception that malware on clients = (trojans/phishing) >>>>>>> has caught up with iTAN procedure complexity. >>>>>>>=20 >>>>>>> At this point, with the presumption that all client PCs are >>>>>>> thoroughly infested with malware, going for a Single Sign-On >>>>>>> mechanism would be completely braindead and irresponsible. >>>>> So using client certificates for authentication is such a bad idea = that >>>>> there is no point in looking into issues on how to make it better? >>>>>=20 >>>>> How is the German e-card supposed work then? >>>>=20 >>>> Just trolling around on this list every now and then, but can't = resist >>>> to comment because I got my new eID card and also HBCI access = recently. >>>>=20 >>>> eID: The electronic identity card contains lots of personal details >>>> about you in some credential storage. It must be put into a = whitelisted, >>>> EAL-whatever certified hardware device, connected via USB. There is = one >>>> well-defined application on your computer which can ask the reader = to >>>> retrieve a *subset* of the personal information stored. Other >>>> applications on the computer talk to this one application via an = API. >>>> Your card reader will present the name of the application which = wants >>>> the data, the pieces of data it wants to have from your card, and = will >>>> ask for your authorisation to reveal that personal data. That is = done >>>> via display+PIN directly on the card reader; no secret information = ever >>>> leaks the card reader unless authorized directly on the device by = the >>>> user. [1] >>>>=20 >>>> This exhibits a property of the system which plain presentation of = a >>>> X.509 certs won't allow: send only a subset of the stored = information. >>=20 >> Here I disagree. A system build with WebID enabled X509 certificates = should be able to release subsets of information too. But instead of = having the information come from your device, or be locked in the = certificate, the information can come from RESTful access to your = profile, or to related resources. >>=20 >> Here is one way to do this: >>=20 >> http://blogs.oracle.com/bblfish/entry/sketch_of_a_restful_photo >>=20 >> This is just a generalisation of what your devices do. Think of = adding a web server to the device in question. Then give profiles a URL, = and then only show parts of the information to the authentified service = requesting them. Now there is no reason to put a web server on that = device, you might as well have it wherever you think is best. If you do = that, you are starting to see how http://webid.info can work. >>=20 >> Henry >>=20 >>=20 >>>>=20 >>>> It was refreshing to see this in action when I got my reader last = week: >>>> my car insurance website signalled they need my real name, = birthdate and >>>> birthplace to log me in to manage my insurance contract - not the = rest >>>> of "me" that the card stores as well. Did that, logged into their >>>> website, no need to even create a username/password combo. >>>>=20 >>>> Note that I didn't use the term "client certificate" at all - the = system >>>> does involve PKI, but it's invisible to the user; all he has is a >>>> hardware token and a PIN. >>>>=20 >>>> Sure: you need the card reader. Joe Sixpack can manage to go to a = shop >>>> and put money on the shelf to get it, I assume - he does that same = thing >>>> when buying a TV. Joe doesn't even have to know or care about how = to get >>>> a "certificate" - he just gets all the stuff piggybacked on his = usual >>>> plastic ID card. >>>>=20 >>>> Banking: These days, TAN lists are going away. Alternatively, = several >>>> approaches come into use: >>>>=20 >>>> a) cell phone transaction numbers: enter transaction details on = website, >>>> website generates a TAN for this very transaction, sends it along = with >>>> the input it received from you to your (pre-registered) cell phone, = you >>>> enter the number from the cell phone into the website. - A second, >>>> independent channel makes sure that even if the PC's comms channel = is >>>> compromised, harm is prevented. >>>>=20 >>>> b) offline generated transaction numbers. You get a hardware = device, >>>> branded to your bank account (provisioned secrets). Its only = interface >>>> to the outside world is a black&white camera to read a bar code; = and a >>>> display to show a resulting TAN. Workflow is: you enter your = transaction >>>> details on the web site, they generate $SOMEDATA from it (which = includes >>>> the transaction details). $SOMEDATA is signalled to the hardware = device >>>> via barcode scan, which uses it to generate a TAN based on the >>>> pre-provisioned secrets and $SOMEDATA. Bank does the same = computation, >>>> TANs must match. Again, a second channel comes to the rescue even = if the >>>> PC is compromised. >>>>=20 >>>> c) HBCI - Home Banking Computer Interface. There is no browser at >>>> all(!). An application uses the HBCI API to talk to bank servers. = Client >>>> authenticates with a smart card to be put into a card reader. All = crypto >>>> again happens on the card reader. Joe sixpack gets the smart = card+PIN by >>>> checking a box on his bank acocunt application and doesn't need to = know >>>> anything more. >>>>=20 >>>> None of these use Client Certificates in a browser. All of them = survive >>>> if the PC is malware-infested. But yes, there are still attacks on = these >>>> - they are not the cure-all. >>>>=20 >>>> Greetings, >>>>=20 >>>> Stefan Winter >>>>=20 >>>> [1] There are also readers without a keyboard. If you use these, = too bad >>>> for you, because then your infested PC will log your PIN and so on. >>>> Because of that, the system got quite some beating when introduced. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >>=20 >=20 Social Web Architect http://bblfish.net/ From paul.hoffman@vpnc.org Thu Jul 28 04:35:17 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEAA721F8BAB for ; Thu, 28 Jul 2011 04:35:17 -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 9mHu5K3wWfuD for ; Thu, 28 Jul 2011 04:35:17 -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 544A221F8BC6 for ; Thu, 28 Jul 2011 04:35:16 -0700 (PDT) Received: from [172.16.55.241] ([207.96.251.20]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p6SBYuRU024549 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jul 2011 04:34:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201107280248.p6S2mY16000185@fs4113.wdf.sap.corp> Date: Thu, 28 Jul 2011 07:35:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2D202CBD-BBEC-4257-9431-F69681383192@vpnc.org> References: <201107280248.p6S2mY16000185@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 11:35:18 -0000 On Jul 27, 2011, at 10:48 PM, Martin Rex wrote: > Overall I'm OK with Erics message. >=20 > I did not notice anything unusual, unexpected or objectionable, > but things that I silently assumed or consider a reasonable approach. >=20 > Paul Hoffman wrote: >>=20 >> On Jul 27, 2011, at 10:33 AM, Eric Rescorla wrote: >>=20 >>> 1. All extensions to TLS (including AD sponsored extensions) must >>> minimally be sent explicitly to the TLS WG prior to or during IETF = LC. >>> If that process surfaces significant objections, then these = objections >>> should be resolved prior to publication. For trivial extensions, = this >>> process is sufficient. An example of a trivial extension would be >>> signaling for a new TLS Exporter (RFC 5705), as this has no impact = on >>> TLS proper. >>=20 >> The person who gets to define "significant" and "resolved" controls = all >> extensions, then. It would be better if they were defined more fully = here. >=20 > The description in (1) sound like WG review and WG consensus process > in case that objections are raised. "A person" would probably more > apply to "expert review" situations. >=20 > What exactly are you looking for? That the TLS WG should come up with > a more narrow "consensus" than used in the rest of the IETF? Note that #1 is not about WG documents, but documents that start outside = the WG. If you feel that every document that starts outside the WG needs = to have WG consensus, that's fine; I believe that would be unique in the = IETF. A different model, one that is much more common in the IETF, would be = that for non-WG documents, the AD reviews the discussion on the WG = mailing list and decides. >>> 2. All non-trivial extensions (i.e., anything which alters TLS >>> processing in some way) must be presented to the TLS WG and at least >>> be considered unobjectionable. >>=20 >> OK, add "unobjectionable" to the list above. >=20 > I believe "unobjectionable" (should) refer to a clean issue resolution = and > WG consensus procedure. Again, that's one option (and apparently the one we are living with = today); another would be like what many other areas use. >> Why is adding a message so important here? >> Who defines what changes the "TLS model" or "TLS state machine? >=20 > Because new TLS handshake messages, and the exact ordering of the = handshake > messages have a significant impact on the TLS state machine, and the > insertion or ommission of messages might have non-obvious consequences > for the security properties of the protocol. >=20 > The ordering of TLS extensions in Client and Server Hello handshake > messages is well defined (=3Darbitrary/unordered) -- unless there are > competing or conflicting extensions. > competing=3Ddiffing preference/ordering about the same characteristic > conflicting=3Ddifferent specificiation of the same characteristic This is the kind of specificity that would be very useful in the policy, = and should be extended to the definition of the "TLS model" and "TLS = state machine". >> Overall: The proposed rules above seem to be about the same as the >> unspoken rules today, with the difference being that they are stated >> but completely unclear. It doesn't feel like this is an improvement >> over the current situation. >=20 >=20 > I did not conceive it as an attempt to change the situation, > but more likely to summarize customs in writing, Unfortunately, I fully agree. > in face of the > recent flood of TLS-related documents, and where at least some > of the authors are not recognized as active TLS WG participants > which could be expected to know how things work around here. >=20 > Do you remember the discussion on these two proposals? > http://tools.ietf.org/html/draft-santesson-tls-gssapi-03 > http://tools.ietf.org/html/draft-housley-evidence-extns-01 --Paul Hoffman From ekr@rtfm.com Thu Jul 28 06:20:52 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37F421F8B74 for ; Thu, 28 Jul 2011 06:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQseckKAZB5O for ; Thu, 28 Jul 2011 06:20:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF29A21F8AF8 for ; Thu, 28 Jul 2011 06:20:39 -0700 (PDT) Received: by wwe5 with SMTP id 5so1634365wwe.13 for ; Thu, 28 Jul 2011 06:20:39 -0700 (PDT) Received: by 10.227.60.201 with SMTP id q9mr11641wbh.52.1311859239056; Thu, 28 Jul 2011 06:20:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 06:20:17 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 28 Jul 2011 09:20:17 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 13:20:52 -0000 On Wed, Jul 27, 2011 at 8:18 PM, Paul Wouters wrote: > On Wed, 27 Jul 2011, Eric Rescorla wrote: >> Regardless, as I said in my review, this seems like it's largely >> duplicative of cached info (and in fact, rather clumsier). > > I'm interested in knowing why you consider it "clumsy". Especially becaus= e > it closely follows the RFC 6066 section 6 extension for supressing of > sending CA bundles with "trusted_ca_keys". =A0That apparent clumsiness > passed WGLC and IESG. What's clumsy is: (1) It's not generic, even though generic caching is useful. (2) It doesn't support bare keys when the client doesn't know the key, whic= h is also useful, if you want to use bare keys at all. In fact, it doesn't even appear to support cases where the client knows only the key hash, which is common. Whether it follows 6066 doesn't seem particularly relevant here, since we h= ave a worked example of something better. -Ekr From ekr@rtfm.com Thu Jul 28 06:27:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B1421F8C33 for ; Thu, 28 Jul 2011 06:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vap0QkUlBOcR for ; Thu, 28 Jul 2011 06:27:46 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7E21F8877 for ; Thu, 28 Jul 2011 06:27:45 -0700 (PDT) Received: by wyj26 with SMTP id 26so23398wyj.31 for ; Thu, 28 Jul 2011 06:27:45 -0700 (PDT) Received: by 10.227.39.154 with SMTP id g26mr30975wbe.37.1311859665210; Thu, 28 Jul 2011 06:27:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 06:27:24 -0700 (PDT) In-Reply-To: <2D202CBD-BBEC-4257-9431-F69681383192@vpnc.org> References: <201107280248.p6S2mY16000185@fs4113.wdf.sap.corp> <2D202CBD-BBEC-4257-9431-F69681383192@vpnc.org> From: Eric Rescorla Date: Thu, 28 Jul 2011 09:27:24 -0400 Message-ID: To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 13:27:47 -0000 On Thu, Jul 28, 2011 at 7:35 AM, Paul Hoffman wrote= : > On Jul 27, 2011, at 10:48 PM, Martin Rex wrote: > >> Overall I'm OK with Erics message. >> >> I did not notice anything unusual, unexpected or objectionable, >> but things that I silently assumed or consider a reasonable approach. >> >> Paul Hoffman wrote: >>> >>> On Jul 27, 2011, at 10:33 AM, Eric Rescorla wrote: >>> >>>> 1. All extensions to TLS (including AD sponsored extensions) must >>>> minimally be sent explicitly to the TLS WG prior to or during IETF LC. >>>> If that process surfaces significant objections, then these objections >>>> should be resolved prior to publication. For trivial extensions, this >>>> process is sufficient. An example of a trivial extension would be >>>> signaling for a new TLS Exporter (RFC 5705), as this has no impact on >>>> TLS proper. >>> >>> The person who gets to define "significant" and "resolved" controls all >>> extensions, then. It would be better if they were defined more fully he= re. >> >> The description in (1) sound like WG review and WG consensus process >> in case that objections are raised. =A0"A person" would probably more >> apply to "expert review" situations. >> >> What exactly are you looking for? =A0That the TLS WG should come up with >> a more narrow "consensus" than used in the rest of the IETF? > > Note that #1 is not about WG documents, but documents that start outside = the WG. If you feel that every document that starts outside the WG needs to= have WG consensus, that's fine; I believe that would be unique in the IETF= . As noted previously, the standard for TLS extensions is IETF Consensus. No, I don't think it's unusual to think that documents relating to protocol X w= hich require IETF Consensus also need to have WG X at least give it a no-obj. I don't think the text above required a WG LC for extensions in category 1. > A different model, one that is much more common in the IETF, would be tha= t for non-WG documents, the AD reviews the discussion on the WG mailing lis= t and decides. I don't necessarily have a problem with that, but I don't really think that= this is much different as a standard, just a matter of whether the chairs or the= AD assesses the discussion. >>> Why is adding a message so important here? >>> Who defines what changes the "TLS model" or "TLS state machine? >> >> Because new TLS handshake messages, and the exact ordering of the handsh= ake >> messages have a significant impact on the TLS state machine, and the >> insertion or ommission of messages might have non-obvious consequences >> for the security properties of the protocol. In addition, new TLS handshake message require a Standards Track document i= n any case, and I don't think it's at all unreasonable to expect that Standards Track documents in TLS have active TLS WG involvement. >> The ordering of TLS extensions in Client and Server Hello handshake >> messages is well defined (=3Darbitrary/unordered) -- unless there are >> competing or conflicting extensions. >> =A0competing=3Ddiffing preference/ordering about the same characteristic >> =A0conflicting=3Ddifferent specificiation of the same characteristic > > This is the kind of specificity that would be very useful in the policy, = and should be extended to the definition of the "TLS model" and "TLS state = machine". I have no problem with that. -Ekr From ekr@rtfm.com Thu Jul 28 06:29:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298D21F8C43 for ; Thu, 28 Jul 2011 06:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmUF64MmjVAJ for ; Thu, 28 Jul 2011 06:29:50 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0A121F8C33 for ; Thu, 28 Jul 2011 06:29:50 -0700 (PDT) Received: by wyj26 with SMTP id 26so25325wyj.31 for ; Thu, 28 Jul 2011 06:29:49 -0700 (PDT) Received: by 10.227.32.136 with SMTP id c8mr53422wbd.7.1311859788850; Thu, 28 Jul 2011 06:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 06:29:28 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 28 Jul 2011 09:29:28 -0400 Message-ID: To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 13:29:51 -0000 On Wed, Jul 27, 2011 at 10:18 PM, Nico Williams wro= te: > The TLS WG need not be around forever, so this > WG-consensus-on-non-objectionability concept has at least that problem. > Beyond that, do we have precedent for requiring that there be WG consensu= s > that a proposal is not objectionable?=A0 (As opposed to WG consensus that= the > proposal should progress.) I was thinking of "not objectionable" as a lower bar than "should progress", so this may be a writing issue. The idea here is to contrast it to category (3) which needs active support, whereas "not objectionable" was intended to mean "some peop= le (perhaps only a few) want it and other people don't care". > I would rather say that the IESG can require review in a then-appropriate > WG=A0 (i.e., WG LC) in addition to IETF LC. Yes, I think that once the TLS WG has closed, the IESG can do what it wants= . -Ekr From paul@xelerance.com Thu Jul 28 07:05:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5BA21F874A for ; Thu, 28 Jul 2011 07:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0LaGTe9bZg+I for ; Thu, 28 Jul 2011 07:05:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA55F21F8793 for ; Thu, 28 Jul 2011 07:05:32 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0489057124; Thu, 28 Jul 2011 10:06:31 -0400 (EDT) Date: Thu, 28 Jul 2011 10:06:30 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:05:33 -0000 On Thu, 28 Jul 2011, Eric Rescorla wrote: >> I'm interested in knowing why you consider it "clumsy". Especially because >> it closely follows the RFC 6066 section 6 extension for supressing of >> sending CA bundles with "trusted_ca_keys".  That apparent clumsiness >> passed WGLC and IESG. > > What's clumsy is: > > (1) It's not generic, even though generic caching is useful. 1) It's generic for allowing an arbitrary authentication method outside PKIX, which generic caching does not, as it requires the TLS client to compute hashes over PKIX information. In fact, the TLS client has to lie about already having the CA bundle in order not to receive the PKIX blob. 2) generic caching is useful and it should also proceed through the IETF process. > (2) It doesn't support bare keys when the client doesn't know the key, which > is also useful, if you want to use bare keys at all. In fact, it > doesn't even appear > to support cases where the client knows only the key hash, which is common. That is a use case I had not considered. It is not hard to add support for that. > Whether it follows 6066 doesn't seem particularly relevant here, since we have a > worked example of something better. "something better" only works with your other assumption of "sending and signing cruft in PKIX is fine". I strongly disagree with that. Paul From ekr@rtfm.com Thu Jul 28 07:13:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB57E21F8793 for ; Thu, 28 Jul 2011 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG62ZsoKM7Li for ; Thu, 28 Jul 2011 07:13:30 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C59621F8770 for ; Thu, 28 Jul 2011 07:13:29 -0700 (PDT) Received: by wyj26 with SMTP id 26so68990wyj.31 for ; Thu, 28 Jul 2011 07:13:29 -0700 (PDT) Received: by 10.227.28.206 with SMTP id n14mr79375wbc.52.1311862409160; Thu, 28 Jul 2011 07:13:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 07:13:09 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 28 Jul 2011 10:13:09 -0400 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:13:31 -0000 On Thu, Jul 28, 2011 at 10:06 AM, Paul Wouters wrote: > On Thu, 28 Jul 2011, Eric Rescorla wrote: > >>> I'm interested in knowing why you consider it "clumsy". Especially >>> because >>> it closely follows the RFC 6066 section 6 extension for supressing of >>> sending CA bundles with "trusted_ca_keys". =A0That apparent clumsiness >>> passed WGLC and IESG. >> >> What's clumsy is: >> >> (1) It's not generic, even though generic caching is useful. > > 1) It's generic for allowing an arbitrary authentication method outside > PKIX, which > =A0 generic caching does not, as it requires the TLS client to compute ha= shes > over > =A0 PKIX information. In fact, the TLS client has to lie about already ha= ving > the CA > =A0 bundle in order not to receive the PKIX blob. As I said, you should *extend* cached-info. > 2) generic caching is useful and it should also proceed through the IETF > process. > >> (2) It doesn't support bare keys when the client doesn't know the key, >> which >> is also useful, if you want to use bare keys at all. In fact, it >> doesn't even appear >> to support cases where the client knows only the key hash, which is >> common. > > That is a use case I had not considered. It is not hard to add support fo= r > that. > >> Whether it follows 6066 doesn't seem particularly relevant here, since w= e >> have a >> worked example of something better. > > "something better" only works with your other assumption of "sending and > signing > cruft in PKIX is fine". I strongly disagree with that. I'm talking about cached-info here. -Ekr From pgut001@login01.cs.auckland.ac.nz Thu Jul 28 07:45:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7483B21F8C77 for ; Thu, 28 Jul 2011 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.62 X-Spam-Level: X-Spam-Status: No, score=-3.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 oXl5E6eY2ZxN for ; Thu, 28 Jul 2011 07:45:15 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1275F21F8C71 for ; Thu, 28 Jul 2011 07:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311864315; x=1343400315; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20stefan.winter@restena.lu,=20tls@ietf.org|Subject: =20Re:=20[TLS]=20HTTPS=20client-certificate-authenticatio n=20in=20browsers|In-Reply-To:=20<4E31299F.6060400@resten a.lu>|Message-Id:=20|Date:=20Fri,=2029=20Jul=202011=2002:45:11=20+12 00; bh=m1c3An9jDVjwu30p55R65HaTMoz2FybN+ubxr4XVtVU=; b=rIVpVqPHP2WErY+tDW7XpMdrywTx0Xr7863YfNCG+U8maq2SA6W7g0zm zkOd1e1nU81oK+p5Wyzd1ZoORjYNln1UdEahb+iLOrgl8LHvzbWgTgt1U j/p8RqZWNwOVr7eYwwFS23nyXP9s/VbO5XQSrNxWLBsNnQ2bXB4QxteQG I=; X-IronPort-AV: E=Sophos;i="4.67,282,1309694400"; d="scan'208";a="74606615" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2011 02:45:11 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QmRpn-0005Za-Gq; Fri, 29 Jul 2011 02:45:11 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QmRpn-0006TH-5l; Fri, 29 Jul 2011 02:45:11 +1200 From: Peter Gutmann To: stefan.winter@restena.lu, tls@ietf.org In-Reply-To: <4E31299F.6060400@restena.lu> Message-Id: Date: Fri, 29 Jul 2011 02:45:11 +1200 Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 14:45:16 -0000 Stefan Winter writes: >Banking: These days, TAN lists are going away. Is there any information on what's being done in countries like France, Italy, the Netherlands, Spain, ...? The only place where it's really documented (in quite some detail) is Germany (with surrounding/similar countries like Austria and Switzerland using equivalent approaches), but what are other countries in Europe doing? There's rather little information *from third parties, not the vendors* publicly available on how e-banking is done in France, Spain, ..., the pros and cons, how it deals with new attack types, and so on. >a) cell phone transaction numbers: The problem is that mTANs are vulnerable to smartphone malware, as Zeus has already shown. It's currently a minor threat, but who knows how far the bad guys will take it. On the whole though mTANs are a nice tradeoff, you get to verify the transaction over an independent channel, and the mTAN is a cryptographic hash over the transaction data so if a MITB tries to modify what the browser sends it gets detected. Peter. From anders.rundgren@telia.com Thu Jul 28 08:00:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70F421F8B05 for ; Thu, 28 Jul 2011 08:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=0.878, 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 LLClUzhX1iCp for ; Thu, 28 Jul 2011 08:00:46 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id F23FD21F8AF9 for ; Thu, 28 Jul 2011 08:00:45 -0700 (PDT) Received: from [192.168.3.119] (193.12.106.2) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E970003744D; Thu, 28 Jul 2011 17:00:37 +0200 Message-ID: <4E317986.3040209@telia.com> Date: Thu, 28 Jul 2011 17:00:22 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 15:00:46 -0000 On 2011-07-28 16:45, Peter Gutmann wrote: > Stefan Winter writes: > >> Banking: These days, TAN lists are going away. > > Is there any information on what's being done in countries like France, Italy, > the Netherlands, Spain, ...? The only place where it's really documented (in > quite some detail) is Germany (with surrounding/similar countries like Austria > and Switzerland using equivalent approaches), but what are other countries in > Europe doing? There's rather little information *from third parties, not the > vendors* publicly available on how e-banking is done in France, Spain, ..., > the pros and cons, how it deals with new attack types, and so on. > >> a) cell phone transaction numbers: > > The problem is that mTANs are vulnerable to smartphone malware, as Zeus has > already shown. It's currently a minor threat, but who knows how far the bad > guys will take it. On the whole though mTANs are a nice tradeoff, you get to > verify the transaction over an independent channel, and the mTAN is a > cryptographic hash over the transaction data so if a MITB tries to modify what > the browser sends it gets detected. It may be nice from a security point of view but it is horribly inconvenient. I don't believe for a second that "this is where we are going". Apple's interest in becoming the PayPal for the physical world will take mobile security to levels PCs never did. In iPhone client-side PKI is already ease to enroll even for Joe Sixpack! Anders > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From henry.story@bblfish.net Thu Jul 28 08:07:13 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49F221F8B85 for ; Thu, 28 Jul 2011 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=1.118, 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 Wiy+0HlLNnm5 for ; Thu, 28 Jul 2011 08:07:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id ACCFA21F8B94 for ; Thu, 28 Jul 2011 08:07:12 -0700 (PDT) Received: by wwe5 with SMTP id 5so1722684wwe.13 for ; Thu, 28 Jul 2011 08:07:09 -0700 (PDT) Received: by 10.227.55.17 with SMTP id s17mr144637wbg.57.1311865629769; Thu, 28 Jul 2011 08:07:09 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id fx12sm924773wbb.25.2011.07.28.08.07.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 08:07:09 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Henry Story In-Reply-To: Date: Thu, 28 Jul 2011 17:07:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EDD6F49-33C4-46D3-9012-765170911A57@bblfish.net> References: To: Peter Gutmann , Martin Gaedke X-Mailer: Apple Mail (2.1244.3) Cc: Stefan Winter , tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 15:07:13 -0000 Hi Peter, You may want to ask Prof. Martin Gaedke about this. He is working his = way through the=20 EU area on this and should have some good pointers on where these token = cards are=20 going around here.=20 Henry On 28 Jul 2011, at 16:45, Peter Gutmann wrote: > Stefan Winter writes: >=20 >> Banking: These days, TAN lists are going away. >=20 > Is there any information on what's being done in countries like = France, Italy, > the Netherlands, Spain, ...? The only place where it's really = documented (in > quite some detail) is Germany (with surrounding/similar countries like = Austria > and Switzerland using equivalent approaches), but what are other = countries in > Europe doing? There's rather little information *from third parties, = not the > vendors* publicly available on how e-banking is done in France, Spain, = ..., > the pros and cons, how it deals with new attack types, and so on. >=20 >> a) cell phone transaction numbers: >=20 > The problem is that mTANs are vulnerable to smartphone malware, as = Zeus has > already shown. It's currently a minor threat, but who knows how far = the bad > guys will take it. On the whole though mTANs are a nice tradeoff, you = get to > verify the transaction over an independent channel, and the mTAN is a > cryptographic hash over the transaction data so if a MITB tries to = modify what > the browser sends it gets detected. >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Social Web Architect http://bblfish.net/ From pgut001@login01.cs.auckland.ac.nz Thu Jul 28 08:12:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA0921F8CAF for ; Thu, 28 Jul 2011 08:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.619 X-Spam-Level: X-Spam-Status: No, score=-3.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 aYeWbNU92z5E for ; Thu, 28 Jul 2011 08:12:54 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1102421F8C0B for ; Thu, 28 Jul 2011 08:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311865974; x=1343401974; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20pgut001@cs.auckland.a c.nz|Subject:=20Re:=20[TLS]=20HTTPS=20client-certificate- authentication=20in=20browsers|Cc:=20stefan.winter@resten a.lu,=20tls@ietf.org|In-Reply-To:=20<4E317986.3040209@tel ia.com>|Message-Id:=20|Date:=20Fri,=2029=20Jul=202011=2003:12:52=20+ 1200; bh=a61StRAPyNK+1UCYVfxM2fWvG4YTlgrmFK9xC6ekaCM=; b=Pdt2aAIJBcAhUaY9yyoAPpSnI39kjKt3nNJc4hEwtINx4fNujAMj8d9l jQox0/D8hRm2NA3kZzFwwfxoeJj+bxQD4c64rvQR+nkLr48w5aXoeUXyU EORfk2xMOmNm/Y1DwNABgZBkY2+AU4bHDKJ4noULx5OdDH1vzgBlE8GSw g=; X-IronPort-AV: E=Sophos;i="4.67,282,1309694400"; d="scan'208";a="74607909" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2011 03:12:53 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QmSGb-0006My-G9; Fri, 29 Jul 2011 03:12:53 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QmSGa-0007gq-V7; Fri, 29 Jul 2011 03:12:52 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, pgut001@cs.auckland.ac.nz In-Reply-To: <4E317986.3040209@telia.com> Message-Id: Date: Fri, 29 Jul 2011 03:12:52 +1200 Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 28 Jul 2011 15:12:55 -0000 Anders Rundgren writes: >It may be nice from a security point of view but it is horribly inconvenient. >I don't believe for a second that "this is where we are going". It's standard for banks in (at least) NZ, SA, and possibly Australia. From talking to banking people involved with it, there haven't been any serious problems. (I've used mTANs before as a case study of "security works in practice but not in theory", because when you tell security people about it they come up with long lists of reasons why it'll never work, and then when you deploy it it works just fine). Peter. From mrex@sap.com Thu Jul 28 09:09:11 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ADA21F8678 for ; Thu, 28 Jul 2011 09:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.917 X-Spam-Level: X-Spam-Status: No, score=-9.917 tagged_above=-999 required=5 tests=[AWL=0.332, 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 OTah6U2AI-5o for ; Thu, 28 Jul 2011 09:09:10 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4652621F86BC for ; Thu, 28 Jul 2011 09:09:10 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6SG96Tb015455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 18:09:07 +0200 (MEST) From: Martin Rex Message-Id: <201107281609.p6SG96qO014774@fs4113.wdf.sap.corp> To: paul.hoffman@vpnc.org (Paul Hoffman) Date: Thu, 28 Jul 2011 18:09:06 +0200 (MEST) In-Reply-To: <2D202CBD-BBEC-4257-9431-F69681383192@vpnc.org> from "Paul Hoffman" at Jul 28, 11 07:35:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 16:09:11 -0000 Paul Hoffman wrote: > > Martin Rex wrote: > > > > The description in (1) sound like WG review and WG consensus process > > in case that objections are raised. "A person" would probably more > > apply to "expert review" situations. > > > > What exactly are you looking for? That the TLS WG should come up with > > a more narrow "consensus" than used in the rest of the IETF? > > Note that #1 is not about WG documents, but documents that start outside > the WG. If you feel that every document that starts outside the WG needs > to have WG consensus, that's fine; I believe that would be unique in > the IETF. > > A different model, one that is much more common in the IETF, would be > that for non-WG documents, the AD reviews the discussion on the WG > mailing list and decides. A decent level of "review" may involve discussion among WG participants, and it might be more appropriate to have those discussions on the WG mailing list rather than on ietf@ietf.org, use semi-formal sync-points when the discussion shifts to the WG mailing list and back, at the end have a WG summary posted back to ietf@ietf.org -Martin From nico@cryptonector.com Thu Jul 28 09:34:01 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90DB21F8C1F for ; Thu, 28 Jul 2011 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=-0.820, 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 mOXdmoffmrds for ; Thu, 28 Jul 2011 09:34:00 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7356B21F8C1E for ; Thu, 28 Jul 2011 09:34:00 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id F316520203C for ; Thu, 28 Jul 2011 09:33:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nkL6PzhJNMrt0butlqAiJ lDJkSXGQ3e4AfQjOLCKUcv/TA4l1FJLXsFCdiZNI9EuVQqCDaVI4XDlYjXjHL5Fe BiPbsUmVtxlL9TJM9IH0So53upnoy2uBYwt0DovKe/iVwL7/TstQbQ0Dk0J9q2Yn fyvVP5H/EOBqMwixB7VaVM= 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=0r4jK4D+/1+xwfMYEhKZ 7l7Gha4=; b=w3fj0KDXiBDT7iyQYzOYOuz7x3R+31QLqsn9LsmmXl+iF2QEns5/ WmQ+6KLrZffh/ojF/3eLMW+f/diVmeSxszPAl5wEkoJFIYKVleodnK6uYlu8t33R taeOgw+VXhZhY8S6JlO0s0En04lWTDxN0RCHbEI8m+rKzO7w/rZBYus= Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id A6515202038 for ; Thu, 28 Jul 2011 09:33:59 -0700 (PDT) Received: by pzk6 with SMTP id 6so4497207pzk.26 for ; Thu, 28 Jul 2011 09:33:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.26.68 with SMTP id j4mr457249pbg.307.1311870839315; Thu, 28 Jul 2011 09:33:59 -0700 (PDT) Received: by 10.68.48.74 with HTTP; Thu, 28 Jul 2011 09:33:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 11:33:59 -0500 Message-ID: From: Nico Williams To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] Setting Policy for Extensions 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, 28 Jul 2011 16:34:01 -0000 A better way to word this might be to say that all TLS extensions I-Ds must be announced at an IETF mailing list that is appropriate for discussion of TLS (for now, the TLS WG's list), and that upon request by any appropriate WG's chairs or by any IESG members, any such TLS extension proposal would have to require WG review -- the outcome of which must be consensus on the question of whether the proposal may or may not progress and/or whether it should be adopted as a WG work item (thus requiring WG LC, not merely WG review). I think this would result in a high likelihood that folks who might object to a given proposal would have a chance to have their objections heard, and then for consensus to be reached. Of course, there might be situations where objections will be ignored (because WG chairs and IESG members are unwilling to request WG review). An appeal path to the IAB might be desirable, but I seriously doubt we'd ever need it. Nico -- From mrex@sap.com Thu Jul 28 09:58:55 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5382D21F8BBF for ; Thu, 28 Jul 2011 09:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.921 X-Spam-Level: X-Spam-Status: No, score=-9.921 tagged_above=-999 required=5 tests=[AWL=0.328, 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 bbQ3yN3ftNPp for ; Thu, 28 Jul 2011 09:58:54 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1521F8BB4 for ; Thu, 28 Jul 2011 09:58:54 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6SGwqOp020185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 18:58:52 +0200 (MEST) From: Martin Rex Message-Id: <201107281658.p6SGwpYY017791@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Thu, 28 Jul 2011 18:58:51 +0200 (MEST) In-Reply-To: from "Paul Wouters" at Jul 28, 11 10:06:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 16:58:55 -0000 Paul Wouters wrote: > > Eric Rescorla wrote: > > >> I'm interested in knowing why you consider it "clumsy". Especially because > >> it closely follows the RFC 6066 section 6 extension for supressing of > >> sending CA bundles with "trusted_ca_keys".  That apparent clumsiness > >> passed WGLC and IESG. To be fair, the trusted_ca_keys extension was originally proposed in rfc3546, and the document update 6066 simply did not change it. The trusted_ca_keys TLS extension itself is a simple/lightweight extension in that it does _not_ modify the syntax or semantics of any other TLS handshake messages (besides the TLS extensions container in ClientHello and ServerHello). > > > What's clumsy is: > > > > (1) It's not generic, even though generic caching is useful. > > 1) It's generic for allowing an arbitrary authentication method > outside PKIX, which generic caching does not, as it requires > the TLS client to compute hashes over PKIX information. > In fact, the TLS client has to lie about already having the CA > bundle in order not to receive the PKIX blob. In TLS WG we definitely need to keep an eye on TLS extension not duplicating each other resulting in conflicts an interop problems. The TLS WG had previously adopted a work item (currently dormant, primarily because of fights over hash algorithm agility that haven't been settled) to do caching in a generic fashion, so caching of data from TLS handshake messages, and in particular _existing_ TLS handshake messages should IMO not be duplicated in any newly proposed TLS extension. > > "something better" only works with your other assumption of "sending > and signing cruft in PKIX is fine". I strongly disagree with that. You seem to be thinking purely about a niche area 1) that does not have TLS at all today 2) where you want to implement TLS newly from scratch and having to implement _all_ of ASN.1-ladden PKIX as a huge burden 3) and where you do not care the slighest about interop with the installed base of TLS. But in case that interop with the installed base of TLS is or may ever become an issue, it might be worthwile thinking about implementing the subset "X.509v1 self-signed cert" as an alternative to inventing a new bare key format, because that is still fairly trivial to implement and fully interoperable with the existing installed base (OK, newer browsers have a braindead nag-ware warning page, but I haven't lost hope yet that they grok it one day and offer sensible cert pinning -- and having to regularly update bug-ridden web browsers is a sad fact of life we've all become used to, it's not nearly as bad with TLS implementations used by programmatic TLS clients and servers). I see not having to modify syntax and semantics of existing TLS handshake messages in order to implement a TLS extension as a big plus. -Martin From ekr@rtfm.com Thu Jul 28 10:13:39 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6CB5E8014 for ; Thu, 28 Jul 2011 10:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rvjSqrkp9QL for ; Thu, 28 Jul 2011 10:13:39 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id F42085E800D for ; Thu, 28 Jul 2011 10:13:38 -0700 (PDT) Received: by wyj26 with SMTP id 26so12948wyj.31 for ; Thu, 28 Jul 2011 10:13:38 -0700 (PDT) Received: by 10.227.200.210 with SMTP id ex18mr347953wbb.7.1311873218080; Thu, 28 Jul 2011 10:13:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 10:13:18 -0700 (PDT) From: Eric Rescorla Date: Thu, 28 Jul 2011 13:13:18 -0400 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] Review of draft-agl-tls-nextproto-00 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, 28 Jul 2011 17:13:39 -0000 This document describes a mechanism whereby a TLS client and server can agree about the "next" protocol, i.e., the protocol which will be carried over TLS. MOTIVATION It's unclear from the draft what the motivation for this work is. Section 1 says that NPN is for preventing cross-protocol attacks, specifically citing WebSockets: The WebSockets [websockets] protocol seeks to allow low-latency, full-duplex communication between browsers and HTTP servers. However, it also permits an unprecedented amount of attacker control over the contents of the connection. In order to prevent cross- protocol attacks, a mechanism to assure that both client and server are speaking the same protocol is required. To this end, the Next Protocol extension described in this document extends the TLS [RFC5246] handshake to allow the client to tell the server the intended application protocol. However, WebSockets does not use NPN; the HyBi working group explicitly rejected NPN because it would have required the use of TLS at all times. I'm not saying I agree with this, but it's what happened. Instead, the HyBi WG designed their own application-layer handshake which is intended to thwart cross-protocol attacks. Similarly, the other major WG which is currently concerned with cross-protocol attacks, WebRTC, is not interested in NPN but rather is using an ICE-based handshake prior to sending traffic. What IETF protocols have a demand for this functionality? ENCRYPTED NEGOTIATION This document specifies a partially encrypted negotiation mechanism: the server advertises some set of protocols (in the ServerHello) and the client specifies a specific protocol (in a separate handshake message inserted between the CCS and the Finished). The client's announcement need not match any of the protocols specified by the server. Thus, the negotiation is partly encrypted. The reason for this appears to be that this mechanism is designed to prevent network attackers from learning which next protocol is being requested. (See Section 4). I'm extremely skeptical of this objective: Avoiding this kind of application identification has not traditionally been a TLS design goal. Indeed, TLS has features which make this problematic, such as unpadded records (in stream cipher modes) and application types in the extended key usage. People who operate DPI boxes will generally be able to identify the relevant applications and block them. Moreover, for applications which do not require TLS client authentication, it's generally easy to determine what the server runs by simply connecting to it (in general, most TLS endpoints run only a small number of protocols) and then block as appropriate. If this sort of evasion becomes a TLS design goal, much more work will be necessary. This wouldn't be a big deal except that this highly imperfect functionality comes at significant architectural cost. This mechanism is clearly more invasive and complicated than necessary to accomplish the goal of addressing cross-protocol attacks. That objective could easily be met by having the client announce in an extension the protocol he wishes and the server either accept or reject immediately (prior to the key exchange stage). This would also be far clearer from a layering perspective, as it would conceptually match the use and timing of the TCP port number, just pushing it a few bytes over into the TLS ClientHello. Moreover, it is extremely odd to have the server advertise a list of protocols which does not match the list which it is actually willing to use. For that matter, it's not even clear what the point of the advertisement is in most cases since, again, most servers run only one protocol and a 16-bit port number is clearly far too crude for version negotiation. From paul@xelerance.com Thu Jul 28 11:00:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E9F21F8588 for ; Thu, 28 Jul 2011 11:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 nKxD-Ehz3Yxf for ; Thu, 28 Jul 2011 11:00:40 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id BC80F21F8584 for ; Thu, 28 Jul 2011 11:00:39 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 4A2DD57124; Thu, 28 Jul 2011 14:01:38 -0400 (EDT) Date: Thu, 28 Jul 2011 14:01:38 -0400 (EDT) From: Paul Wouters To: Martin Rex In-Reply-To: <201107281658.p6SGwpYY017791@fs4113.wdf.sap.corp> Message-ID: References: <201107281658.p6SGwpYY017791@fs4113.wdf.sap.corp> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:00:41 -0000 On Thu, 28 Jul 2011, Martin Rex wrote: > The trusted_ca_keys TLS extension itself is a simple/lightweight extension > in that it does _not_ modify the syntax or semantics of any other > TLS handshake messages (besides the TLS extensions container in > ClientHello and ServerHello). trusted_ca_keys changes sending the CA bundle with EE-cert PKIX blob with only the EE-cert PKIX blob. I am proposing to send only the subjectPublicKeyInfo PKIx blob. It's not different a change of semantics. > In TLS WG we definitely need to keep an eye on TLS extension not > duplicating each other resulting in conflicts an interop problems. Hency my method that is suitable not just for DANE, but for any non-PKIX out of band authentication. > The TLS WG had previously adopted a work item (currently dormant, > primarily because of fights over hash algorithm agility that haven't > been settled) to do caching in a generic fashion, so caching > of data from TLS handshake messages, and in particular _existing_ > TLS handshake messages should IMO not be duplicated in any newly > proposed TLS extension. cached PKIX objects is quite different from not using PKIX. Currently in saag there was also the interesting point of PKIX needing to send duplicate certs in the CA bundle for SHA1/SHA2/SHA3 because you don't know what hashing algo the TLS client can support. The non-PKIX authentication of the TLS server public key could just publish different DANE records with the different hashes of the public key, and the TLS client can pick the one it supports. Please don't suggest that it is perfectly reasonable to keep mandating ever larger PKIX containers that are just scrap around the public key. >> "something better" only works with your other assumption of "sending >> and signing cruft in PKIX is fine". I strongly disagree with that. > > You seem to be thinking purely about a niche area > > 1) that does not have TLS at all today > 2) where you want to implement TLS newly from scratch and having > to implement _all_ of ASN.1-ladden PKIX as a huge burden > 3) and where you do not care the slighest about interop with the > installed base of TLS. Not at all. I am also thinking of a browser supporting non-pkix alongside pkix authentication. > it might be worthwile thinking about implementing > the subset "X.509v1 self-signed cert" as an alternative to inventing > a new bare key format, because that is still fairly trivial to > implement and fully interoperable with the existing installed base We've been carrying PKIX containers for too long already. Suggestions we continue to do so for another twenty years are simply not good enough in my opinion. I know not everyone agrees with me, and I'm not asking people to switch. I'm just asking for the opportunity for everyone to make their own decision on using PKIX or not. > (OK, newer browsers have a braindead nag-ware warning page, but > I haven't lost hope yet that they grok it one day and offer sensible > cert pinning -- and having to regularly update bug-ridden web browsers > is a sad fact of life we've all become used to, it's not nearly as bad > with TLS implementations used by programmatic TLS clients and servers). I'm not sure how this paragraph supports cached pkix objects over non-pkix. > I see not having to modify syntax and semantics of existing TLS handshake > messages in order to implement a TLS extension as a big plus. See the start of this email and the comparison with trusted_ca_keys. We are not forcing TLS servers to change anything like a requirement to support TLS version 1.42. We suggest giving TLS implementations the *option* to implement a non-PKIX extension. cached-objects is not good enough for this case. Paul From paul@xelerance.com Thu Jul 28 11:18:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9F711E8121 for ; Thu, 28 Jul 2011 11:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PTtmSjhhkL4e for ; Thu, 28 Jul 2011 11:18:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA3011E811F for ; Thu, 28 Jul 2011 11:18:33 -0700 (PDT) Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 8422857124; Thu, 28 Jul 2011 14:19:32 -0400 (EDT) Date: Thu, 28 Jul 2011 14:19:32 -0400 (EDT) From: Paul Wouters To: Eric Rescorla In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 18:18:33 -0000 On Thu, 28 Jul 2011, Eric Rescorla wrote: > As I said, you should *extend* cached-info. Note that it was you told me in Prague you found it important that the TLS public key remained transfered and covered by the Finished Message. Using a cached object would only have the hash of the object to be covered by the Finished Message. Would you have no objection to a scheme using cached-info and that would trust a public key that has never been transferred in-band? Paul From anders.rundgren@telia.com Thu Jul 28 12:10:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0841021F858C for ; Thu, 28 Jul 2011 12:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.568 X-Spam-Level: X-Spam-Status: No, score=-3.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 OOOH8+tM0A5c for ; Thu, 28 Jul 2011 12:10:47 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id EA9DC21F85A1 for ; Thu, 28 Jul 2011 12:10:46 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DEDBD7B00E9427E; Thu, 28 Jul 2011 21:10:16 +0200 Message-ID: <4E31B408.40107@telia.com> Date: Thu, 28 Jul 2011 21:10:00 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Henry Story References: <6EDD6F49-33C4-46D3-9012-765170911A57@bblfish.net> In-Reply-To: <6EDD6F49-33C4-46D3-9012-765170911A57@bblfish.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "S.tefan Winter" , Martin Gaedke , tls@ietf.org Subject: Re: [TLS] EU cards 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, 28 Jul 2011 19:10:48 -0000 Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so why would the browser vendor bother about how it works? Now to the cards: Since 1. readers is a non-standard item 2. all cards need different middleware 3. cannot be fitted with additional certificates 4. is generally only trusted by a restricted group 5. commercial CAs require certified RP SW, contracts this is simply put entirely uninteresting The government cards are status projects. We have issued x millions cards. That they are only used as physical ID-cards is something they are slightly less open about... Banks in Scandinavia put eID on credit-cards which means that every merchant get your SSN as well (if they want). As I say all the time: Google and Apple will make all EU cards look like they always was: A pile of s--t. Anders On 2011-07-28 17:07, Henry Story wrote: > Hi Peter, > > You may want to ask Prof. Martin Gaedke about this. He is working his way through the > EU area on this and should have some good pointers on where these token cards are > going around here. > > Henry > > On 28 Jul 2011, at 16:45, Peter Gutmann wrote: > >> Stefan Winter writes: >> >>> Banking: These days, TAN lists are going away. >> >> Is there any information on what's being done in countries like France, Italy, >> the Netherlands, Spain, ...? The only place where it's really documented (in >> quite some detail) is Germany (with surrounding/similar countries like Austria >> and Switzerland using equivalent approaches), but what are other countries in >> Europe doing? There's rather little information *from third parties, not the >> vendors* publicly available on how e-banking is done in France, Spain, ..., >> the pros and cons, how it deals with new attack types, and so on. >> >>> a) cell phone transaction numbers: >> >> The problem is that mTANs are vulnerable to smartphone malware, as Zeus has >> already shown. It's currently a minor threat, but who knows how far the bad >> guys will take it. On the whole though mTANs are a nice tradeoff, you get to >> verify the transaction over an independent channel, and the mTAN is a >> cryptographic hash over the transaction data so if a MITB tries to modify what >> the browser sends it gets detected. >> >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > Social Web Architect > http://bblfish.net/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From henry.story@bblfish.net Thu Jul 28 12:25:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5411E8125 for ; Thu, 28 Jul 2011 12:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.839, 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 WKigpWeG+mNd for ; Thu, 28 Jul 2011 12:25:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 63ADE11E8123 for ; Thu, 28 Jul 2011 12:25:24 -0700 (PDT) Received: by wwe5 with SMTP id 5so1909155wwe.13 for ; Thu, 28 Jul 2011 12:25:23 -0700 (PDT) Received: by 10.227.55.10 with SMTP id s10mr422728wbg.113.1311881123491; Thu, 28 Jul 2011 12:25:23 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id gb1sm1112800wbb.3.2011.07.28.12.25.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jul 2011 12:25:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <4E31B408.40107@telia.com> Date: Thu, 28 Jul 2011 21:25:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <49EDA16B-BE8F-45FA-B75B-AF396FAC9288@bblfish.net> References: <6EDD6F49-33C4-46D3-9012-765170911A57@bblfish.net> <4E31B408.40107@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: "S.tefan Winter" , Martin Gaedke , tls@ietf.org Subject: Re: [TLS] EU cards 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, 28 Jul 2011 19:25:25 -0000 On 28 Jul 2011, at 21:10, Anders Rundgren wrote: > Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so > why would the browser vendor bother about how it works? This is where I disagree. It is not far from becoming the core = authentication on the internet. Really really not far. It may be = surprising, but I have explained in detail here why I believe such a = counterintuitive thing. More here http://webid.info and on my home page. = =20 >=20 > Now to the cards: Since > 1. readers is a non-standard item > 2. all cards need different middleware > 3. cannot be fitted with additional certificates > 4. is generally only trusted by a restricted group > 5. commercial CAs require certified RP SW, contracts > this is simply put entirely uninteresting >=20 > The government cards are status projects. We have issued > x millions cards. That they are only used as physical ID-cards > is something they are slightly less open about... >=20 > Banks in Scandinavia put eID on credit-cards which means that > every merchant get your SSN as well (if they want). >=20 > As I say all the time: Google and Apple will make all EU cards look > like they always was: A pile of s--t. >=20 > Anders >=20 > On 2011-07-28 17:07, Henry Story wrote: >> Hi Peter, >>=20 >> You may want to ask Prof. Martin Gaedke about this. He is working his = way through the=20 >> EU area on this and should have some good pointers on where these = token cards are=20 >> going around here.=20 >>=20 >> Henry >>=20 >> On 28 Jul 2011, at 16:45, Peter Gutmann wrote: >>=20 >>> Stefan Winter writes: >>>=20 >>>> Banking: These days, TAN lists are going away. >>>=20 >>> Is there any information on what's being done in countries like = France, Italy, >>> the Netherlands, Spain, ...? The only place where it's really = documented (in >>> quite some detail) is Germany (with surrounding/similar countries = like Austria >>> and Switzerland using equivalent approaches), but what are other = countries in >>> Europe doing? There's rather little information *from third = parties, not the >>> vendors* publicly available on how e-banking is done in France, = Spain, ..., >>> the pros and cons, how it deals with new attack types, and so on. >>>=20 >>>> a) cell phone transaction numbers: >>>=20 >>> The problem is that mTANs are vulnerable to smartphone malware, as = Zeus has >>> already shown. It's currently a minor threat, but who knows how far = the bad >>> guys will take it. On the whole though mTANs are a nice tradeoff, = you get to >>> verify the transaction over an independent channel, and the mTAN is = a >>> cryptographic hash over the transaction data so if a MITB tries to = modify what >>> the browser sends it gets detected. >>>=20 >>> Peter. >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> Social Web Architect >> http://bblfish.net/ >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 Social Web Architect http://bblfish.net/ From prvs=719062932e=uri@ll.mit.edu Thu Jul 28 12:42:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0211E80F0 for ; Thu, 28 Jul 2011 12:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 A9C6z3+0WGCO for ; Thu, 28 Jul 2011 12:42:21 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 3655211E8134 for ; Thu, 28 Jul 2011 12:42:21 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p6SJgGiL013522 for ; Thu, 28 Jul 2011 15:42:16 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "'tls@ietf.org'" Date: Thu, 28 Jul 2011 15:42:15 -0400 Thread-Topic: [TLS] EU cards Thread-Index: AcxNWhAL/HqxwrMQR8qgTwJUXQayqAABGPOK In-Reply-To: <4E31B408.40107@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-28_05:2011-07-28, 2011-07-28, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107280171 Message-Id: <20110728194221.3655211E8134@ietfa.amsl.com> Subject: Re: [TLS] EU cards 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, 28 Jul 2011 19:42:22 -0000 Anders, Where is your data on government cards usage coming from?=20 In US a lot (literally millions) of government email and Web access is secu= red by what you call "government cards".=20 -- Regards, Uri ----- Original Message ----- From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: Thursday, July 28, 2011 03:10 PM=0A= To: Henry Story Cc: S.tefan Winter ; Martin Gaedke ; tls@ietf.org Subject: Re: [TLS] EU cards Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so why would the browser vendor bother about how it works? Now to the cards: Since 1. readers is a non-standard item 2. all cards need different middleware 3. cannot be fitted with additional certificates 4. is generally only trusted by a restricted group 5. commercial CAs require certified RP SW, contracts this is simply put entirely uninteresting The government cards are status projects. We have issued x millions cards. That they are only used as physical ID-cards is something they are slightly less open about... Banks in Scandinavia put eID on credit-cards which means that every merchant get your SSN as well (if they want). As I say all the time: Google and Apple will make all EU cards look like they always was: A pile of s--t. Anders On 2011-07-28 17:07, Henry Story wrote: > Hi Peter, >=20 > You may want to ask Prof. Martin Gaedke about this. He is working his wa= y through the=20 > EU area on this and should have some good pointers on where these token c= ards are=20 > going around here.=20 >=20 > Henry >=20 > On 28 Jul 2011, at 16:45, Peter Gutmann wrote: >=20 >> Stefan Winter writes: >> >>> Banking: These days, TAN lists are going away. >> >> Is there any information on what's being done in countries like France, = Italy, >> the Netherlands, Spain, ...? The only place where it's really documente= d (in >> quite some detail) is Germany (with surrounding/similar countries like A= ustria >> and Switzerland using equivalent approaches), but what are other countri= es in >> Europe doing? There's rather little information *from third parties, no= t the >> vendors* publicly available on how e-banking is done in France, Spain, .= .., >> the pros and cons, how it deals with new attack types, and so on. >> >>> a) cell phone transaction numbers: >> >> The problem is that mTANs are vulnerable to smartphone malware, as Zeus = has >> already shown. It's currently a minor threat, but who knows how far the= bad >> guys will take it. On the whole though mTANs are a nice tradeoff, you g= et to >> verify the transaction over an independent channel, and the mTAN is a >> cryptographic hash over the transaction data so if a MITB tries to modif= y what >> the browser sends it gets detected. >> >> Peter. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > Social Web Architect > http://bblfish.net/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Thu Jul 28 12:50:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390B011E80F1 for ; Thu, 28 Jul 2011 12:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.926 X-Spam-Level: X-Spam-Status: No, score=-9.926 tagged_above=-999 required=5 tests=[AWL=0.323, 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 4hsL9IwSpDEH for ; Thu, 28 Jul 2011 12:50:42 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B894611E80F0 for ; Thu, 28 Jul 2011 12:50:41 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6SJoeFp006100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 21:50:40 +0200 (MEST) From: Martin Rex Message-Id: <201107281950.p6SJodco027327@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Thu, 28 Jul 2011 21:50:39 +0200 (MEST) In-Reply-To: from "Paul Wouters" at Jul 28, 11 02:01:38 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 19:50:43 -0000 Paul Wouters wrote: > > On Thu, 28 Jul 2011, Martin Rex wrote: > > > > The trusted_ca_keys TLS extension itself is a simple/lightweight extension > > in that it does _not_ modify the syntax or semantics of any other > > TLS handshake messages (besides the TLS extensions container in > > ClientHello and ServerHello). > > trusted_ca_keys changes sending the CA bundle with EE-cert PKIX blob > with only the EE-cert PKIX blob. I am proposing to send only the > subjectPublicKeyInfo PKIx blob. It's not different a change of semantics. > > > I see not having to modify syntax and semantics of existing TLS handshake > > messages in order to implement a TLS extension as a big plus. > > See the start of this email and the comparison with trusted_ca_keys. I do not know what you're looking at, by _my_ copies of rfc6066 and predecessors 4366,3546 are crystal clear, there is *NO* change of syntax and semantics of any other TLS handshake messages, like e.g. the server's Certificate handshake message, so I fail to understand what you mean. There are no such things as CA bundles or PKIX blobs either, btw. The trusted_ca_keys TLS extensions does support more data types to identify acceptable CAs than the certificate_authorities list in the original CertificateRequest handshake message, however, but "cert" is not supported by either. You might be confusing "CA cert" with "distinguished name of CA". > > > The TLS WG had previously adopted a work item (currently dormant, > > primarily because of fights over hash algorithm agility that haven't > > been settled) to do caching in a generic fashion, so caching > > of data from TLS handshake messages, and in particular _existing_ > > TLS handshake messages should IMO not be duplicated in any newly > > proposed TLS extension. > > cached PKIX objects is quite different from not using PKIX. The design of the TLS caching extension is not strictly limited to PKIX-related data. But since PKIX-related data is the largest static data in current TLS handshakes, these data elements are the ones described in the currently dormant WG document. > > Currently in saag there was also the interesting point of PKIX needing > to send duplicate certs in the CA bundle for SHA1/SHA2/SHA3 because you > don't know what hashing algo the TLS client can support. That affects only folks who want to perform academic exercises. For TLS, the use of SHA-1 is pretty pervasive and going to continue just like that for at least the next 5 years. Having to maintain multiple alternative server certificate would currently be a waste of admin and helpdesk resources, if the server software supports it at all. I'm not actually aware of TLS clients or servers that implement and use the TLS extension trusted_ca_keys and personally, and I do not consider that extension generally useful. TLS clients that come with 50+ independent trust anchors preloded will hardly want to use that extension. > > The non-PKIX > authentication of the TLS server public key could just publish different > DANE records with the different hashes of the public key, and the TLS > client can pick the one it supports. Please don't suggest that it is > perfectly reasonable to keep mandating ever larger PKIX containers that > are just scrap around the public key. Or you could just wrap that server's public key in an X.509v1 self-signed cert and use it with pretty much any existing TLS client and TLS server software in the installed base. :) > > >> "something better" only works with your other assumption of "sending > >> and signing cruft in PKIX is fine". I strongly disagree with that. > > > > You seem to be thinking purely about a niche area > > > > 1) that does not have TLS at all today > > 2) where you want to implement TLS newly from scratch and having > > to implement _all_ of ASN.1-ladden PKIX as a huge burden > > 3) and where you do not care the slighest about interop with the > > installed base of TLS. > > Not at all. I am also thinking of a browser supporting non-pkix alongside > pkix authentication. If we were still in year 1995 and the installed base of TLS software was still insignificant, I might believe that TLS with bare public keys might have uses. SSH worked with bare keys back then and succeeded. But we're in 2011 now. I believe support for X.509 (and other authentication schemes) were added to SSH. But personally, I just fail to see a use case for adding raw key support to TLS that I could not simply solve with self-signed X.509v1 certs and existing TLS software in the installed base, even 10+ year old TLS software. Implementing support for self-signed X.509v1 (and JUST THAT) from scratch is probably _a_magnitude_ easier and faster than writing a specification for doing TLS with raw keys, working it through standardization and getting others to implement it. I can perfectly understand that you do not want to implement entire PKIX (rfc5280) from scratch, because that would really be an exhausting multi-year battle. > > > it might be worthwile thinking about implementing > > the subset "X.509v1 self-signed cert" as an alternative to inventing > > a new bare key format, because that is still fairly trivial to > > implement and fully interoperable with the existing installed base > > We've been carrying PKIX containers for too long already. Suggestions we > continue to do so for another twenty years are simply not good enough > in my opinion. I know not everyone agrees with me, and I'm not asking people > to switch. I'm just asking for the opportunity for everyone to make their > own decision on using PKIX or not. Admittedly, PKIX is bad, really really bad. But managing raw keys is _not_ better than a self-signed X.509v1 subset of PKIX, and I'm not aware of a suitable replacement for PKIX so far. And standardizing more ways to skin a cat may cause more harm than good and should be done lightheartedly. (recently mentioned on the IETF list:) http://www.xkcd.com/927/ > > We are not forcing TLS servers to change anything like a requirement > to support TLS version 1.42. We suggest giving TLS implementations the > *option* to implement a non-PKIX extension. cached-objects is not good > enough for this case. I don't mind adding TLS extensions that can be safely ignored and don't affect syntax&semantics of other TLS handshake messages and further evolution of the protocl. But I'm slighty worried about changing syntax or semantics of existing TLS handshake messages, because such changes scale very badly (every future change must address and fully specify the situation for all existing variants and their combinations). -Martin From n.mavrogiannopoulos@gmail.com Thu Jul 28 14:42:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5923721F8BF1 for ; Thu, 28 Jul 2011 14:42:30 -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 Z+01Tp7utIEG for ; Thu, 28 Jul 2011 14:42:29 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20EB921F8BCE for ; Thu, 28 Jul 2011 14:42:28 -0700 (PDT) Received: by wwe5 with SMTP id 5so1976261wwe.13 for ; Thu, 28 Jul 2011 14:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=hE+cuDqnB6Kf/suYQWu/CNwUKVZpBKGJ2hSl6QpdNd8=; b=ImDDovI9Muc4E2jlgw7r36ZompArar4+8kC4DnowyKAR7rYQbPCtlxSF4SWbzXdOMC jsgttnK56SBNRPYB4BNmT/OlNeyptpKr5wb1ZC9PlTKyUYXtWmDNp+9I12fmD3CKNbnS nj3fJ+eHL+OeDrHw168bdkH5SWwba9T+n/5Ng= Received: by 10.227.174.79 with SMTP id s15mr610398wbz.68.1311889347831; Thu, 28 Jul 2011 14:42:27 -0700 (PDT) Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id h1sm997348wee.1.2011.07.28.14.42.25 (version=SSLv3 cipher=OTHER); Thu, 28 Jul 2011 14:42:26 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4E31D7C1.7010308@gnutls.org> Date: Thu, 28 Jul 2011 23:42:25 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: tls@ietf.org References: <201107281658.p6SGwpYY017791@fs4113.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:42:30 -0000 On 07/28/2011 08:01 PM, Paul Wouters wrote: >> The trusted_ca_keys TLS extension itself is a simple/lightweight >> extension in that it does _not_ modify the syntax or semantics of >> any other TLS handshake messages (besides the TLS extensions >> container in ClientHello and ServerHello). > trusted_ca_keys changes sending the CA bundle with EE-cert PKIX blob > with only the EE-cert PKIX blob. I am proposing to send only the > subjectPublicKeyInfo PKIx blob. It's not different a change of > semantics. >> In TLS WG we definitely need to keep an eye on TLS extension not >> duplicating each other resulting in conflicts an interop problems. > Hency my method that is suitable not just for DANE, but for any > non-PKIX out of band authentication. I see two use-cases here. One is to be able to send raw public keys (whether a certificate has been communicated out-of-band seems pretty irrelevant), and the other to reduce bandwidth and (possibly round-trips) by not sending any certificates, either because they have been cached or because they are obtained out-of-band. I think of those of two distinct issues, but before going and solving them check whether it is worth the effort. draft-ietf-tls-cached-info tried to solve the bandwidth problem, but as far as I know it has never been implemented. The other goal of yours of sending raw public keys might as well be solved by defining a new certificate type RAW in the certificateType registry defined in RFC6091 and send anything you like in the "Certificate" message. You don't need WG consensus to do that. But do you really have a use case that makes all that effort worthwhile? Why would others be interested into implementing the RAW keys you are proposing? regards, Nikos From mrex@sap.com Thu Jul 28 17:06:15 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EB611E8133 for ; Thu, 28 Jul 2011 17:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.63 X-Spam-Level: X-Spam-Status: No, score=-9.63 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_41=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 N3ZJflgIq0K3 for ; Thu, 28 Jul 2011 17:06:15 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B136411E809C for ; Thu, 28 Jul 2011 17:06:14 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6T06CaV026884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 02:06:12 +0200 (MEST) From: Martin Rex Message-Id: <201107290006.p6T06BD0012180@fs4113.wdf.sap.corp> To: anders.rundgren@telia.com (Anders Rundgren) Date: Fri, 29 Jul 2011 02:06:11 +0200 (MEST) In-Reply-To: <4E313B9C.3040104@telia.com> from "Anders Rundgren" at Jul 28, 11 12:36:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: stefan.winter@restena.lu, tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 00:06:16 -0000 Anders, Anders Rundgren wrote: > > These two guys says that having a key in the PC is braindead, > particularly if you use it from a browser. I'm sorry for loosing my temper. You don't deserve this. I don't know what particular issue banks have with their weird threat model here in Germany, I'm unable to find an even remotely reasonable explanation why so many of them are suddenly violently determined to completely kill any of their existing paper-based TANs, including iTANs that they introduced just a few years ago, aggressively touted as something that you need. I do not want having to carry around any of their fancy hardware tokens with keypad and display (and personally bear the risk for loosing or breaking it). Nor do I want having to carry around a mobile phone, let alone buy and carry a smartphone for similar reasons. > > Based on 15 years of experience of s.c. "security experts" we > can safely drop this thread; it won't go anywhere. TLS when used by web browsers for HTTPS is a transport protocol with non-persistent connections, which means that the only sensible operational model for TLS client certs in browsers is for Single Sign-On, everthing else is either a security problem or a usability problem or both. But attributing intent with a web browsers HTTPS CCA authentication or authorizing transactions with it seems like a very bad idea, because of the numerous problems in the entire architecture. Browsers do _not_ enforce that elements on a page all come from the exact same server when HTTPS is used, and MSIE8 and Safari4Windows on Windows 7 do not even tell you which server is asking for a client certificate when showing you the client cert selection box. I assume that active content could even perform request "dark" in the background while the pages that you actually see do not look suspicious at all. 13 years ago Online banking regularly worked with secure browser setting (i.e. active content disabled), pure-html and very quick response times. Today, most online banking requires active content enabled and is dead slow for no reasonable purpose. > > This attitude was OK before we entered the "Google- and Apple-age". > It's an entirely different ball-game now! Smart phones are already attractive targets for theft even with no additional digital gems added by the end user. Significantly further increasing the attractiveness of that target for both, digital theft through malware and physical theft of the smartphone, does not seem overly sensible to me. >From what I read in the german computer magazine, http://www.heise.de/artikel-archiv/ct/2011/15/154_kiosk all existing iPhones and iPad1s seem to have the vulnerability in the Boot-Rom (i.e. Hardware, no possibility to fix by software update) that might enable thieves to bypass many if not all of the assumed "protections" and retrieve your private data. -Martin From matt@mattmccutchen.net Thu Jul 28 21:33:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AAC11E8084 for ; Thu, 28 Jul 2011 21:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS7BYPg0H9rS for ; Thu, 28 Jul 2011 21:33:22 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB711E807F for ; Thu, 28 Jul 2011 21:33:22 -0700 (PDT) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 10FFE3BC06C; Thu, 28 Jul 2011 21:33:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=oC5yPoPJBy1UrlNq6ueK75gAbippVLEoyYJPK8WpJj9 btgkE/C7LZA+5OEQEmcmL1uCKdlKtALtTvWbPE7CmX2Uez4IBltwJ32Fla3F4dTf OMHdm3neBuFy8/jsGMzEjQIxO9FmLbpGvAxVMRtXd2Fpg3drK/p1WslKkWiGCMwU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=/nnVwCFzA/DeVymf6ve9lPVoXOo=; b=Dl09ETwwQm imMboiZmsKXAfd/OvDm56o7h50XHLBAD6aVebelnYatzgd/oHaD2pXt7Meaj4DVO ZS8cBaFXA208yHx4P7fKDW77n//qERjyfUdgvNNuIdeBHSnIQ3PKn1d3Lqnpodjb 7dmI33abPd6daAV3AQlkAtLiPte8WiS1s= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 7C96E3BC06A; Thu, 28 Jul 2011 21:33:21 -0700 (PDT) From: Matt McCutchen To: "David A. McGrew" In-Reply-To: <8BE39A5D-EAAF-4BD0-8549-79A87C6EBD3C@mindspring.com> References: <1311734551.7071.72.camel@localhost> <8BE39A5D-EAAF-4BD0-8549-79A87C6EBD3C@mindspring.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 29 Jul 2011 00:33:19 -0400 Message-ID: <1311913999.2035.28.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 04:33:23 -0000 On Thu, 2011-07-28 at 12:48 -0700, David A. McGrew wrote: > > - If you're going to require support from the client, you might as > > well > > do something to support client authentication on the server-side > > connection, e.g., tunnel the PKCS#11 protocol back to the client. > > It would be great to promote client authentication, though I'm not > exactly sure what you are proposing. Do you mean to pass PKCS#11 > through a TLS extension? No, I imagine PKCS#11 would use several round trips, so a new ContentType would be needed. It's probably possible to define a more efficient protocol than a serialization of PKCS#11, but also more work. Whatever the protocol would be, it has to nest to handle multiple proxies. > > - It would be better design to put the whole certificate acceptance > > test > > (trust anchor validation + server name check) on the client. Schemes > > such as DANE replace the certificate acceptance test as a whole. > > I also have the sense that it is best to have the client do all the > work in most cases. But do you think it would be OK to eliminate the > possibility that the proxy does some of the work? Not sure. Do you have a use case for the proxy doing some or all of the work? My point was that splitting the server name check from the trust anchor validation is specific to PKIX certificate acceptance and serves no purpose that I can foresee, while doing the whole test on the client often makes sense because the client is prepared to do the whole test in the absence of a proxy. > > - One approach would be to do a real escrowed TLS where the client > > negotiates directly with the server but releases the confidentiality > > key > > and optionally also the integrity key to the proxy. This subsumes all > > of the above concerns but doesn't allow the proxy to manipulate the > > handshake in any finer way than blocking the connection if it doesn't > > like the outcome. > > I think that propagating secret or private keys from one device to > another is not a good idea, for crypto reasons which are outlined in > Section 6 of the draft. I missed the potential attack when the stream is edited under a single integrity key. And indeed, I am having trouble coming up with any scheme that is fundamentally simpler than two separate TLS connections and does not introduce security problems. You may still wish to provide as much client-to-server negotiation transparency as possible. Another comment: > The ProxyInfo > proposal [...] > allows the client to refuse to deal with untrusted proxies. This has to be understood carefully. An "untrusted proxy" is just a MITM attacker. In general, we already have a mechanism for refusing to deal with them: it's called server authentication. The above benefit exists /compared to the alternative/ of a proxy trust anchor. -- Matt From matt@mattmccutchen.net Thu Jul 28 21:51:36 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC6921F8799 for ; Thu, 28 Jul 2011 21:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU9NO4nJIlvH for ; Thu, 28 Jul 2011 21:51:34 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC721F8797 for ; Thu, 28 Jul 2011 21:51:33 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id A00C2578071; Thu, 28 Jul 2011 21:51:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=u/kwk2VztOVId/8WD9O2RRY+2QBo2M54xtY5Xf40JrP 4mbE4nSwZmHnakFlKjSl1ckckPVcPMr7Aj6sUEdFx/nHHF3C6mFfSZvqRzMG6Et9 BrvHOahWtRWbqrtphV3NYeik4bSiMHNMHEeTB4fhGHaTUJq4kYmzSCiRYRUx7Q3k = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=nRm71EJ9G4LBY/095zRfwIRSEXw=; b=jDMaQSTz43 hO7euqqTC8voGobrpnshXRTZAeakgqqYbtVCoQTajVRAPoP1bIch9mOTNqpd24Us b8Bam5WZP3lIHBpF2qzRjf87RCcVPVfr2rCEK/VQ0ysU6tq4kyLHRNcC7wT2Xyt/ y4RfEKhITApIRo177yUth1wODORvMusl8= Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id BE2E157806C; Thu, 28 Jul 2011 21:51:32 -0700 (PDT) From: Matt McCutchen To: mrex@sap.com In-Reply-To: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp> References: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Fri, 29 Jul 2011 00:51:30 -0400 Message-ID: <1311915090.2035.36.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 Content-Transfer-Encoding: 7bit Cc: pgladstone@cisco.com, mcgrew@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 04:51:36 -0000 On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote: > Only for Web-Browser scenario can I personally see a very limited > value that does not amount to 100% wiretapping. > > Are you aware of rfc2804 "IETF Policy on Wiretapping"? > > http://tools.ietf.org/html/rfc2804 > > Standardizing MITM attacks on TLS-protected communication > ("lawful intercept?") seems like an extremely bad idea to me. This is not wiretapping as defined in that policy. Not that I would ever be willing to use a TLS proxy for personal activities, but I see no reason to block the standardization. In fact, I am intrigued by the idea. > Checking whether some data conforms to a certain company policy will > almost always be illegal in European countries, where we have > sensible data protection laws. If you are thinking of corporate networks (the typical current use of the proxies in question), I don't see how restricting what checks a company can do on its own property is sensible, but that is off topic... > > - One approach would be to do a real escrowed TLS where the client > > negotiates directly with the server but releases the confidentiality key > > and optionally also the integrity key to the proxy. This subsumes all > > of the above concerns but doesn't allow the proxy to manipulate the > > handshake in any finer way than blocking the connection if it doesn't > > like the outcome. > > For the purpose of "centralized malware screening", for the incoming > Web traffic of Web Browsers that are well known to interpret such > data in arbitrarily stupid ways (such as active content, img src, (i)frame, > javascript, css), sharing the encryption traffic keys with the Proxy > would be perfectly sufficient Correct. > and that also enables the clients > to clearly limit who is able to read the traffic. Huh? The proxy's ability to pass decrypted data to someone else is no different than if it were bridging two TLS connections. > No super-CA-equivalent > keys would need to be on the malware-scanning Proxy. You speak as if that were in a whole different class of badness, but the actual effect is simply to give up integrity as well as confidentiality to the proxy. -- Matt From anders.rundgren@telia.com Thu Jul 28 22:07:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B53A11E807F for ; Thu, 28 Jul 2011 22:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 cNV26TjjGS7o for ; Thu, 28 Jul 2011 22:07:56 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 0582D11E8075 for ; Thu, 28 Jul 2011 22:07:52 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0082AA94; Fri, 29 Jul 2011 07:07:49 +0200 Message-ID: <4E324016.90903@telia.com> Date: Fri, 29 Jul 2011 07:07:34 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Blumenthal, Uri - 0668 - MITLL" References: <20110728194221.3655211E8134@ietfa.amsl.com> In-Reply-To: <20110728194221.3655211E8134@ietfa.amsl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] EU cards 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, 29 Jul 2011 05:07:57 -0000 On 2011-07-28 21:42, Blumenthal, Uri - 0668 - MITLL wrote: > Anders, > > Where is your data on government cards usage coming from? various mailing lists such as: http://www.opensc-project.org/opensc Most of the people hanging out there are in some way working with the EU cards. > > In US a lot (literally millions) of government email and Web access > is secured by what you call "government cards". I guess you refer to PIV and CAC? There is a fundamental difference between the US and the EU and that only in the EU there is something called "citizen-cards" or eID. Citizens are supposed to buy eID for carrying out secure services on the Internet. The cost have been high; results have been marginal for the reasons I listed (and some more...). Obama's NSTIC is something similar (but still very different) that will be slightly interesting following although I don't think their NIST friends really understand the consumer market and the huge technical issues they will have to deal with. IMO, the PC platform is dead as a vehicle for innovation; they might go to phones from the start. I never understood why you need a picture on a token for Internet access :-) Well, "it has always been like that" is probably the [lame] excuse. Regards, Anders > > -- > Regards, > Uri > > ----- Original Message ----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Thursday, July 28, 2011 03:10 PM > To: Henry Story > Cc: S.tefan Winter ; Martin Gaedke ; tls@ietf.org > Subject: Re: [TLS] EU cards > > Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so > why would the browser vendor bother about how it works? > > Now to the cards: Since > 1. readers is a non-standard item > 2. all cards need different middleware > 3. cannot be fitted with additional certificates > 4. is generally only trusted by a restricted group > 5. commercial CAs require certified RP SW, contracts > this is simply put entirely uninteresting > > The government cards are status projects. We have issued > x millions cards. That they are only used as physical ID-cards > is something they are slightly less open about... > > Banks in Scandinavia put eID on credit-cards which means that > every merchant get your SSN as well (if they want). > > As I say all the time: Google and Apple will make all EU cards look > like they always was: A pile of s--t. > > Anders > > On 2011-07-28 17:07, Henry Story wrote: >> Hi Peter, >> >> You may want to ask Prof. Martin Gaedke about this. He is working his way through the >> EU area on this and should have some good pointers on where these token cards are >> going around here. >> >> Henry >> >> On 28 Jul 2011, at 16:45, Peter Gutmann wrote: >> >>> Stefan Winter writes: >>> >>>> Banking: These days, TAN lists are going away. >>> >>> Is there any information on what's being done in countries like France, Italy, >>> the Netherlands, Spain, ...? The only place where it's really documented (in >>> quite some detail) is Germany (with surrounding/similar countries like Austria >>> and Switzerland using equivalent approaches), but what are other countries in >>> Europe doing? There's rather little information *from third parties, not the >>> vendors* publicly available on how e-banking is done in France, Spain, ..., >>> the pros and cons, how it deals with new attack types, and so on. >>> >>>> a) cell phone transaction numbers: >>> >>> The problem is that mTANs are vulnerable to smartphone malware, as Zeus has >>> already shown. It's currently a minor threat, but who knows how far the bad >>> guys will take it. On the whole though mTANs are a nice tradeoff, you get to >>> verify the transaction over an independent channel, and the mTAN is a >>> cryptographic hash over the transaction data so if a MITB tries to modify what >>> the browser sends it gets detected. >>> >>> Peter. >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> Social Web Architect >> http://bblfish.net/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From pgut001@login01.cs.auckland.ac.nz Thu Jul 28 23:17:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CB35E8009 for ; Thu, 28 Jul 2011 23:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.618 X-Spam-Level: X-Spam-Status: No, score=-3.618 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 Ye9ZGVji30nw for ; Thu, 28 Jul 2011 23:17:30 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 07D2D5E8007 for ; Thu, 28 Jul 2011 23:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311920250; x=1343456250; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20anders.rundgren@telia.com,=20henry.story@bblfish.n et|Subject:=20Re:=20[TLS]=20EU=20cards|Cc:=20martin.gaedk e@informatik.tu-chemnitz.de,=20pgut001@cs.auckland.ac.nz, =0D=0A=20=20=20=20stefan.winter@restena.lu,=20tls@ietf.or g|In-Reply-To:=20<4E31B408.40107@telia.com>|Message-Id: =20|Date: =20Fri,=2029=20Jul=202011=2018:17:28=20+1200; bh=18LdWS+rvxMgbffa4VrccYotx+oMWOr9eqPoOBBcC3E=; b=F9ktC+Q7mtxwWT4Z81KeeX32ry3ra+I+Avml6Og1JbAsMn+yK+dSpa3q qqxdYjw8HUb/bpCYODU40QL2NNyic7qWmZEGnuPx+0igXdmxBblXyYz3A 511MchioctQb7jYdvWVFJahzF4jC3+5sLVS+qIjRInukhh+byXil0An3u s=; X-IronPort-AV: E=Sophos;i="4.67,286,1309694400"; d="scan'208";a="74802218" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2011 18:17:29 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QmgO0-0008Jy-If; Fri, 29 Jul 2011 18:17:28 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QmgO0-0006w9-NS; Fri, 29 Jul 2011 18:17:28 +1200 From: Peter Gutmann To: anders.rundgren@telia.com, henry.story@bblfish.net In-Reply-To: <4E31B408.40107@telia.com> Message-Id: Date: Fri, 29 Jul 2011 18:17:28 +1200 Cc: stefan.winter@restena.lu, martin.gaedke@informatik.tu-chemnitz.de, tls@ietf.org Subject: Re: [TLS] EU cards 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, 29 Jul 2011 06:17:30 -0000 Anders Rundgren writes: >Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so why would the >browser vendor bother about how it works? > >Now to the cards: Since >1. readers is a non-standard item >2. all cards need different middleware >3. cannot be fitted with additional certificates >4. is generally only trusted by a restricted group >5. commercial CAs require certified RP SW, contracts this is simply put >entirely uninteresting You forgot 2a: 2a. The middleware is buggy, unstable, only works on certain system configurations or on certain hardware, prevents or upsets normal operation of the system it's installed on, etc. Vendors mostly ignore bug reports, and aren't interested in updating their drivers unless you go back and buy another half-million cards. >The government cards are status projects. We have issued x millions cards. I tend to refer to them as "government charities", but that's more or less the same thing. Peter. From mrex@sap.com Thu Jul 28 23:21:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2921F8639 for ; Thu, 28 Jul 2011 23:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.919 X-Spam-Level: X-Spam-Status: No, score=-9.919 tagged_above=-999 required=5 tests=[AWL=0.330, 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 uCHgsk7lflRQ for ; Thu, 28 Jul 2011 23:21:43 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 947EE21F85AE for ; Thu, 28 Jul 2011 23:21:43 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6T6Ld2e008777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 08:21:39 +0200 (MEST) From: Martin Rex Message-Id: <201107290621.p6T6Lckb004132@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 29 Jul 2011 08:21:38 +0200 (MEST) In-Reply-To: <1311915090.2035.36.camel@localhost> from "Matt McCutchen" at Jul 29, 11 00:51:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pgladstone@cisco.com, mcgrew@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 06:21:44 -0000 Matt McCutchen wrote: > > > and that also enables the clients > > to clearly limit who is able to read the traffic. > > Huh? The proxy's ability to pass decrypted data to someone else is no > different than if it were bridging two TLS connections. No, that is entirely different. Revealing the traffic **encryption** keys to the proxy requires cooperation of the client, so a sensible client implementation can ask for consent and the user may deny consent, whereas a proxy with a super-CA-cert can subvert any connection for that client, no matter where that client goes--and MitM all connections any time, including those that do not traverse that proxy. > > > No super-CA-equivalent > > keys would need to be on the malware-scanning Proxy. > > You speak as if that were in a whole different class of badness, but the > actual effect is simply to give up integrity as well as confidentiality > to the proxy. You would not reveal the MAC keys, of course. only the encryption keys. There is no need to allow the proxy to modify the traffic. If the proxy doesn't like some of the data, it should not pass it along and terminate the connection. -Martin From pgut001@login01.cs.auckland.ac.nz Thu Jul 28 23:26:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333C021F8658 for ; Thu, 28 Jul 2011 23:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.084 X-Spam-Level: X-Spam-Status: No, score=-3.084 tagged_above=-999 required=5 tests=[AWL=-0.551, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, SARE_OBFU_ALL=0.751] 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 8A55g-dg2yx4 for ; Thu, 28 Jul 2011 23:26:40 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4850821F8640 for ; Thu, 28 Jul 2011 23:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311920800; x=1343456800; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20tls@ietf.org,=20uri@ll.mit.edu|Subject:=20Re:=20[T LS]=20EU=20cards|In-Reply-To:=20<20110728194221.3655211E8 134@ietfa.amsl.com>|Message-Id:=20|Date:=20Fri,=2029=20Jul=202011=20 18:26:38=20+1200; bh=fNy/B32+t9JQDlG3VoIGz3YphaWLf/7pi0WtmSoN9PM=; b=I3FTiMsIqxVXOm06WUAXNlr1I6XSqdx4niEDRcoPv/UKL3ZN1GS5fXqt 3pVaaMXe2LH+oZRTGJ9WUiKGSgMLaXsj/l9y22Q689tNrz8R/FN1GicvP E73SJnKPTaJ6jIGzDCMiQxPBJIQRWADKez1KEElMa2lvdBRBGCKjhSAzc M=; X-IronPort-AV: E=Sophos;i="4.67,286,1309694400"; d="scan'208";a="74802859" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2011 18:26:39 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1QmgWs-00008Q-Ir; Fri, 29 Jul 2011 18:26:38 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1QmgWs-0007h1-Q3; Fri, 29 Jul 2011 18:26:38 +1200 From: Peter Gutmann To: tls@ietf.org, uri@ll.mit.edu In-Reply-To: <20110728194221.3655211E8134@ietfa.amsl.com> Message-Id: Date: Fri, 29 Jul 2011 18:26:38 +1200 Subject: Re: [TLS] EU cards 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, 29 Jul 2011 06:26:41 -0000 "Blumenthal, Uri - 0668 - MITLL" writes: >In US a lot (literally millions) of government email and Web access is secured >by what you call "government cards". Ah yes, the common access card. Let me tell you about the CAC. A couple of years back, a bunch of us were in a taxi line at a hotel. I was wearing a shirt that said something about PKI. Someone behind us in the queue (who turned out in later conversation to be a mid-ranking US military person) asked what the shirt meant. When we explained it (briefly), his response was "Oh, you mean like the CAC? Man, that stuff SUCKS!". As a member of our party later put it, "when random strangers stop you in taxi queues to tell you how much the technology sucks, you know there's a serious problem". This is why, in a previous message, I specifically asked for reports of European banking authentication from independent third parties and end users, not the people involved in deploying it. As Anders points out, these are status projects, if you ask the people involved in the deployment then you always get the same response, "we have millions of them deployed, it's a great success". You have to ask the end users to get a real picture of what's going on. Peter. From pgut001@login01.cs.auckland.ac.nz Thu Jul 28 23:39:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E259211E808A for ; Thu, 28 Jul 2011 23:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.603 X-Spam-Level: X-Spam-Status: No, score=-3.603 tagged_above=-999 required=5 tests=[AWL=-0.004, 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 Y+yTd+T20juv for ; Thu, 28 Jul 2011 23:39:18 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 01AF911E807F for ; Thu, 28 Jul 2011 23:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1311921558; x=1343457558; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20mrex@sap.com|Subject:=20Re:=20[TLS]=20HTTPS=20clie nt-certificate-authentication=20in=20browsers|Cc:=20tls@i etf.org|In-Reply-To:=20<201107290006.p6T06BD0012180@fs411 3.wdf.sap.corp>|Message-Id:=20|Date:=20Fri,=2029=20Jul=202011=2018:3 9:16=20+1200; bh=9WtnUz5C/c9+y55ltfIF8sMXKjBX48cko46Emld62dI=; b=r/kwza+2/0egSl52dz81Kipo9A4OQvCBUW6a0mKHeDhNLUv5SiP+1XQx 2ZPvA063dGibUVd2bohM1qM5+6M3zgK/wyEFAFS4TNY0aAHgvv4C1St/c ne3nfLsdjPeXL9fPLGLRrIjBnmldPF+I/93+dMK6VT8x8Ypy/IrituST5 Y=; X-IronPort-AV: E=Sophos;i="4.67,286,1309694400"; d="scan'208";a="74803823" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Jul 2011 18:39:16 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qmgj6-0000UT-Ha; Fri, 29 Jul 2011 18:39:16 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qmgj6-0007y4-DJ; Fri, 29 Jul 2011 18:39:16 +1200 From: Peter Gutmann To: mrex@sap.com In-Reply-To: <201107290006.p6T06BD0012180@fs4113.wdf.sap.corp> Message-Id: Date: Fri, 29 Jul 2011 18:39:16 +1200 Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 29 Jul 2011 06:39:19 -0000 Martin Rex writes: >I don't know what particular issue banks have with their weird threat model >here in Germany, I'm unable to find an even remotely reasonable explanation >why so many of them are suddenly violently determined to completely kill any >of their existing paper-based TANs, including iTANs that they introduced just >a few years ago, aggressively touted as something that you need. This has been covered in a number of journal/magazine articles, for example there was a fairly comprehensive one in c't in the middle of last year on this. Since paper-based TANs aren't tied in any way to the transaction they're authenticating, they're vulnerable to both phishing attacks and MITB attacks. iTANs were introduced to counter straight phishing (ask for the next n TANs), the attackers countered with more aggressive TAN phishing and MITB, and the response to that was mTANs and tokens. So German banks are actively tracking threats as they evolve and responding to them, which few other banks seem to be doing (or at least if they are, it's not documented anywhere). This is probably why US phishing losses are a staggering *six hundred times* higher than German ones. In Germany the banks try and address evolving threats. In the US the banks take their customers to court when they become victims of poor banking security. Peter. From anders.rundgren@telia.com Fri Jul 29 00:34:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6821F85B2 for ; Fri, 29 Jul 2011 00:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 N0arCZ4YSopV for ; Fri, 29 Jul 2011 00:34:50 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4065621F85AB for ; Fri, 29 Jul 2011 00:34:49 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E9700087884; Fri, 29 Jul 2011 09:34:43 +0200 Message-ID: <4E326283.3030005@telia.com> Date: Fri, 29 Jul 2011 09:34:27 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stefan.winter@restena.lu, martin.gaedke@informatik.tu-chemnitz.de, tls@ietf.org Subject: Re: [TLS] EU cards 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, 29 Jul 2011 07:34:50 -0000 On 2011-07-29 08:17, Peter Gutmann wrote: > Anders Rundgren writes: > >> Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so why would the >> browser vendor bother about how it works? >> >> Now to the cards: Since >> 1. readers is a non-standard item >> 2. all cards need different middleware >> 3. cannot be fitted with additional certificates >> 4. is generally only trusted by a restricted group >> 5. commercial CAs require certified RP SW, contracts this is simply put >> entirely uninteresting > > You forgot 2a: > > 2a. The middleware is buggy, unstable, only works on certain system > configurations or on certain hardware, prevents or upsets normal operation of > the system it's installed on, etc. Vendors mostly ignore bug reports, and > aren't interested in updating their drivers unless you go back and buy another > half-million cards. You are [unfortunately] quite right. The (relative) success smart cards have had in controlled environment such as payment terminals cannot be translated to the completely uncontrolled consumer computer base. I see two possibilities: 1. The easy one. Let Apple with iPhone/iPad provide us with the "container". 2. Define a new container where the interface is strict and support provisioning so that even Joe Sixpack can succeed. This is my take on the subject which though is about 100 times more difficult than what Apple needs to do so I guess I'm an idiot even trying... http://webpki.org/auth-token-4-the-cloud.html I just don't like the idea of going from an OS monopoly to a fullblown OS + Device + Infrastructure monopoly. Banks and Governments have little to compete with and will also [much too] late realize they're screwed. Anders > >> The government cards are status projects. We have issued x millions cards. > > I tend to refer to them as "government charities", but that's more or less the > same thing. :-) Anders From henry.story@bblfish.net Fri Jul 29 01:00:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF421F8B6D for ; Fri, 29 Jul 2011 01:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[AWL=0.671, 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 TCbD6sc+wTld for ; Fri, 29 Jul 2011 01:00:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C784721F87D9 for ; Fri, 29 Jul 2011 01:00:23 -0700 (PDT) Received: by wyj26 with SMTP id 26so356649wyj.31 for ; Fri, 29 Jul 2011 01:00:22 -0700 (PDT) Received: by 10.227.165.202 with SMTP id j10mr1535488wby.18.1311926422540; Fri, 29 Jul 2011 01:00:22 -0700 (PDT) Received: from bblfish.home (AAubervilliers-651-1-161-132.w81-249.abo.wanadoo.fr [81.249.172.132]) by mx.google.com with ESMTPS id eo18sm1520897wbb.29.2011.07.29.01.00.20 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jul 2011 01:00:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <4E326283.3030005@telia.com> Date: Fri, 29 Jul 2011 10:00:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E326283.3030005@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1244.3) Cc: stefan.winter@restena.lu, martin.gaedke@informatik.tu-chemnitz.de, tls@ietf.org Subject: Re: [TLS] EU cards 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, 29 Jul 2011 08:00:25 -0000 My take from this whole discussion is that PKI has been sold to = unilaterally to one group of people. It has been sold to large banks and = security heavy industries. They tend to make things more complicated, = and their security people are too security conscious, having to deal = with the most determined enemies. A good security profession in banks = MUST like a good military man, be far from the daily family life. He is = there to think about disasters, so that they don't happen, so that = nobody should think about them.=20 What should happen instead is to lower the security requirements, and = enter the mass market. Just as we don't put fort knox security on our = houses, but use simple keys with well known security issues, so one = should start using PKI in a cheap but useful way. Of course PKI has to = solve a problem that passwords don't solve, otherwise they can't get = traction. But they don't have to solve EVERY security problem.=20 To get that ball rolling PKI has to be dirt cheap, and extremely useful. = It has to be=20 - one click to create a throw away certificate - authenticate across all sites (as Facebook connect does) (-> tie into the social web) =20 That would provide a big enough improvement over passwords to get = people interested, and it has a viral side to it. As soon as it works = for enough people, those people become interested in getting others on = board too. With millions or billions of adopters you can create the momentum, and = the mass market, that will make all the other problems easy to solve. If = there were just a million active developers in open source software = using PKI every day for checking in software and communicating with = their peers, you would soon find the technology make its way into every = web site, and browsers being adapted to make their interface easy to = use. With mass adoption it would be much easier to solve all the other = technological problems, because citizens and politicians would have an = immediate understanding of what you were talking about.=20 That is what http://webid.info/ offers. Start with the low hanging = problems: passwords. Then move on to add technology piece by piece to = move up the security ladder. This is the way technology works. = Microsoft started with DOS and moved its way up to more and more secure = versions of Windows - whatever you think of their OS you can't deny that = that was a very successful strategy. Henry On 29 Jul 2011, at 09:34, Anders Rundgren wrote: > On 2011-07-29 08:17, Peter Gutmann wrote: >> Anders Rundgren writes: >>=20 >>> Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so why = would the=20 >>> browser vendor bother about how it works? >>>=20 >>> Now to the cards: Since >>> 1. readers is a non-standard item >>> 2. all cards need different middleware >>> 3. cannot be fitted with additional certificates >>> 4. is generally only trusted by a restricted group >>> 5. commercial CAs require certified RP SW, contracts this is simply = put=20 >>> entirely uninteresting >>=20 >> You forgot 2a: >>=20 >> 2a. The middleware is buggy, unstable, only works on certain system=20= >> configurations or on certain hardware, prevents or upsets normal = operation of=20 >> the system it's installed on, etc. Vendors mostly ignore bug = reports, and=20 >> aren't interested in updating their drivers unless you go back and = buy another=20 >> half-million cards. >=20 > You are [unfortunately] quite right. The (relative) success smart = cards have > had in controlled environment such as payment terminals cannot be = translated > to the completely uncontrolled consumer computer base. >=20 > I see two possibilities: > 1. The easy one. Let Apple with iPhone/iPad provide us with the = "container". > 2. Define a new container where the interface is strict and support = provisioning > so that even Joe Sixpack can succeed. This is my take on the subject = which > though is about 100 times more difficult than what Apple needs to do = so > I guess I'm an idiot even trying... > http://webpki.org/auth-token-4-the-cloud.html > I just don't like the idea of going from an OS monopoly to a fullblown > OS + Device + Infrastructure monopoly. Banks and Governments have = little > to compete with and will also [much too] late realize they're screwed. >=20 > Anders >=20 >>=20 >>> The government cards are status projects. We have issued x millions = cards. =20 >>=20 >> I tend to refer to them as "government charities", but that's more or = less the=20 >> same thing. >=20 > :-) >=20 > Anders >=20 Social Web Architect http://bblfish.net/ From n.mavrogiannopoulos@gmail.com Fri Jul 29 02:00:55 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F1C21F84F6 for ; Fri, 29 Jul 2011 02:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c++7Ydjccprv for ; Fri, 29 Jul 2011 02:00:54 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id A814321F8A6C for ; Fri, 29 Jul 2011 02:00:54 -0700 (PDT) Received: by pzk6 with SMTP id 6so5660026pzk.26 for ; Fri, 29 Jul 2011 02:00:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EVMW4wjBrweNfJl7TG5swEYdJ/X9aG+rl0zMoWbQtjA=; b=ex1zBYmW4hACtZy56SQZfrhe9sB+GjvM8pAOYvDl4aOd0ahusZ5D5Od473xc0qmW4z YkniJwBkKm3JYz5xAzW5dXsQ1pxXnoHAok+gQtfPJRh41zGG56kZzWSlimiw9YwJhgx6 VrSE/B3UTEJd2RsJTVunSuMayvvby756fUVxg= MIME-Version: 1.0 Received: by 10.68.13.193 with SMTP id j1mr1652054pbc.384.1311930054198; Fri, 29 Jul 2011 02:00:54 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.142.156.16 with HTTP; Fri, 29 Jul 2011 02:00:54 -0700 (PDT) In-Reply-To: References: <4E326283.3030005@telia.com> Date: Fri, 29 Jul 2011 11:00:54 +0200 X-Google-Sender-Auth: jOan4tJbOiEAAj1HArCHvMHAbEo Message-ID: From: Nikos Mavrogiannopoulos To: Henry Story Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] EU cards 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, 29 Jul 2011 09:00:55 -0000 On Fri, Jul 29, 2011 at 10:00 AM, Henry Story wro= te: > My take from this whole discussion is that PKI has been sold to unilatera= lly to one group of people. It has been sold to large banks and security he= avy industries. They tend to make things more complicated, and their securi= ty people are too security conscious, having to deal with the most determin= ed enemies. A good security profession in banks MUST like a good military m= an, be far from the daily family life. He is there to think about disasters= , so that they don't happen, so that nobody should think about them. [...] > That is what http://webid.info/ offers. Start with the low hanging proble= ms: passwords. Then move on to add technology piece by piece to move up the= security ladder. =C2=A0This is the way technology works. Microsoft started= with DOS and moved its way up to more and more secure versions of Windows = - whatever you think of their OS you can't deny that that was a very succes= sful strategy. If you are referring to PKI as in PKIX (X.509) then banks had nothing to do with it. Banks had their own set of standards that never took off. PKIX was based on a telecommunications standard, that evolved over the years as DOS in your example did. Many people think that this was a sucessful strategy as well, and some others think it is just ugly. regards, Nikos From ynir@checkpoint.com Fri Jul 29 04:33:34 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495EE21F869D for ; Fri, 29 Jul 2011 04:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 qzLIfhgtnp6e for ; Fri, 29 Jul 2011 04:33:33 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DF9A921F86A4 for ; Fri, 29 Jul 2011 04:33:31 -0700 (PDT) X-CheckPoint: {4E32A819-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6TBXSR9016680; Fri, 29 Jul 2011 14:33:28 +0300 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 29 Jul 2011 14:33:28 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 29 Jul 2011 14:33:27 +0300 From: Yoav Nir To: Henry Story Date: Fri, 29 Jul 2011 14:33:26 +0300 Thread-Topic: [TLS] EU cards Thread-Index: AcxN41WLdK9DeIbuS/2zuFDgULSIOw== Message-ID: <23B9A904-8A0D-48A2-AF45-FB6AFB58C8A9@checkpoint.com> References: <4E326283.3030005@telia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org List" Subject: Re: [TLS] EU cards 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, 29 Jul 2011 11:33:34 -0000 On Jul 29, 2011, at 4:00 AM, Henry Story wrote: > My take from this whole discussion is that PKI has been sold to unilatera= lly to one group of people. It has been sold to large banks and security he= avy industries. They tend to make things more complicated, and their securi= ty people are too security conscious, having to deal with the most determin= ed enemies. A good security profession in banks MUST like a good military m= an, be far from the daily family life. He is there to think about disasters= , so that they don't happen, so that nobody should think about them.=20 >=20 > What should happen instead is to lower the security requirements, and ent= er the mass market. Just as we don't put fort knox security on our houses, = but use simple keys with well known security issues, so one should start us= ing PKI in a cheap but useful way. The well-known issues in keys allow an expert to invade a home and steal th= e big-screen TV. It does not allow the expert to automatically invade all 1= 00,000,000 homes in the US and steal every TV. Computers are very good at a= utomation. >=20 > To get that ball rolling PKI has to be dirt cheap, and extremely useful. = It has to be=20 > - one click to create a throw away certificate > - authenticate across all sites (as Facebook connect does) > (-> tie into the social web) So what would PKI (with throw-away certificates) bring to the table that fa= cebook connect doesn't? > That would provide a big enough improvement over passwords to get people = interested, and it has a viral side to it. As soon as it works for enough p= eople, those people become interested in getting others on board too. I don't see why. Logging into my bank to check my account balance is not on= e of those activities I like to share with friends. This is totally differe= nt from watching a funny video on youtube or pictures of cats with witty re= marks. > With millions or billions of adopters you can create the momentum, and th= e mass market, that will make all the other problems easy to solve. If ther= e were just a million active developers in open source software using PKI e= very day for checking in software and communicating with their peers, you w= ould soon find the technology make its way into every web site, and browser= s being adapted to make their interface easy to use. With mass adoption it = would be much easier to solve all the other technological problems, because= citizens and politicians would have an immediate understanding of what you= were talking about. Again, PKI without a trust relationship with an identity provider can make = some protocols more efficient (compare OpenID to BrowserID) but it doesn't = bring any new security to the table. From prvs=7191e92666=uri@ll.mit.edu Fri Jul 29 07:59:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84AD21F8C53 for ; Fri, 29 Jul 2011 07:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 eju0QeAtQZH7 for ; Fri, 29 Jul 2011 07:59:57 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7D78E21F8C50 for ; Fri, 29 Jul 2011 07:59:56 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p6TExmAf021123; Fri, 29 Jul 2011 10:59:48 -0400 From: "Blumenthal, Uri - 0668 - MITLL" To: "'anders.rundgren@telia.com'" Date: Fri, 29 Jul 2011 10:59:47 -0400 Thread-Topic: [TLS] EU cards Thread-Index: AcxNrXeiSHE2rqByQnqiwpdO1GO6xQAUrELR In-Reply-To: <4E324016.90903@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-07-29_05:2011-07-29, 2011-07-29, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1107290118 Message-Id: <20110729145956.7D78E21F8C50@ietfa.amsl.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] EU cards 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, 29 Jul 2011 14:59:58 -0000 In general I'd disagree - but you've made an excellent point about innovati= on on PC being dead (and therefore no chance to properly secure them while = keeping 'em usable). US DoD is moving along the "secure 'em" axis, thus mak= ing usability suffer (many reasons for that). Thus many bitching end-users = (and some of them actually have reasons to). But overall - comparing what C= AC were expected to do with what they actually do - I'd call it a success b= ecause they _work_, like it or not. (Now OS changes version and fragile mid= dleware quits, some readers aren't supported, etc - overall not a pleasant = picture, but the infrastructure is fine and the capabilities are right.) -- Regards, Uri ----- Original Message ----- From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: Friday, July 29, 2011 01:07 AM=0A= To: Blumenthal, Uri - 0668 - MITLL Cc: 'tls@ietf.org' Subject: Re: [TLS] EU cards On 2011-07-28 21:42, Blumenthal, Uri - 0668 - MITLL wrote: > Anders, >=20 > Where is your data on government cards usage coming from? various mailing lists such as: http://www.opensc-project.org/opensc Most of the people hanging out there are in some way working with the EU ca= rds. >=20 > In US a lot (literally millions) of government email and Web access=20 > is secured by what you call "government cards". I guess you refer to PIV and CAC? There is a fundamental difference between the US and the EU and that only in the EU there is something called "citizen-cards" or eID. Citizens are supposed to buy eID for carrying out secure services on the Internet. The cost have been high; results have been marginal for the reasons I listed (and some more...). Obama's NSTIC is something similar (but still very different) that will be slightly interesting following although I don't think their NIST friends really understand the consumer market and the huge technical issues they will have to deal with. IMO, the PC platform is dead as a vehicle for innovation; they might go to phones from the start. I never understood why you need a picture on a token for Internet access :-) Well, "it has always been like that" is probably the [lame] excuse. Regards, Anders >=20 > -- > Regards, > Uri >=20 > ----- Original Message ----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Thursday, July 28, 2011 03:10 PM > To: Henry Story > Cc: S.tefan Winter ; Martin Gaedke ; tls@ietf.org > Subject: Re: [TLS] EU cards >=20 > Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so > why would the browser vendor bother about how it works? >=20 > Now to the cards: Since > 1. readers is a non-standard item > 2. all cards need different middleware > 3. cannot be fitted with additional certificates > 4. is generally only trusted by a restricted group > 5. commercial CAs require certified RP SW, contracts > this is simply put entirely uninteresting >=20 > The government cards are status projects. We have issued > x millions cards. That they are only used as physical ID-cards > is something they are slightly less open about... >=20 > Banks in Scandinavia put eID on credit-cards which means that > every merchant get your SSN as well (if they want). >=20 > As I say all the time: Google and Apple will make all EU cards look > like they always was: A pile of s--t. >=20 > Anders >=20 > On 2011-07-28 17:07, Henry Story wrote: >> Hi Peter, >> >> You may want to ask Prof. Martin Gaedke about this. He is working his w= ay through the=20 >> EU area on this and should have some good pointers on where these token = cards are=20 >> going around here.=20 >> >> Henry >> >> On 28 Jul 2011, at 16:45, Peter Gutmann wrote: >> >>> Stefan Winter writes: >>> >>>> Banking: These days, TAN lists are going away. >>> >>> Is there any information on what's being done in countries like France,= Italy, >>> the Netherlands, Spain, ...? The only place where it's really document= ed (in >>> quite some detail) is Germany (with surrounding/similar countries like = Austria >>> and Switzerland using equivalent approaches), but what are other countr= ies in >>> Europe doing? There's rather little information *from third parties, n= ot the >>> vendors* publicly available on how e-banking is done in France, Spain, = ..., >>> the pros and cons, how it deals with new attack types, and so on. >>> >>>> a) cell phone transaction numbers: >>> >>> The problem is that mTANs are vulnerable to smartphone malware, as Zeus= has >>> already shown. It's currently a minor threat, but who knows how far th= e bad >>> guys will take it. On the whole though mTANs are a nice tradeoff, you = get to >>> verify the transaction over an independent channel, and the mTAN is a >>> cryptographic hash over the transaction data so if a MITB tries to modi= fy what >>> the browser sends it gets detected. >>> >>> Peter. >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> Social Web Architect >> http://bblfish.net/ >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From marsh@extendedsubset.com Fri Jul 29 08:22:33 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6F11E807A for ; Fri, 29 Jul 2011 08:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccu+Qe-fnxis for ; Fri, 29 Jul 2011 08:22:33 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8511E8072 for ; Fri, 29 Jul 2011 08:22:32 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QmotT-000Flc-67; Fri, 29 Jul 2011 15:22:31 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F34816070; Fri, 29 Jul 2011 15:22:28 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+wK8bt1ljTB+3H0tr7a4PKWgnQkooaCq8= Message-ID: <4E32D033.7020601@extendedsubset.com> Date: Fri, 29 Jul 2011 10:22:27 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: David McGrew References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 15:22:33 -0000 On 07/26/2011 10:01 AM, David McGrew wrote: > > http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 > The ProxyInfo extension only provides information about proxies to > the client; it does not provide any information to the server about > either the client or other proxies on the path. This is acceptable > when there are no client certificates in use, which is (regrettably) > common in practice. It would be possible to generalize the ideas in > this note to also provide information to the server about the client > and other proxies on the path. Nonetheless, that goal is out of > scope for this note. It's good that the draft is explicit about what is not being provided to to the server. But, please, won't somebody think of the poor servers? As someone who works on the security of an authentication service delivered through TLS, I feel the need to oppose the standardization of functionality with the potential to undermine the security of our service. It was once said that the driving purpose of the design of SSL was to make users *feel* secure enough to be comfortable entering their credit card number on the web and I've seen little or no evidence to refute that claim. In this model, all the paranoia is expected to reside with the user. One of the unfortunate artifacts of the resulting design is that the server has no way to prove the nonexistence of a MitM, he can only hope that the client will do a good job of this. We all know how well this works when put to the test by an active attacker. Client certificates are currently the only tool available for server admins to participate in preventing this important class of attacks. The authors of this draft seem to feel the relative infrequency of client certificate usage is "regrettable", yet they propose standardizing a scheme which will break them entirely! Consider, for example, the scenario which was described to me by someone in the retail sector. She was responsible for auditing security policies for a retail credit card website. They interpreted the relevant laws and industry regulations to mean that they were obligated to intercept employee web browser usage to monitor for and block various forms of undesired content. However, employees may also have personal credit cards with the same issuer, the statements of which they might sometimes access from their desk at work. But the organization considered itself forbidden from snooping on that traffic. I don't know if or how they got it sorted out, my point being only that there are several parties involved here and it's not clear at all the circumstances under which one party may have an absolute right to impersonate, decrypt, or MitM the traffic even between its own clients and servers. If you operate a financial or government site, you may be under various legal obligations to ensure that certain information is transmitted only to the intended recipient. Today this is commonly done (weakly) with non-client certificate HTTPS websites. If or when MitM interception becomes standardized and widespread it will obligate the use of client certificates to satisfy this requirement while at the same time breaking their functionality entirely. Any standardization of MitM or interception functionality must take into account the requirements of the server operators as an equal party and stakeholder in the security of the connection. - Marsh From anders.rundgren@telia.com Fri Jul 29 09:21:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8421F8B2B for ; Fri, 29 Jul 2011 09:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 IwJti5Fbz78W for ; Fri, 29 Jul 2011 09:21:20 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6163421F884E for ; Fri, 29 Jul 2011 09:21:20 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E97000B49B9; Fri, 29 Jul 2011 18:21:15 +0200 Message-ID: <4E32DDEB.20600@telia.com> Date: Fri, 29 Jul 2011 18:20:59 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Blumenthal, Uri - 0668 - MITLL" References: <4E1C5F6000A6BF25@smtp-in21.han.skanova.net> (added by postmaster@pne.skanova.net) In-Reply-To: <4E1C5F6000A6BF25@smtp-in21.han.skanova.net> (added by postmaster@pne.skanova.net) X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] EU cards 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, 29 Jul 2011 16:21:21 -0000 On 2011-07-29 16:59, Blumenthal, Uri - 0668 - MITLL wrote: > In general I'd disagree - but you've made an excellent point about innovation on PC being dead (and therefore no chance to properly secure them while keeping 'em usable). US DoD is moving along the "secure 'em" axis, thus making usability suffer (many reasons for that). Thus many bitching end-users (and some of them actually have reasons to). But overall - comparing what CAC were expected to do with what they actually do - I'd call it a success because they _work_, like it or not. (Now OS changes version and fragile middleware quits, some readers aren't supported, etc - overall not a pleasant picture, but the infrastructure is fine and the capabilities are right.) It is a bit unfair comparing an "enterprise" infrastructure that cost huge sums to raise and maintain, with a consumer/citizen scheme lacking any kind of serious client support. As I said, NSTIC will (if actually carried out beyond the policy-definition stage), find that it is a difficult world out there. Having worked for a major token vendor I know the drill: "whatever we do, we must avoid commoditization". This industry have succeed with their to the extent that they will be quite vulnerable to what Google and Apple are doing. Even the venerable SIM-card is slated for extinction. Embedded rocks! The USG as a buyer of technology isn't always an indication of were things are going: http://us.blackberry.com/ataglance/security/products/smartcardreader $200 for an inconvenient card reader! Their hope is that this will be the standard. Not chance in h***. /Anders > > -- > Regards, > Uri > > ----- Original Message ----- > From: Anders Rundgren [mailto:anders.rundgren@telia.com] > Sent: Friday, July 29, 2011 01:07 AM > To: Blumenthal, Uri - 0668 - MITLL > Cc: 'tls@ietf.org' > Subject: Re: [TLS] EU cards > > On 2011-07-28 21:42, Blumenthal, Uri - 0668 - MITLL wrote: >> Anders, >> >> Where is your data on government cards usage coming from? > various mailing lists such as: > http://www.opensc-project.org/opensc > > Most of the people hanging out there are in some way working with the EU cards. > >> In US a lot (literally millions) of government email and Web access >> is secured by what you call "government cards". > I guess you refer to PIV and CAC? > There is a fundamental difference between the US and the EU and that > only in the EU there is something called "citizen-cards" or eID. > > Citizens are supposed to buy eID for carrying out secure services on > the Internet. The cost have been high; results have been marginal > for the reasons I listed (and some more...). > > Obama's NSTIC is something similar (but still very different) that > will be slightly interesting following although I don't think > their NIST friends really understand the consumer market and > the huge technical issues they will have to deal with. > > IMO, the PC platform is dead as a vehicle for innovation; they > might go to phones from the start. I never understood why > you need a picture on a token for Internet access :-) > > Well, "it has always been like that" is probably the [lame] excuse. > > Regards, > Anders > >> -- >> Regards, >> Uri >> >> ----- Original Message ----- >> From: Anders Rundgren [mailto:anders.rundgren@telia.com] >> Sent: Thursday, July 28, 2011 03:10 PM >> To: Henry Story >> Cc: S.tefan Winter ; Martin Gaedke ; tls@ietf.org >> Subject: Re: [TLS] EU cards >> >> Dropping HTTPS CCA, it will never leave the 0.1% slot anyway so >> why would the browser vendor bother about how it works? >> >> Now to the cards: Since >> 1. readers is a non-standard item >> 2. all cards need different middleware >> 3. cannot be fitted with additional certificates >> 4. is generally only trusted by a restricted group >> 5. commercial CAs require certified RP SW, contracts >> this is simply put entirely uninteresting >> >> The government cards are status projects. We have issued >> x millions cards. That they are only used as physical ID-cards >> is something they are slightly less open about... >> >> Banks in Scandinavia put eID on credit-cards which means that >> every merchant get your SSN as well (if they want). >> >> As I say all the time: Google and Apple will make all EU cards look >> like they always was: A pile of s--t. >> >> Anders >> >> On 2011-07-28 17:07, Henry Story wrote: >>> Hi Peter, >>> >>> You may want to ask Prof. Martin Gaedke about this. He is working his way through the >>> EU area on this and should have some good pointers on where these token cards are >>> going around here. >>> >>> Henry >>> >>> On 28 Jul 2011, at 16:45, Peter Gutmann wrote: >>> >>>> Stefan Winter writes: >>>> >>>>> Banking: These days, TAN lists are going away. >>>> Is there any information on what's being done in countries like France, Italy, >>>> the Netherlands, Spain, ...? The only place where it's really documented (in >>>> quite some detail) is Germany (with surrounding/similar countries like Austria >>>> and Switzerland using equivalent approaches), but what are other countries in >>>> Europe doing? There's rather little information *from third parties, not the >>>> vendors* publicly available on how e-banking is done in France, Spain, ..., >>>> the pros and cons, how it deals with new attack types, and so on. >>>> >>>>> a) cell phone transaction numbers: >>>> The problem is that mTANs are vulnerable to smartphone malware, as Zeus has >>>> already shown. It's currently a minor threat, but who knows how far the bad >>>> guys will take it. On the whole though mTANs are a nice tradeoff, you get to >>>> verify the transaction over an independent channel, and the mTAN is a >>>> cryptographic hash over the transaction data so if a MITB tries to modify what >>>> the browser sends it gets detected. >>>> >>>> Peter. >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>> Social Web Architect >>> http://bblfish.net/ >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > From ynir@checkpoint.com Fri Jul 29 09:52:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781A321F86C1 for ; Fri, 29 Jul 2011 09:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 IH2PFxVrntz1 for ; Fri, 29 Jul 2011 09:52:39 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 480425E8010 for ; Fri, 29 Jul 2011 09:52:37 -0700 (PDT) X-CheckPoint: {4E32F2E2-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p6TGqTli001365; Fri, 29 Jul 2011 19:52:29 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 29 Jul 2011 19:52:29 +0300 From: Yoav Nir To: Marsh Ray Date: Fri, 29 Jul 2011 19:52:28 +0300 Thread-Topic: [TLS] TLS Proxy Server Extension Thread-Index: AcxOD+Zl7FILufsgSIiEaCudlcv3Mg== Message-ID: <7F97B097-BF00-432E-849E-D6DCA6DA470E@checkpoint.com> References: <4E32D033.7020601@extendedsubset.com> In-Reply-To: <4E32D033.7020601@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 16:52:42 -0000 On Jul 29, 2011, at 11:22 AM, Marsh Ray wrote: > On 07/26/2011 10:01 AM, David McGrew wrote: >>=20 >> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 >=20 >> The ProxyInfo extension only provides information about proxies to >> the client; it does not provide any information to the server about >> either the client or other proxies on the path. This is acceptable >> when there are no client certificates in use, which is (regrettably) >> common in practice. It would be possible to generalize the ideas in >> this note to also provide information to the server about the client >> and other proxies on the path. Nonetheless, that goal is out of >> scope for this note. >=20 > It's good that the draft is explicit about what is not being provided to > to the server. >=20 > But, please, won't somebody think of the poor servers? >=20 > As someone who works on the security of an authentication service > delivered through TLS, I feel the need to oppose the standardization of > functionality with the potential to undermine the security of our service= . This draft does not invent TLS proxies or even standardize them. It invents= a way for the client to recover some of the information that is lost becau= se of the existing use of TLS proxies. > It was once said that the driving purpose of the design of SSL was to > make users *feel* secure enough to be comfortable entering their credit > card number on the web and I've seen little or no evidence to refute > that claim. In this model, all the paranoia is expected to reside with > the user. >=20 > One of the unfortunate artifacts of the resulting design is that the > server has no way to prove the nonexistence of a MitM, he can only hope > that the client will do a good job of this. We all know how well this > works when put to the test by an active attacker. Client certificates > are currently the only tool available for server admins to participate > in preventing this important class of attacks. The authors of this draft > seem to feel the relative infrequency of client certificate usage is > "regrettable", yet they propose standardizing a scheme which will break > them entirely! I can see how this draft could be extended to support client certificates, = but that would require changes to the server as well, and a change to the s= tate machine that elevates this draft in the new taxonomy from "trivial" to= "significant", so we probably don't want that at all. But client certificates are already broken now behind a TLS proxy. This dra= ft does not make this worse. It does mean that other things that got broken= , like HSTS and EV can be unbroken. > Consider, for example, the scenario which was described to me by someone > in the retail sector. She was responsible for auditing security policies > for a retail credit card website. They interpreted the relevant laws and > industry regulations to mean that they were obligated to intercept > employee web browser usage to monitor for and block various forms of > undesired content. However, employees may also have personal credit > cards with the same issuer, the statements of which they might sometimes > access from their desk at work. But the organization considered itself > forbidden from snooping on that traffic. >=20 > I don't know if or how they got it sorted out, my point being only that > there are several parties involved here and it's not clear at all the > circumstances under which one party may have an absolute right to > impersonate, decrypt, or MitM the traffic even between its own clients > and servers. Operating a MitM requires issuing fake certificates from a CA that is not t= rusted by any browser out of the box. The user will get the warning message= s from the browser unless they choose to trust this CA, or are required to = do so by company policy. In both cases the existence of the MitM is known t= o the user. I agree that there is an ethical issue with having the CA certi= ficate pre-installed on the "company laptop" without telling the user. >=20 > If you operate a financial or government site, you may be under various > legal obligations to ensure that certain information is transmitted only > to the intended recipient. Today this is commonly done (weakly) with > non-client certificate HTTPS websites. If or when MitM interception > becomes standardized and widespread it will obligate the use of client > certificates to satisfy this requirement while at the same time breaking > their functionality entirely. That's the beauty of this draft. If MitM boxes support it, it will expose (= to the browser) the existence of a MitM even without user certificates. May= be WebSec should standardize a header that says "no-tls-proxies". A client = that detects a proxy and receives this header breaks the connection and sho= ws a red warning screen. Fortunately today many people have an alternative to "company network". If = the company network has a MitM and you don't want it to see your credit car= d number or scan the attachments you get to your gmail account, just surf f= rom your phone. Just as you would call from your phone if the company may l= isten in on phone conversations. > Any standardization of MitM or interception functionality must take into > account the requirements of the server operators as an equal party and > stakeholder in the security of the connection. Stealthy MitM are possible today with company computers without any standar= dization effort by the IETF. We can make it possible for clients and MitM t= o play nice - inform the browser, etc. Yoav= From marsh@extendedsubset.com Fri Jul 29 11:33:37 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAA621F8B94 for ; Fri, 29 Jul 2011 11:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xfg1Ip5PY24z for ; Fri, 29 Jul 2011 11:33:36 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 04CF421F8B95 for ; Fri, 29 Jul 2011 11:33:36 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QmrsM-000LNx-Ek; Fri, 29 Jul 2011 18:33:34 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id ECEBD607A; Fri, 29 Jul 2011 18:33:32 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+diE37RwSIjVKuSF/aGSEOOmqp2WYa6V0= Message-ID: <4E32FCFA.3050808@extendedsubset.com> Date: Fri, 29 Jul 2011 13:33:30 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Yoav Nir References: <4E32D033.7020601@extendedsubset.com> <7F97B097-BF00-432E-849E-D6DCA6DA470E@checkpoint.com> In-Reply-To: <7F97B097-BF00-432E-849E-D6DCA6DA470E@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Philip Gladstone , David McGrew , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 18:33:37 -0000 On 07/29/2011 11:52 AM, Yoav Nir wrote: > > This draft does not invent TLS proxies or even standardize them. The IETF defines no such thing as a "TLS proxy". I don't even see how such a thing can be defined without violating some basic guarantees of the protocol, but I'm open to being educated on that. > It invents a way for the client to recover some of the information that > is lost because of the existing use of TLS proxies. I'm really sympathetic to the necessity of the lesser evil in practice. But "TLS proxies" currently work poorly today because they are underspecified and they violate certain protocol assumptions. Sometimes they end up weakening security and breaking higher-layer stuff. > I can see how this draft could be extended to support client > certificates, but that would require changes to the server as well, > and a change to the state machine that elevates this draft in the new > taxonomy from "trivial" to "significant", That would be a good thing in my view because the underlying changes actually are significant. > so we probably don't want > that at all. But client certificates are already broken now behind a > TLS proxy. What is this "TLS proxy" of which you speak? I see no SHOULDs or MUSTs or which apply to it, much less any cryptographic guarantees about it. More importantly, what is its security model? All I see usually amounts to "convince the client to install our trusted root and then the MitM can get away with almost anything". Perhaps this draft is admirable in that it defines a mechanism with which the MitM MAY choose to communicate certain info to the client, but I feel it is handwaving over the deeper questions and tacking features on top of an architecture which isn't really defined at all. > This draft does not make this worse. But it does, it endorses the brokenness as a protocol standard. > It does mean that > other things that got broken, like HSTS and EV can be unbroken. TLS is being changed at a fundamental level, it's not a little tweak that just needs a little tweak to change it. > Operating a MitM requires issuing fake certificates from a CA that is > not trusted by any browser out of the box. Has anyone ever asked the rightful domain holders how they might feel about someone minting certificates with their name on them? > The user will get the > warning messages from the browser unless they choose to trust this > CA, or are required to do so by company policy. In both cases the > existence of the MitM is known to the user. Right, it's TLS operating properly as designed to prevent MitM attacks. If only TLS had been designed such that the server could resist them as well! > I agree that there is an > ethical issue with having the CA certificate pre-installed on the > "company laptop" without telling the user. Honestly, I don't see that as the big issue in general. Such laptops commonly have a wide variety of spyware installed already and employees should have no expectation of privacy on it, IMHO. But note that the web site being accessed is not a party to that employment contract! Lying to the web browser about the authenticity of the server's identity could be viewed as lying to the server about the absence of a MitM. Oh what a tangled web we weave! > That's the beauty of this draft. If MitM boxes support it, it will > expose (to the browser) the existence of a MitM even without user > certificates. Couldn't that be done today without a protocol change by looking at the issuer? > Maybe WebSec should standardize a header that says > "no-tls-proxies". A client that detects a proxy and receives this > header breaks the connection and shows a red warning screen. Why wouldn't the MitM simply strip the header while he was at it? > Fortunately today many people have an alternative to "company > network". If the company network has a MitM and you don't want it to > see your credit card number or scan the attachments you get to your > gmail account, just surf from your phone. Just as you would call from > your phone if the company may listen in on phone conversations. I agree that the best course of action for the user is to use a network which does not have a MitM policy (or possibly establish a secure tunnel to one). > Stealthy MitM are possible today with company computers without any > standardization effort by the IETF. We can make it possible for > clients and MitM to play nice - inform the browser, etc. I don't want them to play nice. They're broken now because they violate a fundamental principle of the security model: clients trust CAs to accurately represent the identity of the target domain (don't laugh :-). Making them 'play nice' appears to reduce my effective security as a server operator. - Marsh From mcgrew@cisco.com Fri Jul 29 12:32:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4195E801A for ; Fri, 29 Jul 2011 12:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.285, 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 aqkAfm18bR2g for ; Fri, 29 Jul 2011 12:32:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8482D5E8011 for ; Fri, 29 Jul 2011 12:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2638; q=dns/txt; s=iport; t=1311967969; x=1313177569; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=kMf6SjgWcYZQQ/45g/bvaqbjaC5+ENHsUm9rFnhKnzY=; b=N2YRF9J9P+z/KGLL+UN/5m/8/ilfPgemIFvUqpUS3iE2po7yWxvig2TY Gb8DgTnNYcRFisRVl1ZYTYwbn/E0QOfswwaKb3+aYeJP6aOCxABXUIUi8 f2f5Cf7fR5bm1+cEWKyOYCCYVwyiLxf3rtpsRpZmCYbNJ5tvqUIHsJ1M6 w=; X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7897144" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 29 Jul 2011 19:32:48 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TJWlBP023800; Fri, 29 Jul 2011 19:32:47 GMT Message-Id: <15A155F5-2F01-408A-AA0F-3AA834C335F3@cisco.com> From: David McGrew To: mrex@sap.com In-Reply-To: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jul 2011 12:32:46 -0700 References: <201107271817.p6RIHHrf000819@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 19:32:50 -0000 Hi Martin, On Jul 27, 2011, at 11:17 AM, Martin Rex wrote: > Matt McCutchen wrote: >> >> On Tue, 2011-07-26 at 08:01 -0700, David McGrew wrote: >>> I would like to request feedback on a new draft that Philip >>> Gladstone >>> and I put together, which aims to solve some of the security >>> problems >>> that happen when there is a (HTTP) proxy present and TLS is in use. >> >> It doesn't seem that this work is in any way specific to HTTP. > > Only for Web-Browser scenario can I personally see a very limited > value that does not amount to 100% wiretapping. > > Are you aware of rfc2804 "IETF Policy on Wiretapping"? > > http://tools.ietf.org/html/rfc2804 > > Standardizing MITM attacks on TLS-protected communication > ("lawful intercept?") seems like an extremely bad idea to me. Standardizing MITM attacks would be awful, but that's not at all what the draft is proposing. > > Checking whether some data conforms to a certain company policy will > almost always be illegal in European countries, where we have > sensible data protection laws. Firewalls are illegal in Europe? That can't be right. IANAL, but it appears that the approach of the draft (which notifies the client about the presence of a proxy, as well as provides info on the server) could help to meet the EU Data Protection Directive, in that it informs the data subject when his/her personal data are being processed by a proxy, a condition that must be met in some cases. >> >> >> - One approach would be to do a real escrowed TLS where the client >> negotiates directly with the server but releases the >> confidentiality key >> and optionally also the integrity key to the proxy. This subsumes >> all >> of the above concerns but doesn't allow the proxy to manipulate the >> handshake in any finer way than blocking the connection if it doesn't >> like the outcome. > > For the purpose of "centralized malware screening", for the incoming > Web traffic of Web Browsers that are well known to interpret such > data in arbitrarily stupid ways (such as active content, img src, > (i)frame, > javascript, css), sharing the encryption traffic keys with the Proxy > would be perfectly sufficient, and that also enables the clients > to clearly limit who is able to read the traffic. No super-CA- > equivalent > keys would need to be on the malware-scanning Proxy. > > In what way is a protocol that propagates secret keys to a proxy any better with regard to privacy? Note that if such a protocol is used by a server, then the client is not informed. David From mcgrew@cisco.com Fri Jul 29 12:33:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8985E8011 for ; Fri, 29 Jul 2011 12:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=-0.259, 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 8d-C4SEpfuLL for ; Fri, 29 Jul 2011 12:33:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D84315E801D for ; Fri, 29 Jul 2011 12:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1839; q=dns/txt; s=iport; t=1311968014; x=1313177614; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=giZuAUJZP4UG6Ouk2ydZrw5APcMt57sevlVOJTyFrug=; b=V5MS1HP2+yKlv0Inn47mWX+AYyp6Wm/ZliJHLcu7T9MuOsaXjBb2mcl/ fBDtbFBtG7AtgvwTLKnN+KGKwu4pFdlA1tQ02PYUjQXPz0eiyBt+ebmUz tkNjcV/NCL5Bd7t/AhS1cTasVW9XnxNUX4EhAc1Nqi3sNFzoVUhE+r9c3 o=; X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7896042" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-2.cisco.com with ESMTP; 29 Jul 2011 19:33:33 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TJWlBQ023800; Fri, 29 Jul 2011 19:33:32 GMT Message-Id: From: David McGrew To: mrex@sap.com In-Reply-To: <201107290621.p6T6Lckb004132@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jul 2011 12:33:31 -0700 References: <201107290621.p6T6Lckb004132@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 19:33:43 -0000 Hi Martin, On Jul 28, 2011, at 11:21 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >>> and that also enables the clients >>> to clearly limit who is able to read the traffic. >> >> Huh? The proxy's ability to pass decrypted data to someone else is >> no >> different than if it were bridging two TLS connections. > > No, that is entirely different. > > Revealing the traffic **encryption** keys to the proxy requires > cooperation > of the client, so a sensible client implementation can ask for consent > and the user may deny consent, whereas a proxy with a super-CA-cert > can subvert any connection for that client, no matter where that > client goes--and MitM all connections any time, including those that > do > not traverse that proxy. It sounds like you misunderstand the proposal. The approach we are going for is one in which the client is fully informed about both the proxy and the server, and the client is free to choose to trust them or not. > > >> >>> No super-CA-equivalent >>> keys would need to be on the malware-scanning Proxy. >> >> You speak as if that were in a whole different class of badness, >> but the >> actual effect is simply to give up integrity as well as >> confidentiality >> to the proxy. > > You would not reveal the MAC keys, of course. only the encryption > keys. > > There is no need to allow the proxy to modify the traffic. If the > proxy doesn't like some of the data, it should not pass it along and > terminate the connection. > > -Martin No, this undermines the cryptographic security. Please see Section 6 of the draft. A malware-screening proxy needs to be able to modify the traffic flowing through it. It would be pointless for it to detect malware, and then pass it on to the client! David From mcgrew@cisco.com Fri Jul 29 13:00:31 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8389821F86AA for ; Fri, 29 Jul 2011 13:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.837 X-Spam-Level: X-Spam-Status: No, score=-102.837 tagged_above=-999 required=5 tests=[AWL=-0.238, 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 a9afNeIWzOuo for ; Fri, 29 Jul 2011 13:00:30 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8E50321F86A4 for ; Fri, 29 Jul 2011 13:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=4881; q=dns/txt; s=iport; t=1311969630; x=1313179230; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=cl4qHHuB1tw8UpIKF4ShQv6ZRo6aUIEZQ5It+VBon2g=; b=H4pj7gjHXjTQ1J87EU7pGQy2+oBXc/H+NC886ZXbFm8m+YFtgx798sdv wOUWNpp6g/q/WkGU+rbkZBEnfBszYcGNNpNO6qch3/j47IpxrYw3H18km 2zHO/WK4JOdybAYHP2fMaSb/KsXKNHAeoxrJ0t58KQD78IOdAGKqGvv0o k=; X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7904040" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 29 Jul 2011 20:00:29 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TK0S1k008264; Fri, 29 Jul 2011 20:00:28 GMT Message-Id: <13649A96-FC0E-4DA6-99DA-C49E20AD9421@cisco.com> From: David McGrew To: Marsh Ray In-Reply-To: <4E32D033.7020601@extendedsubset.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jul 2011 13:00:28 -0700 References: <4E32D033.7020601@extendedsubset.com> X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 20:00:31 -0000 Hi Marsh, On Jul 29, 2011, at 8:22 AM, Marsh Ray wrote: > On 07/26/2011 10:01 AM, David McGrew wrote: >> >> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 > >> The ProxyInfo extension only provides information about proxies to >> the client; it does not provide any information to the server about >> either the client or other proxies on the path. This is acceptable >> when there are no client certificates in use, which is (regrettably) >> common in practice. It would be possible to generalize the ideas in >> this note to also provide information to the server about the client >> and other proxies on the path. Nonetheless, that goal is out of >> scope for this note. > > It's good that the draft is explicit about what is not being > provided to > to the server. > > But, please, won't somebody think of the poor servers? > > As someone who works on the security of an authentication service > delivered through TLS, I feel the need to oppose the standardization > of > functionality with the potential to undermine the security of our > service. > > It was once said that the driving purpose of the design of SSL was to > make users *feel* secure enough to be comfortable entering their > credit > card number on the web and I've seen little or no evidence to refute > that claim. In this model, all the paranoia is expected to reside with > the user. > > One of the unfortunate artifacts of the resulting design is that the > server has no way to prove the nonexistence of a MitM, he can only > hope > that the client will do a good job of this. We all know how well this > works when put to the test by an active attacker. Client certificates > are currently the only tool available for server admins to participate > in preventing this important class of attacks. The authors of this > draft > seem to feel the relative infrequency of client certificate usage is > "regrettable", yet they propose standardizing a scheme which will > break > them entirely! Important clarification: we have not proposed any standards action, we have requested comments on a draft. I felt that the approach outlined in the draft deserved to be discussed even though it does not address the issue of client authentication to the server. I would strongly prefer a solution that works with client certificates, if one can be worked out. (I think the ideal security goal here would be something like three-party mutual authentication and authentication checking. If we are willing to be invasive to TLS, we could do something like that. If C/S/P each issued nonces and signed all of the nonces, that would get us most of the way there. That sounds like an interesting design exercise, but I am skeptical that we could get broad deployment. How close we can get to that goal is something worth exploring.) In the absence of a client certificate, the proxy extension does improve security, because it restores server authentication and authorization, and that operation is essential when the client is using password-based authentication to the server. David > > Consider, for example, the scenario which was described to me by > someone > in the retail sector. She was responsible for auditing security > policies > for a retail credit card website. They interpreted the relevant laws > and > industry regulations to mean that they were obligated to intercept > employee web browser usage to monitor for and block various forms of > undesired content. However, employees may also have personal credit > cards with the same issuer, the statements of which they might > sometimes > access from their desk at work. But the organization considered itself > forbidden from snooping on that traffic. > > I don't know if or how they got it sorted out, my point being only > that > there are several parties involved here and it's not clear at all the > circumstances under which one party may have an absolute right to > impersonate, decrypt, or MitM the traffic even between its own clients > and servers. > > If you operate a financial or government site, you may be under > various > legal obligations to ensure that certain information is transmitted > only > to the intended recipient. Today this is commonly done (weakly) with > non-client certificate HTTPS websites. If or when MitM interception > becomes standardized and widespread it will obligate the use of client > certificates to satisfy this requirement while at the same time > breaking > their functionality entirely. > > Any standardization of MitM or interception functionality must take > into > account the requirements of the server operators as an equal party and > stakeholder in the security of the connection. > > - Marsh From mcgrew@cisco.com Fri Jul 29 13:42:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A2E5E8016 for ; Fri, 29 Jul 2011 13:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.818 X-Spam-Level: X-Spam-Status: No, score=-102.818 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 K2KHxWwyeuVd for ; Fri, 29 Jul 2011 13:42:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 764215E8028 for ; Fri, 29 Jul 2011 13:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=2636; q=dns/txt; s=iport; t=1311972147; x=1313181747; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=Pghry9DLs8Ggt4GkXTfprmbJUxzjyOZqP2Ad4s7EC/w=; b=BKYd5EFObH1kfsu1r9iw5boD/SkwR92p+yVeYX0Kbcm/OxMqq0Mqbb1N fPM208nENXljDdMeu9Zu5b/4cBaIwmAQToezFUx6tibKwN51ia/nlz9VY cYdttfab44j8aCRDqsgGUjXlk+fBMVhXjVAvxY57do+IVdSZMuXSE212T M=; X-IronPort-AV: E=Sophos;i="4.67,288,1309737600"; d="scan'208";a="7918027" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2011 20:42:26 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6TKgOxx019094; Fri, 29 Jul 2011 20:42:24 GMT Message-Id: <68B86175-4A5D-4B4D-B995-D498A42F3973@cisco.com> From: David McGrew To: Marsh Ray In-Reply-To: <4E32FCFA.3050808@extendedsubset.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jul 2011 13:42:23 -0700 References: <4E32D033.7020601@extendedsubset.com> <7F97B097-BF00-432E-849E-D6DCA6DA470E@checkpoint.com> <4E32FCFA.3050808@extendedsubset.com> X-Mailer: Apple Mail (2.936) Cc: Philip Gladstone , "tls@ietf.org" Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 20:42:29 -0000 Hi Marsh, On Jul 29, 2011, at 11:33 AM, Marsh Ray wrote: > On 07/29/2011 11:52 AM, Yoav Nir wrote: >> >> This draft does not invent TLS proxies or even standardize them. > > The IETF defines no such thing as a "TLS proxy". I don't even see > how such a thing can be defined without violating some basic > guarantees of the protocol, but I'm open to being educated on that. > >> It invents a way for the client to recover some of the information >> that >> is lost because of the existing use of TLS proxies. > > I'm really sympathetic to the necessity of the lesser evil in > practice. > > But "TLS proxies" currently work poorly today because they are > underspecified and they violate certain protocol assumptions. > Sometimes they end up weakening security and breaking higher-layer > stuff. > >> I can see how this draft could be extended to support client >> certificates, but that would require changes to the server as well, >> and a change to the state machine that elevates this draft in the new >> taxonomy from "trivial" to "significant", > > That would be a good thing in my view because the underlying changes > actually are significant. > >> so we probably don't want >> that at all. But client certificates are already broken now behind a >> TLS proxy. > > What is this "TLS proxy" of which you speak? I see no SHOULDs or > MUSTs or which apply to it, much less any cryptographic guarantees > about it. > > More importantly, what is its security model? Some appropriate security goals are outlined in Section 6. They are client-oriented; as you pointed out, ideally the server would gain some assurances about the client as well. > > All I see usually amounts to "convince the client to install our > trusted root and then the MitM can get away with almost anything". > Perhaps this draft is admirable in that it defines a mechanism with > which the MitM MAY choose to communicate certain info to the client, > but I feel it is handwaving over the deeper questions and tacking > features on top of an architecture which isn't really defined at all. I would be interested to hear your thoughts on what sort of architecture would be good. It might be appropriate to have the certificate held by the proxy have an attribute that states that it is a proxy. An attribute could be used to limit the scope of the proxy as well, based on e.g. DNS. That sort of mechanism would ensure that a proxy would be known to the client; it couldn't hide its presence just by not sending the TLS Proxy Extension. David From mrex@sap.com Fri Jul 29 13:45:05 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978355E801A for ; Fri, 29 Jul 2011 13:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.905 X-Spam-Level: X-Spam-Status: No, score=-9.905 tagged_above=-999 required=5 tests=[AWL=0.344, 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 VuyprDhPv5zR for ; Fri, 29 Jul 2011 13:45:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 401DE5E8016 for ; Fri, 29 Jul 2011 13:44:59 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6TKioAL011808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 22:44:55 +0200 (MEST) From: Martin Rex Message-Id: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 29 Jul 2011 22:44:49 +0200 (MEST) In-Reply-To: <1311915090.2035.36.camel@localhost> from "Matt McCutchen" at Jul 29, 11 00:51:30 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: pgladstone@cisco.com, mcgrew@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 20:45:05 -0000 Matt McCutchen wrote: > > On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote: > > Only for Web-Browser scenario can I personally see a very limited > > value that does not amount to 100% wiretapping. > > > > Are you aware of rfc2804 "IETF Policy on Wiretapping"? > > > > http://tools.ietf.org/html/rfc2804 > > > > Standardizing MITM attacks on TLS-protected communication > > ("lawful intercept?") seems like an extremely bad idea to me. > > This is not wiretapping as defined in that policy. I *STRONGLY* disagree. That is very much about wiretapping and even goes far beyond that, because it not only reveals the content of the communication, it also allows the "TLS proxy" to arbitrarily manipulate the communication in a fashion that might be entirely concealed to the communication peers at the end. I am strongly opposed to have any document describing such proxies published as an RFC! -Martin From wtc@google.com Fri Jul 29 14:17:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F0311E80AB for ; Fri, 29 Jul 2011 14:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 hctVtMASniyT for ; Fri, 29 Jul 2011 14:17:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9A57921F8AD9 for ; Fri, 29 Jul 2011 14:17:40 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p6TLHdQe018956 for ; Fri, 29 Jul 2011 14:17:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311974260; bh=LhjrTJcEcumTK2Rr0P1ktGlsHN8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=s4zDhSZW6XqltLRzVI2JbkoFTGEvMrzIkSyjTTNIc1ZcO0g4eVE/pcCz5KR6JNjC1 UtzUxkvZuwzooMR3R4dMg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=cbuhrAaw/Zuo2372PbzBPG3gTaOLX8sidNIU9J9Du4w7jGm9ep3ec0XMNetJ1Jw9j oVY7d9F9XRbUOz9NvKOBg== Received: from qwk3 (qwk3.prod.google.com [10.241.195.131]) by kpbe19.cbf.corp.google.com with ESMTP id p6TLHche010061 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 29 Jul 2011 14:17:38 -0700 Received: by qwk3 with SMTP id 3so2814984qwk.33 for ; Fri, 29 Jul 2011 14:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3JPql8t9VvOPTm4iRbfYahO+63fz8ulb/M6Mebc12LE=; b=eZ31I6TA8upP3+NSVYgGOSfQxZS+7edIWdyuWu7bY2+QVwLilSWHoWH2j7CpVhCP1p xvaNcbWLx0osm8i7iC3w== Received: by 10.229.68.141 with SMTP id v13mr690153qci.64.1311974258066; Fri, 29 Jul 2011 14:17:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.141 with SMTP id v13mr690146qci.64.1311974257908; Fri, 29 Jul 2011 14:17:37 -0700 (PDT) Received: by 10.229.77.195 with HTTP; Fri, 29 Jul 2011 14:17:37 -0700 (PDT) In-Reply-To: <4E2D71DB.6020604@telia.com> References: <4E2D5C63.3000408@telia.com> <4E2D688E.5030509@telia.com> <4E2D71DB.6020604@telia.com> Date: Fri, 29 Jul 2011 14:17:37 -0700 Message-ID: From: Wan-Teh Chang To: Anders Rundgren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers 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, 29 Jul 2011 21:17:45 -0000 On Mon, Jul 25, 2011 at 6:38 AM, Anders Rundgren wrote: > > On my wife's firefox the bank have deployed two certs and > both of the show up when she is going to login. =A0If she > takes the one marked "non-repudiation" you get a security > error that only experts understand. Anders, Could you email me those two certs, or tell me their key types (RSA, DSA, or elliptic curve) and the "key usage" and "extended key usage" extensions? I will take a look at the Firefox code that filters client certificates for SSL client authentication. I think the filtering algorithm should be: 1. If the key usage extension exists, it must contain the digitalSignature bit (for the TLS rsa_sign, dsa_sign, and ecdsa_sign client certificate types). 2. If the extended usage extension exists, it must contain the id-kp-clientAuth (TLS WWW client authentication) purpose. Note: this implies if neither the key usage nor the extended key usage extension exists, the certificate may be used for SSL client authentication. Do you agree? Thanks, Wan-Teh Chang From mcgrew@cisco.com Fri Jul 29 15:24:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5364B11E80B8 for ; Fri, 29 Jul 2011 15:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.803 X-Spam-Level: X-Spam-Status: No, score=-102.803 tagged_above=-999 required=5 tests=[AWL=-0.204, 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 E+fsqSDI8T0F for ; Fri, 29 Jul 2011 15:24:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A7BDE11E8095 for ; Fri, 29 Jul 2011 15:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=1685; q=dns/txt; s=iport; t=1311978251; x=1313187851; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=pwmxsBfayqYoYjerMv07nGWL61ZMuhm5GQ+x9UVc6O4=; b=YCp6CZaeZA5iekNBEWe/NWY2rl6qsXt/e4WQiPiTx46jG48OOCcfpnjN bzxb5Qb0ZEgKYDEe6+mxYhGbWvmA65CcTVlY6fHWlhHhHltDZJI3cgdz6 06+QqIiaOrBSusCxl0P2c03+hAcJ5bVicibWfjvu1vaGWFIx8kfm663v9 s=; X-IronPort-AV: E=Sophos;i="4.67,289,1309737600"; d="scan'208";a="7938176" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jul 2011 22:24:11 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6TMO9wM012491; Fri, 29 Jul 2011 22:24:10 GMT Message-Id: From: David McGrew To: mrex@sap.com In-Reply-To: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 29 Jul 2011 15:24:09 -0700 References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension 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, 29 Jul 2011 22:24:16 -0000 On Jul 29, 2011, at 1:44 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >> On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote: >>> Only for Web-Browser scenario can I personally see a very limited >>> value that does not amount to 100% wiretapping. >>> >>> Are you aware of rfc2804 "IETF Policy on Wiretapping"? >>> >>> http://tools.ietf.org/html/rfc2804 >>> >>> Standardizing MITM attacks on TLS-protected communication >>> ("lawful intercept?") seems like an extremely bad idea to me. >> >> This is not wiretapping as defined in that policy. > Right, it's clearly not wiretapping as per RFC 2804: "Wiretapping is what occurs when information passed across the Internet from one party to one or more other parties is delivered to a third party: 1. Without the sending party knowing about the third party ..." The intent of the work we are discussing is to ensure that the client knows about the third party. > > I *STRONGLY* disagree. That is very much about wiretapping and > even goes far beyond that, because it not only reveals the content > of the communication, it also allows the "TLS proxy" to arbitrarily > manipulate the communication in a fashion that might be entirely > concealed to the communication peers at the end. > > > I am strongly opposed to have any document describing such proxies > published as an RFC! > And yet you would favor a protocol that propagates decryption keys around the network? We don't have a choice about whether or not TLS proxying will be done on the Internet; it is being done. What we can choose is whether or not the IETF improves how it is being done. David From mrex@sap.com Fri Jul 29 16:27:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C91E21F898E for ; Fri, 29 Jul 2011 16:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.909 X-Spam-Level: X-Spam-Status: No, score=-9.909 tagged_above=-999 required=5 tests=[AWL=0.340, 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 F-Qay9BeOe9g for ; Fri, 29 Jul 2011 16:27:02 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0690121F8AF7 for ; Fri, 29 Jul 2011 16:27:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6TNQwHg020359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jul 2011 01:26:58 +0200 (MEST) From: Martin Rex Message-Id: <201107292326.p6TNQvGT001711@fs4113.wdf.sap.corp> To: mcgrew@cisco.com (David McGrew) Date: Sat, 30 Jul 2011 01:26:57 +0200 (MEST) In-Reply-To: from "David McGrew" at Jul 29, 11 12:33:31 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 23:27:03 -0000 David McGrew wrote: > > Martin Rex wrote: > > > > You would not reveal the MAC keys, of course. only the encryption keys. > > > > There is no need to allow the proxy to modify the traffic. If the > > proxy doesn't like some of the data, it should not pass it along and > > terminate the connection. > > No, this undermines the cryptographic security. > Please see Section 6 of the draft. I'm having some difficulties understanding Section 6, but some of what is described is clearly bogus and some clearly wrong. Cryptographic security of the TLS protocol is clearly unaffected from sharing the traffic encryption keys with the proxy. What happens is that the proxy may remove confidentiality of the data and look at the data before passing along the original, encrypted data the the rightful communication peer. It is a design property of the TLS protocol that having access to the traffic encryption keys does not allow _you_ to subvert other characteristics of the protocol beyond the confidentiality. > > A malware-screening proxy needs to be able to modify the traffic > flowing through it. It would be pointless for it to detect malware, > and then pass it on to the client! Huh? The peer does not get anything that the proxy does not forward. And if there is something goofy. the proxy simply terminates the connection (both connection. that to the real server and that to the real client). Proxies MUST NOT change a single bit of the data stream, any capability to modify the communication without the receiver aborting the connection because of a data integrity violation would mean that you have _completely_ subvert the security of the whole system, and there would exist no technical limits to arbitrary and fully covert modifications. > > Revealing the traffic **encryption** keys to the proxy requires > > cooperation of the client, so a sensible client implementation > > can ask for consent and the user may deny consent, whereas a proxy > > with a super-CA-cert can subvert any connection for that client, > > no matter where that client goes--and MitM all connections any time, > > including those that do not traverse that proxy. > > It sounds like you misunderstand the proposal. The approach we are > going for is one in which the client is fully informed about both the > proxy and the server, and the client is free to choose to trust them > or not. "The client (should) know(s) about it" is not a legally valid escape from the obligations for data privacy and data integrity guaranteed by the our constitution and the data protection laws, at least not here in Germany. For the purpose of malware screening, the proxy having only the traffic encryption keys is perfectly sufficient. And because it is perfectly sufficient, the MAC keys fall under constitutional protection and requesting them would be unlawful. A little more than three years ago our constitutional court described the concept of a "fundamental right to the guarantee of the confidentiality and integrity of information technology systems" based on the abstract gurantees of fundamental rights by our constitution specifically applied to modern information technology. e.g. http://www.bundesverfassungsgericht.de/pressemitteilungen/bvg08-022en.html (the original german-language decision is elaborate, crystal clear and perfectly fits with 4-5 earlier decisions about telecommunication and informational self-determination that I knew before this decision. The german press release seems just slighty inaccurate in some details (secretarial sloppiness), but I'm having significant difficulties understanding the official english-language press release...) Given the clear and consistent history of decisions by our constitutional court on the "fundamental right for informational self-determination" with respect to telecommunication and protection of data transported by or stored on information technology systems, there are a number of current practices in german companies that are very probably un-constitutional by that measure, and it is only a matter of time when the attitude of lower courts and lawyer, that even today frequently fail to properly account for the requirements published by our constitutional court, get challenged and overturned, with the result that a number of popular current practices encroaching on integrity and privacy of telecommunication, will have to be discontinued in Germany. -Martin From mrex@sap.com Fri Jul 29 19:31:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6410921F8AEA for ; Fri, 29 Jul 2011 19:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.913 X-Spam-Level: X-Spam-Status: No, score=-9.913 tagged_above=-999 required=5 tests=[AWL=0.336, 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 drOoUz5hRZJq for ; Fri, 29 Jul 2011 19:31:02 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2D80621F8BA9 for ; Fri, 29 Jul 2011 19:31:01 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p6U2UwJu003172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 30 Jul 2011 04:30:58 +0200 (MEST) From: Martin Rex Message-Id: <201107300230.p6U2UvZ3012132@fs4113.wdf.sap.corp> To: mcgrew@cisco.com (David McGrew) Date: Sat, 30 Jul 2011 04:30:57 +0200 (MEST) In-Reply-To: from "David McGrew" at Jul 29, 11 03:24:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension 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: Sat, 30 Jul 2011 02:31:03 -0000 David McGrew wrote: > > On Jul 29, 2011, at 1:44 PM, Martin Rex wrote: > > > > Matt McCutchen wrote: > >> > >> On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote: > >>> Only for Web-Browser scenario can I personally see a very limited > >>> value that does not amount to 100% wiretapping. > >>> > >>> Are you aware of rfc2804 "IETF Policy on Wiretapping"? > >>> > >>> http://tools.ietf.org/html/rfc2804 > >>> > >>> Standardizing MITM attacks on TLS-protected communication > >>> ("lawful intercept?") seems like an extremely bad idea to me. > >> > >> This is not wiretapping as defined in that policy. On the contrary, it is EXACTLY wiretapping _as_meant_by_rfc2804_. > > Right, it's clearly not wiretapping as per RFC 2804: "Wiretapping is > what occurs when information passed across the Internet from one party > to one or more other parties is delivered to a third party: 1. Without > the sending party knowing about the third party ..." The intent of > the work we are discussing is to ensure that the client knows about > the third party. As Marsh Ray previously pointed out... ...the server might be sending a response, and due to the server not knowing about the MitM on the communication link to the client this falls within the description and intent of RFC2804. In Germany such a TLS proxy will always and unconditionally fall under the constitutional protection of telecommunications (Art 10 Abs. 1 GG), unless **ALL** communication parties have consciously agreed. (it would fall under the less stringent constitutional protection of informational self-determination of the sender of information when communication contents were leaked only at a rightful TLS endpoint as conceived by the information sender, which is _still_ a very serious legal problem where I live). > > > > > I *STRONGLY* disagree. That is very much about wiretapping and > > even goes far beyond that, because it not only reveals the content > > of the communication, it also allows the "TLS proxy" to arbitrarily > > manipulate the communication in a fashion that might be entirely > > concealed to the communication peers at the end. > > > > > > I am strongly opposed to have any document describing such proxies > > published as an RFC! > > And yet you would favor a protocol that propagates decryption keys > around the network? That approach would ensure communication integrity and keep client certificates functional. Favour? No, but it is by a huge margin the lesser evil and the lesser security problem when compared to a TLS-terminating proxy with a super-CA-equivent keypair that can fake every server cert and surreptitiously modify all comunications, which completely precludes control and accountability through technical/protocol safeguards. > > We don't have a choice about whether or not TLS proxying will be done > on the Internet; it is being done. What we can choose is whether or > not the IETF improves how it is being done. The IETF does not have a choice whether law enforcement does wiretap, yet it refuses to work on and standarize technology that provides or facilitates such activities. -Martin From marsh@extendedsubset.com Fri Jul 29 20:35:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224C411E80E6 for ; Fri, 29 Jul 2011 20:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ0N5QxyBMGc for ; Fri, 29 Jul 2011 20:35:18 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9177411E807E for ; Fri, 29 Jul 2011 20:35:18 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1Qn0Kc-0009se-4s; Sat, 30 Jul 2011 03:35:18 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id B0CA2606F; Sat, 30 Jul 2011 03:35:15 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+T+pFg5UchHMplb2cLMmplWTWmxtiGccM= Message-ID: <4E337BF4.8030307@extendedsubset.com> Date: Fri, 29 Jul 2011 22:35:16 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: David McGrew References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 30 Jul 2011 03:35:19 -0000 On 07/29/2011 05:24 PM, David McGrew wrote: > > On Jul 29, 2011, at 1:44 PM, Martin Rex wrote: >> >> I am strongly opposed to have any document describing such proxies >> published as an RFC! > > And yet you would favor a protocol that propagates decryption keys > around the network? I'm with Martin on this one. If the goal is to allow well-regulated eavesdropping of a TLS protocol stream it would be better done via a mechanism which transfers the minimum necessary secret key material to the authorized party with the consent of both legitimate endpoints. Although I've often wanted such a thing for debugging, I don't like it. But it would be preferable to having middleboxes falsely impersonating the identity of servers. Just because you can convince a client to accept your trusted root cert it doesn't give you the moral authority to impersonate the identity of a third party or deceive them about the connection's security properties. Otherwise, by that logic, there are hundreds of governments and corporations around the world which would be justified in doing so. > We don't have a choice about whether or not TLS proxying will be done on > the Internet; it is being done. Over the internet? Really? The only case I've heard of was Syria using a Blue Coat on their people. I'd assume China has built the capability as well. > What we can choose is whether or not the > IETF improves how it is being done. But this is not really "TLS proxying" at all since the TLS is actually being stripped off entirely and re-established with a largely independent context. From a purely technical perspective it sounds as if people want to convert TLS from a "two party plus PKI" protocol into a "three party plus" protocol, without actually defining the implications of all the new trust relationships it brings up. - Marsh From pgut001@login01.cs.auckland.ac.nz Sat Jul 30 00:02:21 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B253921F8C81 for ; Sat, 30 Jul 2011 00:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-0.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751] 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 iG1-fqNHjDBT for ; Sat, 30 Jul 2011 00:02:16 -0700 (PDT) Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 61F4A21F852E for ; Sat, 30 Jul 2011 00:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1312009336; x=1343545336; h=from:to:subject:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20tls@ietf.org,,=20uri@ll.mit.edu|Subject:=20Re:=20[ TLS]=20EU=20cards|Message-Id:=20|Date:=20Sat,=2030=20Jul=202011=2019 :02:12=20+1200; bh=7QeaGG9fQgasJs+apk10DKKDIDUpubIyoeKCJiJm7r4=; b=jgUf/5WNzVUK3+UWxw5yhr3qohkVZkR+bCppn53/azqokFHZ1v6EEdHh 3m4lLAJIpOff0JLp26Wk0TxrTv0PMYyy8abkF66IYpxDlqlUfHf8gwYqr 5IDVH6y88tVJBMLA4Sa5NBaAyFhr5EdOUDcFBWZ39o/0oe6LEj0tBKQol Y=; X-IronPort-AV: E=Sophos;i="4.67,291,1309694400"; d="scan'208";a="74888064" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Jul 2011 19:02:12 +1200 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Qn3Yq-0007Ww-GZ; Sat, 30 Jul 2011 19:02:12 +1200 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Qn3Yq-0007dr-2v; Sat, 30 Jul 2011 19:02:12 +1200 From: Peter Gutmann To: tls@ietf.org,, uri@ll.mit.edu Message-Id: Date: Sat, 30 Jul 2011 19:02:12 +1200 Subject: Re: [TLS] EU cards 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, 30 Jul 2011 07:02:21 -0000 "Blumenthal, Uri - 0668 - MITLL" writes: >Have you used CAC? My own experience with CAC (or other smart card/PKI technology) is totally non-representative of typical end users, which makes me useless for determining how typical users deal would with it. This is why I go to end users for feedback, or reference studies of end users performed by others. >Then what do you know about how they suck or not? By talking to end users? A rather novel concept, I agree, but quite useful for assessing the impact of something. >I on the other hand have been using them for quite a while - You're about as representative of typical end users as I am. Whether you or I can use them is largely irrelevant, because we're not typical users. This is something that the usability study that I referenced took pains to point out, the people deploying the technology were incapable of understanding that just because they managed to use it didn't mean that a normal user could. In fact when the paper was peer-reviewed, other security researchers had trouble believing the empirical results obtained because it couldn't possibly take users that long to obtain and configure a certificate ("I'm sorry but your facts just don't support our theory"). The researchers who set up the study had themselves managed to complete the task in two-and-a-half minutes. The test users (IT professionals who were given screenshot-by-screenshot paint-by- numbers instructions showing them what to do) took two hours and twenty minutes, and rated it as the hardest computer task they'd ever been asked to perform. That's about how representative you and I are of real-world users. It's funny, there seems to be quite some dissatisfaction with CAC out there, but no-one wants to talk about it in public because they'd risk losing face, or government money, or both, if they did. Within a few hours of my "Man, that stuff SUCKS!" post I got three off-list responses from people who'd worked with it which included comments like "When we rolled out CAC, our support costs skyrocketed. It cost us more to support the damn thing than to roll it out" (quoted verbatim from email). Peter. From anders.rundgren@telia.com Sat Jul 30 00:16:36 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E8621F8CCE for ; Sat, 30 Jul 2011 00:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ma738qGFAlqs for ; Sat, 30 Jul 2011 00:16:36 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 114BD21F8CCA for ; Sat, 30 Jul 2011 00:16:36 -0700 (PDT) Received: from [192.168.0.202] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E305E97000CA048; Sat, 30 Jul 2011 09:16:30 +0200 Message-ID: <4E33AFBC.3070900@telia.com> Date: Sat, 30 Jul 2011 09:16:12 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] EU cards 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, 30 Jul 2011 07:16:37 -0000 On 2011-07-30 09:02, Peter Gutmann wrote: > I got three off-list responses from people who'd > worked with it which included comments like "When we rolled out CAC, our > support costs skyrocketed. It cost us more to support the damn thing than to > roll it out" (quoted verbatim from email). >From a .SE watchtower I believe that the cost per seat usually exceeds $500 over five years when all the *consultant fees* have been added. For small agencies I believe it could easily reach $2000! Even if you have W2KSR2 (with "CertServ") you need a $25 000 Microsoft "Forefront Identity Manager" in order to get a MS-only card solution going. There surely must be something seriously wrong here... Competition: N/A. Anders From henry.story@bblfish.net Sat Jul 30 01:41:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7832621F87ED for ; Sat, 30 Jul 2011 01:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.539 X-Spam-Level: X-Spam-Status: No, score=0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_CREDIT=1.238, J_CHICKENPOX_24=0.6, MANGLED_CREDIT=2.3, 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 jLthAWPwU7HM for ; Sat, 30 Jul 2011 01:41:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02721F84EB for ; Sat, 30 Jul 2011 01:41:14 -0700 (PDT) Received: by wyj26 with SMTP id 26so287931wyj.31 for ; Sat, 30 Jul 2011 01:41:13 -0700 (PDT) Received: by 10.227.19.132 with SMTP id a4mr3234984wbb.46.1312015273609; Sat, 30 Jul 2011 01:41:13 -0700 (PDT) Received: from [192.168.0.26] (bdv75-13-78-237-142-94.fbx.proxad.net [78.237.142.94]) by mx.google.com with ESMTPS id eo18sm2397675wbb.63.2011.07.30.01.41.11 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jul 2011 01:41:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Henry Story In-Reply-To: <23B9A904-8A0D-48A2-AF45-FB6AFB58C8A9@checkpoint.com> Date: Sat, 30 Jul 2011 10:41:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E326283.3030005@telia.com> <23B9A904-8A0D-48A2-AF45-FB6AFB58C8A9@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1244.3) Cc: "tls@ietf.org List" Subject: Re: [TLS] EU cards 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, 30 Jul 2011 08:41:20 -0000 On 29 Jul 2011, at 13:33, Yoav Nir wrote: >=20 > On Jul 29, 2011, at 4:00 AM, Henry Story wrote: >=20 >> My take from this whole discussion is that PKI has been sold to = unilaterally to one group of people. It has been sold to large banks and = security heavy industries. They tend to make things more complicated, = and their security people are too security conscious, having to deal = with the most determined enemies. A good security profession in banks = MUST like a good military man, be far from the daily family life. He is = there to think about disasters, so that they don't happen, so that = nobody should think about them.=20 >>=20 >> What should happen instead is to lower the security requirements, and = enter the mass market. Just as we don't put fort knox security on our = houses, but use simple keys with well known security issues, so one = should start using PKI in a cheap but useful way. >=20 > The well-known issues in keys allow an expert to invade a home and = steal the big-screen TV. It does not allow the expert to automatically = invade all 100,000,000 homes in the US and steal every TV. Computers are = very good at automation. That is why no banks just accepts cr=E9dit card transactions = automatically. They check the recent pattern of activities and compare = it to someone's usual pattern of activity. TLS does not remove the need = to keep doing this type of checking.=20 Again we have here the knee jerk security reaction that tries to compare = TLS with an ideal technology which does not exist, and then finds it = wanting. Consider also that most web sites one has access to don't have anything = to steal. If you do propose financial transactions, then just add extra = levels of verification. >=20 >>=20 >> To get that ball rolling PKI has to be dirt cheap, and extremely = useful. It has to be=20 >> - one click to create a throw away certificate >> - authenticate across all sites (as Facebook connect does) >> (-> tie into the social web) >=20 > So what would PKI (with throw-away certificates) bring to the table = that facebook connect doesn't? Complete decentralization. Banks, companies, personal servers can all = participate. There is a short video on http://webid.info/ that explains = that. If you find that interesting you can also see the paper I = presented at the first conference "Web & Philosophy" sponsored by the = W3C that is on my home page. >=20 >> That would provide a big enough improvement over passwords to get = people interested, and it has a viral side to it. As soon as it works = for enough people, those people become interested in getting others on = board too. >=20 > I don't see why. That is because you have not yet understood the distributed nature of = WebID, as your previous question revealed. > Logging into my bank to check my account balance is not one of those = activities I like to share with friends. This is totally different from = watching a funny video on youtube or pictures of cats with witty = remarks. You would not be going to your bank account as a social site to chat = with people. But you could potentially use your bank certificate to = authenticate on other sites. (This is something that would require some = brainstorming - think of these few paragraphs as an initial = lightenging.) The Bank would put it's webid in the Issuer Alternative = Name. Every country could publish a list of its legal banks and those it = recognized from other countries. Perhaps the US would publish in = https://data.us.gov/banks/ a file containing among other things the = following relation a us:Bank . ...=20 So here the social part is not in who you know, but who knows your bank. = And of course at that level it is states and the global network of = states that form the apropriate social partners. In a banking situation your WebID is not linked to by friends, but more = by commercial transactions. Your bank webid could be https://wellsfargo.com/acnt/1231241243#acnt If you noticed a problem with your private key it's public key would be = removed from that document.=20 >> With millions or billions of adopters you can create the momentum, = and the mass market, that will make all the other problems easy to = solve. If there were just a million active developers in open source = software using PKI every day for checking in software and communicating = with their peers, you would soon find the technology make its way into = every web site, and browsers being adapted to make their interface easy = to use. With mass adoption it would be much easier to solve all the = other technological problems, because citizens and politicians would = have an immediate understanding of what you were talking about. >=20 > Again, PKI without a trust relationship with an identity provider can = make some protocols more efficient (compare OpenID to BrowserID) but it = doesn't bring any new security to the table. There are many more uses of PKIX once one ties PKIX into the web. Should = we call this PKIW? =20 The point is to explore and massively grow the use of PKI here.=20 Btw, this in itself will massively increase security, as it - with = DNSSEC and DANE - will move us to a 100% https web. Think of the huge = security holes in the web currently. A few endpoints are https = protected. But all the other web pages people click on to reach that web = site can be man in the middle attacked and the links in the html be = rewritten to point to fake sites. The pages that the Google crawler = receives, can also be man in the middle attacked. Allow each resource to = be protected just a little bit will in the network effect of the web = lead to huge improvements overall. Henry >=20 Social Web Architect http://bblfish.net/ From mcgrew@cisco.com Sat Jul 30 06:20:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C37621F89BE for ; Sat, 30 Jul 2011 06:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.789 X-Spam-Level: X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 01HMdNset7i5 for ; Sat, 30 Jul 2011 06:20:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9421F8876 for ; Sat, 30 Jul 2011 06:20:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3394; q=dns/txt; s=iport; t=1312032015; x=1313241615; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=9IfPfive7zmvJul0W3AQdwtjP9JoNbmhM3eCYROlkYI=; b=ExsIDyALAt47E9KnC0mdOmKB/6zSJQB0lsNP4No4X2lhO7eKwM4ixO4S rv7Sb8iF6b/6cDRlPgUEIwbrhrJv6yBs4QaTeyK4cqbSwbfhxitV+aDOj I2mq8YBBKhIyN7wTOteIq7x7/OsNNB59x2xeO6/Czsh/0pMGthS+tAz0O o=; X-IronPort-AV: E=Sophos;i="4.67,291,1309737600"; d="scan'208";a="8059271" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jul 2011 13:20:14 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6UDKDWF007102; Sat, 30 Jul 2011 13:20:13 GMT Message-Id: <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com> From: David McGrew To: Marsh Ray In-Reply-To: <4E337BF4.8030307@extendedsubset.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 30 Jul 2011 06:20:12 -0700 References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> <4E337BF4.8030307@extendedsubset.com> X-Mailer: Apple Mail (2.936) Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 30 Jul 2011 13:20:16 -0000 It seems that you do not understand the intent of the draft or the authors. The use case here is web filtering as it is used by organizations and consumers, in which a consumer or an organization chooses to use a service or a product that acts as an HTTP proxy, and configures their clients to do so. It is desirable in such cases to use TLS whenever possible, and it is certainly desirable that the client be able to authenticate the proxy. The intent of the authors is to enable TLS to be used when an proxy is present, and to make clients informed about both the proxy and the server, and to provide cryptographically strong authentication of both. The client should be able to decide if it accepts the proxy for a particular session, and the scope of the proxy should be limited, and the proxy should not lie to the client. The client should also have the full information about the server on the other end of the connection. We oppose the development of a technology that would help a country spy on its citizens, and we certainly oppose the development of standards in that area. The IETF can't control how the technologies that it develops are used, or who uses them, of course, which makes it imperative to not develop any mechanisms that could be used in that way. David On Jul 29, 2011, at 8:35 PM, Marsh Ray wrote: > On 07/29/2011 05:24 PM, David McGrew wrote: >> >> On Jul 29, 2011, at 1:44 PM, Martin Rex wrote: >>> >>> I am strongly opposed to have any document describing such proxies >>> published as an RFC! >> >> And yet you would favor a protocol that propagates decryption keys >> around the network? > > I'm with Martin on this one. > > If the goal is to allow well-regulated eavesdropping of a TLS > protocol stream it would be better done via a mechanism which > transfers the minimum necessary secret key material to the > authorized party with the consent of both legitimate endpoints. > Although I've often wanted such a thing for debugging, I don't like > it. But it would be preferable to having middleboxes falsely > impersonating the identity of servers. > > Just because you can convince a client to accept your trusted root > cert it doesn't give you the moral authority to impersonate the > identity of a third party or deceive them about the connection's > security properties. Otherwise, by that logic, there are hundreds of > governments and corporations around the world which would be > justified in doing so. > >> We don't have a choice about whether or not TLS proxying will be >> done on >> the Internet; it is being done. > > Over the internet? Really? The only case I've heard of was Syria > using a Blue Coat on their people. I'd assume China has built the > capability as well. > >> What we can choose is whether or not the >> IETF improves how it is being done. > > But this is not really "TLS proxying" at all since the TLS is > actually being stripped off entirely and re-established with a > largely independent context. > > From a purely technical perspective it sounds as if people want to > convert TLS from a "two party plus PKI" protocol into a "three party > plus" protocol, without actually defining the implications of all > the new trust relationships it brings up. > > - Marsh From mcgrew@cisco.com Sat Jul 30 06:22:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AA021F858D for ; Sat, 30 Jul 2011 06:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 7oVxjPSvxKx9 for ; Sat, 30 Jul 2011 06:22:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF3B21F8513 for ; Sat, 30 Jul 2011 06:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=5773; q=dns/txt; s=iport; t=1312032145; x=1313241745; h=cc:message-id:from:to:in-reply-to: content-transfer-encoding:mime-version:subject:date: references; bh=a+z4BinFHdRE5POJFBxeKQ2iF2CZKUelf6wiA6fTLJk=; b=H3TCGmcFplJMFR1hwxsiiYqwhOhN3xEkuHzEQZf46tDB2qNGrZgs3u+7 ObRI5cSiY3jFqxU7oszzonYn48tVAnjwqZvkXscTwu4CTjebF+ZVVoBnB vCfgjrS2JItW6TF02zv9ewSVlQdtc8Vj8f3D+08qIj9Odyi8oEzOqL/P9 g=; X-IronPort-AV: E=Sophos;i="4.67,291,1309737600"; d="scan'208";a="8062725" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2011 13:22:24 +0000 Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6UDMNb0012074; Sat, 30 Jul 2011 13:22:23 GMT Message-Id: From: David McGrew To: mrex@sap.com In-Reply-To: <201107292326.p6TNQvGT001711@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 30 Jul 2011 06:22:22 -0700 References: <201107292326.p6TNQvGT001711@fs4113.wdf.sap.corp> X-Mailer: Apple Mail (2.936) Cc: tls@ietf.org, pgladstone@cisco.com Subject: Re: [TLS] TLS Proxy Server Extension 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, 30 Jul 2011 13:22:32 -0000 On Jul 29, 2011, at 4:26 PM, Martin Rex wrote: > David McGrew wrote: >> >> Martin Rex wrote: >>> >>> You would not reveal the MAC keys, of course. only the encryption >>> keys. >>> >>> There is no need to allow the proxy to modify the traffic. If the >>> proxy doesn't like some of the data, it should not pass it along and >>> terminate the connection. >> >> No, this undermines the cryptographic security. >> Please see Section 6 of the draft. > > I'm having some difficulties understanding Section 6, but some of what > is described is clearly bogus and some clearly wrong. I would be obliged if you could provide specifics. > > Cryptographic security of the TLS protocol is clearly unaffected > from sharing the traffic encryption keys with the proxy. It would be an exceedingly brittle solution to build a system that would be cryptographically insecure if proxies added or changed a single byte, then insist and hope that proxies never modify the data stream. > What happens is that the proxy may remove confidentiality of the > data and look at the data before passing along the original, encrypted > data the the rightful communication peer. > > It is a design property of the TLS protocol that having access > to the traffic encryption keys does not allow _you_ to subvert other > characteristics of the protocol beyond the confidentiality. > That property does not hold for any use of authenticated encryption, including that of RFC 5288 or the two drafts using CCM. > >> >> A malware-screening proxy needs to be able to modify the traffic >> flowing through it. It would be pointless for it to detect malware, >> and then pass it on to the client! > > Huh? The peer does not get anything that the proxy does not forward. > And if there is something goofy. the proxy simply terminates the > connection (both connection. that to the real server and that to the > real client). What I have been told is that there are proxies that don't work that way, and it is not realistic to expect them to work that way. Rather than debate that point on the list, let's seek out some objective data. > > Proxies MUST NOT change a single bit of the data stream, > any capability to modify the communication without the receiver > aborting > the connection because of a data integrity violation would mean > that you have _completely_ subvert the security of the whole system, > and there would exist no technical limits to arbitrary and fully > covert > modifications. > > >>> Revealing the traffic **encryption** keys to the proxy requires >>> cooperation of the client, so a sensible client implementation >>> can ask for consent and the user may deny consent, whereas a proxy >>> with a super-CA-cert can subvert any connection for that client, >>> no matter where that client goes--and MitM all connections any time, >>> including those that do not traverse that proxy. >> >> It sounds like you misunderstand the proposal. The approach we are >> going for is one in which the client is fully informed about both the >> proxy and the server, and the client is free to choose to trust them >> or not. > > > "The client (should) know(s) about it" is not a legally valid > escape from the obligations for data privacy and data integrity > guaranteed by the our constitution and the data protection laws, > at least not here in Germany. > > For the purpose of malware screening, the proxy having only the > traffic > encryption keys is perfectly sufficient. And because it is perfectly > sufficient, the MAC keys fall under constitutional protection and > requesting them would be unlawful. Not using end-to-end message authentication is unconstitutional? But decryption in the middle is OK? If I rushed to conclusions on this topic, I might think that we are violating the constitution because we haven't signed our emails with SMIME or PGP. That can't be right, so apparently a more detailed analysis is needed. David > > A little more than three years ago our constitutional court > described the concept of a > "fundamental right to the guarantee of the > confidentiality and integrity of information technology systems" > > based on the abstract gurantees of fundamental rights by our > constitution specifically applied to modern information technology. > > e.g. > http://www.bundesverfassungsgericht.de/pressemitteilungen/bvg08-022en.html > > (the original german-language decision is elaborate, crystal clear and > perfectly fits with 4-5 earlier decisions about telecommunication > and informational self-determination that I knew before this decision. > The german press release seems just slighty inaccurate in some details > (secretarial sloppiness), but I'm having significant difficulties > understanding the official english-language press release...) > > > Given the clear and consistent history of decisions by our > constitutional > court on the "fundamental right for informational self- > determination" with > respect to telecommunication and protection of data transported by > or stored on information technology systems, there are a number of > current practices in german companies that are very probably > un-constitutional by that measure, and it is only a matter of time > when the attitude of lower courts and lawyer, that even today > frequently > fail to properly account for the requirements published by our > constitutional court, get challenged and overturned, with the result > that a number of popular current practices encroaching on integrity > and > privacy of telecommunication, will have to be discontinued > in Germany. > > > -Martin From marsh@extendedsubset.com Sun Jul 31 23:28:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1365F21F85B9 for ; Sun, 31 Jul 2011 23:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_83=0.6] 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 9gkxlkeuuL8k for ; Sun, 31 Jul 2011 23:28:29 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDEA21F85C4 for ; Sun, 31 Jul 2011 23:28:28 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1QnlzN-000B3h-S7; Mon, 01 Aug 2011 06:28:33 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C39996067; Mon, 1 Aug 2011 06:28:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/w2T9ogBnEkwqaqV5qR49FEtl3LTcNkdA= Message-ID: <4E364790.3000305@extendedsubset.com> Date: Mon, 01 Aug 2011 01:28:32 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: David McGrew References: <201107292044.p6TKinFB022634@fs4113.wdf.sap.corp> <4E337BF4.8030307@extendedsubset.com> <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com> In-Reply-To: <145F5A54-7702-4C82-BB39-C630E02E1A99@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pgladstone@cisco.com, tls@ietf.org Subject: Re: [TLS] TLS Proxy Server Extension 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, 01 Aug 2011 06:28:30 -0000 On 07/30/2011 08:20 AM, David McGrew wrote: > It seems that you do not understand the intent of the draft or the authors. The intent is nearly irrelevent. The text of the spec and the bits on the wire are what matters. > The use case here is web filtering as it is used by organizations and > consumers, in which a consumer or an organization chooses to use a > service or a product that acts as an HTTP proxy, and configures their > clients to do so. It is desirable in such cases to use TLS whenever > possible, and it is certainly desirable that the client be able to > authenticate the proxy. HTTP has explicit support for proxies and you can connect to them securely via TLS already. Wouldn't this all be done more appropriately at the HTTP layer? > The intent of the authors is to enable TLS to be > used when an proxy is present, But the intent of TLS is to prevent man-in-the-middle attacks, i.e., to prevent you from proxying it. Just because you can exploit it almost reliably with a custom root CA on today's clients doesn't mean that it's not deeply contrary to the security architecture of TLS. Design a secure way for the legitimate endpoints to agree to share some session key material with you in a way that doesn't impersonate anyone. I might even support such an extension (but good luck convincing the servers of the world). > and to make clients informed about both > the proxy and the server, and to provide cryptographically strong > authentication of both. This concept of polyamorous TLS is more radical than its proponents want to accept. Current TLS: Client strongly authenticates server via trusted CA Server may authenticate client, but usually server relies on client to stop S-C MitM Any proxy can only slow or drop connections "TLS proxy" via root cert on client: Client can't authenticate server any stronger than weakest proxy allows Client may not even be aware of proxies Any proxy may degrade security of connections arbitrarily Any proxy may get pwned and expose its root CA private key Any proxy may prevent the use of protocol features and extensions Any proxy can both read and modify plaintext Server can't authenticate client at all, client certs are busted forever Server can't authenticate proxy at all Server probably can't detect proxy downgrade Proxy relies on client to stop P-C MitM Server relies on proxy to stop S-P MitM > The client should be able to decide if it > accepts the proxy for a particular session, and the scope of the proxy > should be limited, and the proxy should not lie to the client. The > client should also have the full information about the server on the > other end of the connection. But by installing the custom root CA in the browser you've weakened the guarantees (which derive from "MUST"s and "MUST NOT"s) to merely "should"s and "should not"s. I.e., you've removed the strong crypto guarantees from the perspective of the legitimate client and (by extension) the server, who are the only parties given any security guarantees at all in the current TLS RFCs. > We oppose the development of a technology that would help a country spy > on its citizens,and we certainly oppose the development of standards in > that area. Meh. It already exists for anyone controlling a trusted root or sub-CA, why would they choose to turn on this functionality? > The IETF can't control how the technologies that it develops > are used, or who uses them, of course, which makes it imperative to not > develop any mechanisms that could be used in that way. Put it another way: don't develop mechanisms that break basic security guarantees. Even better would be to improve on them. - Marsh