From Michael.Staubermann@webolution.de Sun Mar 4 12:14:31 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA8A21F854E for ; Sun, 4 Mar 2012 12:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_50=0.001, HELO_EQ_DE=0.35, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfAtSsDAIY7E for ; Sun, 4 Mar 2012 12:14:30 -0800 (PST) Received: from mail.webolution.de (mail.webolution.de [80.152.246.40]) by ietfa.amsl.com (Postfix) with ESMTP id 459AA21F8548 for ; Sun, 4 Mar 2012 12:14:29 -0800 (PST) Received: from staubermann.webolution.de ([192.168.168.32] helo=StaubermannPC) by mail.webolution.de with esmtp (Exim 4.69) (envelope-from ) id 1S4Hp4-0004Bf-Th; Sun, 04 Mar 2012 21:14:27 +0100 From: "Michael Staubermann" To: "'Marsh Ray'" References: <068101ccf6c1$053210f0$0f9632d0$@Staubermann@webolution.de> <4F4E7163.2000300@extendedsubset.com> In-Reply-To: <4F4E7163.2000300@extendedsubset.com> Date: Sun, 4 Mar 2012 21:14:29 +0100 Message-ID: <0a3201ccfa43$6a5ec3d0$3f1c4b70$@Staubermann@webolution.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: de Thread-Index: Acz3EdECX85BxghZQVyfLtMmRLwMWQDMOsOw X-SA-Exim-Connect-IP: 192.168.168.32 X-SA-Exim-Mail-From: Michael.Staubermann@webolution.de X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on mail.webolution.de) Cc: tls@ietf.org Subject: Re: [TLS] TLS Hello Request for Connection Request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 20:14:31 -0000 Marsh, thanks for your valuable comment. Do you know, if this was the reason to do the "StartTLS" with a Bit in the EAP-TLS Negotiation? Michael -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Marsh Ray Sent: Wednesday, February 29, 2012 7:42 PM To: Michael Staubermann Cc: tls@ietf.org Subject: Re: [TLS] TLS Hello Request for Connection Request On 02/29/2012 03:03 AM, Michael Staubermann wrote: > Our group is planning to use the TLS Hello Request Message (sent from >the server to the client) to request a new TLS Connection >establishment from the Client to the Server (where the Client has the >choice to ignore the Hello Request). >[...] > Is it ok to use the Hello Request Message for the above mentioned >purpose (initiate a non existing TLS Connection), Not within the definition of TLS, as I read it. TLS has only two defined ways to initiate a connection: An SSL 3.0/TLS format ClientHello message An SSLv2-compatible ClientHello message (deprecated) > or may it collide in the future with a use of Hello Request with > slightly other semantics? It's not so much that, after all no one is likely sending or accepting HelloRequests that you might fail to interoperate with now. It's that the real TLS ClientHello and ServerHello messages have fields necessary for version negotiation. If you go back through the archives of this list, there has been plenty of discussion about the exact details of this process. There are also protections against things like version downgrade attacks that you only get when using the official message. > The word "anew" rises my attention. It's interesting that the TLS RFCs actually say "The HelloRequest message MAY be sent by the server at any time." But clearly the intent here is any time after an initial handshake. Implementations probably vary significantly in their handling of a HelloRequest message sent during an initial (or subsequent) handshake. Note that TLS defines the "client" as "The application entity that initiates a TLS connection to a server." and "server" as "The server is the application entity that responds to requests for connections from clients." So the server cannot initiate the connection, by definition. But of course, TLS only defines TLS. What you want to do at lower or upper protocol layers, or on the same channel before or after TLS is used is your own business. My recommendation would be to define your own super-lightweight transport for this purpose. Since your transport seems to have its own particular properties, you might consider defining a way to separate the proper TLS records from your other messages. It could be a simple TLV format. You could even pick a random GUID or something to indicate the HelloRequest-like semantics you need. Anything could work, but it's probably better if it *doesn't* look too much like an actual TLS message when it's not actually valid TLS. - Marsh P.S. I suspect you might find it useful to have a "TLS-carrying connection closed" message as well. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From hartketzi@googlemail.com Mon Mar 5 05:09:01 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C399521F86EA for ; Mon, 5 Mar 2012 05:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPZgaab74RFu for ; Mon, 5 Mar 2012 05:09:00 -0800 (PST) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id E534521F86F1 for ; Mon, 5 Mar 2012 05:09:00 -0800 (PST) Received: by daec6 with SMTP id c6so5895945dae.27 for ; Mon, 05 Mar 2012 05:09:00 -0800 (PST) Received-SPF: pass (google.com: domain of hartketzi@googlemail.com designates 10.68.228.103 as permitted sender) client-ip=10.68.228.103; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hartketzi@googlemail.com designates 10.68.228.103 as permitted sender) smtp.mail=hartketzi@googlemail.com; dkim=pass header.i=hartketzi@googlemail.com Received: from mr.google.com ([10.68.228.103]) by 10.68.228.103 with SMTP id sh7mr48825786pbc.106.1330952940831 (num_hops = 1); Mon, 05 Mar 2012 05:09:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=3L1g88wtDUiYGJ/rBuUK7BSkyTpbvGaHXhQvbh/irAI=; b=cxB71wRwnAvejQ+BzGw06Ke9h42XzELjrMrIN+itaKkR3lZPUyzQ5ScEKBp9AJcY/e gIzsIo1s8G2+wfFPl++ZPUqlDB133+gXT1ljvG0rgE2qcpEmAAl4ONsUQGl+MzgBNCLP 3ssDdiHzurh5NSk3TprPcxZU1FdheUfK6+cMNA6rm1INIfhc7/mjjgcr4wW21S2ESG9c VsrQU93dpGNhMf8BrCCGBBL7hwuFk2hEXQBhtELgLiLz1A1YK5fPjAXKzr8+WM6h4pZy 891FRkdfwmORQYbjTj0eoDzky2N+OfyDyFSeXo6IIAZjzpWETVv86XmffTO6eci34Fzt XT1g== MIME-Version: 1.0 Received: by 10.68.228.103 with SMTP id sh7mr41833146pbc.106.1330952940743; Mon, 05 Mar 2012 05:09:00 -0800 (PST) Sender: hartketzi@googlemail.com Received: by 10.68.233.74 with HTTP; Mon, 5 Mar 2012 05:09:00 -0800 (PST) Date: Mon, 5 Mar 2012 14:09:00 +0100 X-Google-Sender-Auth: BF8oRgm-hpjG90OKiBGoyQT6uVs Message-ID: From: Klaus Hartke To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] TLS_PSK_WITH_AES_128_CCM_8 security parameters X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 05 Mar 2012 13:09:01 -0000 Dear all / authors of draft-mcgrew-tls-aes-ccm, I'm trying to implement TLS_PSK_WITH_AES_128_CCM_8 [draft-mcgrew-tls-aes-ccm-03], which is the mandatory-to-implement cipher suite for implementations of the Constrained Application Protocol [draft-ietf-core-coap-08] in DTLS PSK mode. It's surprisingly difficult to find some of the security parameters for this cipher suite. It would be great if someone could confirm the following values: prf_algorithm = tls_prf_sha256 bulk_cipher_algorithm = aes cipher_type = aead enc_key_length = 16 octets block_length = 16 octets fixed_iv_length = 4 octets record_iv_length = 8 octets mac_algorithm = null mac_length = 0 octets mac_key_length = 0 octets verify_data_length = 12 octets Another quite unobvious thing is the value of the GenericAEADCipher.nonce_explicit field. Maybe something like the following text could be added to the draft? GenericAEADCipher.nonce_explicit MUST be the 64-bit sequence number (TLS) or the 16-bit epoch concatenated with the 48-bit sequence_number (DTLS). Thanks, Klaus From robert.cragie@gridmerge.com Mon Mar 5 08:18:22 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477F821F884B for ; Mon, 5 Mar 2012 08:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YClLstU20iKj for ; Mon, 5 Mar 2012 08:18:21 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1E21F884A for ; Mon, 5 Mar 2012 08:18:21 -0800 (PST) Received: from client-86-27-23-66.glfd.adsl.virginmedia.com ([86.27.23.66] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1S4ac6-000178-OH for tls@ietf.org; Mon, 05 Mar 2012 16:18:19 +0000 Message-ID: <4F54E792.1030402@gridmerge.com> Date: Mon, 05 Mar 2012 16:19:30 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090907080408080509090206" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] TLS_PSK_WITH_AES_128_CCM_8 security parameters X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 16:18:22 -0000 This is a cryptographically signed message in MIME format. --------------ms090907080408080509090206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Klaus, I agree it does take some effort to figure out the chain of documents=20 which complete the picture. I wrote this applicability statement for PSK = TLS in ZigBee IP: "draft-mcgrew-tls-aes-ccm-03 contains AEAD TLS cipher suites whose AEAD=20 part is detailed in rfc5116, which are very similar to rfc5487, which=20 references both rfc5288 and the original PSK cipher suite document=20 rfc4279, which references TLS 1.2 document rfc5246, which defines the=20 TLS messages." Other comments inline, bracketed by Robert On 05/03/2012 1:09 PM, Klaus Hartke wrote: > Dear all / authors of draft-mcgrew-tls-aes-ccm, > > I'm trying to implement TLS_PSK_WITH_AES_128_CCM_8 > [draft-mcgrew-tls-aes-ccm-03], which is the mandatory-to-implement > cipher suite for implementations of the Constrained Application > Protocol [draft-ietf-core-coap-08] in DTLS PSK mode. > > It's surprisingly difficult to find some of the security parameters > for this cipher suite. It would be great if someone could confirm the > following values: > > prf_algorithm =3D tls_prf_sha256 Corrrect; there is only one PRF for TLS 1.2 (see [RFC5246] Section=20 A.6) > bulk_cipher_algorithm =3D aes Corrrect; implied by 'AES' in the name > cipher_type =3D aead Corrrect; as stated in the draft > enc_key_length =3D 16 octets Corrrect; implied by 'AES_128' in the name > block_length =3D 16 octets Corrrect; implied by 'AES_128' in the name; not relevant for AEAD=20 cipher. > fixed_iv_length =3D 4 octets Correct; implied in section 3 of the draft (uint32) > record_iv_length =3D 8 octets Correct; implied in section 3 of the draft (uint64) > mac_algorithm =3D null > mac_length =3D 0 octets > mac_key_length =3D 0 octets Correct; implied by use of AEAD cipher > verify_data_length =3D 12 octets Correct; as not explicitly specified, 12 octets (from [RFC5246]=20 section 7.4.9) > Another quite unobvious thing is the value of the > GenericAEADCipher.nonce_explicit field. Maybe something like the > following text could be added to the draft? > > GenericAEADCipher.nonce_explicit MUST be the > 64-bit sequence number (TLS) or the 16-bit epoch > concatenated with the 48-bit sequence_number > (DTLS). Section 4 refers to section 3 which states: The "nonce" input to the AEAD algorithm is exactly that of [RFC5288]:=20 the "nonce" SHALL be 12 bytes long and is constructed as follows: struct { case client: uint32 client_write_IV; // low order 32-bits case server: uint32 server_write_IV; // low order 32-bits uint64 seq_num; } CCMNonce. It seems reasonably clear to me what 'seq_num' is from [RFC 5246] and=20 that it is the GenericAEADcipher.nonce_explicit field. Section 3=20 clarifies 'seq_num' for DTLS. > > > Thanks, > Klaus > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------ms090907080408080509090206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMwNTE2MTkzMFowIwYJKoZI hvcNAQkEMRYEFLT6TV88iZypeqeE98hNi2xRh/pzMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQCLW8YUPjuVf5+ZaLtuI5rl /F+nfD8K0qohOQ1LgCW5aMiW2YWOJ6u0qHncSp1C3sBO9lB8ZdzZP1qJP9IIC73yl+J+joHW oaprNAZ9S1EZTwHizz/qOD1nR9WDqLu7rlR8MkjwrDAMHLt2aXqxd78+YI28hq21hOwwTqQr yB8dz2GAUwjRr6OR3NR4yNGSZMPHQeZ+Hm8uXFDpxHP4K/vp3G3oJHhy0gi545bED7B2Bi5s ydgLJgiCUefLk/rhslEn/YeRa3IgDCNww1LhnH03urFhV1In4rttSh5kpxx/h7mTGa9dcTQr FOVWU9zqKmiqifNQU5+0Lt2t9ZCrPyILAAAAAAAA --------------ms090907080408080509090206-- From jsalowey@cisco.com Mon Mar 5 22:09:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613A321E8089 for ; Mon, 5 Mar 2012 22:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.266 X-Spam-Level: X-Spam-Status: No, score=-109.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJV+2tAS2GDv for ; Mon, 5 Mar 2012 22:09:04 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CDB4C21E8045 for ; Mon, 5 Mar 2012 22:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=165; q=dns/txt; s=iport; t=1331014144; x=1332223744; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=quAZMEyF60Z4sSSLRjfafXd3fTZQXW1k82tUbQev9fY=; b=cG7xT878FqzV77T7E6Lq9fAT/iJmQXfu0+of69YHZweymmPhMzIb8Wzs UAE1Jhz1ACEqWefPimYwbdroFKiv0wwCDolz3UHLzprjWcGUhEWlx/7eZ Wh0vdUjguOL1vmt5/TMrdCipjuBT+SMcp+uQyCBkcqguFcDS5acaYscLT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicGAKCpVU+rRDoI/2dsb2JhbABCgwmxZIEHghYBJ4Iyh2SYdIEnAZ8LjTyCP2MEiFCMboVjijODBA X-IronPort-AV: E=Sophos;i="4.73,538,1325462400"; d="scan'208";a="34732551" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 06 Mar 2012 06:09:04 +0000 Received: from [10.0.0.7] (sjc-vpn2-628.cisco.com [10.21.114.116]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26694Pc007960 for ; Tue, 6 Mar 2012 06:09:04 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 22:08:48 -0800 Message-Id: <476745B9-46CE-4EEE-883F-DEAFACDFC7C0@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 TLS meeting at IETF 83 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:09:05 -0000 The TLS meeting is scheduled for Wednesday Afternoon, please let the = chairs know if you have any agenda items you would like to present. =20 Thanks, Joe= From hannes.tschofenig@nsn.com Mon Mar 5 23:03:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4461421F871E for ; Mon, 5 Mar 2012 23:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.352 X-Spam-Level: X-Spam-Status: No, score=-106.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsDUGmkWwB48 for ; Mon, 5 Mar 2012 23:03:09 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 02BE021F8715 for ; Mon, 5 Mar 2012 23:03:08 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q267323i024522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Mar 2012 08:03:02 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q26730A9003569; Tue, 6 Mar 2012 08:03:02 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 08:03:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 09:02:59 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D012C84B1@FIESEXC035.nsn-intra.net> In-Reply-To: <476745B9-46CE-4EEE-883F-DEAFACDFC7C0@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Agenda items for TLS meeting at IETF 83 Thread-Index: Acz7X6YKt0D227s+TXKD8qDAE/I6QQABxppw References: <476745B9-46CE-4EEE-883F-DEAFACDFC7C0@cisco.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Joe Salowey" , X-OriginalArrivalTime: 06 Mar 2012 07:03:00.0547 (UTC) FILETIME=[2AD16130:01CCFB67] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1227 X-purgate-ID: 151667::1331017384-000044A2-29A51037/0-0/0-0 Subject: Re: [TLS] Agenda items for TLS meeting at IETF 83 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:03:10 -0000 Hi Joe,=20 I would like to talk about these two items: * draft-ietf-tls-oob-pubkey * draft-ietf-tls-cached-info draft-ietf-tls-oob-pubkey had been updated since the last IETF meeting and there was feedback on the mailing list. I have also worked on an implementation of it (see https://github.com/hannestschofenig/tschofenig-ids/raw/master/smart-obje ct-security/smart-object-security.pdf).=20 draft-ietf-tls-cached-info had also been updated since the last IETF meeting, there was also feedback on the list, and there are a few open issues with the document. I am planning to submit an update before the draft submission deadline.=20 Ciao Hannes > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > ext Joe Salowey > Sent: Tuesday, March 06, 2012 8:09 AM > To: tls@ietf.org > Subject: [TLS] Agenda items for TLS meeting at IETF 83 >=20 > The TLS meeting is scheduled for Wednesday Afternoon, please let the > chairs know if you have any agenda items you would like to present. >=20 > Thanks, >=20 > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From yngve@opera.com Tue Mar 6 05:01:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B0D21F88E5 for ; Tue, 6 Mar 2012 05:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.949 X-Spam-Level: X-Spam-Status: No, score=-6.949 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0Uo01Hiei4D for ; Tue, 6 Mar 2012 05:01:48 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1799521F885E for ; Tue, 6 Mar 2012 05:01:47 -0800 (PST) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q26D1eOn011560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Mar 2012 13:01:46 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: <20120306124950.6304.36237.idtracker@ietfa.amsl.com> To: "tls@ietf.org" Date: Tue, 06 Mar 2012 14:01:52 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <20120306124950.6304.36237.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/10.63 (Win32) Subject: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:01:49 -0000 FYI ------- Forwarded message ------- From: internet-drafts@ietf.org To: yngve@opera.com Cc: Subject: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt Date: Tue, 06 Mar 2012 13:49:50 +0100 A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-03.txt has been successfully submitted by Yngve N. Pettersen and posted to the IETF repository. Filename: draft-pettersen-tls-ext-multiple-ocsp Revision: 03 Title: Adding Multiple TLS Certificate Status Extension requests Creation date: 2012-03-06 WG ID: Individual Submission Number of pages: 9 Abstract: This document introduces a replacement of the TLS Certificate Status Extension to allow clients to specify and support multiple certificate status methods. Also being introduced is a new OCSP- based method that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF Secretariat -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From dharkins@lounge.org Tue Mar 6 08:22:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F4221F8A05 for ; Tue, 6 Mar 2012 08:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.718 X-Spam-Level: X-Spam-Status: No, score=-5.718 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA-mvp9NnBnk for ; Tue, 6 Mar 2012 08:22:39 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3168321F89CD for ; Tue, 6 Mar 2012 08:22:39 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 33171A88810C; Tue, 6 Mar 2012 08:22:38 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 6 Mar 2012 08:22:38 -0800 (PST) Message-ID: In-Reply-To: <476745B9-46CE-4EEE-883F-DEAFACDFC7C0@cisco.com> References: <476745B9-46CE-4EEE-883F-DEAFACDFC7C0@cisco.com> Date: Tue, 6 Mar 2012 08:22:38 -0800 (PST) From: "Dan Harkins" To: "Joe Salowey" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] Agenda items for TLS meeting at IETF 83 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:22:40 -0000 Hello, I'd like a few minutes to talk, again, about draft-harkins-tls-pwd. There were quite a few comments on the list after the Taipei meeting and I've addressed them in a new version. It's not posted yet but will be before the cut-off date. thanks, Dan. On Mon, March 5, 2012 10:08 pm, Joe Salowey wrote: > The TLS meeting is scheduled for Wednesday Afternoon, please let the > chairs know if you have any agenda items you would like to present. > > Thanks, > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Jeff.Hodges@KingsMountain.com Thu Mar 8 09:10:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6AE21F842A for ; Thu, 8 Mar 2012 09:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.083 X-Spam-Level: X-Spam-Status: No, score=-100.083 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYOUJn7R3jpM for ; Thu, 8 Mar 2012 09:10:01 -0800 (PST) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 2E0E321F8421 for ; Thu, 8 Mar 2012 09:10:01 -0800 (PST) Received: (qmail 12914 invoked by uid 0); 8 Mar 2012 17:09:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 8 Mar 2012 17:09:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=WT72TeZG6BaMCcpsqQD6r2kcmfDyNp79P9S6L3nqPeY=; b=ob9puEJa0Oe3/fDokgl3vFQolJRYcouYjiLjM+IjUg/JhvygegXNa3M+Rr6IPmBg/JCzFisXzqY+qRI0HOYRqLtW57u5ziuMMQhKKXfqbLBQrbV5T5jrMQHw0TQAAlGm; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.56]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S5gqi-0005iX-Rh for tls@ietf.org; Thu, 08 Mar 2012 10:09:56 -0700 Message-ID: <4F58E7E4.5000703@KingsMountain.com> Date: Thu, 08 Mar 2012 09:09:56 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [TLS] fyi: initial draft of "Ciphers in Use in the Internet" is now available X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:10:07 -0000 Of possible interest.. Subject: [Cfrg] Fwd: New Version Notification for draft-irtf-cfrg-cipher-catalog-00.txt From: David McGrew Date: Tue, 6 Mar 2012 07:05:24 -0500 (04:05 PST) To: cfrg@irtf.org Hi, the initial version of "Ciphers in Use in the Internet" is now available at . Sean and I ask for your review, constructive criticism, and input. Some parts of the draft need more detail and organization, but it should be in sound enough shape for review. If you have text to contribute, that would be appreciated, especially if you can supply citations for the more consequential statements. regards, David Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-irtf-cfrg-cipher-catalog-00.txt > Date: March 5, 2012 8:35:57 PM EST > To: mcgrew@cisco.com > Cc: shenshuo@cnnic.cn > > A new version of I-D, draft-irtf-cfrg-cipher-catalog-00.txt has been successfully submitted by David McGrew and posted to the IETF repository. > > Filename: draft-irtf-cfrg-cipher-catalog > Revision: 00 > Title: Ciphers in Use in the Internet > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 63 > > Abstract: > This note catalogs the ciphers in use on the Internet, to guide users > and standards processes. It presents the security goals, security > analysis and results, specification, intellectual property > considerations, and publication dates of each cipher. Background > information and security guidance is provided as well. > > The IETF Secretariat From marsh@extendedsubset.com Thu Mar 8 09:36:36 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10CD21F86BD for ; Thu, 8 Mar 2012 09:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YwHDfUcn-IQ for ; Thu, 8 Mar 2012 09:36:35 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id B8E2821F86BA for ; Thu, 8 Mar 2012 09:36:35 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1S5hGV-000Iwi-8E; Thu, 08 Mar 2012 17:36:35 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2EC016067; Thu, 8 Mar 2012 17:36:34 +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+fy+dnwxzokUwPRSW2YTJ8N4ylQtt1sUI= Message-ID: <4F58EE21.2030405@extendedsubset.com> Date: Thu, 08 Mar 2012 11:36:33 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Michael Staubermann References: <068101ccf6c1$053210f0$0f9632d0$@Staubermann@webolution.de> <4F4E7163.2000300@extendedsubset.com> <0a3201ccfa43$6a5ec3d0$3f1c4b70$@Staubermann@webolution.de> In-Reply-To: <0a3201ccfa43$6a5ec3d0$3f1c4b70$@Staubermann@webolution.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS Hello Request for Connection Request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:36:36 -0000 On 03/04/2012 02:14 PM, Michael Staubermann wrote: > Marsh, > > thanks for your valuable comment. Sorry for the delayed response! > Do you know, if this was the reason to do the "StartTLS" with a Bit in the > EAP-TLS Negotiation? No, I do not know. But clearly STARTTLS protocols do share a lot of these same considerations. - Marsh From dharkins@lounge.org Thu Mar 8 11:06:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3C21F86F3 for ; Thu, 8 Mar 2012 11:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.775 X-Spam-Level: X-Spam-Status: No, score=-5.775 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7YN1FZQsntd for ; Thu, 8 Mar 2012 11:06:36 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 98B3621F84E7 for ; Thu, 8 Mar 2012 11:06:36 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 75ECA1022404C; Thu, 8 Mar 2012 11:06:35 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 8 Mar 2012 11:06:36 -0800 (PST) Message-ID: In-Reply-To: <0a3201ccfa43$6a5ec3d0$3f1c4b70$@Staubermann@webolution.de> References: <068101ccf6c1$053210f0$0f9632d0$@Staubermann@webolution.de> <4F4E7163.2000300@extendedsubset.com> <0a3201ccfa43$6a5ec3d0$3f1c4b70$@Staubermann@webolution.de> Date: Thu, 8 Mar 2012 11:06:36 -0800 (PST) From: "Dan Harkins" To: "Michael Staubermann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] TLS Hello Request for Connection Request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:06:37 -0000 Hello, On Sun, March 4, 2012 12:14 pm, Michael Staubermann wrote: > Marsh, > > thanks for your valuable comment. > > Do you know, if this was the reason to do the "StartTLS" with a Bit in the > EAP-TLS Negotiation? With EAP the server issues requests and the client issues responses to those requests. It's a lock-step protocol initiated by the server. TLS is initiated by the client. To use TLS in EAP it was necessary to have a request from the server start the whole thing off. The semantics are "I want to authenticate you with TLS" and then the client starts TLS. The "StartTLS" request, as well as the final, empty EAP-TLS Response sent by the client were added to graft TLS into EAP. regards, Dan. From ehimawan@gmail.com Fri Mar 9 06:01:16 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C44C21F8642 for ; Fri, 9 Mar 2012 06:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeB-QUwmCeKD for ; Fri, 9 Mar 2012 06:01:16 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A84F921F863F for ; Fri, 9 Mar 2012 06:01:15 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1153127wgb.13 for ; Fri, 09 Mar 2012 06:01:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RkwM1KbEnzYSqAM/WvpZFMMYrGAknaDiVdUJ0koSO00=; b=vx3C9jIqIY1dNwmy8If2/YT8TpWbNWWUKCBg4wzXi/6hcM9qL8WHu6eWThXLH1EiyA cR9anTyQBQqvxWgoOTV8uYwTAez0/X3bUJX+oFBT9MQGBOqenzva8NOJVNFIzMK5YSDC st3Zsc2+oXArr4ZUJ0JLkva0ora5wfOHj6lhfK5oEdPv6UWDk4s6gFOdelsuNeSt18lP rKg+12Y+4AJXYmp/KyCV1O5SKRH3jQl2I8QZmHCiwmhtsP89MuL5EkPKo/lkiBl8KgUw qqlZlexzC4hzHcjusG52NJ5fAUgDKzkjbN+ALa+XUsc3ZCBkDwiTHpIkbjkfZWqg06RL wvJQ== MIME-Version: 1.0 Received: by 10.180.102.129 with SMTP id fo1mr5094931wib.6.1331301674605; Fri, 09 Mar 2012 06:01:14 -0800 (PST) Received: by 10.216.46.76 with HTTP; Fri, 9 Mar 2012 06:01:14 -0800 (PST) Date: Fri, 9 Mar 2012 08:01:14 -0600 Message-ID: From: Erwin Himawan To: tls@ietf.org Content-Type: multipart/alternative; boundary=f46d04448149675cd804bacfd344 Subject: [TLS] DTLS reliable and ordered delivery for "user data" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:01:16 -0000 --f46d04448149675cd804bacfd344 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, The way I understand the way DTLS works, DTLS ensures reliable and ordered delivery of handshake messages during session establishment and key management. When transferring "user data", DTLS does not ensure reliable and ordered delivery. Is my understanding correct? Thanks, Erwin --f46d04448149675cd804bacfd344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,

The way I understand the way DTLS works, DTLS = ensures reliable and ordered delivery of handshake messages during session = establishment and key management.
When transferring "user da= ta", DTLS does not ensure reliable and ordered delivery.

Is my understanding correct?

T= hanks,
Erwin
--f46d04448149675cd804bacfd344-- From Michael.Tuexen@lurchi.franken.de Fri Mar 9 06:29:07 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE47721F85F7 for ; Fri, 9 Mar 2012 06:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mC2SVCS0XvFC for ; Fri, 9 Mar 2012 06:29:07 -0800 (PST) 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 41A7621F85F1 for ; Fri, 9 Mar 2012 06:29:07 -0800 (PST) Received: from [192.168.1.103] (p508FA066.dip.t-dialin.net [80.143.160.102]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E8AB81C0B4610; Fri, 9 Mar 2012 15:29:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Fri, 9 Mar 2012 15:29:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5A43F663-F17D-4A33-8CD7-A955D1F0D37F@lurchi.franken.de> References: To: Erwin Himawan X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] DTLS reliable and ordered delivery for "user data" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:29:07 -0000 On Mar 9, 2012, at 3:01 PM, Erwin Himawan wrote: > Hi Folks, >=20 > The way I understand the way DTLS works, DTLS ensures reliable and = ordered delivery of handshake messages during session establishment and = key management. > When transferring "user data", DTLS does not ensure reliable and = ordered delivery. >=20 > Is my understanding correct? Correct. Best regards Michael >=20 > Thanks, > Erwin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From hannes.tschofenig@gmx.net Sun Mar 11 01:03:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B110021F864E for ; Sun, 11 Mar 2012 01:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOh5VbbFxUT3 for ; Sun, 11 Mar 2012 01:03:10 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 105B121F84F7 for ; Sun, 11 Mar 2012 01:03:09 -0800 (PST) Received: (qmail invoked by alias); 11 Mar 2012 09:03:08 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp031) with SMTP; 11 Mar 2012 10:03:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+HNENYmx+HiLYcMTI+OoMPLWif0rZJdvzdOcw3hG wiUPC8U2p0a9wG Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <030701ccda61$90aea7f0$b20bf7d0$@augustcellars.com> Date: Sun, 11 Mar 2012 11:03:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01D1230B-8947-4FC4-B94F-195B0CEEB88E@gmx.net> References: <030701ccda61$90aea7f0$b20bf7d0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 09:03:11 -0000 Hi Jim,=20 I have missed your review. Sorry about that.=20 As I am updating the draft I now found it.=20 On Jan 24, 2012, at 8:29 AM, Jim Schaad wrote: > I am going to have to disagree with the statement that the document is = ready > for WGLC. I have refrained from reading this document before because = I am > not truly convinced that this is a good idea. >=20 > 1. I have a hard time with the second paragraph in the abstract - = firstly > the concept of a black list seems to be problematic as a method of = deciding > that an oob key is or is not good. A white list could essentially be = a list > of names and keys and thus work. However there are going to be issues = of > trust in terms of how the white list is updated that are exactly the = same > for getting PKIX to work. >=20 The blacklist idea wasn't really worked out. I removed it.=20 > 2. In section 1.1 you state "...a TLS server must always send a list = of > trusted CA keys and..." this does not make sense to me. There is no = list of > trusted CA keys, there is an EE certificate and then the list of CA > certificates that certify the EE certificate (and each other). There = is no > statement that these are trusted CA keys. 5246 explicitly says that = the > trust anchor (i.e. the TRUSTED CA key) does not need to be sent in the = chain > of certificates. >=20 > Even more troubling is that I cannot find anything that defines an = extension > which says - I know who you are don't send me any certificates (or = perhaps > only the EE certificate). However I do note that you state that RFC = 6066 > does have the flag to say don't send me the chain - this appears to = greatly > lessen the argument that you have a large problem in terms of not = sending > the EE certificate. >=20 > Why do you not just have an extension to say - don't send me the EE > certificate I already think I know who you are. That would solve you = issue > without any need for the new certificate extension type. >=20 > I don't believe that this provides a good motivation for the document. = The > small embedded device is a better motivation that is presented here. >=20 This is a left-over from an earlier draft version where we also tried to = incorporate ideas that are now found in=20 http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ I would prefer to remove these paragraphs from the document.=20 > 3. For section 1.2 - see previous item. Again I think the small = embedded > device is a much better statement of applicability. You should be = looking > at cases for raw public keys not for PKIX. >=20 I have polished the text a bit.=20 > 4. I have absolutely no idea how to create a certificate which = contains > only the subject public key info structure. Many of these fields are = not > optional and therefore cannot be omitted. Also you have said that the > entire problem is that you cannot deal with the PKIX structure, and = how you > are suddenly doubling the amount of code that I need to deal with PKIX = since > I now have both a certificate with fields and a certificate w/o = fields. Why > do you not say that your data structure for a "raw key certificate" is = just > going to be the SubjectPublicKeyInfo DER encoded structure? This = would be > much simpler and clearer as well as reducing the amount of ASN.1 = processing > substantially. We are pretty much free to put whatever we want into a message and so = placing only a SubjectPublicKeyInfo works fine. Of course your question = about whether putting the SubjectPublicKeyInfo or just the raw key = parameters in there is good. We initially had proposed the latter but = got the feedback from the group that we should go for the = SubjectPublicKeyInfo structure instead because it allows easier re-use. I tried to implement the extension, only based on RSA keys, as a = contribution for the upcoming Smart Object Security workshop. Here is = the workshop: = http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ and here = is the paper:=20 = https://github.com/hannestschofenig/tschofenig-ids/raw/master/smart-object= -security/smart-object-security.pdf In a nutshell: The amount of ASN.1 functionality for parsing the = SubjectPublicKeyInfo structure is very small.=20 >=20 > 5. You are missing text that needs to be in place about the use of = client > authentication from a raw key. I don't know if this is what you = really want > to do or not. It is going to be much harder for a server to do the = oob > authentication without registration of some type. Additionally this = would > mean that your justification of wanting to suppress the sending of the > server certificate would need to be documented as not working at all = if you > want to do client authentication. Since one case where you might want = to do > the suppression would be a re-authentication process for protected = client > auth, this does not make any since (in this case you already have the > servers certificates from the previous handshake). Does this mean = that you > want to have the ability to have an asymmetric method of specifying = the > "certificate type" so that one can do bare key from server to client, = but > pkix certificate from client to server? This is not an issue for the = case > of PGP since one can assume that both the server and the client are = going to > use PGP certificates for the purpose of authentication. > =20 >=20 > 6. Security considerations - para #2 - It is easy to establish the > authenticity of the public key - just see if the cryptography works. = What > you want to be able to authenticate is the binding between the public = key > and the entity or service you are attempting to contact.=20 >=20 > 7. Security considerations - does not talk about client/public key = binding > authentication by the server at all - this is a short coming To address your last three comments I have re-written the security = consideration section.=20 I agree with you that the cryptography is easy. Binding the public key = to some entity is what we call "out-of-band key validation".=20 We offer a few options, namely pre-configuring a list of keys a client = would accept from servers, or the the usage of DANE. In the CORE WG = folks want to print the hash of the key onto the sensor and then let a = human compare the value with what is shown on the screen of some other = device. These sort of imprinting procedures are in use today by some = consumer devices.=20 Maybe we should elaborate a bit more on the DANE or the smart object use = case.=20 Ciao Hannes >=20 >=20 >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = Paul >> Wouters >> Sent: Friday, January 20, 2012 3:55 PM >> To: tls@ietf.org >> Subject: [TLS] New Version Notification for > draft-ietf-tls-oob-pubkey-01.txt >> (fwd) >>=20 >>=20 >> The only changes to the document is a typo (out of bound -> out of = band) >> found by Bill Frantz and an updated reference to a newer = draft-ietf-dane- >> protocol version. >>=20 >> = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tls-oo= b- >> pubkey-01.txt >>=20 >> I believe this document is ready for WGLC. >>=20 >> Paul >>=20 >> ---------- Forwarded message ---------- >> Date: Fri, 20 Jan 2012 18:06:02 >> From: internet-drafts@ietf.org >> Cc: hannes.tschofenig@gmx.net, weiler@tislabs.com, paul@nohats.ca, >> gnu@toad.com, >> kivinen@iki.fi >> To: paul@nohats.ca >> Subject: New Version Notification for = draft-ietf-tls-oob-pubkey-01.txt >>=20 >> A new version of I-D, draft-ietf-tls-oob-pubkey-01.txt has been > successfully >> submitted by Paul Wouters and posted to the IETF repository. >>=20 >> Filename: draft-ietf-tls-oob-pubkey >> Revision: 01 >> Title: TLS Out-of-Band Public Key Validation >> Creation date: 2012-01-20 >> WG ID: tls >> Number of pages: 10 >>=20 >> Abstract: >> This document specifies a new TLS certificate type for exchanging = raw >> public keys in Transport Layer Security (TLS) and Datagram = Transport >> Layer Security (DTLS) for use with out-of-band authentication. >> Currently, TLS authentication can only occur via PKIX or OpenPGP >> certificates. By specifying a minimum resource for raw public key >> exchange, implementations can use alternative authentication = methods. >>=20 >> One such method is using DANE Resource Records secured by DNSSEC, >> Another use case is to provide authentication functionality when = used >> with devices in a constrained environment that use whitelists and >> blacklists, as is the case with sensors and other embedded devices >> that are constrained by memory, computational, and communication >> limitations where the usage of PKIX is not feasible. >>=20 >> The new certificate type specified can also be used to reduce the >> latency of a TLS client that is already in possession of a = validated >> public key of the TLS server before it starts a (non-resumed) TLS >> handshake. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >> _______________________________________________ >> 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 paul@nohats.ca Sun Mar 11 10:41:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19A5921F85C2 for ; Sun, 11 Mar 2012 10:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxCDwsDuXV0x for ; Sun, 11 Mar 2012 10:41:45 -0700 (PDT) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5037321F85C0 for ; Sun, 11 Mar 2012 10:41:44 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 244FD8244C; Sun, 11 Mar 2012 13:41:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 1B93582449; Sun, 11 Mar 2012 13:41:43 -0400 (EDT) Date: Sun, 11 Mar 2012 13:41:43 -0400 (EDT) From: Paul Wouters To: Jim Schaad , Hannes Tschofenig , John Gilmore , Sam Weiler In-Reply-To: <030701ccda61$90aea7f0$b20bf7d0$@augustcellars.com> Message-ID: References: <030701ccda61$90aea7f0$b20bf7d0$@augustcellars.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.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: Sun, 11 Mar 2012 17:41:46 -0000 On Mon, 23 Jan 2012, Jim Schaad wrote: [ Apologies for the insane RTT ] A lot of Jim's comments have been integrated into the -02 version of the document, but let me address some concerns left. > Even more troubling is that I cannot find anything that defines an extension > which says - I know who you are don't send me any certificates (or perhaps > only the EE certificate). However I do note that you state that RFC 6066 > does have the flag to say don't send me the chain - this appears to greatly > lessen the argument that you have a large problem in terms of not sending > the EE certificate. An EE certificate is still many orders of magnitude more complex then just a SubjectPublicKeyInfo structure. > Why do you not just have an extension to say - don't send me the EE > certificate I already think I know who you are. That would solve you issue > without any need for the new certificate extension type. That was how we did it in the very first draft, and the feedback we got from the working group was that they preferred a new certificate type over a new TLS extension. > I don't believe that this provides a good motivation for the document. The > small embedded device is a better motivation that is presented here. You are not mentioning the other motivations mentioned, such as the ones that relate to using DNSSEC/DANE and getting duplicated/conflicting information that now has to be put in an EE certificate because there is no way to leave this out. > 4. I have absolutely no idea how to create a certificate which contains > only the subject public key info structure. Many of these fields are not > optional and therefore cannot be omitted. The new certificate type would need to get support within the deployed tools and servers. Likely, servers will still load a selfsigned cert with all the unused fields just for compatibility with older TLS clients, and the server process would create the SBKI certificate type to use when TLS clients connecting indicate such support. However, new implementations written to exclude full PKIX support would not need to support this, and ideally openssl and other tools will support creating such SKBI certifiactes in the future. > Also you have said that the > entire problem is that you cannot deal with the PKIX structure, and how you > are suddenly doubling the amount of code that I need to deal with PKIX since > I now have both a certificate with fields and a certificate w/o fields. Why > do you not say that your data structure for a "raw key certificate" is just > going to be the SubjectPublicKeyInfo DER encoded structure? This would be > much simpler and clearer as well as reducing the amount of ASN.1 processing > substantially. Don't we say that? If the negotiated certificate type is RawPublicKey the TLS server MUST place the SubjectPublicKeyInfo structure into the Certificate payload. The public key MUST match the selected key exchange algorithm. > 5. You are missing text that needs to be in place about the use of client > authentication from a raw key. I don't know if this is what you really want > to do or not. It is going to be much harder for a server to do the oob > authentication without registration of some type. Additionally this would > mean that your justification of wanting to suppress the sending of the > server certificate would need to be documented as not working at all if you > want to do client authentication. Since one case where you might want to do > the suppression would be a re-authentication process for protected client > auth, this does not make any since (in this case you already have the > servers certificates from the previous handshake). Does this mean that you > want to have the ability to have an asymmetric method of specifying the > "certificate type" so that one can do bare key from server to client, but > pkix certificate from client to server? This is not an issue for the case > of PGP since one can assume that both the server and the client are going to > use PGP certificates for the purpose of authentication. This was why I originally had the equivalent of the SNI for the client side in the first draft, so the client could convey its identity that the server could then look up credentials out-of-band. Currently, the TLS server can only do out-of-band authentication of the TLS client based on the clients SBKI. Do you suggest we should add this back into this document, or provide a seperate draft for such new TLS extension? > 6. Security considerations - para #2 - It is easy to establish the > authenticity of the public key - just see if the cryptography works. What > you want to be able to authenticate is the binding between the public key > and the entity or service you are attempting to contact. This was addressed in -02 I believe. > 7. Security considerations - does not talk about client/public key binding > authentication by the server at all - this is a short coming This has not yet been addressed. Based on feedback of client SNI version, we could add some text in the section. Paul From internet-drafts@ietf.org Sun Mar 11 14:35:33 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72FE21F8688; Sun, 11 Mar 2012 14:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vuNQZ1sPowV; Sun, 11 Mar 2012 14:35:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85421F865D; Sun, 11 Mar 2012 14:35: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: 4.00 Message-ID: <20120311213533.28900.30345.idtracker@ietfa.amsl.com> Date: Sun, 11 Mar 2012 14:35:33 -0700 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-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: Sun, 11 Mar 2012 21:35: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 : TLS Out-of-Band Public Key Validation Author(s) : Paul Wouters John Gilmore Samuel Weiler Tero Kivinen Hannes Tschofenig Filename : draft-ietf-tls-oob-pubkey-02.txt Pages : 10 Date : 2012-03-11 This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. Currently, TLS authentication can only occur via X.509-based Public Key Infrastructure (PKI) or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative public key validation methods. One such alternative public key valiation method is offered by the DNS-Based Authentication of Named Entities (DANE) together with DNS Security. Another alternative is to utilize pre-configured keys, as is the case with sensors and other embedded devices. The usage of raw public keys, instead of X.509-based certificates, leads to a smaller code footprint. The support for raw public keys is introduced into TLS via a new non- PKIX certificate type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-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-oob-pubkey-02.txt From mbadra@gmail.com Tue Mar 13 14:11:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94F021F861E for ; Tue, 13 Mar 2012 14:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.215 X-Spam-Level: X-Spam-Status: No, score=-3.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yidRP3VKlLEJ for ; Tue, 13 Mar 2012 14:11:00 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8B6321F84C9 for ; Tue, 13 Mar 2012 14:10:59 -0700 (PDT) Received: by lagj5 with SMTP id j5so1040728lag.31 for ; Tue, 13 Mar 2012 14:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=V8+0nIrpwMhb4igUdyIB2k1GgcnDtaYwrWqy+43Y4M8=; b=J6bQUFng8TZJGi5i2Z/ItrVxH4JfZnS62z1oSI+xZHRt6PJ9xQ+vTMeRVNzEpBT7Z9 CbAkW34QuMtGM8eMjejStlso2ByRI2iHWylHEouu88fmjuMYsBxUXWfY3CIPA7dKnwXI GnNPr5y6/3Im65iQA96A+iJ/AR/ZLOUklvw8iffTj4hZ6qI7t7bc6vXLhF/NMeGpQ5EU Tw+KAgbxRqWpJVQx01aVZZnp+SUgXHbwraODloFKsSPldNmXSCnYhS2LuntrMdI015jM EY5Oyhhm52djU95niBRGzIvENVYgBsWn1RLUhtMQZoCfAA7kbFlX8OCbdBADtQcjYmj4 qVyQ== MIME-Version: 1.0 Received: by 10.112.23.100 with SMTP id l4mr30795lbf.24.1331673058749; Tue, 13 Mar 2012 14:10:58 -0700 (PDT) Received: by 10.152.21.36 with HTTP; Tue, 13 Mar 2012 14:10:58 -0700 (PDT) Date: Tue, 13 Mar 2012 22:10:58 +0100 Message-ID: From: Mohamad Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=90e6ba3093509fab8104bb264b09 Subject: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 21:11:01 -0000 --90e6ba3093509fab8104bb264b09 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I have taken an initial crack at a document that defines a set of cipher suites to add client credential protection to TLS: http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersuite-identity-protection-00.txt Looking forward for your comments, best regards Badra --90e6ba3093509fab8104bb264b09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

I have taken an i= nitial crack at a document that=A0defines a set of cipher suites to add client credential=A0protect= ion to TLS:


Looking forward for your comments, best regards
Badra
--90e6ba3093509fab8104bb264b09-- From hannes.tschofenig@nsn.com Wed Mar 14 05:46:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0B021F8782 for ; Wed, 14 Mar 2012 05:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.389 X-Spam-Level: X-Spam-Status: No, score=-106.389 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdhHG43mrBOX for ; Wed, 14 Mar 2012 05:46:36 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2625F21F875B for ; Wed, 14 Mar 2012 05:46:35 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2ECkXPH026111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Mar 2012 13:46:33 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2ECk4X2013400; Wed, 14 Mar 2012 13:46:33 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 13:46:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD01E0.75E9B026" Date: Wed, 14 Mar 2012 14:46:21 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0BXdxM8caJ9DFuSUiKXbVoakW56gAgkY4w References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Mohamad Badra" , X-OriginalArrivalTime: 14 Mar 2012 12:46:23.0324 (UTC) FILETIME=[7655A9C0:01CD01E0] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6657 X-purgate-ID: 151667::1331729194-000033AC-7002978A/0-0/0-0 Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 12:46:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD01E0.75E9B026 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Badra,=20 =20 I looked at your document but I do not quite understand what you are trying to accomplish.=20 =20 When you say that you want to "protect" the client credentials what do you mean? When a client authenticates to the server based on public key cryptography it sends a certificate (among other things).=20 =20 Could you elaborate? =20 Ciao Hannes =20 =20 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Mohamad Badra Sent: Tuesday, March 13, 2012 11:11 PM To: tls@ietf.org Subject: [TLS] cipher suites for protecting client credentials =20 Dear all, =20 I have taken an initial crack at a document that defines a set of cipher suites to add client credential protection to TLS: =20 http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphers uite-identity-protection-00.txt =20 Looking forward for your comments, best regards Badra ------_=_NextPart_001_01CD01E0.75E9B026 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Badra,

 

I looked at your document but I do not quite understand what you are = trying to accomplish.

 

When you say that you want to “protect” the client = credentials what do you mean?

When a client authenticates to the server based on public key = cryptography it sends a certificate (among other things). =

 

Could you elaborate?

 

Ciao

Hannes

 

 

From:= = tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = ext Mohamad Badra
Sent: Tuesday, March 13, 2012 11:11 = PM
To: tls@ietf.org
Subject: [TLS] cipher suites for = protecting client credentials

 

Dear = all,

 

I = have taken an initial crack at a document that defines a set of = cipher suites to add client credential protection to = TLS:

 

------_=_NextPart_001_01CD01E0.75E9B026-- From ynir@checkpoint.com Wed Mar 14 06:22:08 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A0821F86E5 for ; Wed, 14 Mar 2012 06:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AubKqAnPpMA for ; Wed, 14 Mar 2012 06:22:07 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 902A221F86C7 for ; Wed, 14 Mar 2012 06:22:06 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2EDM3Bm010069; Wed, 14 Mar 2012 15:22:03 +0200 X-CheckPoint: {4F609B5D-3-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 14 Mar 2012 15:22:03 +0200 From: Yoav Nir To: "Tschofenig, Hannes (NSN - FI/Espoo)" Date: Wed, 14 Mar 2012 15:22:04 +0200 Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0B5XFoalMDRTHmSJy9ulED567zHg== Message-ID: <87FBF4ED-34AE-449F-B542-F0CB144E54A0@checkpoint.com> References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> 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: multipart/alternative; boundary="_000_87FBF4ED34AE449FB542F0CB144E54A0checkpointcom_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:22:08 -0000 --_000_87FBF4ED34AE449FB542F0CB144E54A0checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hannes There was some talk about things like this in Taipei. His ciphersuites move= the client Certificate to after the CCS, so a passive eavesdropper does no= t get the client identity. Yoav On Mar 14, 2012, at 2:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Badra, I looked at your document but I do not quite understand what you are trying= to accomplish. When you say that you want to =93protect=94 the client credentials what do = you mean? When a client authenticates to the server based on public key cryptography = it sends a certificate (among other things). Could you elaborate? Ciao Hannes From: tls-bounces@ietf.org [mailto:tls-bounces= @ietf.org] On Behalf Of ext Mohamad Badra Sent: Tuesday, March 13, 2012 11:11 PM To: tls@ietf.org Subject: [TLS] cipher suites for protecting client credentials Dear all, I have taken an initial crack at a document that defines a set of cipher su= ites to add client credential protection to TLS: http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersuit= e-identity-protection-00.txt Looking forward for your comments, best regards Badra Scanned by Check Point Total Security Gateway. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_87FBF4ED34AE449FB542F0CB144E54A0checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hannes

There was some talk about things like this in= Taipei. His ciphersuites move the client Certificate to after the CCS, so = a passive eavesdropper does not get the client identity.

Yoav

On Mar 14, 2012, at 2:46 PM, Tschofenig= , Hannes (NSN - FI/Espoo) wrote:

Hi Badra,
&nb= sp;
I looked at your document but I do= not quite understand what you are trying to accomplish.<= /div>
 
Wh= en you say that you want to =93protect=94 the client credentials what do yo= u mean?
When a client authenticat= es to the server based on public key cryptography it sends a certificate (a= mong other things).
 
Could you elaborate?<= /div>
 
Ci= ao
Hannes
=
 
&n= bsp;
 
Dear all,
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; margin-b= ottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">=  
I have taken an initial crack at a docum= ent that defines a set of cipher suites to add client credential = protection to TLS:


Scanned by Check Point Total Security Gateway. 

___________________= ____________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/= tls

= --_000_87FBF4ED34AE449FB542F0CB144E54A0checkpointcom_-- From hannes.tschofenig@nsn.com Wed Mar 14 06:37:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2831A21F87B8 for ; Wed, 14 Mar 2012 06:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.393 X-Spam-Level: X-Spam-Status: No, score=-106.393 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bF2xyKnPcKQ for ; Wed, 14 Mar 2012 06:37:49 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1399E21F87AA for ; Wed, 14 Mar 2012 06:37:48 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2EDbeLM008034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Mar 2012 14:37:40 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2EDbdNg019553; Wed, 14 Mar 2012 14:37:39 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 14:37:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD01E7.9FF2A0A6" Date: Wed, 14 Mar 2012 15:37:37 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01382676@FIESEXC035.nsn-intra.net> In-Reply-To: <87FBF4ED-34AE-449F-B542-F0CB144E54A0@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0B5XFoalMDRTHmSJy9ulED567zHgAAfGlQ References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> <87FBF4ED-34AE-449F-B542-F0CB144E54A0@checkpoint.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Yoav Nir" X-OriginalArrivalTime: 14 Mar 2012 13:37:40.0162 (UTC) FILETIME=[A045E220:01CD01E7] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 12740 X-purgate-ID: 151667::1331732260-000044A2-C50F9F46/0-0/0-0 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:37:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD01E7.9FF2A0A6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav,=20 =20 I was in Taipei at the meeting and I even do not recall this. I guess it should be explained in the draft.=20 =20 I also have a proposal for the terminology: http://tools.ietf.org/html/draft-iab-privacy-terminology-01 =20 Ciao Hannes =20 =20 From: ext Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Wednesday, March 14, 2012 3:22 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: ext Mohamad Badra; tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials =20 Hi Hannes =20 There was some talk about things like this in Taipei. His ciphersuites move the client Certificate to after the CCS, so a passive eavesdropper does not get the client identity. =20 Yoav =20 On Mar 14, 2012, at 2:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Badra, =20 I looked at your document but I do not quite understand what you are trying to accomplish. =20 When you say that you want to "protect" the client credentials what do you mean? When a client authenticates to the server based on public key cryptography it sends a certificate (among other things). =20 Could you elaborate? =20 Ciao Hannes =20 =20 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Mohamad Badra Sent: Tuesday, March 13, 2012 11:11 PM To: tls@ietf.org Subject: [TLS] cipher suites for protecting client credentials =20 Dear all, =20 I have taken an initial crack at a document that defines a set of cipher suites to add client credential protection to TLS: =20 http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphers uite-identity-protection-00.txt =20 Looking forward for your comments, best regards Badra Scanned by Check Point Total Security Gateway.=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 ------_=_NextPart_001_01CD01E7.9FF2A0A6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav,

 

I was in Taipei at the meeting and I even do not recall this. I guess = it should be explained in the draft.

 

I also have a proposal for the terminology:

http= ://tools.ietf.org/html/draft-iab-privacy-terminology-01

 

Ciao
Hannes

 

 

From:= = ext Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Wednesday, = March 14, 2012 3:22 PM
To: Tschofenig, Hannes (NSN - = FI/Espoo)
Cc: ext Mohamad Badra; = tls@ietf.org
Subject: Re: [TLS] cipher suites for protecting = client credentials

 

Hi = Hannes

 

There was some talk about things like this in Taipei. = His ciphersuites move the client Certificate to after the CCS, so a = passive eavesdropper does not get the client = identity.

 

Yoav

 

On = Mar 14, 2012, at 2:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote:



Hi Badra,

 

I looked at your document but I do not quite understand what you are = trying to accomplish.

 

When you say that you want to “protect” the client = credentials what do you mean?

When a client authenticates to the server based on public key = cryptography it sends a certificate (among other = things).

 

Could you elaborate?

 

Ciao

Hannes

 

 

From:=  tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Mohamad = Badra
Sent: Tuesday, March 13, 2012 11:11 = PM
To: tls@ietf.org
Subject: [TLS] cipher suites for = protecting client = credentials

 

Dear all,

 

I have taken an initial crack at a document = that defines a set of cipher suites to add client = credential protection to = TLS:

 



Scan= ned by Check Point Total Security Gateway. 

______________________= _________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/m= ailman/listinfo/tls

 

------_=_NextPart_001_01CD01E7.9FF2A0A6-- From mbadra@gmail.com Wed Mar 14 06:39:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93FC21F8760 for ; Wed, 14 Mar 2012 06:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12nvyeSMkO-E for ; Wed, 14 Mar 2012 06:39:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A448921F857D for ; Wed, 14 Mar 2012 06:39:48 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2371990vcb.31 for ; Wed, 14 Mar 2012 06:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P3gjRfEYSV78Er/EYzovbPXh4jpu6TCnwkkXn9W6mtU=; b=jlXQk0h9rkAo0QzrNC/S/5HGuZY2MuO+WL9iWj9mytGNaNKUOkYtrHlcjV852dntk+ jH1PZHJBYLWb1YLmV9LAasNXn2ZkGjQbTOX/dRbCIcZyjZECVsoOQHThtjdWFAjS/PA6 Qdrh5G1dTtERcNJLSs0abZk7Y+BDX0J1X2oGj7IzZUV/fYKHiUrhdobY9YJzE2fIEYDC o3J7eKqu+lq06EWnjjjGImwjB10f/Oek2RUChp8z8TLBNCnNxqRanj+S81/yGStI2fdJ DbbpLMNLnplP5HgdStZbdCCv5aXhwkDebIpMYOD6qM8OfZMpGccOzwBhkmdS13yK0yiE h1qA== MIME-Version: 1.0 Received: by 10.52.70.209 with SMTP id o17mr1968349vdu.11.1331732388068; Wed, 14 Mar 2012 06:39:48 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 14 Mar 2012 06:39:48 -0700 (PDT) In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> Date: Wed, 14 Mar 2012 14:39:48 +0100 Message-ID: From: Mohamad Badra To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: multipart/alternative; boundary=20cf307f32dced3e7304bb341bb8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:39:49 -0000 --20cf307f32dced3e7304bb341bb8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hannes Yoav answered your question. "protect" the client credentials is to avoid sending the client certificate in cleartext during TLS Handshake Best regards Badra On Wed, Mar 14, 2012 at 1:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) < hannes.tschofenig@nsn.com> wrote: > Hi Badra, **** > > ** ** > > I looked at your document but I do not quite understand what you are > trying to accomplish. **** > > ** ** > > When you say that you want to =93protect=94 the client credentials what d= o you > mean?**** > > When a client authenticates to the server based on public key cryptograph= y > it sends a certificate (among other things). **** > > ** ** > > Could you elaborate?**** > > ** ** > > Ciao**** > > Hannes**** > > ** ** > > ** ** > > *From:* tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] *On Behalf Of = *ext > Mohamad Badra > *Sent:* Tuesday, March 13, 2012 11:11 PM > *To:* tls@ietf.org > *Subject:* [TLS] cipher suites for protecting client credentials**** > > ** ** > > Dear all,**** > > ** ** > > I have taken an initial crack at a document that defines a set of cipher > suites to add client credential protection to TLS:**** > > ** ** > > > http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersu= ite-identity-protection-00.txt > **** > > ** ** > > Looking forward for your comments, best regards**** > > Badra**** > --20cf307f32dced3e7304bb341bb8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Hannes

Yoav answered your question.= =A0

"protect" the client credentials is = to avoid sending the client certificate in cleartext during TLS Handshake

Best regards
Badra

On Wed, Mar 14, 2012 at 1:46 PM, Tschofenig, Hannes (NSN -= FI/Espoo) <hannes.tschofenig@nsn.com> wrote:

Hi Badra, =

=A0<= /p>

I looked at your docum= ent but I do not quite understand what you are trying to accomplish.

=A0<= /p>

When you say that you = want to =93protect=94 the client credentials what do you mean?

When a client authenticat= es to the server based on public key cryptography it sends a certificate (a= mong other things).

=A0<= /p>

Could you elaborate?

=A0<= /p>

Ciao

Hannes

=A0

=A0<= /p>

From: tls-bounces= @ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Mohamad Badra
Sent: Tuesday, March 13, 2012 11:11 PM
To: tls@ietf.org
Subject: [TLS= ] cipher suites for protecting client credentials

<= /div>

=A0

Dear all,

=A0

I have taken a= n initial crack at a document that=A0defines a set of cipher suites to add = client credential=A0protection to TLS:

=A0

=A0

Looking forward for your comments, best regards

Badra

<= /div>

--20cf307f32dced3e7304bb341bb8-- From tom@ritter.vg Wed Mar 14 06:42:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918F821F8760 for ; Wed, 14 Mar 2012 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6YSSHZKpi9e for ; Wed, 14 Mar 2012 06:42:10 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEE2E21F8751 for ; Wed, 14 Mar 2012 06:42:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2082289ghb.31 for ; Wed, 14 Mar 2012 06:42:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=grFTtOfZVzO3OUieaJbLjVEqqeXzbrwW9NhqTk1Dj4A=; b=okgnTatnoUw3YIQ/xd8irFjkVDT4eInDEpltd2ZlxcVYmkY7e00rU7oq2dn9xMS3EJ jSp/YLJAeU6Gcu7Cdmr64SbETrVkzWZ3B+Y3RvmjId5EWR5GmFt/1Ftk0uG4MBbD9cWk 24QQ6D4Oe+rYwyb8m8fkboGEotaO2OLvDjto0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=grFTtOfZVzO3OUieaJbLjVEqqeXzbrwW9NhqTk1Dj4A=; b=O9cbvCdi5IxdD2xL5xBiGEhqTNxTzsgDL6h0KdxN47zXXJoiXvOxALbEyihLSyV5ji OOMuGDOO4klp62vZYYBCExVk6JVY0ep4e43DjjCdmXKAzs8lgucEUMAym0OAWe4WQaj3 2hdad/ch6LIdFNdsAoMO9+x5EJpR3JfqMfOacdG73qxSEyCmqyRzGc2jlzTP159EYsCA Z42fdv3BCMCbjk7ckRhg8RwHRwkPmzQfHhAdfOOY84mqWXKJ7W1dc4fL5CAjR5UTDQnK elAxwpHyyBxjW2R53dwq5bMKVfarHtay1ODuS0pFOWxkmqAJkn/F2zaF8KAMWKhlMl+z JQRg== Received: by 10.60.26.65 with SMTP id j1mr3566302oeg.6.1331732529410; Wed, 14 Mar 2012 06:42:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.89.98 with HTTP; Wed, 14 Mar 2012 06:41:49 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Wed, 14 Mar 2012 09:41:49 -0400 Message-ID: To: Mohamad Badra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn8VbZoCVyvh4aIidQDDyY6ZNrZohkBgSE14FGQ+iIDFxWfUYPkLJzaWrtJtvqgDwSvAaH6 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:42:10 -0000 On 13 March 2012 17:10, Mohamad Badra wrote: > I have taken an initial crack at a document that=A0defines a set of ciphe= r > suites to add client credential=A0protection to TLS: > > http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersu= ite-identity-protection-00.txt What's the advantage of using ciphersuites instead of an extension? This was already proposed in the form of an extension: http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts - using ciphersuites seems much more messy. You're pidgeon-holed into using the specific ciphersuites that are defined in the draft - no DHE, no AES-GCM, etc etc. Plus there's the massive ballooning of ciphersuites defined. I think (not sure) that it could inflate the ClientHello moreso than an extension also. I like the idea though. -tom From hannes.tschofenig@nsn.com Wed Mar 14 06:47:27 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D242B21F87DC for ; Wed, 14 Mar 2012 06:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.398 X-Spam-Level: X-Spam-Status: No, score=-106.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2OgzKMcIb9g for ; Wed, 14 Mar 2012 06:47:27 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8821F87D7 for ; Wed, 14 Mar 2012 06:47:26 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2EDlJHK002757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Mar 2012 14:47:19 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2EDlJ43001980; Wed, 14 Mar 2012 14:47:19 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 14:47:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 15:47:17 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01382687@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0B5/CZfs5qptG4Rl6A8CCzyYIEbAAAAfLg References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Mohamad Badra" X-OriginalArrivalTime: 14 Mar 2012 13:47:19.0747 (UTC) FILETIME=[F9BB8930:01CD01E8] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2283 X-purgate-ID: 151667::1331732840-000044A2-2F836F48/0-0/0-0 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:47:27 -0000 Hi Mohamad,=20 One aspect we noticed when the IAB did privacy reviews of existing IETF = specifications was that most people did not describe their threat model = and the terminology was often confusing as well.=20 You may also want to take a look at our most recent version of the = privacy guidelines document:=20 http://tools.ietf.org/html/draft-iab-privacy-considerations-02 I believe you mostly care eavesdroppers along the path between the TLS = client and the TLS server when using client-side authentication within = TLS. Correct? We defined the term "Identity Confidentiality" in = http://tools.ietf.org/html/draft-iab-privacy-terminology-01#section-3.3 and it covers this case.=20 I do not believe you provide any other privacy properties in your = proposal (which is OK).=20 Ciao Hannes From: ext Mohamad Badra [mailto:mbadra@gmail.com]=20 Sent: Wednesday, March 14, 2012 3:40 PM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials Hi Hannes Yoav answered your question.=A0 "protect" the client credentials is to avoid sending the client = certificate in cleartext during TLS Handshake Best regards Badra On Wed, Mar 14, 2012 at 1:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote: Hi Badra,=20 =A0 I looked at your document but I do not quite understand what you are = trying to accomplish.=20 =A0 When you say that you want to "protect" the client credentials what do = you mean? When a client authenticates to the server based on public key = cryptography it sends a certificate (among other things).=20 =A0 Could you elaborate? =A0 Ciao Hannes =A0 =A0 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = ext Mohamad Badra Sent: Tuesday, March 13, 2012 11:11 PM To: tls@ietf.org Subject: [TLS] cipher suites for protecting client credentials =A0 Dear all, =A0 I have taken an initial crack at a document that=A0defines a set of = cipher suites to add client credential=A0protection to TLS: =A0 http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphersu= ite-identity-protection-00.txt =A0 Looking forward for your comments, best regards Badra From mbadra@gmail.com Wed Mar 14 06:59:31 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD9D21F8778 for ; Wed, 14 Mar 2012 06:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3jLZTSrCSWN for ; Wed, 14 Mar 2012 06:59:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44FE421F8653 for ; Wed, 14 Mar 2012 06:59:31 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2397087vcb.31 for ; Wed, 14 Mar 2012 06:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YHVYm5MMVEzPB20PL72TErqiaNLNY62d68S6FduhX0A=; b=psJnBMUVQpzZmM4RMK9OrAg4CP4IBJ0M1e/8fJuFKVVOEkiaz9j38rHHpq9gB6jBaf 217dGftRrvCY33FYXTv2h1CIPU0UoGZrO3Knzyc6n8GTwRO+dkTQVSXzm3MIVa3hPKCU EjuKL+6vxUCKMdHqlGNWf4mvbx0iVMO59nU4UEXSYR2BTzFEWi9jtxFvasI1K7Gcg5Y6 IZKv9/m+aB1nmy7domAF7gBtNh2JBZvRSlVNGerzXrornuzh5Orh2Z8Uu8Mw4gDPNFzY kK6h2Yqd7i77LL2NlGbGnU+YjmFXnMF1Rqlsjx9fYSf7RhkCj9kKGbHtbPj+a4Dz1oM+ tsgw== MIME-Version: 1.0 Received: by 10.52.240.232 with SMTP id wd8mr1948233vdc.96.1331733570807; Wed, 14 Mar 2012 06:59:30 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 14 Mar 2012 06:59:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 14:59:30 +0100 Message-ID: From: Mohamad Badra To: Tom Ritter Content-Type: multipart/alternative; boundary=20cf307cfd046c675104bb3462e1 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:59:32 -0000 --20cf307cfd046c675104bb3462e1 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom On Wed, Mar 14, 2012 at 2:41 PM, Tom Ritter wrote: > > What's the advantage of using ciphersuites instead of an extension? > Martin Rex already discussed that on http://www.ietf.org/mail-archive/web/tls/current/msg08288.html Another reason is that extension-based solution This solution may sufferfrom interoperability issues related to TLS Extensions, TLS 1.0 and TLS 1.1 implementations using > ciphersuites seems much more messy. You're pidgeon-holed into using > the specific ciphersuites that are defined in the draft - no DHE, no > AES-GCM, etc etc. Plus there's the massive ballooning of ciphersuites > defined. I think (not sure) that it could inflate the ClientHello > moreso than an extension also. > > Last November, I posted another a way to signal the change in the messages' order by defining a single SCSV. Please see draft-badra-tls-identity-protection-01 You cannot enable DHE and ECDHE and have certificate confidentiality if you send CCS before the client certificate. However, I posted a document during 2009 that supports both DHE and ECDHE key exchange algorithms. This document [1] had been approved by IESG but never published as RFC (RFC-Editor denied its publication recently) [1] draft-hajjeh-tls-identity-protection-09 Best regards Badra --20cf307cfd046c675104bb3462e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom

On Wed, Mar 14, 2= 012 at 2:41 PM, Tom Ritter <tom@ritter.vg> wrote:

What's the advantage of using ciphersuites instead of an extensio= n?
=A0

Another reason is that extension-based solution=A0This solution may suffer from interoperab= ility issues related to TLS Extensions, TLS 1.0 and=A0TLS 1.1 implementatio= ns


using
ciphersuites seems much more messy. =A0You're pidgeon-holed into using<= br> the specific ciphersuites that are defined in the draft - no DHE, no
AES-GCM, etc etc. =A0Plus there's the massive ballooning of ciphersuite= s
defined. =A0I think (not sure) that it could inflate the ClientHello
moreso than an extension also.


Last November, I posted another a way = to signal the change in the messages' order by defining a single SCSV. = Please see=A0draft-badra-tls-identity-protection-01

You cannot enable DHE and=A0ECDHE and ha= ve certificate confidentiality if you send CCS before the client certificat= e. However, I posted a document during 2009 that supports both DHE and=A0ECDHE key exchange algorithms. This docu= ment [1] had been approved by IESG but never published as RFC (RFC-Editor d= enied its publication recently)
[1]=A0draft-hajjeh-tls-identity-p= rotection-09

Best regards
Badra
--20cf307cfd046c675104bb3462e1-- From mbadra@gmail.com Wed Mar 14 07:04:04 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5621F8656 for ; Wed, 14 Mar 2012 07:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.406 X-Spam-Level: X-Spam-Status: No, score=-3.406 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xjnqvj-BVaiJ for ; Wed, 14 Mar 2012 07:04:04 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2E3621F85A3 for ; Wed, 14 Mar 2012 07:04:03 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1550056bku.31 for ; Wed, 14 Mar 2012 07:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PY4YKAb+imGesuKvamWl2CfEJXHnPdl1kTwp0SH3ReY=; b=MctHGFyxvNmu3MWY0WcjqE6UhUz08LHod/75sMqC4+yUoz7jJng5mru5B6xNihUShn PUtiUHHZihFsp3hsnZxqQKsPMQr5BcmPvyEp0LfpAsGN6SoM4NyMNYgKVU/FeeXXGKV1 6UE2cr403TBig8QbaFm0fPVL0WbYsshdAkgCOKMcDDLnvTYw6IVR+TtLmecr5SEP54Pd k4Kx4nIN2QAy25QzvigkEoalNJxzSQQqUw4A4QytbfOAZNzn9FybRG7z4R1adZKTvdrw D7ISzniENirTxQTQCmnYVGnODXsqATrhSuiesfMJ0+XponlTnXSkmfKYZD/ABMNFUICm 59RA== MIME-Version: 1.0 Received: by 10.52.70.209 with SMTP id o17mr2044276vdu.11.1331733842586; Wed, 14 Mar 2012 07:04:02 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 14 Mar 2012 07:04:02 -0700 (PDT) In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382687@FIESEXC035.nsn-intra.net> References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718D01382687@FIESEXC035.nsn-intra.net> Date: Wed, 14 Mar 2012 15:04:02 +0100 Message-ID: From: Mohamad Badra To: "Tschofenig, Hannes (NSN - FI/Espoo)" Content-Type: multipart/alternative; boundary=20cf307f32dc9f6d4a04bb347254 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:04:05 -0000 --20cf307f32dc9f6d4a04bb347254 Content-Type: text/plain; charset=ISO-8859-1 Hi Hannes, You may also want to take a look at our most recent version of the privacy > guidelines document: > http://tools.ietf.org/html/draft-iab-privacy-considerations-02 > > I believe you mostly care eavesdroppers along the path between the TLS > client and the TLS server when using client-side authentication within TLS. > Correct? > > Correct! > We defined the term "Identity Confidentiality" in > http://tools.ietf.org/html/draft-iab-privacy-terminology-01#section-3.3 > and it covers this case. > I read Section 3.3 and it describes the problem addressed by the draft. I do not believe you provide any other privacy properties in your proposal > (which is OK). > > True. > Ciao > Hannes > > > Best regards, Badra --20cf307f32dc9f6d4a04bb347254 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hannes,

You may also want to take a look at our most recent vers= ion of the privacy guidelines document:
http://tools.ietf.org/html/draft-iab-privacy-consideratio= ns-02

I believe you mostly care eavesdroppers along the path between the TLS clie= nt and the TLS server when using client-side authentication within TLS. Cor= rect?


Correct!
=A0
We defined the term "Identity Confidentiality" in http://tools.ietf.org/html/draft-iab-privacy-terminology-01#sec= tion-3.3
and it covers this case.
=A0

= =A0I read Section 3.3 and it describes the problem addressed by the draft.<= /div>

I do not believe you provide any other privacy properties in your proposal = (which is OK).


True.
=A0
Ciao
Hannes



Best regards,
Badra=A0
=
--20cf307f32dc9f6d4a04bb347254-- From yngve@opera.com Wed Mar 14 07:20:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CE021F87DA for ; Wed, 14 Mar 2012 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.166 X-Spam-Level: X-Spam-Status: No, score=-7.166 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRPAPXxFLuxQ for ; Wed, 14 Mar 2012 07:20:20 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 18F2921F87D8 for ; Wed, 14 Mar 2012 07:20:19 -0700 (PDT) Received: from damia.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2EEKHeZ024121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 14 Mar 2012 14:20:18 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: Date: Wed, 14 Mar 2012 15:20:15 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve Nysaeter Pettersen" Organization: Opera Software Message-ID: In-Reply-To: User-Agent: Opera Mail/11.61 (Win32) Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:20:21 -0000 On Wed, 14 Mar 2012 14:59:30 +0100, Mohamad Badra wrote: > Hi Tom > > On Wed, Mar 14, 2012 at 2:41 PM, Tom Ritter wrote: > >> >> What's the advantage of using ciphersuites instead of an extension? >> > > Martin Rex already discussed that on > http://www.ietf.org/mail-archive/web/tls/current/msg08288.html > > Another reason is that extension-based solution This solution may > sufferfrom interoperability issues related to TLS Extensions, TLS 1.0 > and TLS 1.1 > implementations 1: Servers will have to be updated in any case to handle this new method, that means that they will (or should) not have interoperability issues with extensions (if for no other reason that they should also get the Renego issue fixed at the same time, if they have not already done so) 2: Modern clients (browsers in particualr) already send TLS extensions (a selection of SNI, Renego Extension, Certificate Status, Session tickets, ECC, etc.) and already have policies for handling version and extension intolerant servers. IOW, adding a new extension will not change the current situation in any way. According to my scans, currently 1.58% of servers are extension intolerant, down from 1.75% 6 months ago. IMO, if this is implemented, it should be implemented using an extension, not cipher suites. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From Ken.Peirce@ONSTAR.com Wed Mar 14 07:29:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FE221E803B for ; Wed, 14 Mar 2012 07:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHIHzCaGCQ4r for ; Wed, 14 Mar 2012 07:29:40 -0700 (PDT) Received: from ahgmler2.imr.gm.com (ahgmler2.imr.gm.com [192.85.154.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4C02921F8505 for ; Wed, 14 Mar 2012 07:29:39 -0700 (PDT) Received: from ahgmlir1.imr.gm.com (ahgmlir1-2.imr.gm.com [192.85.154.169]) by ahgmler2.imr.gm.com (8.14.4/8.13.8) with ESMTP id q2EETU23031715; Wed, 14 Mar 2012 10:29:30 -0400 Received: from ahgmlir1.imr.gm.com (localhost [127.0.0.1]) by ahgmlir1.imr.gm.com (8.14.4/8.12.10) with ESMTP id q2EET04A015354; Wed, 14 Mar 2012 10:29:00 -0400 Received: from USRN4EX0ONS04.onstar.ad.gm.com (usrn4ex0ons04-perm.onstar.ad.gm.com [164.56.144.77] (may be forged)) by ahgmlir1.imr.gm.com (8.14.4/8.12.10) with ESMTP id q2EET0Gr015284; Wed, 14 Mar 2012 10:29:00 -0400 X-EDSINT-Source-Ip: 164.56.144.77 X-EDSINT-Source-Name: [164.56.144.77] X-EDSINT-Reported-Name: USRN4EX0ONS04.onstar.ad.gm.com X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD01EE.CBFD1EE3" Date: Wed, 14 Mar 2012 10:28:59 -0400 Message-ID: <57317BDCBE4B754BBA77A7938FA042A002DEF931@USRN4EX0ONS04.onstar.ad.gm.com> In-Reply-To: <87FBF4ED-34AE-449F-B542-F0CB144E54A0@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0B5XFoalMDRTHmSJy9ulED567zHgAAd0Mg References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> <87FBF4ED-34AE-449F-B542-F0CB144E54A0@checkpoint.com> From: "Peirce, Ken" To: "Yoav Nir" , "Tschofenig, Hannes (NSN - FI/Espoo)" X-CFilter-Loop: Reflected Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:29:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD01EE.CBFD1EE3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Badra et alia., =20 I want to be certain I understand the draft. =20 1. The Server authenticates itself to the Client. 2. The Client does *not* provide either a temporary or certificate based public key for the establishment of the TLS session. 3. The Client issues the CCS to signal encryption will be employed from that point on. At this point the Client has the all of the material required to generate the session's encryption key. 4. The Client now presents an encrypted certificate to the Server. This provides the Server with the material it requires to generate the session's encryption key. 5. The Server can now issue its CCS to signal its future use of encryption. =20 I believe that the above is technically correct/feasible. =20 =20 One widely accepted layering principle is to decouple service authorization from client authentication on access. We therefore recommend that authorization decisions be performed and communicated at the application layer after the TLS handshake has been completed. =20 1. I like the idea of protecting the identity of the Client.=20 2. I like the idea of having the application perform the Client certificate validation. It can result in the simplification of the TLS API/interface. =20 =20 3. The only potential downsides I see are practical.=20 1. Pushing the authentication up the stack from its present location decentralizes the authentication process. This will likely increase the latency for session establishment that in turn may affect the scalability of the solutions that employ this method. =20 2. The linking software between the Transport and Application layers will need to be fuzz tested to avoid introducing vulnerabilities. =20 Clever idea. Thanks, Ken =20 =20 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, March 14, 2012 9:22 AM To: Tschofenig, Hannes (NSN - FI/Espoo) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials =20 Hi Hannes =20 There was some talk about things like this in Taipei. His ciphersuites move the client Certificate to after the CCS, so a passive eavesdropper does not get the client identity. =20 Yoav =20 On Mar 14, 2012, at 2:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Badra, =20 I looked at your document but I do not quite understand what you are trying to accomplish. =20 When you say that you want to "protect" the client credentials what do you mean? When a client authenticates to the server based on public key cryptography it sends a certificate (among other things). =20 Could you elaborate? =20 Ciao Hannes =20 =20 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Mohamad Badra Sent: Tuesday, March 13, 2012 11:11 PM To: tls@ietf.org Subject: [TLS] cipher suites for protecting client credentials =20 Dear all, =20 I have taken an initial crack at a document that defines a set of cipher suites to add client credential protection to TLS: =20 http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-ciphers uite-identity-protection-00.txt =20 Looking forward for your comments, best regards Badra Scanned by Check Point Total Security Gateway.=20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 ------_=_NextPart_001_01CD01EE.CBFD1EE3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Badra et alia.,

 

I want to be certain I understand the draft.

 

1. The Server authenticates itself to the = Client.

2. The Client does *not* provide either a temporary or = certificate based public key for the establishment of the TLS = session.

3. The Client issues the CCS to signal encryption will be employed = from that point on. At this point the Client has the all of the material = required to generate the session’s encryption = key.

4. The Client now presents an encrypted certificate to the Server. = This provides the Server with the material it requires to generate the = session’s encryption key.

5. The Server can now issue its CCS to signal its future use of = encryption.

 

I believe that the above is technically = correct/feasible.

 

 

One widely accepted = layering principle is to decouple service

authorization from client authentication on access.  We = therefore

recommend that = authorization decisions be performed and = communicated

at the application = layer after the TLS handshake has been = completed.

 

1. I like the idea of protecting the identity of the Client. =

2. I like the idea of having the application perform the Client = certificate validation. It can result in the simplification of the TLS = API/interface.  

 

3. The only potential downsides I see are practical. =

1. Pushing the authentication up the stack from its present location = decentralizes the authentication process. This will likely increase the = latency for session establishment that in turn may affect the = scalability of the solutions that employ this method. =  

2. The linking software between the Transport and Application layers = will need to be fuzz tested to avoid introducing = vulnerabilities.

 

Clever idea.

Thanks,

Ken

 

 

From:= = tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = Yoav Nir
Sent: Wednesday, March 14, 2012 9:22 = AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: = tls@ietf.org
Subject: Re: [TLS] cipher suites for protecting = client credentials

 

Hi = Hannes

 

There was some talk about things like this in Taipei. = His ciphersuites move the client Certificate to after the CCS, so a = passive eavesdropper does not get the client = identity.

 

Yoav

 

On = Mar 14, 2012, at 2:46 PM, Tschofenig, Hannes (NSN - FI/Espoo) = wrote:



Hi Badra,

 

I looked at your document but I do not quite understand what you are = trying to accomplish.

 

When you say that you want to “protect” the client = credentials what do you mean?

When a client authenticates to the server based on public key = cryptography it sends a certificate (among other = things).

 

Could you elaborate?

 

Ciao

Hannes

 

 

From:=  tls-bounces@ietf.org [mailto:tls-bounces@ietf.org]<= span class=3Dapple-converted-space> On Behalf Of ext Mohamad = Badra
Sent: Tuesday, March 13, 2012 11:11 = PM
To: tls@ietf.org
Subject: [TLS] cipher suites for = protecting client = credentials

 

Dear all,

 

I have taken an initial crack at a document = that defines a set of cipher suites to add client = credential protection to = TLS:

 



Scan= ned by Check Point Total Security Gateway. 

______________________= _________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/m= ailman/listinfo/tls

 

------_=_NextPart_001_01CD01EE.CBFD1EE3-- From jsalowey@cisco.com Wed Mar 14 10:06:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886E421F8808 for ; Wed, 14 Mar 2012 10:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.676 X-Spam-Level: X-Spam-Status: No, score=-109.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzzJKnSkAucK for ; Wed, 14 Mar 2012 10:06:49 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5EA21F8804 for ; Wed, 14 Mar 2012 10:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=569; q=dns/txt; s=iport; t=1331744809; x=1332954409; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=yf/np9BuDmECcN4JPzE+Ge1AQsJbHo53In7AFY6AKlk=; b=m1tvBs4JsEk98iOhLfW5MVARnh9SqZClbz98z7KkvqZAcZ7S6446kGzI 5DjeRHo9cIM7y0Q9va7sM5TxFT6T4KvGuh0SCLRt0zfj5nlbLm0z0U+j1 d98mfdaxFgar66gJl/7J6ijNhAz+/BOAR6EdvXPlouiq0j/QSRA6+ZSFq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAIAGTPYE+rRDoI/2dsb2JhbAA6CYMMsAaDHIEHgiIBJ4Iyh2eac4EnnyWKMYMrgj9jBIhXjH+Fa4hVgWiDBg X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="36013478" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 14 Mar 2012 17:06:49 +0000 Received: from [10.33.251.22] ([10.33.251.22]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EH6muI020350 for ; Wed, 14 Mar 2012 17:06:48 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Mar 2012 10:06:45 -0700 Message-Id: <7F5C079D-741F-4755-BC47-096E93E3EC81@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Proposed Agenda for IETF 83 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 17:06:49 -0000 IETF 83 TLS Meeting Agenda WEDNESDAY, March 28, 2012, 1510-1610 Afternoon Session II, Room 243 Agenda ----------- 1. Administrivia (blue sheets, agenda, note takers, jabber) (5 min) 2. Raw Public Key and Cached Info (Hannes Tschofenig) (20 min) - draft-ietf-tls-oob-pubkey - draft-ietf-tls-cached-info 3. OCSP multi-stapling (Yngve Pettersen) (10 min) - draft-pettersen-tls-ext-multiple-ocsp 4. TLS-PWD (Dan Harkins) (10 min) - draft-harkins-tls-pwd 5. TLS identity Protection (Mohamad Badra) (10 min) - draft-badra-tls-identity-protection-01 From mbadra@gmail.com Wed Mar 14 14:05:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC321F888F for ; Wed, 14 Mar 2012 14:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5rFSq+0fcCW for ; Wed, 14 Mar 2012 14:05:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9321F888E for ; Wed, 14 Mar 2012 14:05:57 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2899387vcb.31 for ; Wed, 14 Mar 2012 14:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MGzoCx/qxOeQC4MDEe0wWuBgWUz+eArGK0iwasQZ0Os=; b=gdyOyfLXVT5fxUnFXmQpPADDpG65FYwc6T9oVW31IJJQru0KZSW+nPPuzeJfy+z0mf iNP0NvCUPvgeKlWiSmYjpBfsrB3lFZjtrWzow+KLJJxQ0+UGbWQmo7d+z24f4ApJ3owr 85HQpLySK7g8QuSOPfTBl6phrXhrJxqIAAHvOW2qlYBZEhVuwyaPX+/eycqn3rL775hD u52RYgdkQpDn7erA7PBKno63JhD2EwiywiTSOE4m9CXsTBmB15PQUt+gXN5pA/3KcYDS LfeF2dzbmmVXG1mZGYfwvzIdbyXiBadGOy5eIQrTik3Our+L2wKrkhJoZumwK+cOtXN+ guSQ== MIME-Version: 1.0 Received: by 10.52.179.102 with SMTP id df6mr3122885vdc.28.1331759156754; Wed, 14 Mar 2012 14:05:56 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 14 Mar 2012 14:05:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 22:05:56 +0100 Message-ID: From: Mohamad Badra To: Yngve Nysaeter Pettersen Content-Type: multipart/alternative; boundary=bcaec5014c6d76f7ad04bb3a57d3 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:05:58 -0000 --bcaec5014c6d76f7ad04bb3a57d3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 14, 2012 at 3:20 PM, Yngve Nysaeter Pettersen wrote: > > IOW, adding a new extension will not change the current situation in any > way. > > According to my scans, currently 1.58% of servers are extension > intolerant, down from 1.75% 6 months ago. > > IMO, if this is implemented, it should be implemented using an extension, > not cipher suites. draft-badra-tls-identity-protection-01 specifies a single cipher suite. I don't see the advantages of defining an extension over using a single cipher suite. Would you elaborate please? BTW, what was the percent of server that are extension intolerant in Feb 2010? Best regards, Badra --bcaec5014c6d76f7ad04bb3a57d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 14, 2012 at= 3:20 PM, Yngve Nysaeter Pettersen <yngve@opera.com> wrote:

IOW, adding a new extension will not change the current situation in any wa= y.

According to my scans, currently 1.58% of servers are extension intolerant,= down from 1.75% 6 months ago.

IMO, if this is implemented, it should be implemented using an extension, n= ot cipher suites.


draf= t-badra-tls-identity-protection-01 specifies a single cipher suite. I don&#= 39;t see the advantages of defining an extension over using a single cipher= suite. Would you elaborate please?

BTW, what was the percent of server that are exte= nsion intolerant in Feb 2010?

Best regards,=
Badra
--bcaec5014c6d76f7ad04bb3a57d3-- From mbadra@gmail.com Wed Mar 14 14:12:36 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7304721F87E2 for ; Wed, 14 Mar 2012 14:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSgFTQl+eKhp for ; Wed, 14 Mar 2012 14:12:36 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9721F87DE for ; Wed, 14 Mar 2012 14:12:34 -0700 (PDT) Received: by lagj5 with SMTP id j5so2184805lag.31 for ; Wed, 14 Mar 2012 14:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DlpQfkW3cuwsz3cs0UwxPQbvK7T6MxHDyBhL7tOwUaE=; b=BUG0dqyc2E3otguZV2Agm51SURIO+88nIKYelJWBY/VnF65UcHN+8FrVix34XUK/Ma 3MvPL5ZjnuAmuFSf3BtXdPSlIFz5FdA/pFE3iPJ+xnOJkFa5hwBhDluE6aE7Ul189a/B pRxCOK7K3qV9ZyO3v65VxjLQeFgAX9P+cZEZRzzx3pFP9dormZ71kApgYCWbhXMRrEHZ 1mn0mMEDv99sm94JNAZPc9k3iSi0H3+T9bj4ktDbntL25MzzIyErSJi0mTpcgOp/tBT6 wCIXZq9glB8hcg5rfgnW3RzchEiY0Ej53ebi9lSE86iqOFANePpMFQUqHCmrqun5ES/P h9UQ== MIME-Version: 1.0 Received: by 10.112.48.130 with SMTP id l2mr1571272lbn.41.1331759554066; Wed, 14 Mar 2012 14:12:34 -0700 (PDT) Received: by 10.152.148.230 with HTTP; Wed, 14 Mar 2012 14:12:33 -0700 (PDT) In-Reply-To: <57317BDCBE4B754BBA77A7938FA042A002DEF931@USRN4EX0ONS04.onstar.ad.gm.com> References: <999913AB42CC9341B05A99BBF358718D01382608@FIESEXC035.nsn-intra.net> <87FBF4ED-34AE-449F-B542-F0CB144E54A0@checkpoint.com> <57317BDCBE4B754BBA77A7938FA042A002DEF931@USRN4EX0ONS04.onstar.ad.gm.com> Date: Wed, 14 Mar 2012 22:12:33 +0100 Message-ID: From: Mohamad Badra To: "Peirce, Ken" Content-Type: multipart/alternative; boundary=bcaec553ff0c257ae604bb3a6f4a Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:12:36 -0000 --bcaec553ff0c257ae604bb3a6f4a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Ken, On Wed, Mar 14, 2012 at 3:28 PM, Peirce, Ken wrote: > > > 1. The Server authenticates itself to the Client.**** > > 2. The Client does **not** provide either a temporary or certificate > based public key for the establishment of the TLS session.**** > > 3. The Client issues the CCS to signal encryption will be employed from > that point on. At this point the Client has the all of the material > required to generate the session=92s encryption key.**** > > 4. The Client now presents an encrypted certificate to the Server. This > provides the Server with the material it requires to generate the session= =92s > encryption key.**** > > 5. The Server can now issue its CCS to signal its future use of encryptio= n. > **** > > ** > True (in 4. The client sends its certificate) ** > > Clever idea.**** > > Thanks,**** > > Ken > Thank you Best regards Badra --bcaec553ff0c257ae604bb3a6f4a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello Ken,

On Wed, Mar 1= 4, 2012 at 3:28 PM, Peirce, Ken <Ken.Peirce@onstar.com> wrote:

=A0

1. The Server authenticates itself to the Cl= ient.

2. The Client does *no= t* provide either a temporary or certificate based public key for the e= stablishment of the TLS session.

3. The Client issues the = CCS to signal encryption will be employed from that point on. At this point= the Client has the all of the material required to generate the session=92= s encryption key.

4. The Client now present= s an encrypted certificate to the Server. This provides the Server with the= material it requires to generate the session=92s encryption key.=

5. The Server can now iss= ue its CCS to signal its future use of encryption.

<= /blockquote>

True (in 4. The client sends its certificat= e)

Clever idea.

Thanks,

Ken

=A0
Thank you
Best regards
Badra=
--bcaec553ff0c257ae604bb3a6f4a-- From yngve@opera.com Wed Mar 14 15:26:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5752311E808A for ; Wed, 14 Mar 2012 15:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.085 X-Spam-Level: X-Spam-Status: No, score=-7.085 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEHSGG+foDNK for ; Wed, 14 Mar 2012 15:26:57 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id CEC7A11E8079 for ; Wed, 14 Mar 2012 15:26:56 -0700 (PDT) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2EMQstq028086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Mar 2012 22:26:55 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Mohamad Badra" References: Date: Wed, 14 Mar 2012 23:27:05 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.63 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:26:58 -0000 On Wed, 14 Mar 2012 22:05:56 +0100, Mohamad Badra wrote: > On Wed, Mar 14, 2012 at 3:20 PM, Yngve Nysaeter Pettersen > wrote: > >> >> IOW, adding a new extension will not change the current situation in any >> way. >> >> According to my scans, currently 1.58% of servers are extension >> intolerant, down from 1.75% 6 months ago. >> >> IMO, if this is implemented, it should be implemented using an >> extension, >> not cipher suites. > > > > draft-badra-tls-identity-protection-01 specifies a single cipher suite. I > don't see the advantages of defining an extension over using a single > cipher suite. Would you elaborate please? The purpose of the TLS Extensions mechanism is to signal support for non-standard functionality (such as modifying the handshake sequence), or provide information to the server (such as SNI). Signaling cipher suite values have only been used *once* in TLS: In the Renego patch RFC. That was only in order to work around the issue of being able to signal Rengo Indication support when the client could not use extensions at all. This was necessary in such a case to prevent a version rollback attack (which is currently successful in almost all clients) from disabling the Renego patch. Given that the contemplated functionality is to modify the handshake sequence so that the certificate and certificate verify messages are sent after encryption starts, what is needed is an indication of support for non-standard functionality, which can be best signaled using an Extension. Overloading a cipher suite value for such an indication is IMO a bad idea (renego was, and should continue to be, a special case). Any server that is likely to implement the proposed functionality will almost certainly already support TLS Extensions, so there is no real need to consider the possibility that the server does not support them. And the rather small difference in size between the minimum extension (4 bytes) and the SCSV (2 bytes) is IMO not reason enough to go for the SCSV option. Additionally, the server would have to signal back to the client that it is willing to accept the modified sequence. That means that an extension will have to be defined for this purpose in any case, so why complicate things? Of course, there is another way to accomplish the same goal: Define a new version of TLS. > BTW, what was the percent of server that are extension intolerant in Feb > 2010? I don't have reliable numbers before August 2011, due to some result processing bugs (I have not investigated if they can be reconstructed based on recorded results). In early August 2011 (the first after all the problem were resolved) the result for Extension intolerance in the TLS 1.0-TLS 1.2 range (which is what is reported above) range was 2.03%. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From mbadra@gmail.com Wed Mar 14 16:54:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D935D11E8083 for ; Wed, 14 Mar 2012 16:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXM22OqCqXXU for ; Wed, 14 Mar 2012 16:54:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 758AE11E8075 for ; Wed, 14 Mar 2012 16:54:51 -0700 (PDT) Received: by lagj5 with SMTP id j5so2290137lag.31 for ; Wed, 14 Mar 2012 16:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WLIXxIzbO0swhuaBmCIf342pGcNMveFozuz+61zTeaE=; b=kZm/weBzjkRuWB/JVu7m3zlpy6IQpgBH/VfKNo5tmf+8SIu9iz8OKCi6qnfRgdRflp 0d0ntDP8XbvZNNtM5kwupnq/4U3YpHloef3eXPrTmdLRTFr0BZAddsBuSM1hXH7K3iKY Pz+u13Ixv6EWuiVnpITYTX4Z7Knieymet/9v98AAgCyQqwEgkKGxOAy4B6I4c/ZiAKTq QBrYW74zqjV79pQJtMr4a7ADozqlfXdgWUwuBXH9oP40Ui+/Ui1QGIoFZ4r+2U8vp/Oz OSymbOHKoTAFzW4jrXo0SvgqLFgH7lz+tQV5vOObpzGQiwhTT/QiKQ+Kkxq7OabG7Um/ vLyQ== MIME-Version: 1.0 Received: by 10.112.30.137 with SMTP id s9mr1764568lbh.13.1331769290112; Wed, 14 Mar 2012 16:54:50 -0700 (PDT) Received: by 10.152.148.230 with HTTP; Wed, 14 Mar 2012 16:54:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 00:54:50 +0100 Message-ID: From: Mohamad Badra To: "Yngve N. Pettersen (Developer Opera Software ASA)" Content-Type: multipart/alternative; boundary=f46d040123bd75bf1904bb3cb353 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 23:54:53 -0000 --f46d040123bd75bf1904bb3cb353 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 14, 2012 at 11:27 PM, Yngve N. Pettersen (Developer Opera Software ASA) > > Signaling cipher suite values have only been used *once* in TLS: In the > Renego patch RFC. That was only in order to work around the issue of being > able to signal Rengo Indication support when the client could not use > extensions at all. This was necessary in such a case to prevent a version > rollback attack (which is currently successful in almost all clients) from > disabling the Renego patch. > NO, the SCSV is mainly specified because of compatibilty reasons (see RFC5746 Section 3.3): "Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require implementations to ignore data following the ClientHello (i.e., extensions) if they do not understand it. However, some SSLv3 and TLS 1.0 implementations incorrectly fail the handshake in such a case. This means that clients that offer the "renegotiation_info" extension may encounter handshake failures. In order to enhance compatibility with such servers, this document defines a second signaling mechanism via a special Signaling Cipher Suite Value (SCSV) ..." BTW, why nowadays it is not true that "client could not use extensions at all"? And the rather small difference in size between the minimum extension (4 > bytes) and the SCSV (2 bytes) is IMO not reason enough to go for the SCSV > option. > > Additionally, the server would have to signal back to the client that it > is willing to accept the modified sequence. That means that an extension > will have to be defined for this purpose in any case, so why complicate > things? > For the same compatibility issue described above, and it does not complicate things! Any server that is likely to implement the proposed functionality will > almost certainly already support TLS Extensions, so there is no real need > to consider the possibility that the server does not support them. It is true that the server needs to support that extension, but we still need to ensure compatibility. BTW, the draft-badra-tls-identity-protection-02 defines an extension to be sent by the server when a SCSV is received in ClientHello (please see http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-identity-protection-02.txt ). In draft-badra-tls-ciphersuite-identity-protection-00, you don't need to define extensions, and you ensure compatibility with servers that ignore data following the ClientHello. Best regards, Badra --f46d040123bd75bf1904bb3cb353 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 14, 2012 at 11:27 P= M, Yngve N. Pettersen (Developer Opera Software ASA)=A0
Signaling cipher suite values have only been used *once* in TLS: In the Ren= ego patch RFC. That was only in order to work around the issue of being abl= e to signal Rengo Indication support when the client could not use extensio= ns at all. This was necessary in such a case to prevent a version rollback = attack (which is currently successful in almost all clients) from disabling= the Renego patch.


NO, the SCSV is mainly spec= ified because of compatibilty reasons (see RFC5746 Section 3.3):
= 
   =
"Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require
   implementations to ignore data following the ClientHello (i.e.,
   extensions) if they do not understand it.  However, some SSLv3 and
   TLS 1.0 implementations incorrectly fail the handshake in such a
   case.  This means that clients that offer the "renegotiation_info&q=
uot;
   extension may encounter handshake failures.  In order to enhance
   compatibility with such servers, this document defines a second
   signaling mechanism via a special Signaling Cipher Suite Value (SCSV)
   ..."
BTW, why nowadays it is not true that "cl= ient could not use extensions at all"?


And the rather small difference in size between the minimum extension (4 by= tes) and the SCSV (2 bytes) is IMO not reason enough to go for the SCSV opt= ion.

Additionally, the server would have to signal back to the client that it is= willing to accept the modified sequence. That means that an extension will= have to be defined for this purpose in any case, so why complicate things?=


For the same=A0compatibility issue described above, and i= t does not complicate things!
=A0

Any server that is likely to implement the proposed functionali= ty will almost certainly already support TLS Extensions, so there is no rea= l need to consider the possibility that the server does not support them.=A0


It is true that the server needs to supp= ort that extension, but we still need to ensure compatibility.
BT= W, the=A0draft-badra-tls-identity-prot= ection-02 defines an extension to be sent by the server when a SCSV is rece= ived in ClientHello (please see http://= www.ineovation.fr/tls-identity-protection/draft-badra-tls-identity-protecti= on-02.txt).

In=A0draft-badra-tls-ciphersuite-identity-protection-00= , you don't need to define extensions, and you ensure compatibility wit= h servers that ignore data following t= he ClientHello.

Best regards,
Badra
--f46d040123bd75bf1904bb3cb353-- From marsh@extendedsubset.com Wed Mar 14 18:02:25 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9D21F879C for ; Wed, 14 Mar 2012 18:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQOF8jkP-Nwo for ; Wed, 14 Mar 2012 18:02:25 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 60C2B21F8780 for ; Wed, 14 Mar 2012 18:02:25 -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 1S7z5C-0000pc-He; Thu, 15 Mar 2012 01:02:22 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 707D26082; Thu, 15 Mar 2012 01:02: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: U2FsdGVkX1/iKfmO9/Y2s294FnPzd6YBY8RRAOO7biE= Message-ID: <4F613F9D.1050709@extendedsubset.com> Date: Wed, 14 Mar 2012 20:02:21 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Mohamad Badra References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 01:02:26 -0000 On 03/14/2012 06:54 PM, Mohamad Badra wrote: > On Wed, Mar 14, 2012 at 11:27 PM, Yngve N. Pettersen (Developer Opera > Software ASA) > > Signaling cipher suite values have only been used *once* in TLS: In > the Renego patch RFC. That was only in order to work around the > issue of being able to signal Rengo Indication support when the > client could not use extensions at all. This was necessary in such a > case to prevent a version rollback attack (which is currently > successful in almost all clients) from disabling the Renego patch. > > NO, the SCSV is mainly specified because of compatibilty reasons (see > RFC5746 Section 3.3): But these two reasons are closely related and from the perspective of a client implementer like Yngve they are nearly the same: Yngve's client code tries the handshake first with TLS extensions. If that fails, it may try the handshake again without any extensions. So this "compatibility" would represent a downgrade attack against RI without the SCSV, even when the legitimate client and server both supported extensions. There was a *lot* of discussion about this back when it was decided. The one thing I think everyone agrees on is that SCSV was a bit of an emergency hack made necessary only because of the presence of extension-intolerant servers. - Marsh From yngve@opera.com Wed Mar 14 18:53:19 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7663421F858F for ; Wed, 14 Mar 2012 18:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.024 X-Spam-Level: X-Spam-Status: No, score=-7.024 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuy4R-P1Jj5z for ; Wed, 14 Mar 2012 18:53:12 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 307D621F84FE for ; Wed, 14 Mar 2012 18:53:12 -0700 (PDT) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2F1r9bc010573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Mar 2012 01:53:10 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Mohamad Badra" References: Date: Thu, 15 Mar 2012 02:53:20 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/10.63 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 01:53:20 -0000 On Thu, 15 Mar 2012 00:54:50 +0100, Mohamad Badra wrote: > On Wed, Mar 14, 2012 at 11:27 PM, Yngve N. Pettersen (Developer Opera > Software ASA) >> >> Signaling cipher suite values have only been used *once* in TLS: In the >> Renego patch RFC. That was only in order to work around the issue of >> being >> able to signal Rengo Indication support when the client could not use >> extensions at all. This was necessary in such a case to prevent a >> version >> rollback attack (which is currently successful in almost all clients) >> from >> disabling the Renego patch. >> > > > NO, the SCSV is mainly specified because of compatibilty reasons (see > RFC5746 Section 3.3): > > "Both the SSLv3 and TLS 1.0/TLS 1.1 specifications require > implementations to ignore data following the ClientHello (i.e., > extensions) if they do not understand it. However, some SSLv3 and > TLS 1.0 implementations incorrectly fail the handshake in such a > case. This means that clients that offer the "renegotiation_info" > extension may encounter handshake failures. In order to enhance > compatibility with such servers, this document defines a second > signaling mechanism via a special Signaling Cipher Suite Value (SCSV) > ..." > > BTW, why nowadays it is not true that "client could not use extensions at > all"? One of the version rollback modes used by clients is SSL v3-only, without extensions. In fact, I think until MS started to support TLS 1.2, it was the only fallback mode used by clients other than Opera. Opera have, until now, also had a TLS 1.0 without extension mode, and at one time also had a TLS 1.1 w/o extension mode. Those are the situations under which the Renego SCSV would be needed. And the reason it is needed is that an attacker could trick the client into falling back to such a mode, and if not for the SCSV being included in the handshake, the attacker could successfully trick the server and client into completing a connection that could be attacked using the renego attack. That attack scenario could have been prevented by requiring clients to always send extension, but due to the compatibility issues clients had to fall back to configurations that did not send extensions, which is why the SCSV became necessary. A renego patched server should be both version and extension tolerant, so the most likely reason for being intolerant is an attack (of renego patched servers 0.035% are version intolerant in TLS 1.0-TLS 1.2 range, 0.12% extension intolerant, about half of which does not tolerate specific extension) AFAICT such a critical security problem does not exist in this case. The server is the one requesting credentials, and if it does not receive other indications, it can trigger renegotiation of the connection to perform that while protecting the privacy of the user (which do require the Renego patch in order to be done safely). > And the rather small difference in size between the minimum extension (4 >> bytes) and the SCSV (2 bytes) is IMO not reason enough to go for the >> SCSV >> option. >> > >> Additionally, the server would have to signal back to the client that it >> is willing to accept the modified sequence. That means that an extension >> will have to be defined for this purpose in any case, so why complicate >> things? >> > > > For the same compatibility issue described above, and it does not > complicate things! It does complicate things. A supporting server would have to have instructions for looking for the signal in two places, the extensions and the cipher suites, and would need to know what to do if both were there (0.97% of renego patched servers does not tolerate a client hello that send _both_ the extension and the SCSV). All of this increases the likelihood (towards certainty) that somebody will introduce a interoperability issue, which in turn will mean that clients will have to create even more complex fallback procedures, at a time when I, for one, want to get rid of them. In the case of only having the SCSV, not an extension, with a signal back in a extension would look as funny as the renego SCSV (and that one has _barely_ tolerable reasons for being defined that way). A server that does support the proposed change would need to support Extensions, thus the SCSV is not needed. (unless a variant using fully specified cipher suites as proposed earlier was used, which is not a good idea for many reasons, one being scalability) A server that does not support the proposed change and tolerates extensions would ignore the extension, and the SCSV is not needed, since the server does not understand it. A server that does not support the proposed change, and also does not tolerate extensions, would ignore the SCSV since it does not understand it, and all modern clients would anyway have to do a version/extension fallback for these servers because the server would not tolerate the extensions they sent, in any case. Thus the SCSV is not needed for this scenario either. > > Any server that is likely to implement the proposed functionality will >> almost certainly already support TLS Extensions, so there is no real >> need >> to consider the possibility that the server does not support them. > > > > It is true that the server needs to support that extension, but we still > need to ensure compatibility. Which extension supporting clients already do (for the present time) by falling back to configurations that does not use extensions. But if all the supporting servers understand extensions there is no need to signal the client's support of that functionality to servers that will never support the functionality. > BTW, the draft-badra-tls-identity-protection-02 defines an extension to > be > sent by the server when a SCSV is received in ClientHello (please see > http://www.ineovation.fr/tls-identity-protection/draft-badra-tls-identity-protection-02.txt > ). Which, as mentioned earlier, means that it can be sent as an extension and not an SCSV. The server that supports that proposal would (or should) understand extensions in the client hello. > In draft-badra-tls-ciphersuite-identity-protection-00, you don't need to > define extensions, and you ensure compatibility with servers that ignore > data following the ClientHello. Those servers would very likely not support the functionality at all, and if they ignore extensions that probably mean they should be upgraded to support the renego patch, which means that they would understand extensions, too. Servers that are updated with this kind of functionality will require quite a bit of changes to their internal logic, so making sure they understand extensions (which they need to do for other purposes, such as Renego) would probably not increase the complexity all that much, particularly when support for several of the defined extensions is desirable on their own merits. I would also guess that such a server would probably be upgraded to support TLS 1.2 at the same time (particularly in light of the BEAST vulnerability), which means it have to support extensions. As an example, the minimal OCSP Certificate Status extension could, conceivably, have been implemented as an SCSV signal, and support signaled back by the extension. However, servers that did not support that functionality would not understand the SCSV, whether or not they understood/tolerated extensions, and those that did support the functionality would (or should) naturally understand extensions, thus an SCSV is unnecessary, and an unneeded complication. IMO, doing tricks with cipher suites to control the handshake sequence is a waste of resources, except when fixing critical security vulnerabilities (and, even then, only as a last resort). The scenario it is targeted at (an extension ignoring/intolerant server that supports an advanced modification of the handshake) is very likely such an extreme cornercase that it would probably only be realized as a proof of concept, not used in production systems, and I see no reason to encourage such a cornercase to be developed. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From mrex@sap.com Wed Mar 14 19:38:36 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D373B11E8087 for ; Wed, 14 Mar 2012 19:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.05 X-Spam-Level: X-Spam-Status: No, score=-10.05 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4R3yk2sz8uq for ; Wed, 14 Mar 2012 19:38:36 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E10E311E8075 for ; Wed, 14 Mar 2012 19:38:35 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2F2cSp0002378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 03:38:33 +0100 (MET) From: Martin Rex Message-Id: <201203150238.q2F2cRXB022234@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 15 Mar 2012 03:38:27 +0100 (MET) In-Reply-To: from "Yngve N. Pettersen" at Mar 14, 12 11:27:05 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] cipher suites for protecting client credentials 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, 15 Mar 2012 02:38:36 -0000 > On Wed, 14 Mar 2012 22:05:56 +0100, Mohamad Badra wrote: > > > > draft-badra-tls-identity-protection-01 specifies a single cipher suite. I > > don't see the advantages of defining an extension over using a single > > cipher suite. Would you elaborate please? If at all, this scheme ought to be implemented with a TLS extension, using an SCSV ciphersuite value for downgrade protection and for use by clients that do not support TLS extensions at all and programmatic clients that do not have an application level re-connect fallback and therefore do never send any TLS extensions. Yngve N. Pettersen wrote: > > The purpose of the TLS Extensions mechanism is to signal support for > non-standard functionality (such as modifying the handshake sequence), or > provide information to the server (such as SNI). So far the theory goes. But then, the TLS working group failed badly to get the extensibility pushed out for the SSLv3 protocol spec into the installed base when the complete lack of extensibility in the original SSLv3 protocol was noticed and complained on: http://lists.w3.org/Archives/Public/ietf-tls/msg02599.html > > And the rather small difference in size between the minimum extension (4 > bytes) and the SCSV (2 bytes) is IMO not reason enough to go for the SCSV > option. > > Additionally, the server would have to signal back to the client that it > is willing to accept the modified sequence. That means that an extension > will have to be defined for this purpose in any case, so why complicate > things? Not using the TLS extension in the ClientHello (but instead always the SCSV) will actually save the most (in terms of implementation complexity and test cases). > > Signaling cipher suite values have only been used *once* in TLS: In the > Renego patch RFC. That was only in order to work around the issue of being > able to signal Rengo Indication support when the client could not use > extensions at all. Nope, that rationale was rejected back then and you still reject it now, although there are still implementations left that do not support TLS extensions, because they would not be allowed to send it in ClientHello anyway. > > This was necessary in such a case to prevent a version > rollback attack (which is currently successful in almost all clients) from > disabling the Renego patch. *That* was the real reason why it was allowed in by the high priests, to protect the "cutting edge TLS clients" that are not only willing to try TLS extensions, but also have fallbacks in place. > > Given that the contemplated functionality is to modify the handshake > sequence so that the certificate and certificate verify messages are sent > after encryption starts, what is needed is an indication of support for > non-standard functionality, which can be best signaled using an Extension. Maybe in 10 years from now, when the last extensions intolerant servers have gone. > > According to my scans, currently 1.58% of servers are extension > intolerant, down from 1.75% 6 months ago. That is a global average for public servers on the internet and not really meaningful. Typical clients connect only to a very small number of servers, typically less than 100 (ignoring the advertising and statcounter junk that one probably would _not_ mind to loose). For those user that actually want to use the services of such users, the issue may be very relevant. > > Overloading a cipher suite value for such an indication is IMO a bad idea It is not a bad idea, it is merely an alterative approach to implement a 1-bit TLS ClientHello extension in a fully backwards compatible fashion. > > (renego was, and should continue to be, a special case). As long as clients can be forced to downgrade, that special case continues to exist.o Maybe when *ALL* browser vendors have removed the options (and capabilities) to use SSLv3 or to send extension-less TLS ClientHellos, then we can seriously claim that sending TLS extensions is safe. But until then, the use of an SCSV for an extension like client identity protection is quite sensible. -Martin From ekr@rtfm.com Wed Mar 14 20:50:01 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F9611E8096 for ; Wed, 14 Mar 2012 20:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.053 X-Spam-Level: X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv+B-0eKrrZm for ; Wed, 14 Mar 2012 20:50:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE64211E8074 for ; Wed, 14 Mar 2012 20:50:00 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3283834vcb.31 for ; Wed, 14 Mar 2012 20:50:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=7mfSaLpl/inLXbjOFV5omLtbBV+4R+cZV6tMO42x3MM=; b=c2NzpAGMCWC4M028gvi+Oq/Tyri+4T4PHMztewenU6i4H89BF5iZlXVy6Lpn7uiFau K+Ej/7N21cldNN6cae1C9mVT4Fkw0y10mHB6Rp7eEy8gFH0X0HJAlkuSzBE4XS3uO8fd TNH9Ir7yE9zvkgapkk03dJz6iVmVOmjwJa6J8OhSRPhl1BE23KWxBZFXiNN7JpNDL5kl sULwukKUMocdnsMjZHUD/xG4Naj9vz9/uhBQRWDtyZhqcpKcnHEzDPD3QAXtRZhkHmYN oim+AGYrGT3m/oLxFF1483HFtqZEMu8DOu431XdjbmB4ki94shJjGJb0oNOzzIcYKcZ+ Ujvg== Received: by 10.52.24.40 with SMTP id r8mr3607559vdf.108.1331783400111; Wed, 14 Mar 2012 20:50:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Wed, 14 Mar 2012 20:49:20 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <201203150238.q2F2cRXB022234@fs4113.wdf.sap.corp> References: <201203150238.q2F2cRXB022234@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 14 Mar 2012 20:49:20 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl+FWGxvHah8tZyvGQ7Y1oVMcwOuAB7KDa1S6ywhVM2HtqSbx+8v84YwvivxpOkBpi6OPcX Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 03:50:01 -0000 On Wed, Mar 14, 2012 at 7:38 PM, Martin Rex wrote: >> On Wed, 14 Mar 2012 22:05:56 +0100, Mohamad Badra wro= te: >> (renego was, and should continue to be, a special case). > > As long as clients can be forced to downgrade, that special case > continues to exist.o > > Maybe when *ALL* browser vendors have removed the options (and capabiliti= es) > to use SSLv3 or to send extension-less TLS ClientHellos, then we can > seriously claim that sending TLS extensions is safe. =A0But until then, > the use of an SCSV for an extension like client identity protection > is quite sensible. I'm not really interested in relitigating the SCSV-vs-extension issue, but in the specific case of client identity protection, I don't see how SCSV provides rollback protection. The reason that the SCSV is (generally) less susceptible to rollback than extensions is that an attacker can simulate being un-extension-capable and and force the client into trying a non-extension handshake without breaking the Finished, whereas there aren't SCSV-intolerant servers, so the Finished detects SCSV removal. However, unless I'm missing something, that doesn't apply here because the client sends the Certificate before the Finished, so the Finished is too late to detect tampering. The attacker can just simulate not having the extension, wait for the client Certificate, and then RST the connection instead of sending the Finished. -Ekr From mrex@sap.com Wed Mar 14 21:20:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE4921F86FA for ; Wed, 14 Mar 2012 21:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.053 X-Spam-Level: X-Spam-Status: No, score=-10.053 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntAPFM7v7DCT for ; Wed, 14 Mar 2012 21:20:33 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0B221F86F7 for ; Wed, 14 Mar 2012 21:20:32 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2F4KQij011280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 05:20:31 +0100 (MET) From: Martin Rex Message-Id: <201203150420.q2F4KPF9028180@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 15 Mar 2012 05:20:25 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 14, 12 08:49:20 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] cipher suites for protecting client credentials 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, 15 Mar 2012 04:20:37 -0000 Eric Rescorla wrote: > > On Wed, Mar 14, 2012 at 7:38 PM, Martin Rex wrote: > > > > As long as clients can be forced to downgrade, that special case > > continues to exist.o > > I'm not really interested in relitigating the SCSV-vs-extension issue, but > in the specific case of client identity protection, I don't see how SCSV > provides rollback protection. The reason that the SCSV is (generally) > less susceptible to rollback than extensions is that an attacker can > simulate being un-extension-capable and and force the client into > trying a non-extension handshake without breaking the Finished, > whereas there aren't SCSV-intolerant servers, so the Finished > detects SCSV removal. Correct. If both, client and server offer a feature that is considered worth having, the protocol should be resilient to attackers that want the connection to be established without that feature. > > However, unless I'm missing something, that doesn't apply here because > the client sends the Certificate before the Finished, so the Finished > is too late to detect tampering. The attacker can just simulate not > having the extension, wait for the client Certificate, and then RST the > connection instead of sending the Finished. Unless I'm missing something: The key exchange is authenticated with the server credential/certificate, and the client certificate will be encrypted under ephemeral keys derived from that authenticated key exchange. So an attacker can only get at the credential when he can either fully impersonate the server or entice the client to connect (and send that credential) to an entirely different server. -Martin From ekr@rtfm.com Wed Mar 14 21:26:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5599111E809A for ; Wed, 14 Mar 2012 21:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.051 X-Spam-Level: X-Spam-Status: No, score=-103.051 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SU5+K986uCeZ for ; Wed, 14 Mar 2012 21:26:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A68C111E8074 for ; Wed, 14 Mar 2012 21:26:57 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3312477vcb.31 for ; Wed, 14 Mar 2012 21:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=C/M/EJ/g6h8Wv6qqcpLMej4CpW/b95qtCGsR94Gfimc=; b=R6NaPr1a2mgoTsjnp3vJv5jW5Xq0UHkDsp1OP+gAgyiWC3UqnYTmQPTLWNzRvVK/lY Yql/xwmsg2AqZmPW2pnwkJQF7HuQtD6YV24X2HB/C1UVXetn++87DVym3vwKyhFnebq/ sGvJSaolcOtcOdFZhqAquNVI1Zr54Jhk+ZcvCpt74kn30UfMi2y5ta+zQz+Z9xlTx+UT HQ+C3e0E24weIB3mXVnrMJAz/8h9nvl032eKKKzCQXv8bR0Q3KNu7JwzohX9jNy5gwe2 F0XlQBEgREPRooLCyIVWyEcogC8MpSwfIyx6K7kSdWPPd3HJw2PZlgSKfRbCD9B+qd7Z 2Duw== Received: by 10.52.28.228 with SMTP id e4mr3707519vdh.57.1331785617115; Wed, 14 Mar 2012 21:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Wed, 14 Mar 2012 21:26:17 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <201203150420.q2F4KPF9028180@fs4113.wdf.sap.corp> References: <201203150420.q2F4KPF9028180@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 14 Mar 2012 21:26:17 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnUOcWZfQOEe+2J5RWmcDrZoxQdfyGyNYunDYyS3lBl/o9R5udiitDpC6pVjJVaKlRNKYbT Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:26:58 -0000 On Wed, Mar 14, 2012 at 9:20 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Wed, Mar 14, 2012 at 7:38 PM, Martin Rex wrote: >> > >> > As long as clients can be forced to downgrade, that special case >> > continues to exist.o >> >> I'm not really interested in relitigating the SCSV-vs-extension issue, b= ut >> in the specific case of client identity protection, I don't see how SCSV >> provides rollback protection. The reason that the SCSV is (generally) >> less susceptible to rollback than extensions is that an attacker can >> simulate being un-extension-capable and and force the client into >> trying a non-extension handshake without breaking the Finished, >> whereas there aren't SCSV-intolerant servers, so the Finished >> detects SCSV removal. > > Correct. =A0If both, client and server offer a feature that is considered > worth having, the protocol should be resilient to attackers that want > the connection to be established without that feature. Sure. But I don't believe this feature can be offered in that way if the client is prepared not to negotiate that feature. >> However, unless I'm missing something, that doesn't apply here because >> the client sends the Certificate before the Finished, so the Finished >> is too late to detect tampering. The attacker can just simulate not >> having the extension, wait for the client Certificate, and then RST the >> connection instead of sending the Finished. > > > Unless I'm missing something: The key exchange is authenticated with the > server credential/certificate, and the client certificate will be > encrypted under ephemeral keys derived from that authenticated key exchan= ge. > > So an attacker can only get at the credential when he can either fully > impersonate the server or entice the client to connect (and send that > credential) to an entirely different server. Yes, that's how it's *supposed* to work, but if the client is willing to do unencrypted certificates, then the attacker can just force him back to that: Here's how this works: C->S: ClientHello + EncryptedCert indicator A->C: ServerHello (no indicator) C->A: Certificate, ClientKeyExchange, CertificateVerify A->C: RST -Ekr From marsh@extendedsubset.com Wed Mar 14 21:29:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0C111E8093 for ; Wed, 14 Mar 2012 21:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gA2fgW9CxOA for ; Wed, 14 Mar 2012 21:29:20 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6489811E8074 for ; Wed, 14 Mar 2012 21:29:20 -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 1S82JT-00020F-V5; Thu, 15 Mar 2012 04:29:20 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 39E2C6085; Thu, 15 Mar 2012 04:29:18 +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+7f0dQDbza7VkBVIucHQQKwtzxYFJCULM= Message-ID: <4F61701C.7040103@extendedsubset.com> Date: Wed, 14 Mar 2012 23:29:16 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Eric Rescorla References: <201203150238.q2F2cRXB022234@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:29:21 -0000 On 03/14/2012 10:49 PM, Eric Rescorla wrote: > > However, unless I'm missing something, that doesn't apply here because > the client sends the Certificate before the Finished, so the Finished > is too late to detect tampering. The attacker can just simulate not > having the extension, wait for the client Certificate, and then RST the > connection instead of sending the Finished. The ID says > Consequently, static Diffie-Hellman SHOULD NOT be used with this document. But really it's incompatible with all forms of Diffie-Hellman. Which would seem to be a big step backwards compared to the current capabilities of TLS. Current TLS clients and servers can agree to pass client credentials using authenticated encryption to cover a renegotiation handshake. This method is not perfect, but it is widely used today. There should be some discussion in the ID of exactly what is being gained by the new method. Regardless, are there any examples of clients today that would refuse to provide the client credentials if asked by an attacker on a (not-yet-authenticated) initial handshake? If not, perhaps a better first step would be standardizing a method (say via a field in the x509 client cert itself) to inform the client TLS stack that the cert MUST NOT be transmitted except as properly encrypted to an authorized server. - Marsh From ekr@rtfm.com Wed Mar 14 21:32:12 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B14311E809A for ; Wed, 14 Mar 2012 21:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.05 X-Spam-Level: X-Spam-Status: No, score=-103.05 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk57xOlSCpAB for ; Wed, 14 Mar 2012 21:32:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D8D0A11E8074 for ; Wed, 14 Mar 2012 21:32:10 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so13230vbb.31 for ; Wed, 14 Mar 2012 21:32:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Z2aGr0KXRnWCESrLVcuTFItptcBvBgHjomiQ0rCpiLE=; b=Um0vlJK8FbXPHJxgrrHTSrGP1QBPZ/aIhsRyZ05wgwow22lRDA77pJZ3YZRD06JnvB +CBqwQYMiKIKQqTlGocVxEjvjAWz0SYAHCEbVlBLhYvZzEfB030tAoA0KGhyp1uNknB6 vDE7pc+R/62j6+F+TtmykWBR6T6J4rq9CJrkbdDRGsUhFFIinU6iGIdrN8Y42/gQVVUw ex+nMU/y4sdWet73ABDRSSs2FHmo3w7RL0lLDIk8ZRognnH33rW3+gV68nzgLi23fJgA w+opD/4Pd79Yd2f07kts2HD4IciAJTAi0GMAxpW7AV9LfAZ8KkysgnaIl91ZHa62sbJL nGOg== Received: by 10.52.24.40 with SMTP id r8mr3671887vdf.108.1331785930160; Wed, 14 Mar 2012 21:32:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Wed, 14 Mar 2012 21:31:30 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <4F61701C.7040103@extendedsubset.com> References: <201203150238.q2F2cRXB022234@fs4113.wdf.sap.corp> <4F61701C.7040103@extendedsubset.com> From: Eric Rescorla Date: Wed, 14 Mar 2012 21:31:30 -0700 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlSM4C7dvXg8b6SUp8JGWIyy+XCY8sHBcgKApkqk8zqQ3Bespg2A7akLw717PDy/+JAKbJH Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:32:12 -0000 On Wed, Mar 14, 2012 at 9:29 PM, Marsh Ray wrote: > On 03/14/2012 10:49 PM, Eric Rescorla wrote: >> >> >> However, unless I'm missing something, that doesn't apply here because >> the client sends the Certificate before the Finished, so the Finished >> is too late to detect tampering. The attacker can just simulate not >> having the extension, wait for the client Certificate, and then RST the >> connection instead of sending the Finished. > > > > The ID says >> >> Consequently, static Diffie-Hellman SHOULD NOT be used with this document. > > > But really it's incompatible with all forms of Diffie-Hellman. Which would > seem to be a big step backwards compared to the current capabilities of TLS. Hmm... I don't see why. Can you explain? -Ekr From marsh@extendedsubset.com Wed Mar 14 21:34:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D2F21F84F5 for ; Wed, 14 Mar 2012 21:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqxfhsC8vpnJ for ; Wed, 14 Mar 2012 21:34:38 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 92E3F21F84F7 for ; Wed, 14 Mar 2012 21:34:37 -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 1S82OZ-000DFC-0I; Thu, 15 Mar 2012 04:34:35 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2D9A5603D; Thu, 15 Mar 2012 04:34:33 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18LTUT+UqoGqGFWlws07JitVXS8dSTnOqk= Message-ID: <4F617157.1080107@extendedsubset.com> Date: Wed, 14 Mar 2012 23:34:31 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Eric Rescorla References: <201203150238.q2F2cRXB022234@fs4113.wdf.sap.corp> <4F61701C.7040103@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 04:34:40 -0000 On 03/14/2012 11:31 PM, Eric Rescorla wrote: >> >> But really it's incompatible with all forms of Diffie-Hellman. Which would >> seem to be a big step backwards compared to the current capabilities of TLS. > > Hmm... I don't see why. Can you explain? IIRC, ephemeral Diffie-Hellman isn't actually authenticated until the Finished message. So the MitM can supply his own DH parameters right? - Marsh From mrex@sap.com Wed Mar 14 22:01:30 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAF021F8680 for ; Wed, 14 Mar 2012 22:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.054 X-Spam-Level: X-Spam-Status: No, score=-10.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1MuzdgEDwDg for ; Wed, 14 Mar 2012 22:01:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5723821F867F for ; Wed, 14 Mar 2012 22:01:27 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2F51OeX014597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 06:01:24 +0100 (MET) From: Martin Rex Message-Id: <201203150501.q2F51NvE000872@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 15 Mar 2012 06:01:23 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 14, 12 09:31:30 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] cipher suites for protecting client credentials 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, 15 Mar 2012 05:01:30 -0000 Eric Rescorla wrote: > > On Wed, Mar 14, 2012 at 9:29 PM, Marsh Ray wrote: > > On 03/14/2012 10:49 PM, Eric Rescorla wrote: > >> > >> > >> However, unless I'm missing something, that doesn't apply here because > >> the client sends the Certificate before the Finished, so the Finished > >> is too late to detect tampering. The attacker can just simulate not > >> having the extension, wait for the client Certificate, and then RST the > >> connection instead of sending the Finished. > > > > > > > > The ID says > >> > >> Consequently, static Diffie-Hellman SHOULD NOT be used with this document. > > > > > > But really it's incompatible with all forms of Diffie-Hellman. Which would > > seem to be a big step backwards compared to the current capabilities of TLS. > > Hmm... I don't see why. Can you explain? True -- so we would need a new X.509v3 cert attribute in the Server certificate to signal back to the client in a fashion that the attacker can not subvert. (we discussed this previously on this list, I just failed to remember...) https://www.ietf.org/mail-archive/web/tls/current/msg08297.html -Martin From ekr@rtfm.com Wed Mar 14 22:07:30 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DDE21F8795 for ; Wed, 14 Mar 2012 22:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.048 X-Spam-Level: X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLkkriTGFeXa for ; Wed, 14 Mar 2012 22:07:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5C9021F8794 for ; Wed, 14 Mar 2012 22:07:29 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3343068vcb.31 for ; Wed, 14 Mar 2012 22:07:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=JSkwZwQtmzAW7z/TPOCTOynkriOEvbeNGu9tH9FfJho=; b=S1Vwf5poPMRtw0VlJxRAD0aXNPb6XjTotSOuUMsP9y7pKtQYupTVnJ73dydJd7Y9WS 1OM451hU3ut62aNqXvUM8ltv1SvopDnOLS9m9gAe/JcNzsP0pCuZrb8RQHfNQ5jhEHye ml0+31F6dIuKybqOgDyv0I5X0Ry6V8bm2b+u16acS7Yv3ZgDklp+8C0XzNB/3V3lP/Bj LfPaOclzEfF7JUeAnLOFEJN+qSPa0Rh6wSoZbRnNeA65o8Qsdyz1PWskdrYCBZ/DDkxc 4clXWAASlFmJnL0pCeEn/mVSEPYOR+SmSMi0msK+YnFTm2Ny4wykuZ8BxzUnlmmrMvK2 PjNw== Received: by 10.52.91.16 with SMTP id ca16mr3735639vdb.125.1331788049166; Wed, 14 Mar 2012 22:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Wed, 14 Mar 2012 22:06:49 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <201203150501.q2F51NvE000872@fs4113.wdf.sap.corp> References: <201203150501.q2F51NvE000872@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 14 Mar 2012 22:06:49 -0700 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlvGOlpGyzqUzmV04beMkxP3h6P1Nn8bj9SRFd6chdro5O8oLOKKa4/GxwoJgHgwh669WFy Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 05:07:30 -0000 On Wed, Mar 14, 2012 at 10:01 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Wed, Mar 14, 2012 at 9:29 PM, Marsh Ray wrote: >> > On 03/14/2012 10:49 PM, Eric Rescorla wrote: >> >> >> >> >> >> However, unless I'm missing something, that doesn't apply here because >> >> the client sends the Certificate before the Finished, so the Finished >> >> is too late to detect tampering. The attacker can just simulate not >> >> having the extension, wait for the client Certificate, and then RST the >> >> connection instead of sending the Finished. >> > >> > >> > >> > The ID says >> >> >> >> Consequently, static Diffie-Hellman SHOULD NOT be used with this document. >> > >> > >> > But really it's incompatible with all forms of Diffie-Hellman. Which would >> > seem to be a big step backwards compared to the current capabilities of TLS. >> >> Hmm... I don't see why. Can you explain? > > True -- so we would need a new X.509v3 cert attribute in the Server > certificate to signal back to the client in a fashion that the > attacker can not subvert. Correct, but of course at that point downgrade attack in the TLS handshake itself is no longer a concern for this feature. -Ekr From nico@cryptonector.com Wed Mar 14 23:04:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BB821F85DD for ; Wed, 14 Mar 2012 23:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy4ecZo3oXvN for ; Wed, 14 Mar 2012 23:04:45 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id EF39121F85D7 for ; Wed, 14 Mar 2012 23:04:40 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 6DCA436006D for ; Wed, 14 Mar 2012 23:04:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=BCxPISr1QDUvejEBCDfG8 yOAuwpJ3HMTcSrr5GFWQb9fw5fMQuvr4sCz8dGuGcVSiwDAKYz5oDB9R/Z7fR++b KcNfyFPrs+URruYWgjUFb4QqsfyGNuyGb75A2IZA7K48H3/tHAXp+83J23mGhgs9 B8ah4GgoIiF5EO7ugSL5c0= 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=Ey9Uj1ujtex/xR0e2GWQ atjae6U=; b=GHbeO4h0OlBCqNs02cgUnSSStx1Khbr79DXtVCukT+OG7vA+Hvpe YcuIaIaTlk6JNsYtiIyoYKSRbOslBCp8IuCPjlN7svhR3mN5C+vIz7KaXFzQnf96 Zt6D7QJCWaT94M8EHDioefbAFTTf5u0QoX8NIN0Zqq2e+9i8n+9m4r4= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 5E25536006A for ; Wed, 14 Mar 2012 23:04:25 -0700 (PDT) Received: by dald2 with SMTP id d2so5501723dal.27 for ; Wed, 14 Mar 2012 23:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.227.74 with SMTP id ry10mr2143250pbc.160.1331791464929; Wed, 14 Mar 2012 23:04:24 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Wed, 14 Mar 2012 23:04:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 01:04:24 -0500 Message-ID: From: Nico Williams To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 06:04:46 -0000 Instead of this (taken from the I-D): Client Server ClientHello --------> ServerHello Certificate CertificateRequest <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec Certificate CertificateVerify Finished --------> ChangeCipherSpec <-------- Finished Application Data <-------> Application Data I propose this: Client Server ClientHello --------> (With an extension saying "I can send user cert/verify immediately before my first app data". The server's hello must confirm.) ServerHello Certificate* ServerKeyExchange* CertificateRequest* <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished --------> [ChangeCipherSpec] <-------- Finished Certificate CertificateVerify Application Data --------> <-------- Finished Application Data <-------> Application Data This seems a lot easier to analyze, and it's still an optimization over renego (though not as good as the one you propose). Also, billing this as optimized renego seems a lot better to me. Nico -- From ynir@checkpoint.com Thu Mar 15 00:09:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD99121F853E for ; Thu, 15 Mar 2012 00:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je1AqvUiujBT for ; Thu, 15 Mar 2012 00:09:06 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5864C21F8455 for ; Thu, 15 Mar 2012 00:09:03 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2F78vLP009388; Thu, 15 Mar 2012 09:08:57 +0200 X-CheckPoint: {4F619561-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 15 Mar 2012 09:08:57 +0200 From: Yoav Nir To: Nico Williams Date: Thu, 15 Mar 2012 09:08:53 +0200 Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0Cenx3vm5vtYRUTn66kJpwEjKfYA== Message-ID: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 07:09:06 -0000 Or even this: Client Server ClientHello --------> (With an extension saying "I can send user cert/verify immediately before my first app data". The server's hello must confirm.) ServerHello Certificate* ServerKeyExchange* <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished --------> [ChangeCipherSpec] <-------- Finished Application Data --------> <-------- CertificateRequest Certificate CertificateVerify --------> Application Data <-------> Application Data In this case the first Application Data sent by the client carries somethin= g like "GET /LoginWithCerts.html", which would trigger renego otherwise. Or= if the entire website requires client certificates, the CertificateRequest= could just follow the Finished. On Mar 15, 2012, at 8:04 AM, Nico Williams wrote: > Instead of this (taken from the I-D): >=20 > Client Server >=20 > ClientHello --------> > ServerHello > Certificate > CertificateRequest > <-------- ServerHelloDone > ClientKeyExchange > ChangeCipherSpec > Certificate > CertificateVerify > Finished --------> > ChangeCipherSpec > <-------- Finished > Application Data <-------> Application Data >=20 >=20 > I propose this: >=20 >=20 > Client Server >=20 > ClientHello --------> > (With an extension saying "I can > send user cert/verify immediately > before my first app data". > The server's hello must confirm.) > ServerHello > Certificate* > ServerKeyExchange* > CertificateRequest* > <-------- ServerHelloDone > ClientKeyExchange > ChangeCipherSpec > Finished --------> >=20 > [ChangeCipherSpec] > <-------- Finished > Certificate > CertificateVerify > Application Data --------> > <-------- Finished > Application Data <-------> Application Data >=20 > This seems a lot easier to analyze, and it's still an optimization > over renego (though not as good as the one you propose). >=20 > Also, billing this as optimized renego seems a lot better to me. >=20 > Nico > -- > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From mbadra@gmail.com Thu Mar 15 07:24:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7E021F85A7 for ; Thu, 15 Mar 2012 07:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsicEz0SlwJT for ; Thu, 15 Mar 2012 07:24:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCDEC21F852A for ; Thu, 15 Mar 2012 07:24:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so45361vbb.31 for ; Thu, 15 Mar 2012 07:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5bP283v4YnP1meezvVyOodyfyJh1a8ELDusruLoLdig=; b=Cj32lcZ0PxBpPBcN/ZHN2ukZXukxY6L6r6zUCERMSHYZEQkMblcwajIB3cO+3N9veQ ml3+3Oop0kdJhMq1O2F+FjD8actGc7XkUW2vRZlGdTjmJhIIKOSMxzQQ1zejNij1XiF0 zQVAfJCoQh6vDkhwr1vUi75o29G9HwdVMYe7zGewUqcNyTJD0UWM1Y/LCGJpB1gDoZjU 2m9XxgiTy+0XYqJc4jj1R7FAc7bAB/b2KY0wiVYa3FPkE22OTwCNSLxuOSclbTP9FT44 h1O0EW3xU8xGkqWhW1Q6ciM4+TOWaHonjc0gCIOEylJ8pm6QMIqtRMgEan05ogPx9+ly d6/w== MIME-Version: 1.0 Received: by 10.52.30.98 with SMTP id r2mr4781497vdh.8.1331821494161; Thu, 15 Mar 2012 07:24:54 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Thu, 15 Mar 2012 07:24:54 -0700 (PDT) In-Reply-To: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> Date: Thu, 15 Mar 2012 15:24:54 +0100 Message-ID: From: Mohamad Badra To: Yoav Nir Content-Type: multipart/alternative; boundary=20cf3079b89e104f2804bb48db83 Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:24:59 -0000 --20cf3079b89e104f2804bb48db83 Content-Type: text/plain; charset=ISO-8859-1 Eric Rescorla wrote: > so the Finished is too late to detect tampering Yoav Nir wrote: > Or even this: Nico Williams wrote: > Instead of this (taken from the I-D): TLS clients need an indication from the server that is authenticated by the server and cannot be stripped from the handshake. IMO, we don't need major changes to the messages order or to send/receive application data before sending/receiving the Finished messages. What about the following: Client Server ClientHello --------> ServerHello Certificate CertificateRequest <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec --------> ChangeCipherSpec <-------- Finished Certificate CertificateVerify Finished -------> The client will abort the handshake if the identity protection indication is not considered by the server when computing the verify_data. (BTW, it is not legal to send the ServerKeyExchange message because the current approach is limited to RSA key exchange method). Best regards, Badra On Thu, Mar 15, 2012 at 8:08 AM, Yoav Nir wrote: > Or even this: > Client Server > > ClientHello --------> > (With an extension saying "I can > send user cert/verify immediately > before my first app data". > The server's hello must confirm.) > ServerHello > Certificate* > ServerKeyExchange* > <-------- ServerHelloDone > ClientKeyExchange > ChangeCipherSpec > Finished --------> > > [ChangeCipherSpec] > <-------- Finished > Application Data --------> > <-------- CertificateRequest > Certificate > CertificateVerify --------> > Application Data <-------> Application Data > > In this case the first Application Data sent by the client carries > something like "GET /LoginWithCerts.html", which would trigger renego > otherwise. Or if the entire website requires client certificates, the > CertificateRequest could just follow the Finished. > > On Mar 15, 2012, at 8:04 AM, Nico Williams wrote: > > > Instead of this (taken from the I-D): > > > > Client Server > > > > ClientHello --------> > > ServerHello > > Certificate > > CertificateRequest > > <-------- ServerHelloDone > > ClientKeyExchange > > ChangeCipherSpec > > Certificate > > CertificateVerify > > Finished --------> > > ChangeCipherSpec > > <-------- Finished > > Application Data <-------> Application Data > > > > > > I propose this: > > > > > > Client Server > > > > ClientHello --------> > > (With an extension saying "I can > > send user cert/verify immediately > > before my first app data". > > The server's hello must confirm.) > > ServerHello > > Certificate* > > ServerKeyExchange* > > CertificateRequest* > > <-------- ServerHelloDone > > ClientKeyExchange > > ChangeCipherSpec > > Finished --------> > > > > [ChangeCipherSpec] > > <-------- Finished > > Certificate > > CertificateVerify > > Application Data --------> > > <-------- Finished > > Application Data <-------> Application Data > > > > This seems a lot easier to analyze, and it's still an optimization > > over renego (though not as good as the one you propose). > > > > Also, billing this as optimized renego seems a lot better to me. > > > > Nico > > -- > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > Scanned by Check Point Total Security Gateway. > > --20cf3079b89e104f2804bb48db83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Eric Rescorla wrote:=A0
so the Finished=A0is too late to detect tamp= ering=A0
=A0
Yoav Nir=A0<= ynir@checkpoint.com>= =A0wrote:
Or even this:
=A0
Nico Williams wrote:
Instead of this (taken from the I-D):=A0

<= div>
TLS clients need an indication from the server that is authenticate= d by the server and cannot be stripped from the handshake. IMO, we don'= t need major changes to the messages order or to send/receive application d= ata before sending/receiving the Finished messages.

What about the following:

            Client          =
                 Server

            ClientHello       -------->
                                             ServerHello
                                             Certificate
                                             CertificateRequest
                              <--------      ServerHelloDone
            ClientKeyExchange
            ChangeCipherSpec  -------->
                                             ChangeCipherSpec
                              <--------      Finished           =A0
            Certi=
ficate
            CertificateVerify

            =
Finished          ------->     =20


The client will abort the handshake if the identity pr=
otection indication is not considered by the server when computing the veri=
fy_data.

(BTW, it is= not legal to send the ServerKeyExchange message because=A0the curre= nt approach is limited to RSA key exchange method).

Best regards,
Badra=A0

On Thu, Mar 15, 2012 at 8:08 AM, Yoav Nir <ynir@checkpoint.com><= /span> wrote:
Or even this:
=A0 =A0 Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Server

=A0 =A0 ClientHello =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-------->
=A0 =A0 (With an extension saying "I can
=A0 =A0 =A0send user cert/verify immediately
=A0 =A0 =A0before my first app data".
=A0 =A0 =A0The server's hello must confirm.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ServerHello
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Certificate*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0ServerKeyExchange*
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0<-------- =A0 =A0 =A0ServerHelloDone
=A0 =A0 ClientKeyExchange
=A0 =A0 ChangeCipherSpec
=A0 =A0 Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -------->

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0[ChangeCipherSpec]
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<---= ----- =A0 =A0 =A0 =A0 =A0 =A0 Finished
=A0 =A0 Application Data =A0 =A0 =A0 =A0 =A0 =A0 -------->
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<---= ----- =A0 CertificateRequest
=A0 =A0 Certificate
=A0 =A0 CertificateVerify =A0 =A0 =A0 =A0 =A0 =A0-------->
=A0 =A0 Application Data =A0 =A0 =A0 =A0 =A0 =A0 <---= ----> =A0 =A0 Application Data

In this case the first Application Data sent by the client carries so= mething like "GET /LoginWithCerts.html", which would trigger rene= go otherwise. Or if the entire website requires client certificates, the Ce= rtificateRequest could just follow the Finished.

On Mar 15, 2012, at 8:04 AM, Nico Williams wrote:

> Instead of this (taken from the I-D):
>
> =A0 =A0 =A0 =A0 =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 Server
>
> =A0 =A0 =A0 =A0 =A0 =A0ClientHello =A0 =A0 =A0 -------->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 ServerHello
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 Certificate
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 CertificateRequest
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-------= - =A0 =A0 =A0ServerHelloDone
> =A0 =A0 =A0 =A0 =A0 =A0ClientKeyExchange
> =A0 =A0 =A0 =A0 =A0 =A0ChangeCipherSpec
> =A0 =A0 =A0 =A0 =A0 =A0Certificate
> =A0 =A0 =A0 =A0 =A0 =A0CertificateVerify
> =A0 =A0 =A0 =A0 =A0 =A0Finished =A0 =A0 =A0 =A0 =A0-------->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 ChangeCipherSpec
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<-------= - =A0 =A0 =A0Finished
> =A0 =A0 =A0 =A0 =A0 =A0Application Data =A0<-------> =A0 =A0 =A0= Application Data
>
>
> I propose this:
>
>
> =A0 =A0 =A0Client =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Server
>
> =A0 =A0 =A0ClientHello =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-------->=
> =A0 =A0 =A0(With an extension saying "I can
> =A0 =A0 =A0 send user cert/verify immediately
> =A0 =A0 =A0 before my first app data".
> =A0 =A0 =A0 The server's hello must confirm.)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ServerHello
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Certificate*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 ServerKeyExchange*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0CertificateRequest*
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &l= t;-------- =A0 =A0 =A0ServerHelloDone
> =A0 =A0 =A0ClientKeyExchange
> =A0 =A0 =A0ChangeCipherSpec
> =A0 =A0 =A0Finished =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 --------&g= t;
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 [ChangeCipherSpec]
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &l= t;-------- =A0 =A0 =A0 =A0 =A0 =A0 Finished
> =A0 =A0 =A0Certificate
> =A0 =A0 =A0CertificateVerify
> =A0 =A0 =A0Application Data =A0 =A0 =A0 =A0 =A0 =A0 -------->
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &l= t;-------- =A0 =A0 =A0 =A0 =A0 =A0 Finished
> =A0 =A0 =A0Application Data =A0 =A0 =A0 =A0 =A0 =A0 <-------> = =A0 =A0 Application Data
>
> This seems a lot easier to analyze, and it's still an optimization=
> over renego (though not as good as the one you propose).
>
> Also, billing this as optimized renego seems a lot better to me.
>
> Nico
> --
> _________________________________= ______________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
> Scanned by Check Point T= otal Security Gateway.


--20cf3079b89e104f2804bb48db83-- From mrex@sap.com Thu Mar 15 17:49:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0A021E8053 for ; Thu, 15 Mar 2012 17:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.056 X-Spam-Level: X-Spam-Status: No, score=-10.056 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Qz-tek9b5C for ; Thu, 15 Mar 2012 17:49:50 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 62FCE21E8049 for ; Thu, 15 Mar 2012 17:49:49 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2G0naRN015727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Mar 2012 01:49:36 +0100 (MET) From: Martin Rex Message-Id: <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Fri, 16 Mar 2012 01:49:35 +0100 (MET) In-Reply-To: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> from "Yoav Nir" at Mar 15, 12 09:08:53 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] cipher suites for protecting client credentials 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, 16 Mar 2012 00:49:51 -0000 Yoav Nir wrote: > > Or even this: > Client Server > > ClientHello --------> > (With an extension saying "I can > send user cert/verify immediately > before my first app data". > The server's hello must confirm.) > ServerHello > Certificate* > ServerKeyExchange* > <-------- ServerHelloDone > ClientKeyExchange > ChangeCipherSpec > Finished --------> > > [ChangeCipherSpec] > <-------- Finished > Application Data --------> > <-------- CertificateRequest > Certificate > CertificateVerify --------> > Application Data <-------> Application Data > > In this case the first Application Data sent by the client carries > something like "GET /LoginWithCerts.html", which would trigger renego > otherwise. Or if the entire website requires client certificates, > the CertificateRequest could just follow the Finished. I find this approach appealing. The stuff that is signed by CertificateVerify here is slightly different from what is signed during the regular handshake, though. We still have the Finished Message around (tls channel bindings). While binding the finished message is weaker that the handshake message hash that goes into the original CertificateVerify, it is probably OK (excessive truncation of the finished message in TLSv1.2 is a pity). Doing it in this fashion would get rid of the problem of the channel binding or the tls exporters changing when the server requests the client certificate not in the initial handshake. It amounts to an "optimized renegotiation" for the sole purpose of requesting a client certificate. Existing Apps that are exposed to the flow of the TLS handshake tokens (like apps sitting on top of transportless APIs, such as Microsoft's SSPI for schannel, might be surprised by a "renegotiation" that completes in 1 round-trip, so this is a feature that should be employed by the TLS stack only by request of the caller. -Martin From nico@cryptonector.com Thu Mar 15 18:03:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE01521E8059 for ; Thu, 15 Mar 2012 18:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYwfZgrMPQw4 for ; Thu, 15 Mar 2012 18:03:38 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 33F8C21F852E for ; Thu, 15 Mar 2012 18:03:38 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 02F802F406A for ; Thu, 15 Mar 2012 18:03:38 -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=UnFnw7SI+B4TdldiRAyMQ GfoLuP3HpvlIufNqTHpsx1QVxhT5rxC3haAxYy6b8BIHJ1a+L+F2TkdRi8hMlKlG VmHedsZ4DIPahxB3wO0cFPUI23TE/wsaUhDvGEP49mf4fYOp1+ed7MAiqrS492rV XHcSlX9QXeTs4B1HDGyU5U= 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=dhCdrXBR7cAAGeqAh8CC MEhksn8=; b=udPvfmFHpZpF528FYOz03D3LAq/IHrIeBbdIZZlqG9JHB8b6cfKA 2cklkOpigvKluyP2VDTwwdsXKJs4MxeU2oNEcM9vewyixiPXGo57QphV4NTIyuft cCGD5wi+eOvqU7WtoR95qImm+fkTdKm4kJ289snaznaZ2FecTQh4eC0= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id D1ADB2F4059 for ; Thu, 15 Mar 2012 18:03:37 -0700 (PDT) Received: by dakl33 with SMTP id l33so6191560dak.31 for ; Thu, 15 Mar 2012 18:03:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.100 with SMTP id hf4mr9319723pbc.118.1331859817248; Thu, 15 Mar 2012 18:03:37 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Thu, 15 Mar 2012 18:03:37 -0700 (PDT) In-Reply-To: <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> Date: Thu, 15 Mar 2012 20:03:37 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 01:03:38 -0000 Marsh's point remains. We're talking about how to authenticate with privacy protection in fewer round-trips. That's nice. But how does the client know whether it can reveal its identity (cert) to a given server, and if so, which ID (since the client can have many). There are several methods by which the client could know: - out of band - policy information delivered with cert when using CSRs - policy information embedded in the cert - online infrastructure - user interaction and probably more. This does need addressing, otherwise if an active attacker with a valid cert can cause the client to reveal its ID -which is bad a priori given the point of renego and this extension- then we've not achieved the goal of protecting the client's ID. Nico -- From tom@ritter.vg Fri Mar 16 01:16:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D95921F871A for ; Fri, 16 Mar 2012 01:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.855 X-Spam-Level: X-Spam-Status: No, score=-2.855 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFmEj5sLa6t8 for ; Fri, 16 Mar 2012 01:16:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2121F8617 for ; Fri, 16 Mar 2012 01:16:26 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4458365ghb.31 for ; Fri, 16 Mar 2012 01:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=jKMU/mbVjBsmhpbH2J9XqCxBZdsXSmCNW2Olp6pb7nQ=; b=VABVnFHDpPgP5BmcEPgFhEqoB3tEDWaishX56fAQNY4VdX+kE2spQ/w4adMTkncmNk 2EiO72cW9g4YPIpr5/gRwYbWmAhIV87DUIm5Q+lE8eAXfNZfLMvAHIKCNGxGtyiB21Sl sDARq5/YNKlNlazTbgg/fts+on/O2Z4/268fQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=jKMU/mbVjBsmhpbH2J9XqCxBZdsXSmCNW2Olp6pb7nQ=; b=jRO8By2xIM6tQc3Ddmv5vhvIYK0/zjqzkdginY1irqJk3UpfuHDo2VkiiDMcZMuxds OuCPpWEDQUf+2dxbLdzywu+Su0RCoZOd12+6EqC6ZCdP+IZt52ZYk1oqCcgIJpY7CjVz jjZwYE3fcDQfpb/H1jan+ccw3jJ7ZnHv+CV3m3AA9KnuVrHxCUpQDKRabwOtIqW5arPS 8tE78BAo4mKM5Wp/oP/dYFrFwqfHPQA7+W0u4H5SOALPkSsy9DRdq8SKjztf3Dtx09oh 8+47Onevv6FRfeyHjl1g0Ksv3HJr7f0pYN/4pa2238/FOAbfjYSlC2UPzVpaKrmfQt7Y qz5w== Received: by 10.60.22.233 with SMTP id h9mr1995407oef.30.1331885785884; Fri, 16 Mar 2012 01:16:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.105 with HTTP; Fri, 16 Mar 2012 01:16:05 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> From: Tom Ritter Date: Fri, 16 Mar 2012 09:16:05 +0100 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb2016026284804bb57d35e X-Gm-Message-State: ALoCoQlPWQsbf0HxEVQnEWIoZ+RmsaQfOX4BR9humq60Gi4MDPVDacduAoSWwVj2MpOI4Q3F2F2y Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 08:16:28 -0000 --e89a8fb2016026284804bb57d35e Content-Type: text/plain; charset=ISO-8859-1 On 16 March 2012 02:03, Nico Williams wrote: > an active attacker with a valid cert > We started the discussion with a proposal designed to protect against a passive eavesdropper, then moved to an active attacker willing to break the handshake, then an active attacker who can fully impersonate the server. I'm not saying this progression is bad, but obviously it makes things way more complicated. If the attacker can fully impersonate the server and/or the client is willing to send their client cert to the server - I don't know if there's much protocol wise that can be done. A thought I had, probably dinged by my lack of PKI consulting, is if the "Always send the client cert confidentially" flag wasn't on the server cert but instead the client cert. The client cert would be unusable without talking to a server who supported the mode - but in all deployments I've seen of Client Certs the user and server already have a trust relationship, and the user follows the server's instructions to obtain a client cert. If client certs expire in a reasonable timeline, after the server is upgraded, all employees will roll onto the newer certs after a period of time. And the user will never be tricked into sending the certificate unencrypted - if an active adversary removes the indicator for encrypted client certs, the client fails. The big drawback is that a client cert now becomes unusuable on the 'broad' internet, which has not been upgraded and cannot accept encrypted client certs. -tom --e89a8fb2016026284804bb57d35e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 16 March 2012 02:03, Nico Williams <nic= o@cryptonector.com> wrote:
an active attacker with a valid cert

We started th= e discussion with a proposal designed to protect against a passive eavesdro= pper, then moved to an active attacker willing to break the handshake, then= an active attacker who can fully impersonate the server.=A0 I'm not sa= ying this progression is bad, but obviously it makes things way more compli= cated. If the attacker can fully impersonate the server and/or the client i= s=20 willing to send their client cert to the server - I don't know if=20 there's much protocol wise that can be done.

A thought I had, probably dinged by my lack of PKI consulting, is if th= e "Always send the client cert confidentially" flag wasn't on= the server cert but instead the client cert.=A0 The client cert would be u= nusable without talking to a server who supported the mode - but in all dep= loyments I've seen of Client Certs the user and server already have a t= rust relationship, and the user follows the server's instructions to ob= tain a client cert.=A0 If client certs expire in a reasonable timeline, aft= er the server is upgraded, all employees will roll onto the newer certs aft= er a period of time.=A0 And the user will never be tricked into sending the= certificate unencrypted - if an active adversary removes the indicator for= encrypted client certs, the client fails.=A0 The big drawback is that a cl= ient cert now becomes unusuable on the 'broad' internet, which has = not been upgraded and cannot accept encrypted client certs.

-tom
--e89a8fb2016026284804bb57d35e-- From hannes.tschofenig@nsn.com Fri Mar 16 02:00:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53A721F8699 for ; Fri, 16 Mar 2012 02:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.421 X-Spam-Level: X-Spam-Status: No, score=-106.421 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNwG0UDbJiJ4 for ; Fri, 16 Mar 2012 02:00:06 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8487021F858B for ; Fri, 16 Mar 2012 02:00:05 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2G903Z3001242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Mar 2012 10:00:03 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2G8xx4E027376; Fri, 16 Mar 2012 10:00:01 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 09:59:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0353.296D7CC3" Date: Fri, 16 Mar 2012 10:59:56 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01382E3F@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0DTR7HE8Ge11GhRme872toG1XE9wABZmVg References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com><201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Tom Ritter" , X-OriginalArrivalTime: 16 Mar 2012 08:59:58.0262 (UTC) FILETIME=[29D53560:01CD0353] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 8284 X-purgate-ID: 151667::1331888403-000044A2-F1C70D63/0-0/0-0 Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 09:00:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0353.296D7CC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a thought that came to my mind: How often is client authentication via certificates used in TLS in the real world?=20 If you think about all the Web use cases then there authentication happens at the application layer.=20 If you think about the network access authentication use cases then folks are more focused on tunneled methods (instead of plain EAP-TLS).=20 For enterprise uses cases where client certificates are used there you often have the WebSSO solution in place and there the scenario is likely different as well. =20 =20 From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of ext Tom Ritter Sent: Friday, March 16, 2012 10:16 AM To: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials =20 On 16 March 2012 02:03, Nico Williams wrote: an active attacker with a valid cert We started the discussion with a proposal designed to protect against a passive eavesdropper, then moved to an active attacker willing to break the handshake, then an active attacker who can fully impersonate the server. I'm not saying this progression is bad, but obviously it makes things way more complicated. If the attacker can fully impersonate the server and/or the client is willing to send their client cert to the server - I don't know if there's much protocol wise that can be done. A thought I had, probably dinged by my lack of PKI consulting, is if the "Always send the client cert confidentially" flag wasn't on the server cert but instead the client cert. The client cert would be unusable without talking to a server who supported the mode - but in all deployments I've seen of Client Certs the user and server already have a trust relationship, and the user follows the server's instructions to obtain a client cert. If client certs expire in a reasonable timeline, after the server is upgraded, all employees will roll onto the newer certs after a period of time. And the user will never be tricked into sending the certificate unencrypted - if an active adversary removes the indicator for encrypted client certs, the client fails. The big drawback is that a client cert now becomes unusuable on the 'broad' internet, which has not been upgraded and cannot accept encrypted client certs. -tom ------_=_NextPart_001_01CD0353.296D7CC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a thought that came to my mind: How often is client = authentication via certificates used in TLS in the real world? =

If you think about all the Web use cases then there authentication = happens at the application layer.

If you think about the network access authentication use cases then = folks are more focused on tunneled methods (instead of plain EAP-TLS). =

For enterprise uses cases where client certificates are used there = you often have the WebSSO solution in place and there the scenario is = likely different as well.

 

 

From:= = tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = ext Tom Ritter
Sent: Friday, March 16, 2012 10:16 = AM
To: tls@ietf.org
Subject: Re: [TLS] cipher suites = for protecting client credentials

 

On 16 = March 2012 02:03, Nico Williams <nico@cryptonector.com> wrote:

an active attacker with a valid = cert


We started the = discussion with a proposal designed to protect against a passive = eavesdropper, then moved to an active attacker willing to break the = handshake, then an active attacker who can fully impersonate the = server.  I'm not saying this progression is bad, but obviously it = makes things way more complicated. If the attacker can fully impersonate = the server and/or the client is willing to send their client cert to the = server - I don't know if there's much protocol wise that can be = done.

A thought I had, probably dinged by my lack of PKI = consulting, is if the "Always send the client cert = confidentially" flag wasn't on the server cert but instead the = client cert.  The client cert would be unusable without talking to = a server who supported the mode - but in all deployments I've seen of = Client Certs the user and server already have a trust relationship, and = the user follows the server's instructions to obtain a client = cert.  If client certs expire in a reasonable timeline, after the = server is upgraded, all employees will roll onto the newer certs after a = period of time.  And the user will never be tricked into sending = the certificate unencrypted - if an active adversary removes the = indicator for encrypted client certs, the client fails.  The big = drawback is that a client cert now becomes unusuable on the 'broad' = internet, which has not been upgraded and cannot accept encrypted client = certs.

-tom

------_=_NextPart_001_01CD0353.296D7CC3-- From mbadra@gmail.com Fri Mar 16 05:09:08 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5720421F85F7 for ; Fri, 16 Mar 2012 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61gZ2EjV9k+T for ; Fri, 16 Mar 2012 05:09:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF421F85F4 for ; Fri, 16 Mar 2012 05:09:07 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5112545vcb.31 for ; Fri, 16 Mar 2012 05:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uC++Sb3OqMNdtUDogI3t1faaKjutPq38IHgK07FdFw8=; b=G4nV/MNHn8sQoswfpVFRR/X74LJnDe/JAfgO/Doshb0j6Ok9UT0UfCCDXCq4Gac3IA jFMYfTPSlOQ19hYVqtB62TW8CmqDfVNUuU6Kdv7QPCD46NlI1syBroZLFdHI37dWJ+QQ FHaKdaUwoXl5TJaKUcH06NSun7qQY4iz93GlE95Jtvnko0n55yiVCRbH8Rb6IKiwJxBI vNAmmPTifP63zYm7zdPK2SwMg1CUWA1zWQWvU/3fH1X+mjxv7+1oghhiir3PD4l1KijW 5LBBwZ1LhNoZkxWgU6IMtSXWWZotdTB+gn6IaxWyw6vfJdWiOOVBDv06A4qSRnsJl4Di Csmg== MIME-Version: 1.0 Received: by 10.52.34.200 with SMTP id b8mr1401121vdj.59.1331899746789; Fri, 16 Mar 2012 05:09:06 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Fri, 16 Mar 2012 05:09:06 -0700 (PDT) In-Reply-To: <201203150501.q2F51NvE000872@fs4113.wdf.sap.corp> References: <201203150501.q2F51NvE000872@fs4113.wdf.sap.corp> Date: Fri, 16 Mar 2012 13:09:06 +0100 Message-ID: From: Mohamad Badra To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf30780f3e48a78404bb5b13fd Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:09:08 -0000 --20cf30780f3e48a78404bb5b13fd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 15, 2012 at 6:01 AM, Martin Rex wrote: > Eric Rescorla wrote: > > > > On Wed, Mar 14, 2012 at 9:29 PM, Marsh Ray > wrote: > > True -- so we would need a new X.509v3 cert attribute in the Server > certificate to signal back to the client in a fashion that the > attacker can not subvert. > I believe there is a better alternative that could be done at the TLS level; what if the server sends its Finished (see diagram below) before sending the client's certificate and computes the verify_data in case it supports the SCSV, as follows: verify_data PRF(master_secret, finished_label, Hash(handshake_messages + {0xXX, 0xXX})) [0..verify_data_length-1]; where + mean concatenation and {0xXX, 0xXX} is the SCSV's code point. The client MUST verify that the contents are correct to continue the Handshake. Otherwise, it MUST abort the handshake. This protects clients against tampering attacks and allows them to receive an indication from the server that is authenticated by the server and cannot be stripped from the handshake. Client Server ClientHello --------> ServerHello Certificate CertificateRequest <-------- ServerHelloDone ClientKeyExchange ChangeCipherSpec --------> ChangeCipherSpec <-------- Finished Certificate CertificateVerify Finished -------> Comments? Best regards, Badra --20cf30780f3e48a78404bb5b13fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 15, 2012 at 6:01 AM= , Martin Rex <mrex@sap= .com> wrote:
Eric Rescorla wrote:
>
> On Wed, Mar 14, 2012 at 9:29 PM, Marsh Ray <marsh@extendedsubset.com> wrote:

True -- so we would need a new X.509v3 cert attribute in the Server certificate to signal back to the client in a fashion that the
attacker can not subvert.


I believe there is a better alternative that could be done at the TLS lev= el; what if the server sends its Finished (see diagram below) before sendin= g the client's certificate and computes=A0the verify_data in case it su= pports the SCSV, as follows:

      verify_data
         PRF(master_secret, finished_label, Hash(handshake_messages +=A0{0xXX, 0xXX}))
            [0..verify_data_length-1];

where= + mean concatenation and=A0{0xXX, 0xXX} is t= he SCSV's=A0code point.

The client=A0MUST verify that the contents are correct to continue t= he Handshake. Otherwise, it MUST abort the handshake.

=
This protects clients against tampering attacks and allows them to rec= eive=A0an indication from the server that is authenticated by t= he server and cannot be stripped from the handshake.

            Client                 =
          Server

            ClientHello       -------->
                                             ServerHello
                                             Certificate
                                             CertificateRequest
                              <--------      ServerHelloDone
            ClientKeyExchange
            ChangeCipherSpec  -------->
                                             ChangeCipherSpec
                              <--------      Finished           =A0
            Certificate
            CertificateVerify

            Finished          ------->     =20

Comments?
Best regards,
Badra=A0
--20cf30780f3e48a78404bb5b13fd-- From nico@cryptonector.com Fri Mar 16 06:27:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F9721F865B for ; Fri, 16 Mar 2012 06:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXG27XYZoKXB for ; Fri, 16 Mar 2012 06:27:05 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E765621F86D1 for ; Fri, 16 Mar 2012 06:27:04 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 918E89406D for ; Fri, 16 Mar 2012 06:27:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mo/t3soJY/b41hOZPJzB30naYeqUPp8GI9cn4zKjAMdv 7AP05zwcTYP9o9jE8YbOeClggIHcM6mlEc5G1SGi/qz+9eP+owVJpgvUnEPbZRc4 Ls+DRneQG1knfUwzflF264KR07QxamhX10eKpApyeMtiqI3kQGgc9Nk0mGj50E8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=CYCCOrfaM68tSJrRKXmo8a4FP7w=; b=RnvMz+ERz24 mINPIq5aWoGWhj9+mRpMpmR/jYuX6A4x7weY1PckNyq+if6wXsaNdV6fx8eDuWOj vFZXL+e0xqVvhiqqXXGK8xSHatsBN4dQFrtESYX2kfImN+5fM6tT/i114QXcT/jn W1/5NV+kD5UPu/qp4bLQV3yUiqAEgYqw= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 8116994005 for ; Fri, 16 Mar 2012 06:27:04 -0700 (PDT) Received: by dakl33 with SMTP id l33so7073734dak.31 for ; Fri, 16 Mar 2012 06:27:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.129 with SMTP id ka1mr11643pbc.160.1331904424030; Fri, 16 Mar 2012 06:27:04 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 06:27:03 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> Date: Fri, 16 Mar 2012 08:27:03 -0500 Message-ID: From: Nico Williams To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:27:05 -0000 On Fri, Mar 16, 2012 at 3:16 AM, Tom Ritter wrote: > On 16 March 2012 02:03, Nico Williams wrote: >> >> an active attacker with a valid cert > > We started the discussion with a proposal designed to protect against a > passive eavesdropper, then moved to an active attacker willing to break t= he > handshake, then an active attacker who can fully impersonate the server. > I'm not saying this progression is bad, but obviously it makes things way > more complicated. If the attacker can fully impersonate the server and/or > the client is willing to send their client cert to the server - I don't k= now > if there's much protocol wise that can be done. The TLS threat model assumes active attackers, else we wouldn't bother with server certificates. This is why things are complicated already :) It follows that we if we care about confidentiality of client certificates then we should assume active attackers. This means that the authorization function for deciding when to present a(which) client certificate cannot depend merely on the server's having a valid certificate. > A thought I had, probably dinged by my lack of PKI consulting, is if the > "Always send the client cert confidentially" flag wasn't on the server ce= rt > but instead the client cert.=C2=A0 The client cert would be unusable with= out This is one of the things Marsh suggested. I realize that in my post I didn't clarify which cert might carry authorization information for this. But I think it's clear that it's much easier to use such information when it's in the client's cert. > talking to a server who supported the mode - but in all deployments I've > seen of Client Certs the user and server already have a trust relationshi= p, > and the user follows the server's instructions to obtain a client cert.= =C2=A0 If In those cases you can have out-of-band authz-data. Out of band does not scale to Internet scale, but: > client certs expire in a reasonable timeline, after the server is upgrade= d, > all employees will roll onto the newer certs after a period of time.=C2= =A0 And > the user will never be tricked into sending the certificate unencrypted -= if > an active adversary removes the indicator for encrypted client certs, the > client fails.=C2=A0 The big drawback is that a client cert now becomes un= usuable > on the 'broad' internet, which has not been upgraded and cannot accept > encrypted client certs. Client certs are already pretty much not used on the Internet. Nico -- From mbadra@gmail.com Fri Mar 16 08:22:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C3B21F863E for ; Fri, 16 Mar 2012 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SF8r3Se8V+mX for ; Fri, 16 Mar 2012 08:22:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B786721F862B for ; Fri, 16 Mar 2012 08:22:53 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5342127vcb.31 for ; Fri, 16 Mar 2012 08:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gL60wHU8wsUj+cqW7Y0sAUdnile8squjhqFRXZgQQAU=; b=GpeVPTkJuMVK448Qcr+2Bfd9RD5pxy0rhcO+7I4wXIK6JhuYJnzFs/ZMTMd34j5Yc+ ijkCrVajVDj1XIeQATKCCzYF7Me6Inr/y9++jURvwLo9J0/hSMB8BNdYsQALM1hfEM8Z vidJe6NL2/dKg7YKiZw/xkSgy1//GdfOmKWkw8jZPxSVLKAY8GrdmBy3I4BBqekMGeLD vFaMQvVr4qfeUDBJRHqFj2FH86mfBQZIzxEQ0BqPPHP3g3AhoEEk0DNX+y6+eCaWcD8A EfswmGgJoLlBrRzG8DUWLX7b5ez370gw4OLMKa6B4MSJ5ODoMHUagvRLod/JKDOx9rT/ Xetw== MIME-Version: 1.0 Received: by 10.52.93.74 with SMTP id cs10mr1646720vdb.42.1331911373120; Fri, 16 Mar 2012 08:22:53 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Fri, 16 Mar 2012 08:22:53 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> Date: Fri, 16 Mar 2012 16:22:53 +0100 Message-ID: From: Mohamad Badra To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec501673944666a04bb5dc8d2 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:22:57 -0000 --bcaec501673944666a04bb5dc8d2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 16, 2012 at 2:27 PM, Nico Williams wrote: > On Fri, Mar 16, 2012 at 3:16 AM, Tom Ritter wrote: > > On 16 March 2012 02:03, Nico Williams wrote: > >> > >> an active attacker with a valid cert > > > > We started the discussion with a proposal designed to protect against a > > passive eavesdropper, then moved to an active attacker willing to break > the > > handshake, then an active attacker who can fully impersonate the server. > > I'm not saying this progression is bad, but obviously it makes things way > > more complicated. If the attacker can fully impersonate the server and/or > > the client is willing to send their client cert to the server - I don't > know > > if there's much protocol wise that can be done. > > The TLS threat model assumes active attackers, else we wouldn't bother > with server certificates. This is why things are complicated already > :) > > Still not clear to me how in your opinion does TLS protect clients from active attackers with valid certificate? > It follows that we if we care about confidentiality of client > certificates then we should assume active attackers. Active attackers are considered into account in the draft. This means that > the authorization function for deciding when to present a(which) > client certificate cannot depend merely on the server's having a valid > certificate. > It depends on the server's having a valid certificate and on an authenticated indication (that the server supports identity protection) sent to the client. Best regards, Badra --bcaec501673944666a04bb5dc8d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 16, 2012 at 2:27 PM, Nico Williams <nico@cryptonector.com= > wrote:
On Fri, Mar 16, 2012 at 3:16 AM, Tom Ritter <tom@ritter.vg> wrote:
> On 16 March 2012 02:03, Nico Williams <nico@cryptonector.com> wrote:
>>
>> an active attacker with a valid cert
>
> We started the discussion with a proposal designed to protect against = a
> passive eavesdropper, then moved to an active attacker willing to brea= k the
> handshake, then an active attacker who can fully impersonate the serve= r.
> I'm not saying this progression is bad, but obviously it makes thi= ngs way
> more complicated. If the attacker can fully impersonate the server and= /or
> the client is willing to send their client cert to the server - I don&= #39;t know
> if there's much protocol wise that can be done.

The TLS threat model assumes active attackers, else we wouldn't b= other
with server certificates. =A0This is why things are complicated already
:)



Still not clear to me h= ow in your opinion does TLS protect clients from active attackers with vali= d certificate?=A0

=A0
It follows that we if we care about confidentiality of client
certificates then we should assume active attackers. =A0
<= br>

Active attackers are considered into account i= n the draft.=A0


This means that
the authorization function for deciding when to present a(which)
client certificate cannot depend merely on the server's having a valid<= br> certificate.

It depends on the server&#= 39;s having a valid certificate and on an authenticated indication (that th= e server supports identity protection) sent to the client.
=A0
Best regards,
Badra
--bcaec501673944666a04bb5dc8d2-- From paul.hoffman@vpnc.org Fri Mar 16 08:42:29 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3E521F8721 for ; Fri, 16 Mar 2012 08:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsO5hhi7-esk for ; Fri, 16 Mar 2012 08:42:26 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4376621F871B for ; Fri, 16 Mar 2012 08:42:26 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2GFgOAU042609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2012 08:42:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382E3F@FIESEXC035.nsn-intra.net> Date: Fri, 16 Mar 2012 08:42:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com><201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <999913AB42CC9341B05A99BBF358718D01382E3F@FIESEXC035.nsn-intra.net> To: "Tschofenig, Hannes (NSN - FI/Espoo)" X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:42:29 -0000 On Mar 16, 2012, at 1:59 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Just a thought that came to my mind: How often is client = authentication via certificates used in TLS in the real world? Often. It is just not use often on the web for typical commerce. > If you think about all the Web use cases then there authentication = happens at the application layer. Completely false. There are plenty of use cases where the server would = not want to even proceed with the underlying protocol if it didn't know = ahead of time that the client was able to authenticate. > If you think about the network access authentication use cases then = folks are more focused on tunneled methods (instead of plain EAP-TLS). TLS is used for many things other than network access. :-) > For enterprise uses cases where client certificates are used there you = often have the WebSSO solution in place and there the scenario is likely = different as well. And there are plenty of places where WebSSO is completely inappropriate. If you are suggesting "TLS is really only for web access", your argument = holds. TLS is designed, and actively used, for much more than that. --Paul Hoffman From paul.hoffman@vpnc.org Fri Mar 16 08:47:52 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A5321F866D for ; Fri, 16 Mar 2012 08:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.691 X-Spam-Level: X-Spam-Status: No, score=-102.691 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDcezwR7rMiO for ; Fri, 16 Mar 2012 08:47:51 -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 83F9721F866C for ; Fri, 16 Mar 2012 08:47:51 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2GFln7b042826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2012 08:47:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 16 Mar 2012 08:47:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8C2AA0F9-E11A-408D-AA46-0B75B4F267B4@vpnc.org> References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> To: Nico Williams X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:47:52 -0000 On Mar 16, 2012, at 6:27 AM, Nico Williams wrote: > The TLS threat model assumes active attackers, else we wouldn't bother > with server certificates. This is why things are complicated already > :) Indeed. > It follows that we if we care about confidentiality of client > certificates then we should assume active attackers. =20 Yes. > This means that > the authorization function for deciding when to present a(which) > client certificate cannot depend merely on the server's having a valid > certificate. Not necessarily. It is perfectly fine for us to say "we care about = protecting the identity in the client certificate only from passive = attackers if protecting from active attackers adds significant = complexity". It is also perfectly fine for us to say "we care about = protecting the identity in the client certificate in all cases". = However, the latter should not be assumed, given the already complex = nature of TLS. If the WG goes forward with "protect the client cert" work, I would want = to see the best proposal for protecting just against passive attackers = and the best proposal for protecting against active attackers before I = decide what is to complicated. I suspect the latter will be beyond what = I would want to deploy, and would be happy to be wrong about that. --Paul Hoffman From nico@cryptonector.com Fri Mar 16 09:15:23 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29C1921F86BA for ; Fri, 16 Mar 2012 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7Jy6vJwqlK4 for ; Fri, 16 Mar 2012 09:15:22 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFAE21F86B2 for ; Fri, 16 Mar 2012 09:15:22 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 3138B21DE59 for ; Fri, 16 Mar 2012 09:15: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:content-transfer-encoding; q=dns; s= cryptonector.com; b=TIHpSrsc1+Lx7Y3pXWjr74QGJstsJqhpPVFvPUANWTi/ r5MvbtILMwF2jOpvTa+tz/H7ZkyLKLQBzL2RYi7uLv84vEb5c58Jgo2gH3YymCvp CPRH6rTtpQyVLYD68CS7OBMYamnjp01Qw+LhwrSQejuT19GgiSf6d8bOvN+qCaU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wyff7WIo9cZmutorXXHG6rDR5pU=; b=sOQOUumW1aY gmfrSc+WCJXxeXiaviuZ55jb2IbQLtM8a+6pCbYN6KPbC22Z65GY8dI91Cno27ke cw+wCWRIRZm1OLxLhf0lJLUnN6Ayigr+F0mmrnqgpSK4RPMocfu0Z9Zwsv735nsm waxR0ARvPhabuaPHLwn+A+P+FsbI21pY= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (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 00C0C21DE58 for ; Fri, 16 Mar 2012 09:15:21 -0700 (PDT) Received: by yenm5 with SMTP id m5so4960715yen.31 for ; Fri, 16 Mar 2012 09:15:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.100 with SMTP id hf4mr15689446pbc.118.1331914521128; Fri, 16 Mar 2012 09:15:21 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 09:15:20 -0700 (PDT) In-Reply-To: <8C2AA0F9-E11A-408D-AA46-0B75B4F267B4@vpnc.org> References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <8C2AA0F9-E11A-408D-AA46-0B75B4F267B4@vpnc.org> Date: Fri, 16 Mar 2012 11:15:20 -0500 Message-ID: From: Nico Williams To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:15:23 -0000 On Fri, Mar 16, 2012 at 10:47 AM, Paul Hoffman wrot= e: > On Mar 16, 2012, at 6:27 AM, Nico Williams wrote: >> This means that >> the authorization function for deciding when to present a(which) >> client certificate cannot depend merely on the server's having a valid >> certificate. > > Not necessarily. It is perfectly fine for us to say "we care about protec= ting the identity in the client certificate only from passive attackers if = protecting from active attackers adds significant complexity". It is also p= erfectly fine for us to say "we care about protecting the identity in the c= lient certificate in all cases". However, the latter should not be assumed,= given the already complex nature of TLS. You could argue that this authorization problem is entirely external to TLS. The client application has to make the decision. So... go talk to the PKIX WG if you need anything from PKIX (e.g., cert extensions for carrying CA-issued policy information for the app to interpret). I'm fine with that. But the fact that this authorization has to happen (even if it's just "reveal my ID to any server with a valid cert") needs to be documented in the security considerations of TLS. I don't see anything about this in an admittedly cursory scan of RFC5246. Nico -- From nico@cryptonector.com Fri Mar 16 09:16:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D521F86E3 for ; Fri, 16 Mar 2012 09:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLVW2gYGGjmv for ; Fri, 16 Mar 2012 09:16:11 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 03B0A21F86B7 for ; Fri, 16 Mar 2012 09:16:10 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id AA5B72C806B for ; Fri, 16 Mar 2012 09:16:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=WQITzMfzz4E0NkRs5go9V NJb0FfloM3tfGZQvecvFnOKRvcIIU3NqHvmfUzua9a3z7/WgxfPDvMgBb2MV0WJz /uX9SkBCH/fJpQubtKHFGc+VkG3LuTgsGiu4KMoJK4gO9VwYyDCy4h3aY2CQaF0X yK/oktymbFB0PlfkSJstfs= 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=CBMJkWoF+t9T30l3g2Fa Y7any3E=; b=kAcw9bddpRgYsYKz1IidbHZRZrbPN/tN2cvcRRpVEwYUhmaESBL/ mY1SPb1b/C6uL5qp7gVIVA+vxwGlHqAfgYw1KCW+LKRqo2vuEKHPKtRzxaRkWt6k 0AgC/YwOQ2RU2cZU9EFiIrnmh8e1pFvRZqQp8hMlXjUZvuY/NRms+gM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 90F162C8057 for ; Fri, 16 Mar 2012 09:16:10 -0700 (PDT) Received: by dakl33 with SMTP id l33so7267628dak.31 for ; Fri, 16 Mar 2012 09:16:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.102 with SMTP id ot6mr16324270pbb.76.1331914570274; Fri, 16 Mar 2012 09:16:10 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 09:16:10 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> Date: Fri, 16 Mar 2012 11:16:10 -0500 Message-ID: From: Nico Williams To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:16:11 -0000 On Fri, Mar 16, 2012 at 10:22 AM, Mohamad Badra wrote: > Still not clear to me how in your opinion does TLS protect clients from > active attackers with valid certificate? Think of redirection/misdirection, typo squatting, ... Nico -- From fweimer@bfk.de Fri Mar 16 09:23:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5BC21F8738 for ; Fri, 16 Mar 2012 09:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfdqu4bYnS28 for ; Fri, 16 Mar 2012 09:23:07 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 88F6021F8757 for ; Fri, 16 Mar 2012 09:23:05 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1S8Zvh-000367-Kz; Fri, 16 Mar 2012 16:23:01 +0000 Received: by bfk.de with local id 1S8Zvh-00039u-Gt; Fri, 16 Mar 2012 16:23:01 +0000 From: Florian Weimer To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <999913AB42CC9341B05A99BBF358718D01382E3F@FIESEXC035.nsn-intra.net> Date: Fri, 16 Mar 2012 16:23:01 +0000 In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382E3F@FIESEXC035.nsn-intra.net> (Hannes Tschofenig's message of "Fri, 16 Mar 2012 10:59:56 +0200") Message-ID: <82d38c8qhm.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:23:10 -0000 * Hannes Tschofenig: > Just a thought that came to my mind: How often is client authentication > via certificates used in TLS in the real world?=20 Various folks have written middleware on top of TLS and rely on client certificates for authentication. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From dkg@fifthhorseman.net Fri Mar 16 09:43:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9390A21F84D2 for ; Fri, 16 Mar 2012 09:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbX-Xu4Z0XkN for ; Fri, 16 Mar 2012 09:43:42 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9B10021E8012 for ; Fri, 16 Mar 2012 09:43:41 -0700 (PDT) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id D67BAF970; Fri, 16 Mar 2012 12:43:34 -0400 (EDT) Message-ID: <4F636DB8.1020207@fifthhorseman.net> Date: Fri, 16 Mar 2012 12:43:36 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1 MIME-Version: 1.0 To: Mohamad Badra References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:43:42 -0000 On 03/16/2012 11:22 AM, Mohamad Badra wrote: > Still not clear to me how in your opinion does TLS protect clients from > active attackers with valid certificate? As a point of clarification: are you talking about an active attacker with a copy of the server's valid certificate *and* a copy of the server's secret key? Or are you just asking about an active attacker with a copy of the valid certificate but *without* the corresponding secret key? In the former case, i'm not sure what TLS as a protocol can possibly do to protect the client from anything (including disclosure of identity). In the latter case, we need to consider an active attacker willing to cause a handshake failure in order to learn the identity of the client. --dkg From mbadra@gmail.com Fri Mar 16 11:58:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD121F85EE for ; Fri, 16 Mar 2012 11:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBUWLmxpIOar for ; Fri, 16 Mar 2012 11:58:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D49BA21F85DD for ; Fri, 16 Mar 2012 11:58:36 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5582909vcb.31 for ; Fri, 16 Mar 2012 11:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9fK55VAog/Ml3GKCX8Fb8zwtc0cckJXiDSLl/NI0WhU=; b=PDfOOFex78mhoEE1zFLso1j//VNmfXm5K1S2HAxQiGliIo8UUuhH5XQ85/zUCew8oD xh47fgdf6+Z9auMkF9zWcaaoblGYZH0LnA25qqLll8VeNQmvJVEVxBJfIUvhCKJU+4c5 n3ehfPEgbxRz5iCrZMnujEtSdygrfogTD3eosFeobfH3gJNKrl+iRO+gQXHYotcxM2t/ IaBbE50ZMxC2/KnVTiAW7NxHkhWiGtdu+G8Q86TsA5wKLG24Ue8Ki7Oj12NzaprecE7I aDG5Y7BOfUH1gsKrWtBGrezTWZIbToC4X6aVWiSnGIWKDfuRSLNZuLNbNHzY9Ft/14Z8 GERw== MIME-Version: 1.0 Received: by 10.52.180.7 with SMTP id dk7mr1944002vdc.25.1331924316378; Fri, 16 Mar 2012 11:58:36 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Fri, 16 Mar 2012 11:58:36 -0700 (PDT) In-Reply-To: <4F636DB8.1020207@fifthhorseman.net> References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Fri, 16 Mar 2012 19:58:36 +0100 Message-ID: From: Mohamad Badra To: Nico Williams , Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=bcaec5196509bed6db04bb60cb88 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:58:37 -0000 --bcaec5196509bed6db04bb60cb88 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 16, 2012 at 5:16 PM, Nico Williams wrote: > On Fri, Mar 16, 2012 at 10:22 AM, Mohamad Badra wrote: > > Still not clear to me how in your opinion does TLS protect clients from > > active attackers with valid certificate? > > Think of redirection/misdirection, typo squatting, ... I cannot see anything in the Security Considerations of RFC5246, is there any RFC that discussed these issues? Daniel Kahn Gillmor wrote: > > As a point of clarification: are you talking about an active attacker with > a copy of the server's valid certificate *and* a copy of the server's > secret key? > > Yes > Or are you just asking about an active attacker with a copy of the valid > certificate but *without* the corresponding secret key? > > In the former case, i'm not sure what TLS as a protocol can possibly do to > protect the client from anything (including disclosure of identity). > Indeed In the latter case, we need to consider an active attacker willing to cause > a handshake failure in order to learn the identity of the client. The cattacker will never learn the client identity, even if the handshake fails Best regards Badra --bcaec5196509bed6db04bb60cb88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 16, 2012 at 5:16 PM, Nico Williams=A0<nico@cryptonector.com= >=A0wrote:
On Fri, Mar 16, 2012 at 10:22 AM, Mohamad Badra <mbadra@gmail.com> wrote:
> Stil= l not clear to me how in your opinion does TLS protect clients from
>= active attackers with valid certificate?

Think of redirection/misdirection, typo squatting, ...


I cannot see anything in the Security = Considerations of RFC5246, is there any RFC that discussed these issues?
Daniel Kahn Gillmor <dkg@fifthhorseman.net>= wrote:

As a point of clarification: are you talking about an active attacker with = a copy of the server's valid certificate *and* a copy of the server'= ;s secret key?


Yes
=A0
Or are you just asking about an active attacker with a copy of the valid ce= rtificate but *without* the corresponding secret key?

In the former case, i'm not sure what TLS as a protocol can possibly do= to protect the client from anything (including disclosure of identity).
=A0
Indeed=A0

In the latter case, we need to consider an active attacker willing to cause= a handshake failure in order to learn the identity of the client.


The cattacker will never learn the c= lient identity, even if the handshake fails

Best regards
Badra
--bcaec5196509bed6db04bb60cb88-- From nico@cryptonector.com Fri Mar 16 13:40:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA121E8067 for ; Fri, 16 Mar 2012 13:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O0m2chU4wd9 for ; Fri, 16 Mar 2012 13:40:20 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3477F21E801A for ; Fri, 16 Mar 2012 13:40:12 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id C8A7326C06F for ; Fri, 16 Mar 2012 13:40:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Vt2ZmFHPenA8ZuvvyviVWrfsNDud9cAX6wGJD+N9jzwE FVDvfGLnT4keji/tVsWBWox7igzO+DAYdhO1TKgnF6qUtRgLljJQLbw5QXgCgkxK Ix1s+Xl+GB2b8L+VcXyf4U32cm9uQ9bmzvCYOaLj7oMAHHoVen4iNKDqjubBpEI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=xlEivnf27Asmn6rSgvska/yZb9g=; b=EAI8+/T/1l7 pDsiWI106+N6uG0slzE5jAzw4P/9Kr8wqSqLrQpTwmg2LHg6V8YAxJ6zQwGeNInt CC8PeFk+qlFbe2vfkjnBL/ivggtf89gyNFsmMgIwdDz8nL3B5B1M2DLAIk6w6PRH vyEA/mJ8qbSqcwTE5+tQEw26B2emgBSQ= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id AFEC726C069 for ; Fri, 16 Mar 2012 13:40:11 -0700 (PDT) Received: by dakl33 with SMTP id l33so7563380dak.31 for ; Fri, 16 Mar 2012 13:40:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.241.226 with SMTP id wl2mr12930401pbc.139.1331930411145; Fri, 16 Mar 2012 13:40:11 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 13:40:11 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Fri, 16 Mar 2012 15:40:11 -0500 Message-ID: From: Nico Williams To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 20:40:21 -0000 On Fri, Mar 16, 2012 at 1:58 PM, Mohamad Badra wrote: > On Fri, Mar 16, 2012 at 5:16 PM, Nico > Williams=C2=A0=C2=A0wrote: >> >> On Fri, Mar 16, 2012 at 10:22 AM, Mohamad Badra wrote= : >> > Still not clear to me how in your opinion does TLS protect clients fro= m >> > active attackers with valid certificate? >> >> Think of redirection/misdirection, typo squatting, ... > > I cannot see anything in the Security Considerations of RFC5246, is there > any RFC that discussed these issues? RFC5246 doesn't discuss anything regarding how the client should decide whether to use a cert (or which) with any given server. It's not surprising that it wouldn't discuss any issues regarding redirection either. So if a client is willing to show its cert to any server with a valid cert... then an active attacker need only cause a client to talk to a server that the attacker controls that has a valid cert. On the web this is child's play. You could typo squat on some domain and setup http to redirect to https and then have the server request client certificates. Or, simpler, if you're on the path then you can just... respond to any http request with a redirect to your attack host... if users get a dialog about the redirection you can count on enough clicking through anyways. The point is: if you're going to have a mechanism for protecting the confidentiality of the user cert then you kinda have to do something to prevent the above. In an IMAP client, say, (or LDAP, or SUBMIT) this attack is not realistic, but in a browser it seems quite realistic to me. Nico -- From mbadra@gmail.com Fri Mar 16 14:17:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E47321F8647 for ; Fri, 16 Mar 2012 14:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY5vIzF4OGwK for ; Fri, 16 Mar 2012 14:17:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9C83721F8644 for ; Fri, 16 Mar 2012 14:17:38 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5730120vcb.31 for ; Fri, 16 Mar 2012 14:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3FZCLy0HK7MboFG7Vkx0wq3bWbqG9Vxsf8MRISUbbKw=; b=yfWkDQWc3fO5nks1P2CrBio9FBJjhoeIQObjww1zlrSyU7YLlCoNulCiER/DyjU20e 2t7D+aWt1VCjHa70/55lZiMeYa4GcCeEusT4tJWNO/Q+EwUunXaZX1AuCi1OxZQZ3Txq rVMsIztfNnBsJSMssFYOGzrGei3f6CYEnI0uaNLV1Np6pF9py7RWFNjMQdBXIalBjtWL 0ffjdJYc7goP/RXvgzU8tLWLY2MUzuNVIOo961W3koD3fM6IgoIWK3d3k0LvVN2zuR24 /2RemEKaAwt65pxtPOEPZLS2bU7gca3UBHp1MVezG6DJ9cXtHdVE2CjyihNIbHOLYVn+ /aUA== MIME-Version: 1.0 Received: by 10.52.93.74 with SMTP id cs10mr2056186vdb.42.1331932658177; Fri, 16 Mar 2012 14:17:38 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Fri, 16 Mar 2012 14:17:38 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Fri, 16 Mar 2012 22:17:38 +0100 Message-ID: From: Mohamad Badra To: Nico Williams Content-Type: multipart/alternative; boundary=bcaec5016739f494e304bb62bc12 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:17:39 -0000 --bcaec5016739f494e304bb62bc12 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 16, 2012 at 9:40 PM, Nico Williams wrote: > > I cannot see anything in the Security Considerations of RFC5246, is there > > any RFC that discussed these issues? > > RFC5246 doesn't discuss anything regarding how the client should > decide whether to use a cert (or which) with any given server. It's > not surprising that it wouldn't discuss any issues regarding > redirection either. > > So if a client is willing to show its cert to any server with a valid > cert... then an active attacker need only cause a client to talk to a > server that the attacker controls that has a valid cert. On the web > this is child's play. You could typo squat on some domain and setup > http to redirect to https and then have the server request client > certificates. Or, simpler, if you're on the path then you can just... > respond to any http request with a redirect to your attack host... if > users get a dialog about the redirection you can count on enough > clicking through anyways. > > The point is: if you're going to have a mechanism for protecting the > confidentiality of the user cert then you kinda have to do something > to prevent the above. In an IMAP client, say, (or LDAP, or SUBMIT) > this attack is not realistic, but in a browser it seems quite > realistic to me. > > Will it be our only concern to care about "client identity protection" when our server is totally broken by an active attacker? Concerns related to the client identity protection becomes really ridiculous when the above thing happens. What will be the solution to protect clients (no certificates) from such an attacker or at least to discover it by these clients? Best regards, Badra --bcaec5016739f494e304bb62bc12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 16, 2012 at 9:40 PM= , Nico Williams <nico@cryptonector.com> wrote:
> I cannot see anything in the Security Considerations of RFC5246, = is there
> any RFC that discussed these issues?

RFC5246 doesn't discuss anything regarding how the client should<= br> decide whether to use a cert (or which) with any given server. =A0It's<= br> not surprising that it wouldn't discuss any issues regarding
redirection either.

So if a client is willing to show its cert to any server with a valid
cert... then an active attacker need only cause a client to talk to a
server that the attacker controls that has a valid cert. =A0On the web
this is child's play. =A0You could typo squat on some domain and setup<= br> http to redirect to https and then have the server request client
certificates. =A0Or, simpler, if you're on the path then you can just..= .
respond to any http request with a redirect to your attack host... if
users get a dialog about the redirection you can count on enough
clicking through anyways.

The point is: if you're going to have a mechanism for protecting the confidentiality of the user cert then you kinda have to do something
to prevent the above. =A0In an IMAP client, say, (or LDAP, or SUBMIT)
this attack is not realistic, but in a browser it seems quite
realistic to me.



Wil= l it be our only concern to care about "client identity protection&quo= t; when our server is totally broken by an active attacker?

Concerns related to the client identity protection becomes r= eally ridiculous when the above thing happens.

Wha= t will be the solution to protect clients (no certificates) from such an at= tacker or at least to discover it by these clients?

Best regards,
Badra
--bcaec5016739f494e304bb62bc12-- From nico@cryptonector.com Fri Mar 16 14:35:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC2021F864F for ; Fri, 16 Mar 2012 14:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bKwtXA+gjOkt for ; Fri, 16 Mar 2012 14:35:57 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id D6BEC21F864C for ; Fri, 16 Mar 2012 14:35:57 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id AB41A768059 for ; Fri, 16 Mar 2012 14:35:56 -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=sIQ3rJ+opEZ34C/EslUM9 DigTPsP5R8d11DCVrUD2V8ipf7qWtsZLoKK4tdhJklQTEI27pf/lg2bo/iwdersc ymAS2aeeKhINSYh79TmQsvClmmp9Uta091OihXhOMOwbzCwSvDgZR+4I1uZbqMOD kWU9SXMvlEHyNRyV2XkjLU= 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=LzKVDwGrV3ww6JrhSIiH zY1kDWI=; b=aoInX12cWPLI1/nEaLoT/CwlER26OJOGfHy7G3jUqdfhQI1jxt36 MZbUFcxVJX8NHpcPkg++E28ZBaTqLEB12aS4BQWIg2K+1OY4oMINzb/jHNKL+79H qxZJW6ZZNZYBkhnV+rQrQSrDljbuumdF/SU3ksa36atvqESuYAFJz4s= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 9004E768057 for ; Fri, 16 Mar 2012 14:35:56 -0700 (PDT) Received: by dakl33 with SMTP id l33so7621876dak.31 for ; Fri, 16 Mar 2012 14:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.191.161 with SMTP id gz1mr147007pbc.76.1331933755106; Fri, 16 Mar 2012 14:35:55 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 14:35:54 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Fri, 16 Mar 2012 16:35:54 -0500 Message-ID: From: Nico Williams To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:35:58 -0000 On Fri, Mar 16, 2012 at 4:17 PM, Mohamad Badra wrote: > Will it be our only concern to care about "client identity protection" when > our server is totally broken by an active attacker? The attacker has not compromised any servers in this scenario: 0) user enters http://somesite.example 1) attacker responds with a redirect to https://domain-owned-by-the-attacker To make this better the attacker's domain can be a typosquat on somesite.example 2) attacker's server requests a client cert 3) client/user picks a cert 4) client sends a cert 5) attacker learns the client's cert Nico - From nico@cryptonector.com Fri Mar 16 15:11:15 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B512C21F860F for ; Fri, 16 Mar 2012 15:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=-0.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xy4uAz9hZ+xG for ; Fri, 16 Mar 2012 15:11:13 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 92AE821F860E for ; Fri, 16 Mar 2012 15:11:13 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 4ED9D43807C for ; Fri, 16 Mar 2012 15:11:13 -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=rwwN26ZcBCs/24WJVhx4d KzkcSrtIkxKV2IhXEkLfVc4dzWfCQ0VWGbQiYkm+nwWk0GRggdQ2oEXw/fGy5Jvg pBpQtbQ4EjZoMz/kIjOB+gjau8NeaGuhgcRddi7He90iEFUeZ9Q8o6APpSFPdkS3 F1gJhxiyH5ZfaiVCKjidwo= 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=TEUk8mIG9u3YCVw4bR/+ HXvfnUI=; b=mbS6mmOB/l/eTZgrSB6bcbn1B+WHchrTOG0ihxx8/mFETFnure/t nkwqVmvT7Qr1PrfGA4R3TAdDNoE3tyS0U/ZhDcK00yB6D8NSuQYV3w1HGviYY1kz 1HlvohZ3Au0rE6gYtnvHJHxtsNMHO3ZPMwOgY5/gvjGxTbL1Bz32IPs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 37C51438079 for ; Fri, 16 Mar 2012 15:11:13 -0700 (PDT) Received: by dakl33 with SMTP id l33so7658672dak.31 for ; Fri, 16 Mar 2012 15:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.201.98 with SMTP id jz2mr18282452pbc.97.1331935872808; Fri, 16 Mar 2012 15:11:12 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Fri, 16 Mar 2012 15:11:12 -0700 (PDT) In-Reply-To: <4F63B958.8000705@gmail.com> References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> <4F63B958.8000705@gmail.com> Date: Fri, 16 Mar 2012 17:11:12 -0500 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 22:11:15 -0000 On Fri, Mar 16, 2012 at 5:06 PM, Nikos Mavrogiannopoulos wrote: > On 03/16/2012 10:35 PM, Nico Williams wrote: >> The attacker has not compromised any servers in this scenario: >> > > This is pretty extreme scenario. If the client decided to send his Extreme? It's less extreme than BEAST, say, except that there probably isn't that much value in learning client identities, so it's probably not a very likely attack. > certificate to a malicious server, how would you prevent that? Well, first, I'm not actually proposing that there be a solution. I'm pointing out that for some use cases (web browsers) there's not that much use to a client identity confidentiality protection scheme that doesn't say anything at all about how the client decides whether a[n authenticated] server is to be allowed to see the client's certificate. Second, there are possible ways to protect the client from this redirect/misdirect attack. I'm not sure which of those are likely to be workable in practice, but it's worth considering. Paul Hoffman points out that such solutions are probably outside the purview of the TLS WG but I'm not so sure. We may want to figure out a) whether we care (but I think it's silly not to care about this attack), b) where to work on it. Nico -- From n.mavrogiannopoulos@gmail.com Fri Mar 16 15:11:27 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447CD21E802D for ; Fri, 16 Mar 2012 15:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxI9Qjal08hj for ; Fri, 16 Mar 2012 15:11:26 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62521E801A for ; Fri, 16 Mar 2012 15:11:25 -0700 (PDT) Received: by eeke51 with SMTP id e51so2526841eek.31 for ; Fri, 16 Mar 2012 15:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=qdIF/eWGuaith2k2p+PkYFM1igk4ScwkmlwY+/TvWdI=; b=Uz9FaqMb/hYvRLRB9QT9jWZsHjCyUbp6n8bJCjMn2uqpsgeFSoV084Jat/Gs+i/XN8 Nt20HPLf09mJFOGnSgNvraKaucQ+5G2DW1+GipTRK50tf4HTfYDl1J/x+LlXORcQsKOQ XyUXaQrIudz4+NLVTqke6Z7nMXPO6ICc07UrnVJgLMqmIutTwg/UAQsLbYe3Ko1KQq3U vAc1sXhWIrUnv8wXuWh5JGGnnRuxCinPF4xgB0mvSQxHonVoFfy+mYF/AWDuXzF00fub FTQP71bR81BP1MDm47R+vEvk7rxZDtbZoNVKLqLnPInR9D8t1Kx2DvRDYXlbBnDknGFP HTGg== Received: by 10.213.3.72 with SMTP id 8mr269461ebm.173.1331935885318; Fri, 16 Mar 2012 15:11:25 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id u9sm22595703eem.11.2012.03.16.15.11.24 (version=SSLv3 cipher=OTHER); Fri, 16 Mar 2012 15:11:24 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F63BC1A.3030500@gnutls.org> Date: Fri, 16 Mar 2012 23:18:02 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: tls@ietf.org References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> 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] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 22:11:27 -0000 On 03/16/2012 10:35 PM, Nico Williams wrote: > On Fri, Mar 16, 2012 at 4:17 PM, Mohamad Badra > wrote: >> Will it be our only concern to care about "client identity >> protection" when our server is totally broken by an active >> attacker? > > The attacker has not compromised any servers in this scenario: > > 0) user enters http://somesite.example 1) attacker responds with a > redirect to https://domain-owned-by-the-attacker To make this better > the attacker's domain can be a typosquat on somesite.example 2) > attacker's server requests a client cert 3) client/user picks a cert > 4) client sends a cert 5) attacker learns the client's cert This is pretty extreme scenario. If the client decided to send his certificate to a malicious server, how would you prevent that? The scenarios that I think such a draft should target would be one of the following (I don't think there are other possibilities but I might be wrong): 1. identity protection for client against passive attackers 2. identity protection for client _and_ server against passive attackers 3. identity protection for client against passive and active attackers. 4. identity protection for client against passive and active attackers and against passive for the server. Currently as I understand the draft offers (1) mostly because is targeted on web security, but for several applications where server and client do not actually differ (p2p protocols), (2) might make more sense. (3) and (4) look appealing to cases where the client-server relation exists and revealing the client identity has a cost, which is not an everyday use-case but certainly some applications could benefit from it. regards, Nikos From mbadra@gmail.com Fri Mar 16 16:21:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DD521E801F for ; Fri, 16 Mar 2012 16:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdcvOq3gyOVh for ; Fri, 16 Mar 2012 16:21:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFB6F21E801A for ; Fri, 16 Mar 2012 16:20:46 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5822316vcb.31 for ; Fri, 16 Mar 2012 16:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FqFI1d8LhIGtekaQFBDnWFCgUwWia1UPb0ixPxUA0BI=; b=AuU4WIjISf2MhV75bAfhONAcJmKM+vWrR31AWrk034vJRjVch2mJuoHZYKdWmRc9HW xEVyHIh/mlW07Zn2xVwKCXhD9ua5R2iDIhd/e9V6NLMpQXf3oF4zcY7H2A+9IU0j47uZ pIr0j2EtQd1XmS2pKK+JO4h9n+693rZIlPCuVl2h+D58Sz9z87Z82bBvxaeSx4RCzRMk FmWChOBW/IVzG3lmHEtrBXE+HLyCo3zd/s6m0yPQR/KGT+wr6dDVjlCfwKyyfVQdIykr 78XVPwmse2NsoGkMPGID2sDm/FFNENEuNknYGaT761j1UokHSbrbd5NjX8xv3EdxcoN1 qFDA== MIME-Version: 1.0 Received: by 10.220.108.10 with SMTP id d10mr1065340vcp.34.1331940046167; Fri, 16 Mar 2012 16:20:46 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Fri, 16 Mar 2012 16:20:46 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Sat, 17 Mar 2012 00:20:46 +0100 Message-ID: From: Mohamad Badra To: Nico Williams Content-Type: multipart/alternative; boundary=f46d043d645750603a04bb6475a8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 23:21:13 -0000 --f46d043d645750603a04bb6475a8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 16, 2012 at 10:35 PM, Nico Williams wrote: > On Fri, Mar 16, 2012 at 4:17 PM, Mohamad Badra wrote: > > Will it be our only concern to care about "client identity protection" > when > > our server is totally broken by an active attacker? > > The attacker has not compromised any servers in this scenario: > > 0) user enters http://somesite.example > 1) attacker responds with a redirect to > https://domain-owned-by-the-attacker > To make this better the attacker's domain can be a typosquat on > somesite.example > 2) attacker's server requests a client cert > 3) client/user picks a cert > 4) client sends a cert > 5) attacker learns the client's cert > > The draft in its "Security Considerations" Section discusses that and makes some recommendations that may help to avoid this attack. The application itself can help too (maintain a blocked list, etc...). Best regards, Badra --f46d043d645750603a04bb6475a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Mar 16, 2012 at 10:= 35 PM, Nico Williams <nico@cryptonector.com> wrote:
On Fri, Mar 16, 2012 at 4:17 PM, Mohamad Badra <mbadra@gmail.com> wrote:
> Will it be our only concern to care about "client identity protec= tion" when
> our server is totally broken by an active attacker?

The attacker has not compromised any servers in this scenario:

0) user enters http:/= /somesite.example
1) attacker responds with a redirect to https://domain-owned-by-the-attacker =A0 To make this better the attacker's domain can be a typosquat on somesite.example
2) attacker's server requests a client cert
3) client/user picks a cert
4) client sends a cert
5) attacker learns the client's cert


The draft in its "Security Consid= erations" Section discusses that and makes some recommendations that m= ay help to avoid this attack. The application itself can help too (maintain= a blocked list, etc...).=A0

Best regards,
Badra
--f46d043d645750603a04bb6475a8-- From n.mavrogiannopoulos@gmail.com Sat Mar 17 01:35:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B58A21F8595 for ; Sat, 17 Mar 2012 01:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS+X1BHHGXXx for ; Sat, 17 Mar 2012 01:35:43 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8721F856D for ; Sat, 17 Mar 2012 01:35:39 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2543456eaa.31 for ; Sat, 17 Mar 2012 01:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=iDj3G52dDjsV1K1xG7I0jN8Y0Orx2nZy+JVKh1OXBoE=; b=WMWFGEG0pis32b/W9izb/bplZRLjkkkASSuzM2XBj86C28leteq8hykaNfziFvLUEi AZb5STG+g/1oEZ1jqtAKwA5RiDyLS5hwLJdHhjPXpkrumxYdogdQPmWMzEQ6jFG/jAc+ rM1zhbb46xTFb+ENczBWYsGso3GTyKQFBvUiiAOth5xkpfmXfNF5CnLd0kF+BoK4Xsie jTQjp4nwdM8IPu5M1GYoH+SM/5rjRTroUcWFyl50XDblYz04eMRr59yi7s5NCToBbkCi p6HlN26SGvVlnO8Qu+l9c/N+BSqRj8kEjkSAbjei4x3aZFAZssCqOkDPaYXH4lZctdkk K68Q== Received: by 10.14.52.133 with SMTP id e5mr657782eec.127.1331973338940; Sat, 17 Mar 2012 01:35:38 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id r44sm26783127eef.2.2012.03.17.01.35.37 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 01:35:38 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F644CD4.7070408@gnutls.org> Date: Sat, 17 Mar 2012 09:35:32 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Nico Williams References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> <4F63B958.8000705@gmail.com> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 08:35:44 -0000 On 03/16/2012 11:11 PM, Nico Williams wrote: >> This is pretty extreme scenario. If the client decided to send his > > Extreme? It's less extreme than BEAST, say, except that there > probably isn't that much value in learning client identities, so > it's probably not a very likely attack. I mean extreme to be handled by the low-level protocol. It looks like an attack to be mitigated by the user interface application (e.g. by explicitly warning the user that is sending this certificate for the first time to this server or something similar). >> certificate to a malicious server, how would you prevent that? > Well, first, I'm not actually proposing that there be a solution. > I'm pointing out that for some use cases (web browsers) there's not > that much use to a client identity confidentiality protection scheme > that doesn't say anything at all about how the client decides whether > a[n authenticated] server is to be allowed to see the client's > certificate. Authentication is also (and mostly) depending on the upper protocols. E.g. in SMTP client authentication might mean something very different than HTTPS client authentication, thus it might make sense to delegate some of the security considerations to the upper protocols. If there are common pitfalls across protocols it might make sense to have some general guidelines, but I don't think much can be done on the TLS layer for the attack that you specify. regards, Nikos From n.mavrogiannopoulos@gmail.com Sat Mar 17 06:04:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1AC21F8552 for ; Sat, 17 Mar 2012 06:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAKTkf6p-+F1 for ; Sat, 17 Mar 2012 06:04:13 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6AEA21F8546 for ; Sat, 17 Mar 2012 06:04:12 -0700 (PDT) Received: by eeke51 with SMTP id e51so2606831eek.31 for ; Sat, 17 Mar 2012 06:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=dqyJVX32UBwPoHvuQuKrFHkBoDxkn9vFDjfxypBmY+0=; b=e2/Xk1biTfb11OPSYzDcqqOhlhMIxt1Os4b/CkZXrM/0g9i0f+/o2u6uq9MfZY5Wzn PvSWlh1s64WB2sOgEghwlKH1GOTDmNJIigTaUrS7rMVFYALUPpXVmRMgNdn+TfFmVx1Y 2NxGns7KldxLYKDDYK+jEumS4Nz+kexV5ap53M6xDP3w1Q+sWXyskVLvV+yhzAdS7oFb jMkwXvV8HY68AroTfH36j5zn4oGJPTY/xN/GLzU/5rW473uhaXTaaQw0qYIsGwBBZZOX D7JeEm7p3fwS+wF4Xl0mj6r/2SDH7dqAqDB5b/KX7Tr2agx/2FNHUfUVUM1SAWHoQFl7 LdUg== Received: by 10.213.31.131 with SMTP id y3mr375669ebc.134.1331989451996; Sat, 17 Mar 2012 06:04:11 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id z47sm28627965een.5.2012.03.17.06.04.11 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 06:04:11 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F648BCB.2090401@gnutls.org> Date: Sat, 17 Mar 2012 14:04:11 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 13:04:13 -0000 Hello, I noticed today that gnutls isn't interoperable with openssl with the elliptic curve ciphersuites [0]. In particular the ECC document says "This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines...". My understanding of it is that SSL 3.0 shouldn't be used with ECC ciphersuites, but it seems openssl as a server negotiates them under SSL 3.0. What is the behavior of other implementations? Should it be that similar version restrictions in this and other drafts be ignored? By the way the ECC draft doesn't mention TLS 1.0 or later, and if taken literally it means that these ciphersuites are not to be used in TLS 1.2. regards, Nikos [0]. http://tools.ietf.org/html/rfc4492 From paul.hoffman@vpnc.org Sat Mar 17 08:06:04 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4333721F86B4 for ; Sat, 17 Mar 2012 08:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq3QSocoh8+R for ; Sat, 17 Mar 2012 08:06:03 -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 C8A9821F86B2 for ; Sat, 17 Mar 2012 08:06:03 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2HF5R0D081303 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 17 Mar 2012 08:05:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4F648BCB.2090401@gnutls.org> Date: Sat, 17 Mar 2012 08:05:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> References: <4F648BCB.2090401@gnutls.org> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1257) Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 15:06:04 -0000 On Mar 17, 2012, at 6:04 AM, Nikos Mavrogiannopoulos wrote: > Hello, > I noticed today that gnutls isn't interoperable with openssl with the > elliptic curve ciphersuites [0]. In particular the ECC document says > "This document describes additions to TLS to support ECC, applicable > both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In = particular, > it defines...". >=20 > My understanding of it is that SSL 3.0 shouldn't be used with ECC > ciphersuites, but it seems openssl as a server negotiates them under = SSL > 3.0. What is the behavior of other implementations? Should it be > that similar version restrictions in this and other drafts be > ignored? SSL 3.0's use of the cipersuites is undefined in RFC 4492. > By the way the ECC draft doesn't mention TLS 1.0 or later, and if = taken > literally it means that these ciphersuites are not to be used in TLS = 1.2. Not true. TLS 1.2 (RFC 5246) explicitly updates RFC 4492, both in the = boilerplate at the top of the RFC and in Appendix A.7. --Paul Hoffman From n.mavrogiannopoulos@gmail.com Sat Mar 17 13:33:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC46F21F854A for ; Sat, 17 Mar 2012 13:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtBfG50riOL9 for ; Sat, 17 Mar 2012 13:33:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E608121F84FD for ; Sat, 17 Mar 2012 13:33:50 -0700 (PDT) Received: by eeke51 with SMTP id e51so2651338eek.31 for ; Sat, 17 Mar 2012 13:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=BPIItuyfdUomwfSJXT6SpfIIN2bc8V8UeKFvECafTC8=; b=QzEMCkha9LoYKcHPdeY+NyOVWCIhBUVGrxibnFBFMB365nVTEZdkNGatNEKHyREXdG bNMFtg5amt8dXPV2ahaK1dphvvqRnamRofNj39/TqY8C/JINODiqEsTIv6x5UMMvuMDg rus54XgcbyLCIhrYwT44e+n9xsXDVqYqWoMqLdfP/rLtKI8gX6hnxM6t3B8XHEAB4lwa XXcTLErgjClFyPaWggyQJxBYMAjTz/WoLkpj9ujkjsHVp07qzbORT1qD5l/Wea/DmHhq zHneWMdRDOOPpt+PXeW29hJAhBamhrh8OMtzN41efFX54aqQobKuzZRRwXtVfOhu3rMF UwSA== Received: by 10.14.202.200 with SMTP id d48mr884441eeo.44.1332016429969; Sat, 17 Mar 2012 13:33:49 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id r44sm31864562eef.2.2012.03.17.13.33.48 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 13:33:49 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F64F527.6000600@gnutls.org> Date: Sat, 17 Mar 2012 21:33:43 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: "tls@ietf.org" References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> In-Reply-To: <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 20:33:53 -0000 On 03/17/2012 04:05 PM, Paul Hoffman wrote: >> My understanding of it is that SSL 3.0 shouldn't be used with ECC >> ciphersuites, but it seems openssl as a server negotiates them under SSL >> 3.0. What is the behavior of other implementations? Should it be >> that similar version restrictions in this and other drafts be >> ignored? > SSL 3.0's use of the cipersuites is undefined in RFC 4492. This is my reading of the document as well, but it seems that this interpretation is not universal and for good reasons. For example rfc4132 adds new ciphersuites to TLS 1.0. Should they be used under SSL 3.0 or not? I say not, but it can be claimed that there is no good reason not to use these ciphersuites under SSL 3.0 [0]. What do we do then? Live with interoperability issues? Have other implementations run into it and handled it somehow? regards, Nikos [0]. http://marc.info/?l=openssl-dev&m=133200238929226&w=2 From marsh@extendedsubset.com Sat Mar 17 14:09:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF6621F853B for ; Sat, 17 Mar 2012 14:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy0dG5jnJQvr for ; Sat, 17 Mar 2012 14:09:09 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7397421F852D for ; Sat, 17 Mar 2012 14:09:07 -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 1S90s6-0006V5-Uy; Sat, 17 Mar 2012 21:09:07 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 973D16085; Sat, 17 Mar 2012 21:09:05 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+TUYV8yEqEfodx6aw/kkip86SFcsxexQE= Message-ID: <4F64FD71.1070103@extendedsubset.com> Date: Sat, 17 Mar 2012 16:09:05 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> In-Reply-To: <4F64F527.6000600@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 21:09:10 -0000 On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote: > > For example rfc4132 adds new ciphersuites to TLS 1.0. Should they be > used under SSL 3.0 or not? I say not, but it can be claimed that there > is no good reason not to use these ciphersuites under SSL 3.0 [0]. SSL 3.0 isn't a standard maintained by the IETF TLS WG (or by anybody for that matter). So nobody can say what SHOULD be done with it. (OK maybe that's not strictly true, RFC 6176 says TLS clients and servers MUST NOT use SSL 2.0 but I don't think there are any RFCs that are directly prescriptive about how SSL 2.0 or 3.0 should behave if its use is negotiated.) > What do we do then? Live with interoperability issues? > Have other implementations run into it and handled it somehow? For the record, I suppose the official answer would be: use TLS 1.0 or higher. I realize you may be testing the corner case explicitly, but really, are there any implementations that speak RFC 4132 ciphersuites but *don't* speak TLS? There's probably a server or two in the wild configured that way but it doesn't seem like a good idea to me. The Qualys survey 2 years ago http://blog.ivanristic.com/Qualys_SSL_Labs-State_of_SSL_2010-v1.6.pdf found only 0.05% of servers that had SSL 3.0 as the highest supported protocol (none were found to only do SSL 2.0). Perhaps it would be a good idea for server implementations to strongly de-prioritize or ignore entirely the RFC 4132 and newer ciphersuites for handshakes that negotiate the use of SSL 3.0. - Marsh From ynir@checkpoint.com Sat Mar 17 14:41:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE6B21F860D for ; Sat, 17 Mar 2012 14:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.485 X-Spam-Level: X-Spam-Status: No, score=-10.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXFUZrD2nFSP for ; Sat, 17 Mar 2012 14:41:54 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BA61B21F860B for ; Sat, 17 Mar 2012 14:41:53 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2HLfasY013998; Sat, 17 Mar 2012 23:41:36 +0200 X-CheckPoint: {4F6504C1-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 17 Mar 2012 23:41:35 +0200 From: Yoav Nir To: Marsh Ray Date: Sat, 17 Mar 2012 23:41:46 +0200 Thread-Topic: [TLS] incompatibilities with ECC rfc Thread-Index: Ac0EhrmllEcLS+/aRgaL0j4U1wMwkA== Message-ID: <07B8FD82-190D-4824-8659-CEAE087ACEBF@checkpoint.com> References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> In-Reply-To: <4F64FD71.1070103@extendedsubset.com> 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" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 21:41:54 -0000 On Mar 17, 2012, at 11:09 PM, Marsh Ray wrote: > On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote: >=20 >> What do we do then? Live with interoperability issues? >> Have other implementations run into it and handled it somehow? >=20 > For the record, I suppose the official answer would be: use TLS 1.0 or=20 > higher. >=20 > I realize you may be testing the corner case explicitly, but really, are= =20 > there any implementations that speak RFC 4132 ciphersuites but *don't*=20 > speak TLS? Probably not. But there's also few if any web browsers that don't speak SSL= v3. Most browsers will begin the SSL handshake at version 3.0 and indicate = support in the ClientHello Version field for TLS 1.0 or 1.2 (everyone who's= implemented 1.1 has implemented 1.2 by now). The same ClientHello that neg= otiates versions also negotiates ciphersuites, so the client offers SSLv3 a= nd an ECC ciphersuite at the same time. It has to be ready for the case whe= re the server replies at SSLv3, and chooses the ECC ciphersuite. We could decide that this is wrong, goes against the RFC, and the client sh= ould abort with some alert. I just don't see any reason why a client should= do so. As for the server, it should choose the highest TLS version supported by it= and the client. It's fairly unreasonable that this will be SSLv3 if an ECC= ciphersuite is being offered and understood. The client should be ready fo= r this. . = From ekr@rtfm.com Sat Mar 17 14:52:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84F21F8677 for ; Sat, 17 Mar 2012 14:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.042 X-Spam-Level: X-Spam-Status: No, score=-103.042 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jb1g13nWIypI for ; Sat, 17 Mar 2012 14:51:59 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4142E21F8476 for ; Sat, 17 Mar 2012 14:51:59 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so6466438vcb.31 for ; Sat, 17 Mar 2012 14:51:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=GHS6GwvdU4GF1GUCGG+RfEwrBle6t6EsbD6ZAXSJqX0=; b=QTW8SO4X+8OwsRqY+cbd7u/8SlDqQ5IsnhPzUjK/aRfT6nCsT0KS5jrG49TQ8bCwbi GOJPIPOvryMiqzLRDK3CzFCSX74EZ+hW5Fb4dZA70b67tmo7se4XyCo52UODZWN3Wy/+ zSEyxhhsK5JFCL1xwjFD7qR3Z8t5pl8OIbRYCsPBF6uJ+Evn8rQ+JcaG4Iy6EtSIhpRz PBnkPduqefJcaQzl+Zr8csF/dFTIK4jN85+RwbM2emeNEKBBLq9AFUn3gQ8HNfOAoW65 hjAt7uPrnenU/Uv+kWMVCKrgustFkhS49hU+NuXZCPDamH92Db4UEgSMsQFu8GxMi6SG Xv4A== Received: by 10.52.67.11 with SMTP id j11mr1672705vdt.40.1332021118709; Sat, 17 Mar 2012 14:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Sat, 17 Mar 2012 14:51:18 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <07B8FD82-190D-4824-8659-CEAE087ACEBF@checkpoint.com> References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> <07B8FD82-190D-4824-8659-CEAE087ACEBF@checkpoint.com> From: Eric Rescorla Date: Sat, 17 Mar 2012 14:51:18 -0700 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkOISAZjt88IOutQrFjDYqt6iS5S3EBEBdRgCqF5z8xcC51Pcq1ulOWOWaIq9cO2YX96vpy Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 17 Mar 2012 21:52:00 -0000 On Sat, Mar 17, 2012 at 2:41 PM, Yoav Nir wrote: > > On Mar 17, 2012, at 11:09 PM, Marsh Ray wrote: > >> On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote: >> >>> What do we do then? Live with interoperability issues? >>> Have other implementations run into it and handled it somehow? >> >> For the record, I suppose the official answer would be: use TLS 1.0 or >> higher. >> >> I realize you may be testing the corner case explicitly, but really, are >> there any implementations that speak RFC 4132 ciphersuites but *don't* >> speak TLS? > > Probably not. But there's also few if any web browsers that don't speak S= SLv3. Most browsers will begin the SSL handshake at version 3.0 and indicat= e support in the ClientHello Version field for TLS 1.0 or 1.2 (everyone who= 's implemented 1.1 has implemented 1.2 by now). The same ClientHello that n= egotiates versions also negotiates ciphersuites, so the client offers SSLv3= and an ECC ciphersuite at the same time. It has to be ready for the case w= here the server replies at SSLv3, and chooses the ECC ciphersuite. Could you explain what you mean by "begin the SSL handshake at version 3.0"? You indicate the highest version you support (and nothing else) in the ClientHello. So you're not offering SSLv3--the server has no idea if you would accept it, and indeed if the server chooses it you are free to reject it. -Ekr From nico@cryptonector.com Sat Mar 17 18:14:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F821F8672 for ; Sat, 17 Mar 2012 18:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXQc+O8sQZIm for ; Sat, 17 Mar 2012 18:14:46 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id D75A921F8671 for ; Sat, 17 Mar 2012 18:14:43 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 7A8FE2C2060 for ; Sat, 17 Mar 2012 18:14:43 -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=xvFn+lu9erVtlDUzeMChV XYEd4lRFIeRgsjlPMGUU8aHwX/XQfKHggIBI6SOnvF7ZOXTkOUYbKnCfAYlgKe5R qFuZ6fdCvTpHTKAMhl6KGYdvUfUvbIEP4MQuiJwqU7M74JIsRqnFr0AAWoT/gLOf etrpZvEVEjvtGqmgoihHmk= 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=EbNiSVKqdh4AZ8zHol+0 /U8X9K4=; b=HNRojDz/GNcprg2UhBg6QU9uYv40OgMsD4xT7AVTEWvdZNBGwuKp MbIKSpXgmJWhdIySTC7VRtnjYiivtR3sWij3bMZhf0PbiDng4gNzll7f/f93Owm8 tLO9VrqWZd5JOnGpHjQVzysD9zEVStFshlI0lwOzsNGJ6DtFmdke2xg= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 60EA12C2059 for ; Sat, 17 Mar 2012 18:14:43 -0700 (PDT) Received: by dakl33 with SMTP id l33so9063911dak.31 for ; Sat, 17 Mar 2012 18:14:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.230.99 with SMTP id sx3mr27464694pbc.55.1332033282978; Sat, 17 Mar 2012 18:14:42 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Sat, 17 Mar 2012 18:14:42 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Sat, 17 Mar 2012 20:14:42 -0500 Message-ID: From: Nico Williams To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 01:14:46 -0000 So, after thinking about it more I think any authorization to see a cert problem is well outside the scope of this WG. Apps already have this problem regarding username&password-over-TLS authentication anyways. This does rate a security considerations mention though. Nico -- From mbadra@gmail.com Sat Mar 17 23:26:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96F11E8079 for ; Sat, 17 Mar 2012 23:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP4t7KPF0BbK for ; Sat, 17 Mar 2012 23:26:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AAA2811E8072 for ; Sat, 17 Mar 2012 23:26:10 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so6629257vcb.31 for ; Sat, 17 Mar 2012 23:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cfuDO+QSWci0RYWspa51iVzgTQTl1VwPBBv6pyZ1L2E=; b=1H6OrzWEQPLGRPiOAN8Y6eeIwbEw7cXz9lF5z6Q6pHst4/zPZjTHa7Y53kjGx20bgM XzuleemHq/C1OOtsGSD/v61hkAWxmG4vbOgze3uxpUGTkqRPNa7PxYPUVApZouwvqGa0 /aySdQx5xaJiqQS2HD/cSSBHnBF6gYZMRvA5TyHx3vN5kE3wCTHFicAxbu3SxgFaiJeI 8HUdwT4ApydqD8gt5FZm1YY0xgJZQ1jlxyQU9KW8XjTpFnwjBfGUerP1NX5PJ41XXIjS XcIRI3i0FxSh3CWN7q81cSCphrHzALftj1xNlUnCzPzdOZwxADL0uqNvLOfmKgO4DDeQ UMYg== MIME-Version: 1.0 Received: by 10.52.30.98 with SMTP id r2mr3661122vdh.8.1332051970039; Sat, 17 Mar 2012 23:26:10 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Sat, 17 Mar 2012 23:26:09 -0700 (PDT) In-Reply-To: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> Date: Sun, 18 Mar 2012 10:26:09 +0400 Message-ID: From: Mohamad Badra To: Nico Williams Content-Type: multipart/alternative; boundary=20cf3079b89e7f1e5104bb7e8404 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 06:26:44 -0000 --20cf3079b89e7f1e5104bb7e8404 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Mar 18, 2012 at 5:14 AM, Nico Williams wrote: > ... I think any authorization to see a > cert problem is well outside the scope of this WG. TLS clients establish TLS sessions based on parameters set by the Applications (protocol version, cipher suites, etc). I don't see any technical reason to don't negotiate the certificate protection during the handshake. Looking for your technical reasons, best regards, Badra --20cf3079b89e7f1e5104bb7e8404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 18, 2012 at 5:14 AM= , Nico Williams <nico@cryptonector.com> wrote:
... I think any authorization to see a
cert problem is well outside the scope of this WG. =A0
TLS clients establish TLS sessions based on parameters set by t= he Applications (protocol version, cipher suites, etc). I don't see any= technical reason to don't negotiate the certificate=A0protection durin= g the handshake.

Looking for your technical reasons, best regards,
=
Badra
--20cf3079b89e7f1e5104bb7e8404-- From ynir@checkpoint.com Sun Mar 18 00:15:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C113D21F84DC for ; Sun, 18 Mar 2012 00:15:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhoa2qodjHSn for ; Sun, 18 Mar 2012 00:15:03 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A65D421F84DA for ; Sun, 18 Mar 2012 00:15:02 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2I7Ev49027257; Sun, 18 Mar 2012 09:14:58 +0200 X-CheckPoint: {4F658B1D-0-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 18 Mar 2012 09:14:56 +0200 From: Yoav Nir To: "'Eric Rescorla'" Date: Sun, 18 Mar 2012 09:14:56 +0200 Thread-Topic: [TLS] incompatibilities with ECC rfc Thread-Index: Ac0EiDKd154n1eU3QnyQGpxRrM8fJAATlwKw Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A75325A18@il-ex01.ad.checkpoint.com> References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> <07B8FD82-190D-4824-8659-CEAE087ACEBF@checkpoint.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" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 07:15:04 -0000 3.0 in the TLS header 3.1/3.3 in the ClientHello 3.1/3.3 are the highest version you support, but you can obviously accept S= SLv3, because of the TLS header=20 -----Original Message----- From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: 17 March 2012 23:51 To: Yoav Nir Cc: Marsh Ray; tls@ietf.org Subject: Re: [TLS] incompatibilities with ECC rfc On Sat, Mar 17, 2012 at 2:41 PM, Yoav Nir wrote: > > On Mar 17, 2012, at 11:09 PM, Marsh Ray wrote: > >> On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote: >> >>> What do we do then? Live with interoperability issues? >>> Have other implementations run into it and handled it somehow? >> >> For the record, I suppose the official answer would be: use TLS 1.0=20 >> or higher. >> >> I realize you may be testing the corner case explicitly, but really,=20 >> are there any implementations that speak RFC 4132 ciphersuites but=20 >> *don't* speak TLS? > > Probably not. But there's also few if any web browsers that don't speak S= SLv3. Most browsers will begin the SSL handshake at version 3.0 and indicat= e support in the ClientHello Version field for TLS 1.0 or 1.2 (everyone who= 's implemented 1.1 has implemented 1.2 by now). The same ClientHello that n= egotiates versions also negotiates ciphersuites, so the client offers SSLv3= and an ECC ciphersuite at the same time. It has to be ready for the case w= here the server replies at SSLv3, and chooses the ECC ciphersuite. Could you explain what you mean by "begin the SSL handshake at version 3.0"= ? You indicate the highest version you support (and nothing else) in the Cl= ientHello. So you're not offering SSLv3--the server has no idea if you would accept it, and indeed if the ser= ver chooses it you are free to reject it. -Ekr From ekr@rtfm.com Sun Mar 18 08:06:52 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0821F85CF for ; Sun, 18 Mar 2012 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.041 X-Spam-Level: X-Spam-Status: No, score=-103.041 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGgE4zgYhB8q for ; Sun, 18 Mar 2012 08:06:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35DC821F85C7 for ; Sun, 18 Mar 2012 08:06:52 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so6821845vcb.31 for ; Sun, 18 Mar 2012 08:06:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=ZL+7thO0R6gPSUZbSFlMB+O4Kyik57GsVI02CFIOVwk=; b=NmR8Tuhh7Jy6ZaukWzjtX3cvlOj9zZc9MKTzf2FsykhVQo95bYlgwx/+DfevQv3r13 GUVETSz5WLPOpRkoHFqDMD46YZwMPihim6p1b9zEZobmFp+XUOpkr/1Rnd7mlygSUcmn P4uddQud5Dzpr1D37aB4+Us+zbkKpkXuRRc1dylX9uR5sL9OE5zAchbLo4QB9MCxBVwg wbjcav3nheJGsNTMJk6Ec+gMCXoQtsYhMNQ9msv+N73HOb4iUTNY85HzDToZAsN2vkFG EjUur+B5iShxHoBhCEIpMd5BMbBDZrfuw+CmtvDY9SQknjg22JzKWWBF77UB8L/R4l5w mumA== Received: by 10.52.76.164 with SMTP id l4mr4078763vdw.6.1332083211681; Sun, 18 Mar 2012 08:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Sun, 18 Mar 2012 08:06:11 -0700 (PDT) X-Originating-IP: [74.95.2.169] In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A75325A18@il-ex01.ad.checkpoint.com> References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> <07B8FD82-190D-4824-8659-CEAE087ACEBF@checkpoint.com> <006FEB08D9C6444AB014105C9AEB133F017A75325A18@il-ex01.ad.checkpoint.com> From: Eric Rescorla Date: Sun, 18 Mar 2012 08:06:11 -0700 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkIRHjRpAWRdBg+EQ5hAUSDD8QGTlDmAdJ4TZeNOO6lxT8AkOCwRI1a6INCJZqO1a+I6nsX Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 15:06:53 -0000 Well, the record header isn't used for negotiation. So while RFC 5246; S E.2 does in fact recommend this practice, there's no requirement that a client which sends the 3.0/3.x pair actually supports the range 3.0-3.x. -Ekr On Sun, Mar 18, 2012 at 12:14 AM, Yoav Nir wrote: > 3.0 in the TLS header > 3.1/3.3 in the ClientHello > > 3.1/3.3 are the highest version you support, but you can obviously accept= SSLv3, because of the TLS header > > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: 17 March 2012 23:51 > To: Yoav Nir > Cc: Marsh Ray; tls@ietf.org > Subject: Re: [TLS] incompatibilities with ECC rfc > > On Sat, Mar 17, 2012 at 2:41 PM, Yoav Nir wrote: >> >> On Mar 17, 2012, at 11:09 PM, Marsh Ray wrote: >> >>> On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote: >>> >>>> What do we do then? Live with interoperability issues? >>>> Have other implementations run into it and handled it somehow? >>> >>> For the record, I suppose the official answer would be: use TLS 1.0 >>> or higher. >>> >>> I realize you may be testing the corner case explicitly, but really, >>> are there any implementations that speak RFC 4132 ciphersuites but >>> *don't* speak TLS? >> >> Probably not. But there's also few if any web browsers that don't speak = SSLv3. Most browsers will begin the SSL handshake at version 3.0 and indica= te support in the ClientHello Version field for TLS 1.0 or 1.2 (everyone wh= o's implemented 1.1 has implemented 1.2 by now). The same ClientHello that = negotiates versions also negotiates ciphersuites, so the client offers SSLv= 3 and an ECC ciphersuite at the same time. It has to be ready for the case = where the server replies at SSLv3, and chooses the ECC ciphersuite. > > Could you explain what you mean by "begin the SSL handshake at version 3.= 0"? You indicate the highest version you support (and nothing else) in the = ClientHello. > So you're not offering > SSLv3--the server has no idea if you would accept it, and indeed if the s= erver chooses it you are free to reject it. > > -Ekr From paul.hoffman@vpnc.org Sun Mar 18 12:42:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9EC21F85EA for ; Sun, 18 Mar 2012 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.683 X-Spam-Level: X-Spam-Status: No, score=-102.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jh+zxBEKz7Kg for ; Sun, 18 Mar 2012 12:42:02 -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 8FACF21F85B7 for ; Sun, 18 Mar 2012 12:42:02 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2IJg0jR024889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 18 Mar 2012 12:42:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Sun, 18 Mar 2012 12:42:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46047D39-2968-4C4A-89FB-B2D34B0A1AF4@checkpoint.com> <201203160049.q2G0nZ5G007211@fs4113.wdf.sap.corp> <4F636DB8.1020207@fifthhorseman.net> To: Nico Williams X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 19:42:03 -0000 On Mar 17, 2012, at 6:14 PM, Nico Williams wrote: > So, after thinking about it more I think any authorization to see a > cert problem is well outside the scope of this WG. Apps already have > this problem regarding username&password-over-TLS authentication > anyways. This does rate a security considerations mention though. Disagree that it is out of scope for the WG. I don't think there is a = strong use case, given that it is pretty trivial for a client to get a = cert whose identity is not actually related to the person using the = cert, but others do think there is the use case so it should be dealt = with. There are use cases where a server wouldn't want to finish the = handshake without knowing that the client is authorized to even talk to = the next protocol. I still hate the idea of munging cipher suites for the functionality, = though. --Paul Hoffman From mrex@sap.com Mon Mar 19 12:13:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E9921F883D for ; Mon, 19 Mar 2012 12:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.057 X-Spam-Level: X-Spam-Status: No, score=-10.057 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sDrMm0Jgbqc for ; Mon, 19 Mar 2012 12:13:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 046AA21F87DB for ; Mon, 19 Mar 2012 12:13:58 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2JJDomb020294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Mar 2012 20:13:50 +0100 (MET) From: Martin Rex Message-Id: <201203191913.q2JJDnUT019343@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Mon, 19 Mar 2012 20:13:49 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Mar 18, 12 08:06:11 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] incompatibilities with ECC rfc 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, 19 Mar 2012 19:13:59 -0000 Eric Rescorla wrote: > > Well, the record header isn't used for negotiation. So while RFC 5246; > S E.2 does in fact recommend this practice, there's no requirement that > a client which sends the 3.0/3.x pair actually supports the range 3.0-3.x. The protocol version in the TLS record header describes the version of the protocol for that particular PDU. A client that sends { 0x03, 0x00 } in the TLS record protocol for the records conveying the ClientHello is actively indicating that it has implemented SSLv3. version The version of the protocol being employed. This does _not_ indicate, however, that the client will agree to negotiating SSLv3 for the connection. Depending on client policy or configuration, the client may be offering { 0x03, 0x03 } as his highest supported client_version within ClientHello and abort if the server does not choose at least { 0x03, 0x01 } TLSv1.0 for his ServerHello response. -Martin From mrex@sap.com Mon Mar 19 12:23:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF6621E8024 for ; Mon, 19 Mar 2012 12:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.059 X-Spam-Level: X-Spam-Status: No, score=-10.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVZAOEA1czXA for ; Mon, 19 Mar 2012 12:23:37 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9723221E801F for ; Mon, 19 Mar 2012 12:23:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2JJNNEx021606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Mar 2012 20:23:23 +0100 (MET) From: Martin Rex Message-Id: <201203191923.q2JJNNE2020025@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 19 Mar 2012 20:23:22 +0100 (MET) In-Reply-To: <4F648BCB.2090401@gnutls.org> from "Nikos Mavrogiannopoulos" at Mar 17, 12 02:04: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] incompatibilities with ECC rfc 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, 19 Mar 2012 19:23:38 -0000 Nikos Mavrogiannopoulos wrote: > > I noticed today that gnutls isn't interoperable with openssl with the > elliptic curve ciphersuites [0]. In particular the ECC document says > "This document describes additions to TLS to support ECC, applicable > both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, > it defines...". > > My understanding of it is that SSL 3.0 shouldn't be used with ECC > ciphersuites, but it seems openssl as a server negotiates them under SSL > 3.0. What is the behavior of other implementations? Should it be > that similar version restrictions in this and other drafts be > ignored? Why should there be a limitation of ECC to TLS? That would have the prerequisite of partitioning the cipher suite number range to cipher suites that are TLS only and a range that can be used with SSLv3. It is quite possible that disabling ciphersuites for use with SSLv3 (instead of letting them just work) would require additional code, so adding such code hardly makes sense. There seem to be similar interop issues with AES ciphersuites (rfc3268), which work fine in Firefox with SSLv3, but Microsoft's Channel does not support them with SSLv3. -Martin From wtc@google.com Mon Mar 19 17:37:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913EB21F88DC for ; Mon, 19 Mar 2012 17:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJx3-Hcrfxzd for ; Mon, 19 Mar 2012 17:37:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ED09121F88DA for ; Mon, 19 Mar 2012 17:37:02 -0700 (PDT) Received: by iazz13 with SMTP id z13so12055191iaz.31 for ; Mon, 19 Mar 2012 17:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=E5T8giUtDqcDPAhKcHS8URiKTYRG9mfnHudEgyA7zTY=; b=YSzvoex85nl7FYraXJiByD4+DjkESPbaPsD6yoV7qXwIvtgMCSrQTjYkEZv+bqVfQO V87c0MzuhbZzQPx0mkDS+O9SVTAsAQZwla4NL1GCIqryW1NBpHSaxh/lReyHA1Rdi6jq 8MFuaLgJHGflOoqp7aVLJjj03za9dzv6Lor39WDL2huWLgnZuNN0buj+Qd/gAeqkERdN tDM81APFagxzdPFPPV+LzGclWE6i3fKpGYWygsyBIk6E2OHDMicRk17HFCPWZlVt7zxU VLTGb2DjgW1x5BLlRQ3ZIpSaSdzDUNjRvVI+VjG2Oc9fGbY48eqs3fo1ttvFqs1l2Zvi fTwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=E5T8giUtDqcDPAhKcHS8URiKTYRG9mfnHudEgyA7zTY=; b=XUHKYTtmCZHH9hrQUXUx8TiGDej6f7gXV1qy0T0VC014Ij49Zaq6nlXxOwmSU/DOQv jfmPlwdptpo034XGw3vOD3TSJUXxywSgFpqDzMQqcPhFMlUzQ11YeUzOUYmiS5O4pfux qdw+B5vMOWpdkSnYkuk+fazVcyKGce2PxwJfJHYbLnW8hT7u6GH7E/WGoJAgO3u2sFFQ G/6obuu39yxxEChlM5/C176tPctZM8Ypsat7jyudSqMSZa6LqwGSsau9d4EA4kx1eCtZ N/6aJb1Vb/SCo8+aa/0aUDtCaNHufXmJ8GaO3hGKInFjMrXUxWBXSpy56JL2+txNDrEl 3N9g== Received: by 10.50.89.197 with SMTP id bq5mr7612549igb.13.1332203822642; Mon, 19 Mar 2012 17:37:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.89.197 with SMTP id bq5mr7612544igb.13.1332203822564; Mon, 19 Mar 2012 17:37:02 -0700 (PDT) Received: by 10.231.7.217 with HTTP; Mon, 19 Mar 2012 17:37:02 -0700 (PDT) In-Reply-To: <4F648BCB.2090401@gnutls.org> References: <4F648BCB.2090401@gnutls.org> Date: Mon, 19 Mar 2012 17:37:02 -0700 Message-ID: From: Wan-Teh Chang To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmikgfULIiuitiwbBleytc0ZUAoIp6/7vmpakd3xkk3JSnpX1kD1mAQysue0H87414fAqfaW2MBrJsWTtaMXp32D+rflVXpBCdSFe/LnE0p0SxwLut5DAVmf61K9JRTu6Ag2VC7 Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:37:03 -0000 On Sat, Mar 17, 2012 at 6:04 AM, Nikos Mavrogiannopoulos wrote: > > My understanding of it is that SSL 3.0 shouldn't be used with ECC > ciphersuites, but it seems openssl as a server negotiates them under SSL > 3.0. What is the behavior of other implementations? Should it be > that similar version restrictions in this and other drafts be > ignored? Since the ECC ciphersuites require the use of the Supported Point Formats extension, it would be difficult to use them with SSL 3.0 since most SSL 3.0 implementations don't support extensions. In any case, with widespread deployment of TLS, I agree with Marsh Ray that this is a corner case that should only happen when the server is misconfigured to turn off TLS. In NSS, AES and Camellia cipher suites can be used in SSL 3.0, but ECC cipher suites can't because of the extension issue. Wan-Teh From paul.hoffman@vpnc.org Mon Mar 19 17:57:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7B221F8664 for ; Mon, 19 Mar 2012 17:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.68 X-Spam-Level: X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzxpZr6fdouU for ; Mon, 19 Mar 2012 17:57:21 -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 874D421F862B for ; Mon, 19 Mar 2012 17:57:21 -0700 (PDT) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q2K0vKoG086040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Mar 2012 17:57:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <201203191923.q2JJNNE2020025@fs4113.wdf.sap.corp> Date: Mon, 19 Mar 2012 17:57:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201203191923.q2JJNNE2020025@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1257) Cc: tls@ietf.org Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 00:57:22 -0000 On Mar 19, 2012, at 12:23 PM, Martin Rex wrote: > Why should there be a limitation of ECC to TLS? =20 Because that is how the document describing how to do ECC defined it, = and that is how the document was evaluated. If you believe that RFC 4492 = should be updated to also cover other versions of TLS, it should be = quite simple to generate a one-page draft, and if there is no technical = problem, it should sail through. > There seem to be similar interop issues with AES ciphersuites = (rfc3268), > which work fine in Firefox with SSLv3, but Microsoft's Channel > does not support them with SSLv3. Ditto. --Paul Hoffman From ynir@checkpoint.com Tue Mar 20 04:49:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B217821F85CF for ; Tue, 20 Mar 2012 04:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xkdx9sfHahrT for ; Tue, 20 Mar 2012 04:49:52 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 52E2421F85C4 for ; Tue, 20 Mar 2012 04:49:52 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2KBno9C019693; Tue, 20 Mar 2012 13:49:50 +0200 X-CheckPoint: {4F686E6A-2-1B221DC2-5FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 20 Mar 2012 13:49:50 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Tue, 20 Mar 2012 13:49:49 +0200 Thread-Topic: [TLS] incompatibilities with ECC rfc Thread-Index: Ac0Gj43O8om7JIbER8aTs9eRk5FA/w== Message-ID: <25A5208F-E942-4AC5-A4F2-2BE75D016100@checkpoint.com> References: <201203191913.q2JJDnUT019343@fs4113.wdf.sap.corp> In-Reply-To: <201203191913.q2JJDnUT019343@fs4113.wdf.sap.corp> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org list" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 11:49:53 -0000 On Mar 19, 2012, at 9:13 PM, Martin Rex wrote: > Eric Rescorla wrote: >>=20 >> Well, the record header isn't used for negotiation. So while RFC 5246; >> S E.2 does in fact recommend this practice, there's no requirement that >> a client which sends the 3.0/3.x pair actually supports the range 3.0-3.= x. >=20 > The protocol version in the TLS record header describes the version > of the protocol for that particular PDU. >=20 > A client that sends { 0x03, 0x00 } in the TLS record protocol for the > records conveying the ClientHello is actively indicating that it has > implemented SSLv3. >=20 > version > The version of the protocol being employed.=20 >=20 > This does _not_ indicate, however, that the client will agree to > negotiating SSLv3 for the connection. Depending on client policy or > configuration, the client may be offering { 0x03, 0x03 } as his highest > supported client_version within ClientHello and abort if the server > does not choose at least { 0x03, 0x01 } TLSv1.0 for his ServerHello > response. That would be a strange way to deploy the client. Why would it send 0x03,0x= 00 if it doesn't agree to negotiate it? In that case it should send 0x03,0x= 01 in the TLS header. I understand why a server would accept an SSLv3 or even SSLv2 header when i= t won't accept them as the negotiated version for the connection, but I fai= l to see why that would be a good idea for a client. Yoav From SRS0=lzeZ=B3=acm.org=bmoeller@srs.kundenserver.de Tue Mar 20 07:14:56 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE52D21F86DC for ; Tue, 20 Mar 2012 07:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.29 X-Spam-Level: X-Spam-Status: No, score=-102.29 tagged_above=-999 required=5 tests=[AWL=1.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4hQl87ucKSU for ; Tue, 20 Mar 2012 07:14:56 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id CDAA021F86F2 for ; Tue, 20 Mar 2012 07:14:55 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0M8iqK-1S090o39bg-00CXDu; Tue, 20 Mar 2012 15:14:51 +0100 Received: by yhkk25 with SMTP id k25so89507yhk.31 for ; Tue, 20 Mar 2012 07:14:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.116.6 with SMTP id k6mr806707qaq.91.1332252889675; Tue, 20 Mar 2012 07:14:49 -0700 (PDT) Received: by 10.224.186.207 with HTTP; Tue, 20 Mar 2012 07:14:49 -0700 (PDT) In-Reply-To: <4F64FD71.1070103@extendedsubset.com> References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> Date: Tue, 20 Mar 2012 15:14:49 +0100 Message-ID: From: Bodo Moeller To: Marsh Ray Content-Type: multipart/alternative; boundary=20cf3074b0b23d78e504bbad4cf3 X-Provags-ID: V02:K0:C7Jv0T9/F1Ewj9FCLx7RYiJOkki3huNvWYsUAU7Kjk/ Scc32hMJuB9njPh0jiOeICi3tmnF5wfc6Ty3JocKsi+FDYJ9gm 7tCGd/edDp+lrJkbLxuWryrLtr7ldN8h0WYvqbswoUq5HhN+Yd 2T9pEEi2cWUHPxTaeawxmGlWMgkLKmqaLaSsNHschNjNplJc4r KlOM1KFBVhf/n5k3GpjxAHcf8ZQ0Xv38Z2zZIMhAlZCNAMSgQc nq6qvnhTAWnHf/7xcwKOHj+8nInMsjk+qgS/nlIHIhaT7k47FK n9/UsYnyExx/Rt7YWbfDJIEjl22WAgp4WWssWkIhnL8mgyTpye 6p2EkNK1Tbxf54gvkUTB5VVusrijKvTaGEkvP8F8rYgyv+SBow oFZTxKUbhG7Y2P8Y6iYe8VyFWtxesNpkoJ6M7MZyJ6Cs2xNXvp mR3Cr Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 14:26:37 -0000 --20cf3074b0b23d78e504bbad4cf3 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Mar 17, 2012 at 10:09 PM, Marsh Ray wrote: > On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote: > > For example rfc4132 adds new ciphersuites to TLS 1.0. Should they be >> used under SSL 3.0 or not? I say not, but it can be claimed that there >> is no good reason not to use these ciphersuites under SSL 3.0 [0]. >> > > SSL 3.0 isn't a standard maintained by the IETF TLS WG (or by anybody for > that matter). So nobody can say what SHOULD be done with it. > That's my interpretation too. Any "SSL 3.0" implementation is based on an ad-hoc interpretation of a bunch of specs (or, worse, is following the historical SSL 3.0 specification by the letter). If both the client and the server do support any version of TLS, then they won't be negotiating use of SSL 3.0 anyway. If they negotiate a non-IETF protocol, we can't expect IETF specifications to have all the details on how that protocol works. Generally, this shouldn't be relevant -- SSL 3.0 is historic, so implementations that don't support TLS but do support a new ciphersuite are somewhat unexpected. (Specifically for the ECC ciphersuites, these normally do involve TLS extensions, which aren't defined for SSL 3.0, so RFC 4492 couldn't just have said that the ECC ciphersuites work exactly the same for SSL 3.0.) Bodo --20cf3074b0b23d78e504bbad4cf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Mar 17, 2012 at 10:09 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
On 03/17/2012 03:33 PM, Nikos Mavrogiannopoulos wrote:
=A0
For example rfc4132 adds new ciphersuites to TLS 1.0. Should they be
used under SSL 3.0 or not? I say not, but it can be claimed that there
is no good reason not to use these ciphersuites under SSL 3.0 [0].

SSL 3.0 isn't a standard maintained by the IETF TLS WG (or by anybody f= or that matter). So nobody can say what SHOULD be done with it.

That's my interpretation too.=A0 Any "SSL 3.0" = implementation is based on an ad-hoc interpretation of a bunch of specs (or= , worse, is following the historical SSL 3.0 specification by the letter).= =A0 If both the client and the server do support any version of TLS, then t= hey won't be negotiating use of SSL 3.0 anyway.=A0 If they negotiate a = non-IETF protocol, we can't expect IETF specifications to have all the = details on how that protocol works.=A0 Generally, this shouldn't be rel= evant -- SSL 3.0 is historic, so implementations that don't support TLS= but do support a new ciphersuite are somewhat unexpected.

(Specifically for the ECC ciphersuites, these normally do involve TLS e= xtensions, which aren't defined for SSL 3.0, so RFC 4492 couldn't j= ust have said that the ECC ciphersuites work exactly the same for SSL 3.0.)=

Bodo


--20cf3074b0b23d78e504bbad4cf3-- From fweimer@bfk.de Tue Mar 20 08:37:29 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6D21F85CF for ; Tue, 20 Mar 2012 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdX3e+HD44UX for ; Tue, 20 Mar 2012 08:37:29 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id CA24521F85C4 for ; Tue, 20 Mar 2012 08:37:28 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1SA17h-0000nV-R5; Tue, 20 Mar 2012 15:37:21 +0000 Received: by bfk.de with local id 1SA17h-0001AF-Hu; Tue, 20 Mar 2012 15:37:21 +0000 From: Florian Weimer To: Peter Gutmann References: Date: Tue, 20 Mar 2012 15:37:21 +0000 In-Reply-To: (Peter Gutmann's message of "Sat, 17 Mar 2012 14:57:52 +1300") Message-ID: <823993xozy.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 15:37:29 -0000 * Peter Gutmann: > Hannes Tschofenig writes: > >>Just a thought that came to my mind: How often is client authentication v= ia >>certificates used in TLS in the real world? > > Use is practically nonexistent except for a small number of stovepipe > applications, and certainly widespread public use is nonexistent. What would qualify as "widespread use"? Perhaps tens of thousands of users in Germany who rely client certificate authentication in browsers to access specific applications? I recently had to debug a handshake issue, and even though the whole service is wrapped in a quite different way, it does use Internet Explorer, TLS and a client certificate underneath. I was quite surprised. > So this approach is "solving" a problem that practically doesn't > exist. I'm not sure if the added complexity is worth the effort. If this is somehow addressed, the next thing on the list is the Server Name Indication and the server certificate, I guess. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From n.mavrogiannopoulos@gmail.com Tue Mar 20 10:27:27 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2621F872F for ; Tue, 20 Mar 2012 10:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrKjT+zhZy1n for ; Tue, 20 Mar 2012 10:27:26 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 681B821F8704 for ; Tue, 20 Mar 2012 10:27:26 -0700 (PDT) Received: by eaaq11 with SMTP id q11so120088eaa.31 for ; Tue, 20 Mar 2012 10:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=1qrUY2vGF7onlPy4i/0l/GhdeN8FHwE58Mquxe59hD8=; b=qBRPb4cV7mH3Hg3I1LpKj8VbgKSpEEZ5XhWfkh16BkSfKlEGdgNZr/BwXoGeJmsum4 uy7ptRMgi/ncTb9BMc+Pc+KBHgOvS7TczOZ+uJ/zOVJevu/3Q5B8fAWKCeUCoxEgDI9c SuKh5UpEjZ5r1M72AsZqzqEt6n8IKg7eYPLK+goonNh3oskG2dZoaLWzNxttfiGVQvmo s41g2F1ciFXWLi8RrA7mINE8Ugl6LF7QFn+zbIqnlxDPMay7zBKO68eDG9xelCdqHIFo xLyDoN3oQkH3ErVGPqq/COYBQm9PlBCHWyCMJap8jkWtRCMnJcTg9BxTD7gPjVKtsm15 1tmw== Received: by 10.14.47.5 with SMTP id s5mr98304eeb.97.1332264445575; Tue, 20 Mar 2012 10:27:25 -0700 (PDT) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id n56sm7330175eeb.4.2012.03.20.10.27.23 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 10:27:24 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <4F68BDF6.3010508@gnutls.org> Date: Tue, 20 Mar 2012 18:27:18 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Bodo Moeller References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> 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] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 17:27:27 -0000 On 03/20/2012 03:14 PM, Bodo Moeller wrote: >> For example rfc4132 adds new ciphersuites to TLS 1.0. Should they be >>> used under SSL 3.0 or not? I say not, but it can be claimed that there >>> is no good reason not to use these ciphersuites under SSL 3.0 [0]. >> SSL 3.0 isn't a standard maintained by the IETF TLS WG (or by anybody for >> that matter). So nobody can say what SHOULD be done with it. > That's my interpretation too. Any "SSL 3.0" implementation is based on an > ad-hoc interpretation of a bunch of specs (or, worse, is following the > historical SSL 3.0 specification by the letter). If both the client and > the server do support any version of TLS, then they won't be negotiating > use of SSL 3.0 anyway. The TLS 1.0 protocol is designed in a way to interoperate with SSL 3.0 as well as SSL 2.0 (we even have an SSL 2.0 compatible hello). Thus interoperability issues with SSL 3.0 are within the scope of the WG clearly. However the issue isn't on SSL 3.0, but on the RFCs in question. Are the TLS numbers mentioned hard limits? Implementations MUST follow them, or MAY follow them? regards, Nikos From SRS0=lzeZ=B3=acm.org=bmoeller@srs.kundenserver.de Tue Mar 20 11:01:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57321F8600 for ; Tue, 20 Mar 2012 11:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4q42sYFAY5M for ; Tue, 20 Mar 2012 11:01:35 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id B4C7F21F85ED for ; Tue, 20 Mar 2012 11:01:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LgSHJ-1Sg8O82ck9-00nx2V; Tue, 20 Mar 2012 19:01:33 +0100 Received: by yenm5 with SMTP id m5so363307yen.31 for ; Tue, 20 Mar 2012 11:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.195.201 with SMTP id ed9mr2085636qab.65.1332266492529; Tue, 20 Mar 2012 11:01:32 -0700 (PDT) Received: by 10.224.186.207 with HTTP; Tue, 20 Mar 2012 11:01:32 -0700 (PDT) In-Reply-To: <4F68BDF6.3010508@gnutls.org> References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> <4F68BDF6.3010508@gnutls.org> Date: Tue, 20 Mar 2012 19:01:32 +0100 Message-ID: From: Bodo Moeller To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=20cf300fb217088c0c04bbb077e1 X-Provags-ID: V02:K0:Sae7F+ovA/FCrKB+idu2kQ9bAKpoLj1mIC1tUppLChF +jW2lKpneteHq2+sKMw/ox10xPGZ6C7ij5tGBdBYHPIZUSi0hh kwGDMIGlJmUIu5M3/Pl81jGpDC9T51IUUkyZcp7d1sO+QP1yhZ WZFSUff7zCaY1qsUKv8G/Oa0b1HKzu62/33Kj21JAh5YGC2is2 G21VEUNkQPx2XkLmSiZFwgVYkCuW6ebwCACMyLHMGtMzX59O0d 8EUWyB99IA+n/5BbRbb4YPGmj9y6Bu5cLI87EN+ztH4Rks9fCE RXdrFiUHzJ3G58LQypObrcpH6KGTWDb9YbS4Fr4e8YQbSHyr1D CbzjLKRtS1jxgg4mzngcvXbA4+3STOvNrwzoFvEvbgF4TC+kaJ WWtjQ8aJrW3f0cAJDJPEmIMZWF8/cK4PD3umGemwYQ7NHGJYl9 HzO44 Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:01:35 -0000 --20cf300fb217088c0c04bbb077e1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 20, 2012 at 6:27 PM, Nikos Mavrogiannopoulos wrote: The TLS 1.0 protocol is designed in a way to interoperate with SSL 3.0 > as well as SSL 2.0 (we even have an SSL 2.0 compatible hello). Thus > interoperability issues with SSL 3.0 are within the scope of the WG > clearly. > How to **support** SSL backwards-compatibility within a TLS handshake clearly is within the scope (if TLS servers don't accept your backwards-compatible client hellos, you can't try to interoperate with SSL servers), but once a client and server have **actually** negotiated SSL, that's a different matter. However the issue isn't on SSL 3.0, but on the RFCs in question. Are > the TLS numbers mentioned hard limits? Implementations MUST follow them, > or MAY follow them? > As one data point, the TLS Extensions RFCs (RFC 3546, RFC 4366, RFC 6066) don't mention SSL at all, but RFC 5746 (TLS Renegotiation Indication Extension) assumes that you'd use extensions exactly similarly with SSL 3.0. Bodo --20cf300fb217088c0c04bbb077e1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 20, 2012 at 6:27 PM, Nikos Mavrogiannopoulos = <nmav@gnutls.org> wrote= :

The TLS 1.0 protocol is designed in a way to interoperate with SSL 3.0
as well as SSL 2.0 (we even have an SSL 2.0 compatible hello). Thus
interoperability issues with SSL 3.0 are within the scope of the WG clearly= .

How to *support* SSL backwards-compatibil= ity within a TLS handshake clearly is within the scope (if TLS servers don&= #39;t accept your backwards-compatible client hellos, you can't try to = interoperate with SSL servers), but once a client and server have *actua= lly* negotiated SSL, that's a different matter.

However the issue isn't on SSL 3.0, but on the RFCs in question. Are the TLS numbers mentioned hard limits? Implementations MUST follow them, or MAY follow them?

As one data point, the TLS Ext= ensions RFCs (RFC 3546, RFC 4366, RFC 6066) don't mention SSL at all, b= ut RFC 5746 (TLS Renegotiation Indication Extension) assumes that you'd= use extensions exactly similarly with SSL 3.0.

Bodo

--20cf300fb217088c0c04bbb077e1-- From marsh@extendedsubset.com Tue Mar 20 11:18:30 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B724E21F85FD for ; Tue, 20 Mar 2012 11:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI71qwBUP80B for ; Tue, 20 Mar 2012 11:18:30 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1726921F858A for ; Tue, 20 Mar 2012 11:18:30 -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 1SA3db-0003BR-Lb; Tue, 20 Mar 2012 18:18:27 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C32B56082; Tue, 20 Mar 2012 18:18:25 +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+bRYaY6h/JBvFwokD3Gy8NgvPhD03NCH8= Message-ID: <4F68C9F3.5010909@extendedsubset.com> Date: Tue, 20 Mar 2012 13:18:27 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Bodo Moeller References: <4F648BCB.2090401@gnutls.org> <9A109ED4-2975-459C-BF0F-3BBEF4ED9247@vpnc.org> <4F64F527.6000600@gnutls.org> <4F64FD71.1070103@extendedsubset.com> <4F68BDF6.3010508@gnutls.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 18:18:30 -0000 On 03/20/2012 01:01 PM, Bodo Moeller wrote: > > However the issue isn't on SSL 3.0, but on the RFCs in question. Are > the TLS numbers mentioned hard limits? Implementations MUST follow them, > or MAY follow them? > > As one data point, the TLS Extensions RFCs (RFC 3546, RFC 4366, RFC > 6066) don't mention SSL at all, but RFC 5746 (TLS Renegotiation > Indication Extension) assumes that you'd use extensions exactly > similarly with SSL 3.0. RFC 5746 was developed with the primary goal of getting a solid bugfix out as quickly as possible to as many vulenerable systems as possible. Compatibility with the installed base, even of some nonstandard and noncompliant servers, was an overriding concern because it could delay adoption. There was a lot of discussion over how it could be made to benefit SSL 3.0 implementations too; the SCSV is an example of that. But in this regard I wouldn't hold up RFC 5746 as a model of recommended policy! It is data point though. - Marsh From tom@ritter.vg Tue Mar 20 12:52:37 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310A421F8623 for ; Tue, 20 Mar 2012 12:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LrltTKgWlLk for ; Tue, 20 Mar 2012 12:52:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0D721F8622 for ; Tue, 20 Mar 2012 12:52:36 -0700 (PDT) Received: by yenm5 with SMTP id m5so485299yen.31 for ; Tue, 20 Mar 2012 12:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=EliPILJOnhwd36euoPqHYTB0EyYPnBAqSKjxrDnd518=; b=QCdZ1n7tA2nrtyBCkPfqvEl4uS6WxZO5IwldAxSn2XoXSCjE0PpwzzP2Oc9Q13hcWP hdxn6CJzLcFKkZHFMxPVQNcMFqtq910L6D+8U77yiw5nz9liDiTFwQp/9T3WCgY6FRXf /52pYBXUp+KEy8Pf2TiT65yFKrfSiVnkpAa1M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EliPILJOnhwd36euoPqHYTB0EyYPnBAqSKjxrDnd518=; b=VHRy/lEN1MthfeSJrP2r6aNArl/VLIaN5zFYks1XRnfeJL0GY77D/AQ/glTWou8kBB DTrgZZq9BLXG5AeHvI8HugEcbNZ8gZSfKYfrKFS30DCNPFb09LjJKN61lSjqiUzmjcP1 MNybnygPMiKiIs+YdI1D5uEqhiYWGyU4g1UFJtmOBgDTvuiaodltZAG9V98DCyt+/yB9 r2T9//lfEK1lUYU/TppHcBl0bWDf0Rd+u0wTRgdPpiYkAH1D41M8PNlwdeYdzrmzEsmy XJkW7Kli+4T8djv2fZGfwB5vRO8bddQfsfnSRkesLcTY+GA1MsUWEc7NgTLYmP0uISEu 0bHg== Received: by 10.60.25.162 with SMTP id d2mr1626389oeg.30.1332273155508; Tue, 20 Mar 2012 12:52:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.231.105 with HTTP; Tue, 20 Mar 2012 12:52:14 -0700 (PDT) In-Reply-To: <823993xozy.fsf@mid.bfk.de> References: <823993xozy.fsf@mid.bfk.de> From: Tom Ritter Date: Tue, 20 Mar 2012 15:52:14 -0400 Message-ID: To: Florian Weimer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnFLu/Gl47xd3ii4Rk4CxWue5bKWwdtVKTMd5zxa3DmWg5nxjDqQhangmqwj9tq1a1OUduO Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 19:52:37 -0000 On 20 March 2012 11:37, Florian Weimer wrote: >> So this approach is "solving" a problem that practically doesn't >> exist. > > I'm not sure if the added complexity is worth the effort. =A0If this is > somehow addressed, the next thing on the list is the Server Name > Indication and the server certificate, I guess. My immediate reaction is that exposing the personal details of a user connecting to a service is an issue, but exposing the details of the service is less important. It's not very difficult to set up a filter that watches all TLS connections in a home/company/ISP/country (depending on your access) and look for client certificate connections that include an email address ending in .mil, or google.com, or acme.com where acme is any of the 1000 interesting defense contractors, software manufacturers, certificate authorities, or organizations whose employees enjoy privileged access to something valuable. It's a very scalable, very low-noise, very good ROI type of espionage. So I think encrypted client certs that defend against such a passive adversary is a very nice way to shut that down. That's my biggest interest in this. If I wanted to target an endpoint, like vpnserver.oakridgelaboratory.gov, I could filter for a SNI extension... but it'd be easier and more interesting to just resolve the domain name, and watch all IP traffic - a technique TLS can't solve. Protecting SNI/Server cert doesn't help there. Protecting them *does* help then you don't know the endpoint, but have a keyword ("oakridgelaboratory.gov")... but you would catch all TLS traffic (noisy, low ROI). And when you have a target like that, the 'smart attacker'* would just enumerate dns names, get IP addresses, and go back to the IP logging. There are lists of IP addresses that belong to the RIAA, MPAA, and anti-piracy companies that are used in blacklist firewalls to protect folks pirating. I imagine there's similar lists for "interesting and valuable IP space". * i.e. me if I were into that sort of thing -tom From hannes.tschofenig@nsn.com Tue Mar 20 21:07:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5C421E8050 for ; Tue, 20 Mar 2012 21:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.427 X-Spam-Level: X-Spam-Status: No, score=-106.427 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdEdVLODHNh1 for ; Tue, 20 Mar 2012 21:07:43 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C080021E804A for ; Tue, 20 Mar 2012 21:07:42 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2L47W2E018568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Mar 2012 05:07:32 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2L47Tvm028559; Wed, 21 Mar 2012 05:07:31 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 05:06:58 +0100 Received: from 10.159.32.12 ([10.159.32.12]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Mar 2012 04:06:57 +0000 MIME-Version: 1.0 Message-ID: <2de301cd0718$0ebf16f5$0c209f0a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0HGA6+aZDIKqmhQju/DeV1eZp44g== Date: Wed, 21 Mar 2012 06:06:59 +0200 To: "ext Florian Weimer" , "Peter Gutmann" Content-Type: multipart/alternative; boundary="_8783878E-A379-7855-82CA-F145836D0532_"; charset="iso-8859-1" X-OriginalArrivalTime: 21 Mar 2012 04:06:58.0435 (UTC) FILETIME=[0F813D30:01CD0718] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5808 X-purgate-ID: 151667::1332302852-00003570-2CF0EC7D/0-0/0-0 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 04:07:44 -0000 --_8783878E-A379-7855-82CA-F145836D0532_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hi Florian, I have no problem with the proposed extension even if it is not the most wi= despread extension we have ever seen. I do think, however, that an accurate= description of the provided privacy protection is important. I am happy to= to propose text (after the IETF meeting). A separate but related discussion is how authentication on the Web should l= ook like and what role privacy protection plays there. I had written a doc = about this topic but it isn't really focused on TLS... Ciao Hannes Sent from my Windows Phone -----Original Message----- From: ext Florian Weimer Sent: 3/20/2012 5:37 PM To: Peter Gutmann Cc: hannes.tschofenig@nsn.com; tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials * Peter Gutmann: > Hannes Tschofenig writes: > >>Just a thought that came to my mind: How often is client authentication v= ia >>certificates used in TLS in the real world? > > Use is practically nonexistent except for a small number of stovepipe > applications, and certainly widespread public use is nonexistent. What would qualify as "widespread use"? Perhaps tens of thousands of users in Germany who rely client certificate authentication in browsers to access specific applications? I recently had to debug a handshake issue, and even though the whole service is wrapped in a quite different way, it does use Internet Explorer, TLS and a client certificate underneath. I was quite surprised. > So this approach is "solving" a problem that practically doesn't > exist. I'm not sure if the added complexity is worth the effort. If this is somehow addressed, the next thing on the list is the Server Name Indication and the server certificate, I guess. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 --_8783878E-A379-7855-82CA-F145836D0532_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Hi Florian,

I have no problem with the propos= ed extension even if it is not the most widespread extension we have ever s= een. I do think, however, that an accurate description of the provided priv= acy protection is important. I am happy to to propose text (after the IETF = meeting).

A separate but related discussion is how authentication on= the Web should look like and what role privacy protection plays there. I h= ad written a doc about this topic but it isn't really focused on TLS...
=
Ciao
Hannes

Sent from my Windows Phone
From: ext Florian Weimer
Sent: 3/20/2012 5:37 PM<= br>To: Peter Gutmann
Cc: hannes.tschofenig@nsn.com; t= ls@ietf.org
Subject: Re: [TLS] cipher suites for protecting= client credentials

* Peter Gutmann:

> Hannes Tscho= fenig <Hannes.Tschofenig@gmx.net> writes:
>
>>Just a t= hought that came to my mind: How often is client authentication via
>= >certificates used in TLS in the real world?
>
> Use is prac= tically nonexistent except for a small number of stovepipe
> applicat= ions, and certainly widespread public use is nonexistent.

What would= qualify as "widespread use"?  Perhaps tens of thousands of
users i= n Germany who rely client certificate authentication in browsers
to acce= ss specific applications?

I recently had to debug a handshake issue,= and even though the whole
service is wrapped in a quite different way, = it does use Internet
Explorer, TLS and a client certificate underneath.&= nbsp; I was quite
surprised.

> So this approach is "solving" a= problem that practically doesn't
> exist.

I'm not sure if the= added complexity is worth the effort.  If this is
somehow addresse= d, the next thing on the list is the Server Name
Indication and the serv= er certificate, I guess.

--
Florian Weimer   &nbs= p;            <fw= eimer@bfk.de>
BFK edv-consulting GmbH     &n= bsp; http://www.bfk.de/
Kriegsstra=DFe 100     =          tel: +49-721-96201-1
D-= 76133 Karlsruhe          =    fax: +49-721-96201-99
= --_8783878E-A379-7855-82CA-F145836D0532_-- From anders.rundgren@telia.com Wed Mar 21 02:52:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FA321F8688 for ; Wed, 21 Mar 2012 02:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxArGehibvNa for ; Wed, 21 Mar 2012 02:52:53 -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 D0CB321F85F7 for ; Wed, 21 Mar 2012 02:52:52 -0700 (PDT) Received: from [192.168.3.131] (193.12.106.2) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CBA4E003F4A43; Wed, 21 Mar 2012 10:52:44 +0100 Message-ID: <4F69A4EA.3080208@telia.com> Date: Wed, 21 Mar 2012 10:52:42 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <2de301cd0718$0ebf16f5$0c209f0a@nsnintra.net> In-Reply-To: <2de301cd0718$0ebf16f5$0c209f0a@nsnintra.net> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 09:52:53 -0000 On 2012-03-21 05:06, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Florian, >>>Just a thought that came to my mind: How often is client authentication via >>>certificates used in TLS in the real world? >> >> Use is practically nonexistent except for a small number of stovepipe >> applications, and certainly widespread public use is nonexistent. > > What would qualify as "widespread use"? Perhaps tens of thousands of > users in Germany who rely client certificate authentication in browsers > to access specific applications? There are millions of users of TLS c-c-a in Asia and Europe. With mobile phones we will soon be counting them in billions. At least if we get enrollment to work :-) Anders From marsh@extendedsubset.com Wed Mar 21 08:34:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB53D21F84F8 for ; Wed, 21 Mar 2012 08:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fCZBm8M9say for ; Wed, 21 Mar 2012 08:34:26 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 01F5F21E800E for ; Wed, 21 Mar 2012 08:34: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 1SANYP-000JVf-E2; Wed, 21 Mar 2012 15:34:25 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 921CB6067; Wed, 21 Mar 2012 15:34:23 +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: U2FsdGVkX197IY6Avg8cnNiqE8ouM1na39crC95i9CA= Message-ID: <4F69F4FF.10203@extendedsubset.com> Date: Wed, 21 Mar 2012 10:34:23 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Anders Rundgren References: <2de301cd0718$0ebf16f5$0c209f0a@nsnintra.net> <4F69A4EA.3080208@telia.com> In-Reply-To: <4F69A4EA.3080208@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:34:26 -0000 On 03/21/2012 04:52 AM, Anders Rundgren wrote: > On 2012-03-21 05:06, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >> What would qualify as "widespread use"? Perhaps tens of thousands of >> users in Germany who rely client certificate authentication in browsers >> to access specific applications? > > There are millions of users of TLS c-c-a in Asia and Europe. > With mobile phones we will soon be counting them in billions. > > At least if we get enrollment to work :-) Per Wikipedia, there are about 3.5 million active smart card IDs issued by the US DoD: https://en.wikipedia.org/wiki/Common_Access_Card These cards include client certs for accessing secure websites via TLS. Of course, they have a bit more of a supporting infrastructure for enrollment than your typical website! - Marsh From anders.rundgren@telia.com Wed Mar 21 12:51:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB20D21E80BE for ; Wed, 21 Mar 2012 12:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER2pNY8h0RZH for ; Wed, 21 Mar 2012 12:51:24 -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 BE37321E8083 for ; Wed, 21 Mar 2012 12:51:23 -0700 (PDT) Received: from [192.168.0.207] (213.66.133.125) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4F5CB81D0030B3BF; Wed, 21 Mar 2012 20:51:19 +0100 Message-ID: <4F6A3134.3080209@telia.com> Date: Wed, 21 Mar 2012 20:51:16 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Marsh Ray References: <2de301cd0718$0ebf16f5$0c209f0a@nsnintra.net> <4F69A4EA.3080208@telia.com> <4F69F4FF.10203@extendedsubset.com> In-Reply-To: <4F69F4FF.10203@extendedsubset.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:51:25 -0000 On 2012-03-21 16:34, Marsh Ray wrote: > On 03/21/2012 04:52 AM, Anders Rundgren wrote: >> On 2012-03-21 05:06, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>> >>> What would qualify as "widespread use"? Perhaps tens of thousands of >>> users in Germany who rely client certificate authentication in browsers >>> to access specific applications? >> >> There are millions of users of TLS c-c-a in Asia and Europe. >> With mobile phones we will soon be counting them in billions. >> >> At least if we get enrollment to work :-) > > Per Wikipedia, there are about 3.5 million active smart card IDs issued > by the US DoD: > https://en.wikipedia.org/wiki/Common_Access_Card > > These cards include client certs for accessing secure websites via TLS. > > Of course, they have a bit more of a supporting infrastructure for > enrollment than your typical website! Indeed, but now when they have decided supporting "Derived Credentials" http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-02/feb1_nist-800-63-1_overview_enewton.pdf they are in the same deep s**t as everybody else. Anders > > - Marsh > From mrex@sap.com Wed Mar 21 13:53:15 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790EA21F85B6 for ; Wed, 21 Mar 2012 13:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.062 X-Spam-Level: X-Spam-Status: No, score=-10.062 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPsF+wiCCKNM for ; Wed, 21 Mar 2012 13:53:14 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFC521F867F for ; Wed, 21 Mar 2012 13:53:14 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2LKr56M004511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Mar 2012 21:53:05 +0100 (MET) From: Martin Rex Message-Id: <201203212053.q2LKr58n005154@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Wed, 21 Mar 2012 21:53:05 +0100 (MET) In-Reply-To: <25A5208F-E942-4AC5-A4F2-2BE75D016100@checkpoint.com> from "Yoav Nir" at Mar 20, 12 01:49: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] incompatibilities with ECC rfc X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:53:15 -0000 Yoav Nir wrote: > > > On Mar 19, 2012, at 9:13 PM, Martin Rex wrote: > > > > The protocol version in the TLS record header describes the version > > of the protocol for that particular PDU. > > > > A client that sends { 0x03, 0x00 } in the TLS record protocol for the > > records conveying the ClientHello is actively indicating that it has > > implemented SSLv3. > > > > version > > The version of the protocol being employed. > > > > This does _not_ indicate, however, that the client will agree to > > negotiating SSLv3 for the connection. Depending on client policy or > > configuration, the client may be offering { 0x03, 0x03 } as his highest > > supported client_version within ClientHello and abort if the server > > does not choose at least { 0x03, 0x01 } TLSv1.0 for his ServerHello > > response. > > That would be a strange way to deploy the client. > Why would it send 0x03,0x00 if it doesn't agree to negotiate it? > In that case it should send 0x03,0x01 in the TLS header. > > I understand why a server would accept an SSLv3 or even SSLv2 header > when it won't accept them as the negotiated version for the connection, > but I fail to see why that would be a good idea for a client. One motivation for a client to do this would be to get back a comprehensible server reply rather than a simple closure of the network connection. There are TLS peers (pretty much all that run on top of Microsoft SChannel), that do _not_ send TLS Alerts before closing the network connection when encountering a problem. In principle I agree with you that sending the lowest supported protocol version is in theory a good choice. This question comes up every now and then. :) e.g.: https://www.ietf.org/mail-archive/web/tls/current/msg05673.html and the end of this message: https://www.ietf.org/mail-archive/web/tls/current/msg07653.html -Martin From jsalowey@cisco.com Tue Mar 27 08:45:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8463521F87EF for ; Tue, 27 Mar 2012 08:45: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj6CRZAMJpX0 for ; Tue, 27 Mar 2012 08:45:50 -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 A930F21F87E6 for ; Tue, 27 Mar 2012 08:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=105; q=dns/txt; s=iport; t=1332863150; x=1334072750; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=mYZ86Zghq8Fge97/s+eRZGb87tnGAHxI1XkgiVC4kBE=; b=bm7q8FXLNdE5BE2QR4nuf/u5da/m0gvw1WyvgMdiAIHb4hh9bqxpGZtP h5mK46MJYRJgcTGZfOSIaGCenBWsYBUJwuxOEkbNmtNYUOMSk5ZV0KzpU B6yfHP9ihDA4oahQtmzvpK4AWkwhiKY2deM804hL7qxRnxR5VIgG7a6WE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEHAN7fcU+tJV2c/2dsb2JhbABDgxe1N4EHggUdASeBYVGFJgeCKRKdS4EnlyuNa4JBYwSIWI0JhW+IVoFogwc X-IronPort-AV: E=Sophos;i="4.73,658,1325462400"; d="scan'208";a="69797403" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 27 Mar 2012 15:45:50 +0000 Received: from [192.168.8.114] (rtp-vpn2-202.cisco.com [10.82.240.202]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2RFjnrg007806 for ; Tue, 27 Mar 2012 15:45:49 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 08:45:47 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Slides Please X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:45:51 -0000 If you are presenting slides tomorrow please send slides as soon as = possible. =20 Thanks, Joe= From mbadra@gmail.com Tue Mar 27 12:59:44 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45ACD21E814F for ; Tue, 27 Mar 2012 12:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmm+aVfeUlE2 for ; Tue, 27 Mar 2012 12:59:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A867E21E80CE for ; Tue, 27 Mar 2012 12:59:43 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so251781vcb.31 for ; Tue, 27 Mar 2012 12:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=39dWTSN+JHPugvC/NpDYPeaTdcttentrKGQVVkG3MU4=; b=OQohjoiOdFqVubsjzJ3k3uZ6BWbOEG/2ogW/O7j33G4jyNdVTB/z3tVU3Zx8Ts3HJv RgY6NvXDKSQF9ESAu41KkvE3CnOVCkMqUjbfgldvuE7X+Fi8h2KMlbnS8qi9YZDIo4il LeQARZPQF6ChuQB3JmEetktTljb7EkjHmAT1oieURyANERNbbk9pebBpWu2tuem/uHRZ TrdU9LQW0hdF+4ohH4mQew0vt8iHiaOjTmTSS9J4EDEdyGYRZHxb6umpJa7BXxbLy/LC ZV73Gy0HH9JRJl57FaT+iuc9rjXIZm+WCDDc8t+DncS+NDkulAUB5+0MPWBX0vvprIee bOoQ== MIME-Version: 1.0 Received: by 10.220.116.68 with SMTP id l4mr12805106vcq.4.1332878382766; Tue, 27 Mar 2012 12:59:42 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Tue, 27 Mar 2012 12:59:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 21:59:42 +0200 Message-ID: From: Mohamad Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=f46d042fdb36889b1204bc3eee5e Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:59:44 -0000 --f46d042fdb36889b1204bc3eee5e Content-Type: text/plain; charset=ISO-8859-1 Dear All, I posted a revised version of "SCSV for TLS Client Credential Protection". In this version, no need for any extension or for changes in the server certificate to include an authenticated indication to the client that the server supports identity protection. Moreover, active attacks are not possible in the current document version. Kindly have a look on the document and send your comments (I will present it during tomorrow TLS session). http://www.ietf.org/id/draft-badra-tls-identity-protection-02.txt Best regards, Badra --f46d042fdb36889b1204bc3eee5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,
=A0
I posted a revised version of "= SCSV for TLS Client Credential Protection". In this version, no need f= or any extension or for changes in the server certificate to include an aut= henticated indication to the client that the server supports identity prote= ction. Moreover, active attacks are not possible in the current document ve= rsion.
=A0
Kindly have a look on the document and send your comment= s (I will present it during tomorrow TLS session).
=A0
= http://www.ietf.org/id/draft-badra-tls-identity-protection-02.txt
=A0
Best regards,
Badra
--f46d042fdb36889b1204bc3eee5e-- From ekr@rtfm.com Tue Mar 27 15:25:08 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32521E80FD for ; Tue, 27 Mar 2012 15:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDFH-Jo2cPmt for ; Tue, 27 Mar 2012 15:25:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A818B21E8011 for ; Tue, 27 Mar 2012 15:25:06 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so352231vcb.31 for ; Tue, 27 Mar 2012 15:25:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=usTG/eW+w0bVZL/KRjMGO/Nedsc2WkH1+vP2MPdekdw=; b=fBNJ+aBU4SLw/35JCJMcLg7Hj3N21LbtZAmMDGZc5KlssELM8fsXBQLISotaN2pNkF rb75nRnKdg6BJnrWpEmMRYwXP2hei3j4Mjh+z3Wlfht344gsBLaE8UK5UuRa0sdOXf9L KyvHGkOQ7q2qEiWWDAyAFew+VUq1StLJ9S7KM4E2cB6q/QRuxVUOe+HvSO1uHyTbrqfQ juwikoeniel+4db6VmQ4iRzye6hWp95hwoerK+PR68n63PsuhthX3MmjarkESy4ngf49 JxBHNt3Ya8/Ud2INFlcMu3GWL367UfwyAhq3uVT743lxej33xQ19vLBqb4NnS1/+5Bo2 ibgQ== Received: by 10.220.232.10 with SMTP id js10mr12781582vcb.53.1332887106163; Tue, 27 Mar 2012 15:25:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Tue, 27 Mar 2012 15:24:26 -0700 (PDT) X-Originating-IP: [81.253.34.150] In-Reply-To: References: From: Eric Rescorla Date: Wed, 28 Mar 2012 00:24:26 +0200 Message-ID: To: Mohamad Badra Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl9giy9CZSro6SLSC94tLoZuj7zjBB7Rp6CGT8Pi3dnHCL/2alztLNAD+I7/1eVHniiFPhc Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:25:08 -0000 As far as I can tell this still has an active attack. The attacker simply replies to the client by aborting the handshake as shown in S 2. At this point, the client has the option of connecting normally (and disclosing his cert) or not connecting. This is the same downgrade issue all other proposals have. Moreover, the requirement : o If the server does not support the client credential protection described here, the server MUST abort the handshake (by sending a fatal handshake_failure alert). Is incompatible with existing TLS cipher suite behavior. The world is full of servers which will ignore the SCSV. Indeed, this is why it is attractive in other settings. -Ekr On Tue, Mar 27, 2012 at 9:59 PM, Mohamad Badra wrote: > Dear All, > > I posted a revised version of "SCSV for TLS Client Credential Protection". > In this version, no need for any extension or for changes in the server > certificate to include an authenticated indication to the client that the > server supports identity protection. Moreover, active attacks are not > possible in the current document version. > > Kindly have a look on the document and send your comments (I will present it > during tomorrow TLS session). > > http://www.ietf.org/id/draft-badra-tls-identity-protection-02.txt > > Best regards, > Badra > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mbadra@gmail.com Tue Mar 27 16:00:38 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C40B21F8507 for ; Tue, 27 Mar 2012 16:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+IHEsCmRjBp for ; Tue, 27 Mar 2012 16:00:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23ECF21F8505 for ; Tue, 27 Mar 2012 16:00:37 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so371292vcb.31 for ; Tue, 27 Mar 2012 16:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9pHQ0rtrr0SXBt3p+ulDvevjbFiqbGWHZoSQCXlml2c=; b=ivt999YV1iSWdIMdxGIFKjAMXk1A9uCQ6S2ThjrtFxY6X1IAzB4k3Ybeur3XKBq6Pk q6QVjAz2/8cutc4/EasixNTMCyE7gmE2sxvFp/eCfJYbALJx/DaQrM8Pt4jTXtrT7gfx 3cPlnqqSv+6H/PuNk00m6t53lWT9jcDK18XM3DwFjXyhD0u07rZHsnUK9iPR9J2aMSa5 QM1pW9iCYOjrVJB2aPFwfUcE5+HIitV1l2tpSQutKF4eKct+h7v4D/Xe4xOTPJIukT+5 YuC1wlpHicKt0+AArTf705QY2qdcMfTYclaZCzkdzHqEHhgNaooL7X8+oT8anIpWbtnu QyKw== MIME-Version: 1.0 Received: by 10.220.116.68 with SMTP id l4mr13054050vcq.4.1332889236458; Tue, 27 Mar 2012 16:00:36 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Tue, 27 Mar 2012 16:00:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 01:00:36 +0200 Message-ID: From: Mohamad Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=f46d042fdb3676ced304bc417503 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 23:00:38 -0000 --f46d042fdb3676ced304bc417503 Content-Type: text/plain; charset=ISO-8859-1 Eric Rescorla wrote: > As far as I can tell this still has an active attack. The attacker > simply replies > to the client by aborting the handshake as shown in S 2. At this point, > the client has the option of connecting normally (and disclosing his > cert) or not connecting. This is the same downgrade issue all other > proposals have. The main concern was: the client shall receive (before sending its certificate) an authenticated indication showing the server support of the identity protection. I think the other proposals don't provide that. The attack you describe cannot be defended against by TLS. However, it doesn't apply to clients that refuse to send their certificates (I agree this is the same downgrade issue...) > Moreover, the requirement : > > o If the server does not support the client credential protection > described here, the server MUST abort the handshake (by sending a > fatal handshake_failure alert). > > Is incompatible with existing TLS cipher suite behavior. The world is full > of servers which will ignore the SCSV. Indeed, this is why it is attractive > in other settings I will replace "MUST" with "MAY". Best regards Badra On Tue, Mar 27, 2012 at 9:59 PM, Mohamad Badra wrote: > Dear All, > > I posted a revised version of "SCSV for TLS Client Credential Protection". > In this version, no need for any extension or for changes in the server > certificate to include an authenticated indication to the client that the > server supports identity protection. Moreover, active attacks are not > possible in the current document version. > > Kindly have a look on the document and send your comments (I will present it > during tomorrow TLS session). > > http://www.ietf.org/id/draft-badra-tls-identity-protection-02.txt > > Best regards, > Badra > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --f46d042fdb3676ced304bc417503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Eric Rescorla <ekr@rtfm.com> wrote:
As far as I can tell this still has an active attack. The attacker
simply replies
to the client by aborting the handshake as shown in S 2. At this point,
the client has the option of connecting normally (and disclosing his
cert) or not connecting. This is the same downgrade issue all other
proposals have.
=A0
=A0
The main conce= rn was: the client shall receive (before sending=A0its certificate) an auth= enticated indication showing the server support of the identity protection.= I think the other proposals don't provide that.
=A0
The attack you describe cannot be defended against by TL= S. However, it doesn't apply to clients that refuse to send their certi= ficates=A0(I agree this is the same downgrade issue...)
=A0
=
=A0
Moreover, the requirement :

=A0o =A0If the server does not support the client credential protection =A0 =A0 =A0described here, the server MUST abort the handshake (by sending= a
=A0 =A0 =A0fatal handshake_failure alert).

Is incompatible with existing TLS cipher suite behavior. The world is full<= br> of servers which will ignore the SCSV. Indeed, this is why it is attractive=
in other settings
=A0
I will=A0replace "MUST"=A0with &q= uot;MAY".
Best regards
Badra=A0
=A0

On Tue, Mar 27, 2012 at 9:59 PM, Mohamad Badra <mbadra@gmail.com> wrote:
> Dear All,
>
> I posted a revised version of "SCSV for TLS Client Credential Pro= tection".
> In this version, no need for any extension or for changes in the serve= r
> certificate to include an authenticated indication to the client that = the
> server supports identity protection. Moreover, active attacks are not<= br> > possible in the current document version.
>
> Kindly have a look on the document and send your comments (I will pres= ent it
> during tomorrow TLS session).
>
> http://www.ietf.org/id/draft-badra-tls-identity-p= rotection-02.txt
>
> Best regards,
> Badra
>
> _______= ________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d042fdb3676ced304bc417503-- From marsh@extendedsubset.com Tue Mar 27 19:27:45 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E0A21E8032 for ; Tue, 27 Mar 2012 19:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL3z2GvLEGGL for ; Tue, 27 Mar 2012 19:27:44 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id CBBC921E801A for ; Tue, 27 Mar 2012 19:27:44 -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 1SCibw-000E4g-DK; Wed, 28 Mar 2012 02:27:44 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 5B5A160A1; Wed, 28 Mar 2012 02:27:43 +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: U2FsdGVkX18bIjp/7GDI6bcaUbIaFQofoG+TpUX8ag8= Message-ID: <4F72771F.6050606@extendedsubset.com> Date: Tue, 27 Mar 2012 21:27:43 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 02:27:45 -0000 I don't support the idea of using new SCSVs as bitflags for things unrelated to cipher suite selection that would more properly be negotiated by an extension. I realize RI uses an SCSV, but it was clearly an exceptional case. I also think this is not a problem that many client apps need to solve right now and it's not the best way to promote the usage of client certs. However, to be fair to Mohamad's proposal ... On 03/27/2012 05:24 PM, Eric Rescorla wrote: > As far as I can tell this still has an active attack. The attacker > simply replies > to the client by aborting the handshake as shown in S 2. At this point, > the client has the option of connecting normally (and disclosing his > cert) or not connecting. This is the same downgrade issue all other > proposals have. But by this same logic, aren't TLS 1.0, 1.1, 1.2, and all current extensions (with the exception noted previously) also subject to this downgrade attack? Is this not an argument against them too? If the downgrade you're talking about is one of browser's behavior (i.e., if the highest protocol level handshake fails they retry with a lower version on a different TCP connection) then that seems almost out of scope for [TLS]. What could be said in a transport layer spec that could help prevent application layer logic from subverting it in this way? - Marsh From ekr@rtfm.com Tue Mar 27 20:12:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C601021E801A for ; Tue, 27 Mar 2012 20:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2AsBH2-bLbw for ; Tue, 27 Mar 2012 20:12:40 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB03021F850B for ; Tue, 27 Mar 2012 20:12:40 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so458425vbb.31 for ; Tue, 27 Mar 2012 20:12:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=U367ELQ/+IdRqyz1f8vpAcN65SXDtAUE/0U8wJaR81E=; b=huoXNHvqiyy7RbLbchnj25Ego2JVz3eVVJN8hJgFw/zknzXqcB1U1LuQa+ly8OLZv1 f3uZS12NszcqxXHLj6rtnobZNEFnwfXm94h2LH55O58tQ5eaE7IPyfXQYvZZjKkPIQUn I4dprYo5JFrbPvqLqApTRVSvtku9knQxSSyAb9TxCWzIxdVPTYRpNAx2ai0JWzNTo4kD vxyR6fyJeBKV6Pns2tv7jRFbZVTJ7Rj6KCiOWZ9aneTiS8FHXXJnAiHk1RSHjuwovZis 3uzSBswIhs56lq3or7v/qFcnMZuMJ3yCQNW3kF6HkNh4CY1rUPs3WAhU/0tvcs/TxHUJ o4pA== Received: by 10.52.173.38 with SMTP id bh6mr10870226vdc.43.1332904351755; Tue, 27 Mar 2012 20:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Tue, 27 Mar 2012 20:11:51 -0700 (PDT) X-Originating-IP: [81.253.50.98] In-Reply-To: References: From: Eric Rescorla Date: Wed, 28 Mar 2012 05:11:51 +0200 Message-ID: To: Mohamad Badra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQleh6gS/1p0PVAOfN0RQp+FfrZPxB56xfDv+KqDZck9L0mUqs75SBCq7IZcDXNJQWh0uUJu Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 03:12:42 -0000 On Wed, Mar 28, 2012 at 1:00 AM, Mohamad Badra wrote: > Eric Rescorla wrote: >> >> As far as I can tell this still has an active attack. The attacker >> simply replies >> to the client by aborting the handshake as shown in S 2. At this point, >> the client has the option of connecting normally (and disclosing his >> cert) or not connecting. This is the same downgrade issue all other >> proposals have. > > > > The main concern was: the client shall receive (before sending=A0its > certificate) an authenticated indication showing the server support of th= e > identity protection. I think the other proposals don't provide that. That wasn't my main concern. >> Moreover, the requirement : >> >> =A0o =A0If the server does not support the client credential protection >> =A0 =A0 =A0described here, the server MUST abort the handshake (by sendi= ng a >> =A0 =A0 =A0fatal handshake_failure alert). >> >> Is incompatible with existing TLS cipher suite behavior. The world is fu= ll >> of servers which will ignore the SCSV. Indeed, this is why it is >> attractive >> in other settings > > > I will=A0replace "MUST"=A0with "MAY". I don't see how this helps. You still need to distinguish new from old. -Ekr From ekr@rtfm.com Tue Mar 27 20:15:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAFB21E80D9 for ; Tue, 27 Mar 2012 20:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW55sVTYeia3 for ; Tue, 27 Mar 2012 20:15:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80BDC21E80D6 for ; Tue, 27 Mar 2012 20:15:02 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so490341vcb.31 for ; Tue, 27 Mar 2012 20:15:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=1X1ObEMxYweMVyKagMZxT/0Z1Cfwx5WNI+r9UwQOsUY=; b=gek4wtwzTPIqXEgALZcUTcLAWomdRvWDv+VddSxcnTXqS9FbevCdidNjEgvlf7V8du lPs+2JuW0o0yQzWxNPspMuxyBa6ip25ahpTZGm+M6hf703K0ExveG0wrAjPTHT/NhrPz Q8/NRjm4p6LD8qLoZKsgrbdmGfDadgzHJI4alilqX3IufrN+dtC2twdv9eWF5unfe9ST ukYZY4dJCMvR7pZYVUJ4qiK2zSDV2H2VL297PiDMJAfR4b2+GVWPcgTIcoWTopX9XOSK +dbt5XN5KG1gSgVYIcpBvia7AK3OGMsyP33szMYG8TuIlaLtWNOchp751dL0w5NXq2qD iyrA== Received: by 10.52.65.134 with SMTP id x6mr11015184vds.60.1332904502009; Tue, 27 Mar 2012 20:15:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Tue, 27 Mar 2012 20:14:21 -0700 (PDT) X-Originating-IP: [81.253.50.98] In-Reply-To: <4F72771F.6050606@extendedsubset.com> References: <4F72771F.6050606@extendedsubset.com> From: Eric Rescorla Date: Wed, 28 Mar 2012 05:14:21 +0200 Message-ID: To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmogxb9wkFA/oHZ+xv1rNvNoORKArBgYlVOHnHjXLnM/vV8ALh/ZM3c+S91fG7ouhFUQs+M Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 03:15:03 -0000 On Wed, Mar 28, 2012 at 4:27 AM, Marsh Ray wrote: > > I don't support the idea of using new SCSVs as bitflags for things unrelated > to cipher suite selection that would more properly be negotiated by an > extension. I realize RI uses an SCSV, but it was clearly an exceptional > case. > > I also think this is not a problem that many client apps need to solve right > now and it's not the best way to promote the usage of client certs. > > However, to be fair to Mohamad's proposal ... > > > On 03/27/2012 05:24 PM, Eric Rescorla wrote: >> >> As far as I can tell this still has an active attack. The attacker >> simply replies >> to the client by aborting the handshake as shown in S 2. At this point, >> the client has the option of connecting normally (and disclosing his >> cert) or not connecting. This is the same downgrade issue all other >> proposals have. > > > But by this same logic, aren't TLS 1.0, 1.1, 1.2, and all current extensions > (with the exception noted previously) also subject to this downgrade attack? > Is this not an argument against them too? > > If the downgrade you're talking about is one of browser's behavior (i.e., if > the highest protocol level handshake fails they retry with a lower version > on a different TCP connection) then that seems almost out of scope for > [TLS]. What could be said in a transport layer spec that could help prevent > application layer logic from subverting it in this way? This proposal does not depend on any such application logic, as the failure happens during the initial handshake. But yes, willingness to back off to non-extension versions of TLS does in fact represent a downgrade threat to most extensions. -Ekr From mbadra@gmail.com Wed Mar 28 00:30:56 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63ECD21F852E for ; Wed, 28 Mar 2012 00:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.734 X-Spam-Level: X-Spam-Status: No, score=-3.734 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui02FB4bCMpu for ; Wed, 28 Mar 2012 00:30:55 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1A5A21F8620 for ; Wed, 28 Mar 2012 00:30:55 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so598459vcb.31 for ; Wed, 28 Mar 2012 00:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2Hr6EnVaBicVt1o48Hj59wRjh8lSrpPWyqINw3cOkUc=; b=rIRdTN8MVsdCdQuK1xK+41L6K00TaMUqTVePPP8LmRJNnXuAA+8a0Ec/8t0cxQO0CN LaILWbSA5mWxnVQC1e8vjlfcyejmSKkW6cTn10EyeiZ5SZZIDNyofGMGn7FGuw6TLDQO k4ODubLH6ULJTBetaGAk5Y/nGD1fn1Ef80QYr6uBHAN1afQOaWD1Qq5jW5+OiYO0WgCE TdCPc0GQ/dfEWzaP6+m5Q45rNQ7iysQ9KUh6piwHjyauk4VOI6amhRgOFEcmx+Emel0O M+34YKS7ADVDJx0A4tzjeSNcda3o2uw8HJzjmZtANUgP2bupkZ9iCMEVWJeb6EDZIGHo 3GhQ== MIME-Version: 1.0 Received: by 10.52.32.231 with SMTP id m7mr674682vdi.59.1332919855246; Wed, 28 Mar 2012 00:30:55 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 28 Mar 2012 00:30:55 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 09:30:55 +0200 Message-ID: From: Mohamad Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec51d27127c6d0604bc4896ae Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:30:56 -0000 --bcaec51d27127c6d0604bc4896ae Content-Type: text/plain; charset=ISO-8859-1 > > >> > >> Is incompatible with existing TLS cipher suite behavior. The world is > full > >> of servers which will ignore the SCSV. Indeed, this is why it is > >> attractive > >> in other settings > > > > > > I will replace "MUST" with "MAY". > > I don't see how this helps. You still need to distinguish new from old. > I don't see how other setting can achieve that. Would you elaborate please? Best regards Badra --bcaec51d27127c6d0604bc4896ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>
>> Is incompatible with existing TLS cipher suite behavior. The world= is full
>> of servers which will ignore the SCSV. Indeed, this is why it is >> attractive
>> in other settings
>
>
> I will=A0replace "MUST"=A0with "MAY".

I don't see how this helps. You still need to distinguish new = from old.

=A0
I don't see how other sett= ing can achieve that.=A0Would you elaborate please?=A0
=A0
<= div> Best regards
Badra
--bcaec51d27127c6d0604bc4896ae-- From n.mavrogiannopoulos@gmail.com Wed Mar 28 00:56:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D9521F893B for ; Wed, 28 Mar 2012 00:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGVOQnZfvEbG for ; Wed, 28 Mar 2012 00:56:27 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1688B21F893A for ; Wed, 28 Mar 2012 00:56:26 -0700 (PDT) Received: by werb10 with SMTP id b10so535482wer.31 for ; Wed, 28 Mar 2012 00:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nWZjDon/OfXGYjdSiAjMkMmeskLBOLo/zgr4Qf/fep8=; b=obY5Ad7O6XxGstvSuG0weegLjdOMlo7E8pBuixmrGjzhnUaG5/IOeAZNSQxbJqzIqC XWEaw9tkaprqfXZCQd3MjJjpwICyimEwraTWTby3Am94UqFwLd3oRBGtc2R8obQfWA0B eouA28Maz4ZfgmM+H/CQaHzMpmCLHMIKfgFgCfH5mMOAQZvKj7wNEiN5fuiYN2TvYFvT fPEmKzhjyHhsFipTqLcJWyKCR6Xx2eb+AYvb4Jsy3x5x5fu9Phg54aLmEeu/4EjKKxJk qJu3DOuj9KxXBFdQ4fY+4rLBgOoAUZMw9eLGbCmANEBvW6vjee++jLdVEeTpxyw5dM7r T85Q== MIME-Version: 1.0 Received: by 10.180.79.135 with SMTP id j7mr4539897wix.19.1332921385680; Wed, 28 Mar 2012 00:56:25 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.24.231 with HTTP; Wed, 28 Mar 2012 00:56:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 09:56:25 +0200 X-Google-Sender-Auth: JD4s6315ixhsM03FGym2Ofvll2o Message-ID: From: Nikos Mavrogiannopoulos To: Mohamad Badra Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:56:28 -0000 On Tue, Mar 27, 2012 at 9:59 PM, Mohamad Badra wrote: > Dear All, > I posted a revised version of "SCSV for TLS Client Credential Protection". > In this version, no need for any extension or for changes in the server > certificate to include an authenticated indication to the client that the > server supports identity protection. Moreover, active attacks are not > possible in the current document version. Hello, I don't see any reason to define an SCSV ciphersuite, as compatibility with early-SSL 3.0 draft servers isn't a major concern for such an extension. regards, Nikos From mbadra@gmail.com Wed Mar 28 01:39:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A25421F8877 for ; Wed, 28 Mar 2012 01:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.728 X-Spam-Level: X-Spam-Status: No, score=-3.728 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B08I4hUz8Fd for ; Wed, 28 Mar 2012 01:39:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7731921F886B for ; Wed, 28 Mar 2012 01:39:19 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so634657vcb.31 for ; Wed, 28 Mar 2012 01:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=38S/7VCYizaLK4hTktNdW+xBQ6X3Y69AN/4HDgY5EbI=; b=DhKzrQwpNxcqjo1cMVWOx7cA8NqhsZVNL1WNFSPiCdG+gI+JQUSRdTSSC2/2MicD2s NO4mCB4AQgzDSY5PKryyZvUuRztXgtXcILKTj/5PXm2OyKnL8sVbkGMBbEsHhdg6dJwl 8sXOyK36emzYEVS2ojt6MznIz5Ng/024UG7dJSXhY+76iVu/rAKqNHTeyaI+vtWIOpv/ WNbEf4skbuBsVXo/L9PdgpVyHbqCnqG+q9HaETAFvvCR28hDGq3aSsb/tFOMVW1CgXo5 B9bvVr/cZxX2iL9zfnc95TXsY7PbHH5jqDlcZ2IQIfN+PhZ6Tt9+QVF+ozebX6jf9dLM yp7Q== MIME-Version: 1.0 Received: by 10.52.93.74 with SMTP id cs10mr11258013vdb.42.1332923959027; Wed, 28 Mar 2012 01:39:19 -0700 (PDT) Received: by 10.220.108.135 with HTTP; Wed, 28 Mar 2012 01:39:18 -0700 (PDT) In-Reply-To: <4F72771F.6050606@extendedsubset.com> References: <4F72771F.6050606@extendedsubset.com> Date: Wed, 28 Mar 2012 10:39:18 +0200 Message-ID: From: Mohamad Badra To: Marsh Ray Content-Type: multipart/alternative; boundary=bcaec50167391725f604bc498ba4 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:39:20 -0000 --bcaec50167391725f604bc498ba4 Content-Type: text/plain; charset=ISO-8859-1 Marsh Ray wrote: > I realize RI uses an SCSV, but it was clearly an exceptional case. > On Wed, Mar 28, 2012 at 9:56 AM, Nikos Mavrogiannopoulos wrote: >> >> I don't see any reason to define an SCSV ciphersuite, >> > Weren't it possible to avoid using SCSV in rfc5746? What are the requirements to justify exceptional cases there but not here? Best regards, Badra --bcaec50167391725f604bc498ba4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Marsh Ray <marsh@extendedsubset.com> wrote:<= br>
I realize RI uses an SCSV, but it was clearly an exceptional case.
On Wed, Mar 28, 2012 at 9:56 AM, Ni= kos Mavrogiannopoulos <nmav@gnutls.org> wrote:

I don't see any reason to define an SCSV ciphersuite,

=A0
=A0
Weren't it= possible to avoid=A0using SCSV=A0in rfc5746? What are the requirements to = justify exceptional cases=A0there but not here?
Best regards,
Badra
--bcaec50167391725f604bc498ba4-- From ynir@checkpoint.com Wed Mar 28 02:03:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5A521F89C8 for ; Wed, 28 Mar 2012 02:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.5 X-Spam-Level: X-Spam-Status: No, score=-10.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcFIkYv3S3hw for ; Wed, 28 Mar 2012 02:03:52 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 188D821F8902 for ; Wed, 28 Mar 2012 02:03:51 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2S93jYR009812; Wed, 28 Mar 2012 11:03:46 +0200 X-CheckPoint: {4F72D30A-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Mar 2012 11:03:22 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 28 Mar 2012 11:03:21 +0200 From: Yoav Nir To: Mohamad Badra Date: Wed, 28 Mar 2012 11:03:23 +0200 Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0MwZ+q8eFSKJqcQhKdkJofqtiTeQ== Message-ID: References: <4F72771F.6050606@extendedsubset.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: multipart/alternative; boundary="_000_EE4CD31DA55C46BFB8F8D18DF76A3ABCcheckpointcom_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:03:53 -0000 --_000_EE4CD31DA55C46BFB8F8D18DF76A3ABCcheckpointcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mar 28, 2012, at 10:39 AM, Mohamad Badra wrote: Marsh Ray > wrote= : I realize RI uses an SCSV, but it was clearly an exceptional case. On Wed, Mar 28, 2012 at 9:56 AM, Nikos Mavrogiannopoulos > wrote: I don't see any reason to define an SCSV ciphersuite, Weren't it possible to avoid using SCSV in rfc5746? Yes, but all browsers that have extensions also have a no-extensions fallba= ck mode. An attacker can force a browser to the no-extensions mode, but can= 't force a browser to a no-SCSV mode. The WG wanted to make sure the messag= e about RI support definitely makes it to the server, even in the presence = of an attacker that can force no-extensions mode. What are the requirements to justify exceptional cases there but not here? Mostly, it's been two years. Browsers complain about lack of support for RI= , and this has forced most websites to update. It's no longer common to hav= e extensions disabled. I don't think browsers are quick to take away this B= C feature, and maybe Yngve has statistics about how common no-extensions se= rvers are, but they're definitely going away. But the big differentiator I think is urgency. That was an prefix injection= attack that anyone could perform against any site with the possible abilit= y to steal real money and cause real damage. I was able to disable the secu= rity policy on a development firewall by injecting into an administrator se= ssion. (the vulnerability was fixed in time for release). A document went f= rom draft-00 to RFC in three months. This is not business as usual for the = IETF. The attack you are trying to mitigate doesn't have the same level of = ubiquity and urgency, so I don't think it warrants such a deviation from th= e rules. Yoav --_000_EE4CD31DA55C46BFB8F8D18DF76A3ABCcheckpointcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On Mar 28, 2= 012, at 10:39 AM, Mohamad Badra wrote:

Marsh Ray <marsh@extend= edsubset.com> wrote:
I realize RI uses an SCSV, but it was clearly an exceptional case.
On Wed, Mar 28, 2012 at 9:56 AM, Ni= kos Mavrogiannopoulos <nmav@gnutls.org> wrote:

I don't see a= ny reason to define an SCSV ciphersuite,

 
 
Weren't it possible to avoid&= nbsp;using SCSV in rfc5746?

Yes, but all browsers that have extensions also have a no-extensions fal= lback mode. An attacker can force a browser to the no-extensions mode, but = can't force a browser to a no-SCSV mode. The WG wanted to make sure the mes= sage about RI support definitely makes it to the server, even in the presen= ce of an attacker that can force no-extensions mode.

What are the requirements to j= ustify exceptional cases there but not here?

Mostly, it's been two years. Browsers com= plain about lack of support for RI, and this has forced most websites to up= date. It's no longer common to have extensions disabled. I don't think brow= sers are quick to take away this BC feature, and maybe Yngve has statistics= about how common no-extensions servers are, but they're definitely going a= way.

But the big differentiator I think is urgency= . That was an prefix injection attack that anyone could perform against any= site with the possible ability to steal real money and cause real damage. = I was able to disable the security policy on a development firewall by inje= cting into an administrator session. (the vulnerability was fixed in time f= or release). A document went from draft-00 to RFC in three months. This is = not business as usual for the IETF. The attack you are trying to mitigate d= oesn't have the same level of ubiquity and urgency, so I don't think it war= rants such a deviation from the rules.

Yoav
<= div>

= --_000_EE4CD31DA55C46BFB8F8D18DF76A3ABCcheckpointcom_-- From ekr@rtfm.com Wed Mar 28 05:17:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E5821F844A for ; Wed, 28 Mar 2012 05:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSTlUv7EccWY for ; Wed, 28 Mar 2012 05:17:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC4221F8796 for ; Wed, 28 Mar 2012 05:17:22 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so764596vcb.31 for ; Wed, 28 Mar 2012 05:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=NDbnWo3KXVlWzUFZOAssVC9XzAgzrVdaCdfZODeP11I=; b=pLN78Hbg3w4dgwpcTfcKxTWa6CvlRKbpfdoD+sP4l7zID7A7QPXBFs920VHMS+Mw9O Zm6V3pqhI1JK/UNSVa4CESEbA4cQYYu3575OVhYUcVvC1L6Wyzge11Bt8Zo1UKnDQ+Z1 XV2uLfvrh2d8+uASdIVbZwPDNanbRSwrx5HMKeRy5/KNRbtc7bEPdOA8lyGQA7rODzIB xjNo0wO69+6nPv0EBFUlnTBlRaI/EwZTraC19m/xWhSVsmoGcW4xdAjeLzg/o/xJ2kih fJkAH9gGJF4ADQJ5wfMBwHQRyL+DRMp/zrzuwDEj2hnw28WCPjcEQwvEBgBsGZtXgwBx N/lQ== Received: by 10.52.69.100 with SMTP id d4mr12173648vdu.9.1332937041612; Wed, 28 Mar 2012 05:17:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.195 with HTTP; Wed, 28 Mar 2012 05:16:41 -0700 (PDT) X-Originating-IP: [130.129.85.212] In-Reply-To: References: <4F72771F.6050606@extendedsubset.com> From: Eric Rescorla Date: Wed, 28 Mar 2012 14:16:41 +0200 Message-ID: To: Mohamad Badra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmLyKADXA5WUKIOH8uBOwFBoiPuDDFHT0lSoo3ZCIGhcKsoa+zVpUt0Vyi4+4JiLzeZHNtO Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:17:32 -0000 On Wed, Mar 28, 2012 at 10:39 AM, Mohamad Badra wrote: > Marsh Ray wrote: >> >> I realize RI uses an SCSV, but it was clearly an exceptional case. >> On Wed, Mar 28, 2012 at 9:56 AM, Nikos Mavrogiannopoulos >> wrote: >>> >>> I don't see any reason to define an SCSV ciphersuite, > > > > Weren't it possible to avoid=A0using SCSV=A0in rfc5746? What are the > requirements to justify exceptional cases=A0there but not here? The SCSV in RFC 5746 was required to avoid downgrade attacks by simulating faulty extension processing. However, in the case of this draft, an SCSV does not prevent downgrade attacks, so there is no reason not to use an extension. -Ekr From mbadra@gmail.com Wed Mar 28 05:54:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A98B21E820F for ; Wed, 28 Mar 2012 05:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.722 X-Spam-Level: X-Spam-Status: No, score=-3.722 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7eu0ngx5njc for ; Wed, 28 Mar 2012 05:54:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5744921E81DE for ; Wed, 28 Mar 2012 05:54:04 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so793420vcb.31 for ; Wed, 28 Mar 2012 05:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BEFEow5qQYkC57pHrVZ7okeh3gwtlgmwSstRSGu61kQ=; b=Ja47rVL+zm5lKX6p5mK6oiXWmfqycxrYV0IE7QugLld8ArjB8VnmJil45ufUoTP3wD /DknqQqASqNA4Uk9LUytfd7o1jYwfvM6TXjnXAdFmv6CBV6a8swbF9CKJvBmWnE1Arj7 BMtXYXxdYzsr8yQIBhj0uKf1BM36JZeT4G7p7tr3OD6HuKuhVU5gt3CtAI+gha10Xcv/ oTvkgj1KdA+Fd5KODjTAmkF6PepYw9jI+MeZudCXgQHaze8TfE8T6A5LQ+HH73s4ygba sQmTOAsZRG17sy0vd2zpC6RPDlVqfKL9OPNAIMYrVi8++qlJJN3bGdJu5OVaDncVzxap tJUA== MIME-Version: 1.0 Received: by 10.220.227.70 with SMTP id iz6mr14009715vcb.29.1332939243912; Wed, 28 Mar 2012 05:54:03 -0700 (PDT) Received: by 10.220.17.133 with HTTP; Wed, 28 Mar 2012 05:54:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 14:54:03 +0200 Message-ID: From: Mohamad Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=14dae9cdc10723fefe04bc4d1ad0 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:54:05 -0000 --14dae9cdc10723fefe04bc4d1ad0 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 5:11 AM, Eric Rescorla > > > I will replace "MUST" with "MAY". > > I don't see how this helps. You still need to distinguish new from old. > > -Ekr > The Finished received from the server will allow client to distinguish new from old. Best regards Badra --14dae9cdc10723fefe04bc4d1ad0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 28, 2012 at 5:11 AM, Eric Re= scorla <ekr@rtfm.com>=A0
> I will=A0replace "MUST"=A0with "MAY".

I don't see how this helps. You still need to distinguish new fro= m old.

-Ekr

The Finished received from the server will allo= w client to distinguish new from old.

Best regards=
Badra
--14dae9cdc10723fefe04bc4d1ad0-- From mbadra@gmail.com Wed Mar 28 06:46:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85621E80CB for ; Wed, 28 Mar 2012 06:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFpNZ2OhkZY2 for ; Wed, 28 Mar 2012 06:46:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5779321E8165 for ; Wed, 28 Mar 2012 06:46:12 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so808592vbb.31 for ; Wed, 28 Mar 2012 06:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=neOxiQff5Si9bCmPtVrrSgxwbos7uljrouWnFecLm08=; b=pshuOrO51+sDWTUXRo6aQTbRr1UVO5sdGH96fRttgmJZWN1X/SEX5F0NdAlq7mfBfY yzRgqDMwCsH9I4hxb5CTwdgVskTqD/hX+JcYdQ1pqcN6JiJRm4bVXV88Xjyo8TG8K/FJ lpo9ViHvGegCWEu7E8/IIlKMwC+Qx/lhnXBrcLLkQc116iXlODVtsAwxcUxkSjo+/6xx mqERSengn0CVnuVYIz8Y7C2I8jkkkqEcpSv0h691RNyfkJpt1TfOkrgoZma3GKX/tIA0 fXVXmzLa3elHy5F7yU+/c7jgl1ZT/tq6GQt052xjGHa5/SIJRScJ8bESwGMgrrcsbKc/ 5zow== MIME-Version: 1.0 Received: by 10.220.227.70 with SMTP id iz6mr14092540vcb.29.1332942371886; Wed, 28 Mar 2012 06:46:11 -0700 (PDT) Received: by 10.220.17.133 with HTTP; Wed, 28 Mar 2012 06:46:11 -0700 (PDT) In-Reply-To: References: <4F72771F.6050606@extendedsubset.com> Date: Wed, 28 Mar 2012 15:46:11 +0200 Message-ID: From: Mohamad Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=14dae9cdc10795159504bc4dd4e8 Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 13:46:13 -0000 --14dae9cdc10795159504bc4dd4e8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 28, 2012 at 2:16 PM, Eric Rescorla wrote: > > The SCSV in RFC 5746 was required to avoid downgrade attacks > by simulating faulty extension processing. However, in the case > of this draft, an SCSV does not prevent downgrade attacks, so > there is no reason not to use an extension. > > -Ekr > The first reason is extracted from your document [1]: "An extension is not suitable as extension-intolerance is one form of incompatibility" Best regards, Badra [1] http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt --14dae9cdc10795159504bc4dd4e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 2:16 PM, Eric Resco= rla <ekr@rtfm.com> wrote:

The SCSV in RFC 5746 was required to avoid downgrade attacks by simulating faulty extension processing. However, in the case
of this draft, an SCSV does not prevent downgrade attacks, so
there is no reason not to use an extension.

-Ekr


The first reason is extrac= ted from your document [1]:
"An ex=
tension is not
   suitable as extension-intolerance is one form of incompatibility"

Best regards,
Badra
[1]=A0
http://svn.resiprocate.org/rep/ietf-dra=
fts/ekr/draft-rescorla-tls-version-cs.txt
--14dae9cdc10795159504bc4dd4e8-- From yngve@opera.com Wed Mar 28 08:53:33 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE1921E8294 for ; Wed, 28 Mar 2012 08:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.677 X-Spam-Level: X-Spam-Status: No, score=-6.677 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE7ZrEdj1Rmr for ; Wed, 28 Mar 2012 08:53:24 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id E1EB821E829B for ; Wed, 28 Mar 2012 08:53:23 -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 q2SFrJu5008266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 28 Mar 2012 15:53:21 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "tls@ietf.org" Date: Wed, 28 Mar 2012 17:53:25 +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] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:53:33 -0000 Hi, As mentioned during my presentation at the TLS WG meeting today, when implementing my multiple OCSP stapling specification I encountered a problem with the variant records structure in my specification (which was based on the corresponding structure in RFC 6066), when I was going to code the server side handling of unknown status request types. Investigating, I found that the Server Name Indication and Trusted CA extensions have the same problem, and that this will seriously affect the future expandability by these extensions. The problem occurs with records that can be used in vector records, that is sequences, when the client knows, and uses, variants of a record structure that the server does not know about, and that they cannot negotiate before sending. When the server tries to read such an unknown variant record, it will not be able to tell how much to read from the vector in order to reach the next record in the vector. As an example, in the following example structure, the client knows about Wha1 and the associated fields whatsths and whatstht, but the server does not. They both know about all the other fields and values. enum{ Foo, Bar, Wha1; } Typ struct { Typ rec_typ; Select(rec_typ) { case Foo: opaque food<1..2^8-1>; case Bar: opaque barge<1..2^16-1>; case Wha1: opaque whatsths<1..2^8-1>; opaque whatstht<1..2^16-1>; } payload; }Rec; Rec Recs<1..2^16-1>; If the client sends a Recs vector that includes a Wha1 variant, the server will not be able to read the Rec.payload field, and will likely crash or abandon the connection. Within the current framework the only way to work around this is to add a payload length field before the payload field. It is a matter of taste whether it is placed at the beginning of the record, or just before the payload, but with the placement of the payload, the entire length and payload combination can be treated as an entire opaque<> vector. This results in the following example structure enum{ Foo, Bar, Wha1; } Typ struct { Typ rec_typ; uint16 payload_length; Select(rec_typ) { case Foo: opaque food<1..2^8-1>; case Bar: opaque barge<1..2^16-1>; case Wha1: opaque whatsths<1..2^8-1>; opaque whatstht<1..2^16-1>; } payload; }Rec; Rec Recs<1..2^16-1>; The server will now be able to read the structure even if it does not know about the Wha1 alternative, since it knows how many bytes to ignore. A more elaborate example of the above can be found in the Appendix (last half) of my presentation slides at Consequences for existing, deployed extensions? IMO the currently deployed extensions, at least SNI and Trusted CA will have to be frozen in their current designs. If new functionality is needed, new extensions will have to be defined. This may affect other extensions, too. This might require an errata to be published where the problem is noted, and available actions outlined for future updates. Long term, it might be an idea to consider adding a variable record format for the vector type in TLS, alternatively, update the "Select" encoding to include a length field. These changes would have to be done in new extensions, and/or a new TLS version, and would still not be applied to records that will must be understood by older servers. Please note that I do not think that there is any such problem for the client side, *unless* the server can pick variants for vector records that are not negotiated in advance. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From marsh@extendedsubset.com Wed Mar 28 09:10:56 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDE621E82D1 for ; Wed, 28 Mar 2012 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxdMrnC+z98u for ; Wed, 28 Mar 2012 09:10:56 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3721E808F for ; Wed, 28 Mar 2012 09:10:56 -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 1SCvSZ-000M1E-Jk; Wed, 28 Mar 2012 16:10:55 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 43CEB6082; Wed, 28 Mar 2012 16:10:54 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/9HQqssYn9mKJzJJbStYhFzg5PfSTNlDo= Message-ID: <4F73380D.7050300@extendedsubset.com> Date: Wed, 28 Mar 2012 11:10:53 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Yngve N. Pettersen" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:10:56 -0000 On 03/28/2012 10:53 AM, Yngve N. Pettersen wrote: > > IMO the currently deployed extensions, at least SNI and Trusted CA will > have to be frozen in their current designs. If new functionality is > needed, new extensions will have to be defined. Would it be sufficient to declare that all new extension sub-types (i.e., the types selected by the cases) begin with a length count of a predefined length? For example, SNI http://tools.ietf.org/html/rfc4366#section-3.1 : > struct { > NameType name_type; > select (name_type) { > case host_name: HostName; > } name; > } ServerName; > > enum { > host_name(0), (255) > } NameType; > > opaque HostName<1..2^16-1>; > > struct { > ServerName server_name_list<1..2^16-1> > } ServerNameList; So if new NameType is defined, it would be required to also have a length field of uint16. - Marsh From marsh@extendedsubset.com Wed Mar 28 09:23:17 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563A521F89F9 for ; Wed, 28 Mar 2012 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbTkyjLpRoD1 for ; Wed, 28 Mar 2012 09:23:16 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC7621F89F8 for ; Wed, 28 Mar 2012 09:23:14 -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 1SCveR-0003GJ-Gj; Wed, 28 Mar 2012 16:23:11 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 63B646085; Wed, 28 Mar 2012 16:23:10 +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: U2FsdGVkX18puAsadajxBHqMjtk5fZT6B4KtUW+VjrA= Message-ID: <4F733AED.2000600@extendedsubset.com> Date: Wed, 28 Mar 2012 11:23:09 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Mohamad Badra References: <4F72771F.6050606@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:23:17 -0000 On 03/28/2012 03:39 AM, Mohamad Badra wrote: > > Weren't it possible to avoid using SCSV in rfc5746? It would definitely have slowed deployment of the security fix. > What are the > requirements to justify exceptional cases there but not here? Approximately half the world's webservers were vulnerable to a man-in-the-middle attack, sometimes quite severe. I invite you to review the full discussion in the list archives starting about here: http://www.ietf.org/mail-archive/web/tls/current/msg03928.html - Marsh From yngve@opera.com Wed Mar 28 09:44:48 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF0621E8258 for ; Wed, 28 Mar 2012 09:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8KrNl8L-15N for ; Wed, 28 Mar 2012 09:44:47 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id D243121E80F3 for ; Wed, 28 Mar 2012 09:44:46 -0700 (PDT) Received: from lessa-ii.oslo.os (dhcp-11b9.meeting.ietf.org [130.129.17.185]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2SGieLb029401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Mar 2012 16:44:43 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Marsh Ray" References: <4F73380D.7050300@extendedsubset.com> Date: Wed, 28 Mar 2012 18:44:47 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <4F73380D.7050300@extendedsubset.com> User-Agent: Opera Mail/10.62 (Win32) Cc: "tls@ietf.org" Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:44:48 -0000 On Wed, 28 Mar 2012 18:10:53 +0200, Marsh Ray wrote: > On 03/28/2012 10:53 AM, Yngve N. Pettersen wrote: >> >> IMO the currently deployed extensions, at least SNI and Trusted CA will >> have to be frozen in their current designs. If new functionality is >> needed, new extensions will have to be defined. > > Would it be sufficient to declare that all new extension sub-types > (i.e., the types selected by the cases) begin with a length count of a > predefined length? I don't know. The main question for how that would work is how a *currently* deployed server reacts when it reads an unknown variant determining enum? My guess is that it will not try to parse the variant as a field it already know, or as a vector, but will terminate reading of the extension. How aggressively it will terminate its reading is a good question; worst case it might terminate the connection, best case it will just ignore the rest of the current extension and go to the next extension. Also, reading it as a vector would require that all future additions are single vectors, not multiple sequential fields which may or may not be vectors (In the Certificate Status extension the OCSP variant is a multiple field). The only way to accomodate that would be that all sub structures must be wrapped in a vector. Some variant fields may also be fixed length, such as ints and enum, but also fixed-size vectors like the SHA1 hashes in Trusted CA; of course that can be avoided in the future, but not for integer/enum values. > For example, SNI http://tools.ietf.org/html/rfc4366#section-3.1 : > >> struct { >> NameType name_type; >> select (name_type) { >> case host_name: HostName; >> } name; >> } ServerName; >> >> enum { >> host_name(0), (255) >> } NameType; >> >> opaque HostName<1..2^16-1>; >> >> struct { >> ServerName server_name_list<1..2^16-1> >> } ServerNameList; > > So if new NameType is defined, it would be required to also have a > length field of uint16. > > - Marsh -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From ynir@checkpoint.com Wed Mar 28 13:08:20 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1509621E8109 for ; Wed, 28 Mar 2012 13:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.503 X-Spam-Level: X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y97yJbR-63sB for ; Wed, 28 Mar 2012 13:08:19 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E84E721E80F1 for ; Wed, 28 Mar 2012 13:08:12 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2SK82oS013668; Wed, 28 Mar 2012 22:08:02 +0200 X-CheckPoint: {4F736EB5-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Mar 2012 22:08:01 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 28 Mar 2012 22:08:00 +0200 From: Yoav Nir To: Marsh Ray Date: Wed, 28 Mar 2012 22:07:59 +0200 Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0NHnk2/PkOdEJTQF6wXPWUOnvpjw== Message-ID: References: <4F72771F.6050606@extendedsubset.com> <4F733AED.2000600@extendedsubset.com> In-Reply-To: <4F733AED.2000600@extendedsubset.com> 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 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:08:20 -0000 On Mar 28, 2012, at 6:23 PM, Marsh Ray wrote: > On 03/28/2012 03:39 AM, Mohamad Badra wrote: >>=20 >> Weren't it possible to avoid using SCSV in rfc5746? >=20 > It would definitely have slowed deployment of the security fix. >=20 >> What are the >> requirements to justify exceptional cases there but not here? >=20 > Approximately half the world's webservers were vulnerable to a=20 > man-in-the-middle attack, sometimes quite severe. Half? Which half wasn't? Sure, the amount of damage an attacker could do varied: the firewall that I= could power down or disable the security policy from would count as a lot = of damage, plus any case where money could be stolen, while servers where t= he attack was not exploitable (because maybe they used randomized ephemeral= paths) would count as little damage, but where there actual servers where = you could not inject a prefix? Yoav= From marsh@extendedsubset.com Wed Mar 28 13:20:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6933021E80A3 for ; Wed, 28 Mar 2012 13:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocHv49IvNsVk for ; Wed, 28 Mar 2012 13:20:57 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id EF64621E8089 for ; Wed, 28 Mar 2012 13:20:56 -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 1SCzMV-00067O-TZ; Wed, 28 Mar 2012 20:20:55 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id DC13E6085; Wed, 28 Mar 2012 20:20:53 +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: U2FsdGVkX18hP9v21LD4Lt9kZxxhIP0zOBu6VDFeNQU= Message-ID: <4F7372A2.5020603@extendedsubset.com> Date: Wed, 28 Mar 2012 15:20:50 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Yoav Nir References: <4F72771F.6050606@extendedsubset.com> <4F733AED.2000600@extendedsubset.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:20:58 -0000 On 03/28/2012 03:07 PM, Yoav Nir wrote: >> >> Approximately half the world's webservers were vulnerable to a >> man-in-the-middle attack, sometimes quite severe. > > Half? Which half wasn't? > > Sure, the amount of damage an attacker could do varied: the firewall > that I could power down or disable the security policy from would > count as a lot of damage, plus any case where money could be stolen, > while servers where the attack was not exploitable (because maybe > they used randomized ephemeral paths) would count as little damage, > but where there actual servers where you could not inject a prefix? MS IIS tended to not be vulnerable much of the time because it didn't accept client-initiated renegotiation. But it was still vulnerable when configured with client certs or certain other checkboxes were set. There are probably still other devices around where renegotiation was simply not implemented. A lot of https hosts serve nothing but static content to the public anyway and would likely not be 'vulnerable' in the strict sense. So in my head I combined IIS's less-than-half market share with a guess about a smaller percentage of other devices and web apps that were (by accident) not effectively vulnerable to come up with the ballpark figure 'half'. We could certainly come up with a better number, but why would we need it? - Marsh From ynir@checkpoint.com Wed Mar 28 13:28:46 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07DCA21F87BC for ; Wed, 28 Mar 2012 13:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.504 X-Spam-Level: X-Spam-Status: No, score=-10.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FewIDihRbown for ; Wed, 28 Mar 2012 13:28:45 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1221E21F87D6 for ; Wed, 28 Mar 2012 13:28:44 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2SKSau2017055; Wed, 28 Mar 2012 22:28:36 +0200 X-CheckPoint: {4F737387-0-1B221DC2-5FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 28 Mar 2012 22:28:36 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 28 Mar 2012 22:28:35 +0200 From: Yoav Nir To: Marsh Ray Date: Wed, 28 Mar 2012 22:28:34 +0200 Thread-Topic: [TLS] cipher suites for protecting client credentials Thread-Index: Ac0NIVkg6pe/jfVZRzaW4YjTzT+NWQ== Message-ID: References: <4F72771F.6050606@extendedsubset.com> <4F733AED.2000600@extendedsubset.com> <4F7372A2.5020603@extendedsubset.com> In-Reply-To: <4F7372A2.5020603@extendedsubset.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] cipher suites for protecting client credentials X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:28:46 -0000 On Mar 28, 2012, at 10:20 PM, Marsh Ray wrote: > On 03/28/2012 03:07 PM, Yoav Nir wrote: >>>=20 >>> Approximately half the world's webservers were vulnerable to a >>> man-in-the-middle attack, sometimes quite severe. >>=20 >> Half? Which half wasn't? >>=20 >> Sure, the amount of damage an attacker could do varied: the firewall >> that I could power down or disable the security policy from would >> count as a lot of damage, plus any case where money could be stolen, >> while servers where the attack was not exploitable (because maybe >> they used randomized ephemeral paths) would count as little damage, >> but where there actual servers where you could not inject a prefix? >=20 > MS IIS tended to not be vulnerable much of the time because it didn't=20 > accept client-initiated renegotiation. But it was still vulnerable when=20 > configured with client certs or certain other checkboxes were set. >=20 > There are probably still other devices around where renegotiation was=20 > simply not implemented. A lot of https hosts serve nothing but static=20 > content to the public anyway and would likely not be 'vulnerable' in the= =20 > strict sense. >=20 > So in my head I combined IIS's less-than-half market share with a guess=20 > about a smaller percentage of other devices and web apps that were (by=20 > accident) not effectively vulnerable to come up with the ballpark figure= =20 > 'half'. >=20 > We could certainly come up with a better number, but why would we need it= ? OK. Didn't know that about IIS. I did find that some servers implemented wi= th an old Java library didn't support renegotiation at all, but IIS is a su= rprise.= From mrex@sap.com Thu Mar 29 06:13:15 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E884321F8B29 for ; Thu, 29 Mar 2012 06:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.767 X-Spam-Level: X-Spam-Status: No, score=-9.767 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8V-SSkq3emfn for ; Thu, 29 Mar 2012 06:13:14 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B078A21F8AEA for ; Thu, 29 Mar 2012 06:13:07 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2TDD5LQ017065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2012 15:13:05 +0200 (MEST) From: Martin Rex Message-Id: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 29 Mar 2012 15:13:05 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Mar 28, 12 05:53:25 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] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 13:13:15 -0000 Yngve N. Pettersen wrote: > > If the client sends a Recs vector that includes a Wha1 variant, the server > will not be able to read the Rec.payload field, and will likely crash or > abandon the connection. A reasonable implementation would simply skip to the next TLS extension (ignoring the rest of what it didn't understand). If it crashes, it is probably an early beta version that should neither be distributed nor used in production environments... > > Within the current framework the only way to work around this is to add a > payload length field before the payload field. It is a matter of taste > whether it is placed at the beginning of the record, or just before the > payload, but with the placement of the payload, the entire length and > payload combination can be treated as an entire opaque<> vector. > > This results in the following example structure > > > enum{ > Foo, Bar, Wha1; > } Typ > > struct { > Typ rec_typ; > uint16 payload_length; > Select(rec_typ) > { > case Foo: opaque food<1..2^8-1>; > case Bar: opaque barge<1..2^16-1>; > case Wha1: > opaque whatsths<1..2^8-1>; > opaque whatstht<1..2^16-1>; > } payload; > }Rec; > > Rec Recs<1..2^16-1>; Shouldn't this more likely read enum{ Foo, Bar, Wha1, (255); } Typ struct { Typ rec_typ; Select(rec_typ) { case Foo: opaque food<1..2^8-1>; case Bar: opaque barge<1..2^16-1>; case Wha1: opaque whatsths<1..2^8-1>; opaque whatstht<1..2^16-1>; } payload<1..2^16-1>; }Rec; Rec Recs<4..2^16-1>; -Martin From yngve@opera.com Thu Mar 29 07:28:07 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC16E21E80AE for ; Thu, 29 Mar 2012 07:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.609 X-Spam-Level: X-Spam-Status: No, score=-6.609 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id araOpy1P4Gr5 for ; Thu, 29 Mar 2012 07:28:05 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8A21E804B for ; Thu, 29 Mar 2012 07:28:04 -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 q2TERwCi032272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2012 14:28:01 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> Date: Thu, 29 Mar 2012 16:28:08 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.62 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:28:07 -0000 On Thu, 29 Mar 2012 15:13:05 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> If the client sends a Recs vector that includes a Wha1 variant, the >> server >> will not be able to read the Rec.payload field, and will likely crash or >> abandon the connection. > > A reasonable implementation would simply skip to the next TLS extension > (ignoring the rest of what it didn't understand). If it crashes, > it is probably an early beta version that should neither be distributed > nor > used in production environments... Counterargument: SSL v3 and TLS 1.0+ required servers to ignore Client Hello content following the compression field. As we all know, a large number of servers did not implement it that way, causing the handshakes to fail. Similar problem exists for the version indication. Maybe I am being pessimistic, but I am concerned about the possibility that implementations of the affected variants records will have failed in similar fashions. Only an extensive and detailed review of what existing implementations do will reveal what has been implemented. >> >> Within the current framework the only way to work around this is to add >> a >> payload length field before the payload field. It is a matter of taste >> whether it is placed at the beginning of the record, or just before the >> payload, but with the placement of the payload, the entire length and >> payload combination can be treated as an entire opaque<> vector. >> >> This results in the following example structure >> >> >> enum{ >> Foo, Bar, Wha1; >> } Typ >> >> struct { >> Typ rec_typ; >> uint16 payload_length; >> Select(rec_typ) >> { >> case Foo: opaque food<1..2^8-1>; >> case Bar: opaque barge<1..2^16-1>; >> case Wha1: >> opaque whatsths<1..2^8-1>; >> opaque whatstht<1..2^16-1>; >> } payload; >> }Rec; >> >> Rec Recs<1..2^16-1>; > > > Shouldn't this more likely read The syntax below is AFAIK currently not supported by RFC 5246, and this is IMO clearly indicated by the fact that similar variant records in TLS, such as Handshake and the Record Protocol records, are not coded in that fashion, but the one I am using above. Extending the syntax might be an option, but at present I don't think it is realistic. > > enum{ > Foo, Bar, Wha1, (255); > } Typ > > struct { > Typ rec_typ; > Select(rec_typ) > { > case Foo: opaque food<1..2^8-1>; > case Bar: opaque barge<1..2^16-1>; > case Wha1: > opaque whatsths<1..2^8-1>; > opaque whatstht<1..2^16-1>; > } payload<1..2^16-1>; > }Rec; > > Rec Recs<4..2^16-1>; > > > > -Martin -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From marsh@extendedsubset.com Thu Mar 29 07:39:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9949721F88D4 for ; Thu, 29 Mar 2012 07:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7pkc5w1O3LA for ; Thu, 29 Mar 2012 07:39:53 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 28C7121F8885 for ; Thu, 29 Mar 2012 07:39:53 -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 1SDGW0-0002O9-Lk; Thu, 29 Mar 2012 14:39:52 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id CC2516085; Thu, 29 Mar 2012 14:39:50 +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/5NjBv+nmirbMyK1e0YDp4IeYIkCgNpCc= Message-ID: <4F747436.2030400@extendedsubset.com> Date: Thu, 29 Mar 2012 09:39:50 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: mrex@sap.com References: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> In-Reply-To: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:39:54 -0000 On 03/29/2012 08:13 AM, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> If the client sends a Recs vector that includes a Wha1 variant, the server >> will not be able to read the Rec.payload field, and will likely crash or >> abandon the connection. > > A reasonable implementation would simply skip to the next TLS extension > (ignoring the rest of what it didn't understand). If it crashes, > it is probably an early beta version that should neither be distributed nor > used in production environments... So now there's an ordering dependency on the payload records. All records that the server doesn't understand must come after all the records that the server needs to process. There are many other places where TLVs are defined in IETF protocols. Surely they require a consistent format for T and L for any given context? If I were an implementor trying to code from this spec, I would probably look at the payload field and think "Well, the only way this is gonna work is if all future extensions have the same length to their payload length as well. I'll infer that to be the case and yet be sure to check if the length I interpret implies the end outside of the extension." That's the number one rule of extensible record formats: at least fix the length field in advance so receivers can know how to skip the stuff they don't understand. - Marsh From Peter.Sylvester@edelweb.fr Thu Mar 29 08:00:36 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B838A21E81E5 for ; Thu, 29 Mar 2012 08:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPtfNKnvFn2Q for ; Thu, 29 Mar 2012 08:00:34 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id AA53421E81DD for ; Thu, 29 Mar 2012 08:00:32 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id 0E7A57D89 for ; Thu, 29 Mar 2012 17:00:25 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 763A0781D72 for ; Thu, 29 Mar 2012 16:21:48 +0200 (CEST) Received: from [130.129.23.18] (dhcp-1712.meeting.ietf.org [130.129.23.18]) by smtps.on-x.com (Postfix) with ESMTPSA id BE444236369 for ; Thu, 29 Mar 2012 10:57:04 -0400 (EDT) Message-ID: <4F747907.4000201@edelweb.fr> Date: Thu, 29 Mar 2012 17:00:23 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: tls@ietf.org References: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:00:36 -0000 On 03/29/2012 04:28 PM, Yngve N. Pettersen wrote: > On Thu, 29 Mar 2012 15:13:05 +0200, Martin Rex wrote: > >> Yngve N. Pettersen wrote: >>> >>> If the client sends a Recs vector that includes a Wha1 variant, the >>> server >>> will not be able to read the Rec.payload field, and will likely >>> crash or >>> abandon the connection. >> >> A reasonable implementation would simply skip to the next TLS extension >> (ignoring the rest of what it didn't understand). If it crashes, >> it is probably an early beta version that should neither be >> distributed nor >> used in production environments... ually With the ServerNameIndication this can create problems. The current spec provides for a list of names, some of them may not be recognizable. If one wants to be able to skip unknown names and still recognize good ones, it would be dangerous to put new names in the fronnt Openssl actually assumes that any opaque servername value has two octets length. and skips through that ... Peter From Peter.Sylvester@edelweb.fr Thu Mar 29 08:02:29 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3A21F858F for ; Thu, 29 Mar 2012 08:02: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=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld2KN94PvuZP for ; Thu, 29 Mar 2012 08:02:29 -0700 (PDT) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4371921F858D for ; Thu, 29 Mar 2012 08:02:29 -0700 (PDT) Received: from varuna.puteaux.on-x (varuna.puteaux.on-x [192.168.10.6]) by mx1.on-x.com (Postfix) with ESMTP id A0FCC7D89 for ; Thu, 29 Mar 2012 17:02:28 +0200 (CEST) Received: from smtps.on-x.com (mintaka.puteaux.on-x [192.168.14.11]) by varuna.puteaux.on-x (Postfix) with ESMTP id 66B81781E5F for ; Thu, 29 Mar 2012 16:23:52 +0200 (CEST) Received: from [130.129.23.18] (dhcp-1712.meeting.ietf.org [130.129.23.18]) by smtps.on-x.com (Postfix) with ESMTPSA id B743C236369 for ; Thu, 29 Mar 2012 10:59:08 -0400 (EDT) Message-ID: <4F747983.4020601@edelweb.fr> Date: Thu, 29 Mar 2012 17:02:27 +0200 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: tls@ietf.org References: <201203291313.q2TDD5FX004235@fs4113.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:02:30 -0000 > Maybe I am being pessimistic, but I am concerned about the possibility > that implementations of the affected variants records will have failed > in similar fashions. Only an extensive and detailed review of what > existing implementations do will reveal what has been implemented. Yes. From mike-list@pobox.com Thu Mar 29 11:18:51 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721F921F88AF for ; Thu, 29 Mar 2012 11:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRhelvVSKdG1 for ; Thu, 29 Mar 2012 11:18:50 -0700 (PDT) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [74.115.168.62]) by ietfa.amsl.com (Postfix) with ESMTP id D394321F88AD for ; Thu, 29 Mar 2012 11:18:48 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 1ABE89B08; Thu, 29 Mar 2012 14:18:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=NSU7467cEa6s ek3M5jCbzIFxLuo=; b=NVMdHgXrCuJM7Tifcuz1+xXD/HG5b8ZqfgH9hdnt5Vwt NC71/MslyhuXgdt6dNhcsldt6BKnCnaztmNJJopHMJoojkGbylZTiXW7V+3FRfGN 28XEbTbkFl2izlaq535QD5li/wM9Q3SouzuhNwZ2kaCTY47js/iNM608/w4JC04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Bsoli3 71kvHjDMSZMUd/gbQpp/YFC/vqaHtouWNyHy34/q/ULHtGDlq6NU1K4rdzHsMy2u HxvukKoxPo0Txvo3F344UAIhptuoIXKuXxtRoktLRp1K7I0JTf5mcCCnFEcnk9yI ytmn4RYCe34OhRP5rZAsB344ar+WpTw19GPz8= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 13E209B06; Thu, 29 Mar 2012 14:18:47 -0400 (EDT) Received: from iMac.local (unknown [68.224.233.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 3791C9B05; Thu, 29 Mar 2012 14:18:46 -0400 (EDT) Message-ID: <4F74A785.30301@pobox.com> Date: Thu, 29 Mar 2012 11:18:45 -0700 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Yngve N. Pettersen" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 9FCD58DA-79CB-11E1-8922-65B1DE995924-38729857!a-pb-sasl-sd.pobox.com Cc: "tls@ietf.org" Subject: Re: [TLS] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:18:51 -0000 This problem was discussed several years ago w.r.t. the SNI extension. Please see: http://www6.ietf.org/mail-archive/web/tls/current/msg02663.html http://www6.ietf.org/mail-archive/web/tls/current/msg02664.html Perhaps we need to update our notation to add a length-prefixed variant record to be used wherever needed in the future. That shouldn't affect backward-compatibility since only new protocol elements and extensions would use it. Mike Yngve N. Pettersen wrote: > Hi, > > As mentioned during my presentation at the TLS WG meeting today, when > implementing my multiple OCSP stapling specification I encountered a > problem with the variant records structure in my specification (which > was based on the corresponding structure in RFC 6066), when I was going > to code the server side handling of unknown status request types. > > Investigating, I found that the Server Name Indication and Trusted CA > extensions have the same problem, and that this will seriously affect > the future expandability by these extensions. > > The problem occurs with records that can be used in vector records, that > is sequences, when the client knows, and uses, variants of a record > structure that the server does not know about, and that they cannot > negotiate before sending. > > When the server tries to read such an unknown variant record, it will > not be able to tell how much to read from the vector in order to reach > the next record in the vector. > > As an example, in the following example structure, the client knows > about Wha1 and the associated fields whatsths and whatstht, but the > server does not. They both know about all the other fields and values. > > enum{ > Foo, Bar, Wha1; > } Typ > > struct { > Typ rec_typ; > Select(rec_typ) > { > case Foo: opaque food<1..2^8-1>; > case Bar: opaque barge<1..2^16-1>; > case Wha1: > opaque whatsths<1..2^8-1>; > opaque whatstht<1..2^16-1>; > } payload; > }Rec; > > Rec Recs<1..2^16-1>; > > If the client sends a Recs vector that includes a Wha1 variant, the > server will not be able to read the Rec.payload field, and will likely > crash or abandon the connection. > > Within the current framework the only way to work around this is to add > a payload length field before the payload field. It is a matter of taste > whether it is placed at the beginning of the record, or just before the > payload, but with the placement of the payload, the entire length and > payload combination can be treated as an entire opaque<> vector. > > This results in the following example structure > > > enum{ > Foo, Bar, Wha1; > } Typ > > struct { > Typ rec_typ; > uint16 payload_length; > Select(rec_typ) > { > case Foo: opaque food<1..2^8-1>; > case Bar: opaque barge<1..2^16-1>; > case Wha1: > opaque whatsths<1..2^8-1>; > opaque whatstht<1..2^16-1>; > } payload; > }Rec; > > Rec Recs<1..2^16-1>; > > > The server will now be able to read the structure even if it does not > know about the Wha1 alternative, since it knows how many bytes to ignore. > > A more elaborate example of the above can be found in the Appendix (last > half) of my presentation slides at > > > Consequences for existing, deployed extensions? > > IMO the currently deployed extensions, at least SNI and Trusted CA will > have to be frozen in their current designs. If new functionality is > needed, new extensions will have to be defined. > > This may affect other extensions, too. > > This might require an errata to be published where the problem is noted, > and available actions outlined for future updates. > > Long term, it might be an idea to consider adding a variable record > format for the vector type in TLS, alternatively, update the "Select" > encoding to include a length field. These changes would have to be done > in new extensions, and/or a new TLS version, and would still not be > applied to records that will must be understood by older servers. > > Please note that I do not think that there is any such problem for the > client side, *unless* the server can pick variants for vector records > that are not negotiated in advance. > > > From mrex@sap.com Thu Mar 29 11:19:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32E421F88AF for ; Thu, 29 Mar 2012 11:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCWD+TJA7yDo for ; Thu, 29 Mar 2012 11:19:57 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E092D21F88AD for ; Thu, 29 Mar 2012 11:19:56 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q2TIJttx000780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2012 20:19:55 +0200 (MEST) From: Martin Rex Message-Id: <201203291819.q2TIJstB021782@fs4113.wdf.sap.corp> To: yngve@opera.com (Yngve N. Pettersen) Date: Thu, 29 Mar 2012 20:19:54 +0200 (MEST) In-Reply-To: from "Yngve N. Pettersen" at Mar 29, 12 04:28:08 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] Backwards compatilbility problem with variant recordsa X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:19:58 -0000 Yngve N. Pettersen wrote: > > On Thu, 29 Mar 2012 15:13:05 +0200, Martin Rex wrote: > > > > Yngve N. Pettersen wrote: > >> > >> If the client sends a Recs vector that includes a Wha1 variant, the > >> server > >> will not be able to read the Rec.payload field, and will likely crash or > >> abandon the connection. > > > > A reasonable implementation would simply skip to the next TLS extension > > (ignoring the rest of what it didn't understand). If it crashes, > > it is probably an early beta version that should neither be distributed > > nor used in production environments... > > Counterargument: SSL v3 and TLS 1.0+ required servers to ignore Client > Hello content following the compression field. As we all know, a large > number of servers did not implement it that way, causing the handshakes to > fail. Similar problem exists for the version indication. No, the problem here was that the SSLv3 spec was retroactively changed, and neither was that change clearly communicated, nor was an updated SSLv3 spec prominently published and all prior variants of the SSLv3 spec without that backwards-incompatible change killed! > > Maybe I am being pessimistic, but I am concerned about the possibility > that implementations of the affected variants records will have failed in > similar fashions. Only an extensive and detailed review of what existing > implementations do will reveal what has been implemented. I agree that this ambiguity must be expected to cause interop problems (in the fashion that new name types inserted by clients may cause servers to entirely ignore the extension although the very same server would understand a traditional TLS extension SNI. There is a certain likelyhood that for servers that need SNI badly to pick the right cert, this would likely cause clients to barf on the server picking the wrong cert when not understanding fancy names sent by the client. What I do not understand is (a) servers crashing and (b) servers aborting the handshake. It just does not make sense. What confuses me here is that so many folks claim to have implemented and shipped TLS extension SNI (and the RFC went through 2 revs!!), and you're the first implementor to point out that there is a problem with that part of the spec. If there is an ambiguity, then it is crystal clear from the spec and it is impossible for a sensible implementor to MISS that fact and request clarification. I'm disappointed. I would really appreciate implementors to pay more attention and point out problems that they encounter. The IETF mantra is "running code", and that does not include "crashing code". > > The syntax below is AFAIK currently not supported by RFC 5246, and this is > IMO clearly indicated by the fact that similar variant records in TLS, > such as Handshake and the Record Protocol records, are not coded in that > fashion, but the one I am using above. > > Extending the syntax might be an option, but at present I don't think it > is realistic. Where does rfc5246 say that variants (section 4.6.1) being a variation of Constructed type (section 4.6) can not be defined as variable length vectors (section 4.3)? Just because there is no current example / usage of this in the spec, I do not see anything that could be interpreted to preclude this. -Martin From mrex@sap.com Thu Mar 29 11:35:05 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F8421E8145 for ; Thu, 29 Mar 2012 11:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.065 X-Spam-Level: X-Spam-Status: No, score=-10.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii9oihAV5Ess for ; Thu, 29 Mar 2012 11:35:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 115BD21E80CA for ; Thu, 29 Mar 2012 11:35:04 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q2TIZ2ME016802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Mar 2012 20:35:02 +0200 (MEST) From: Martin Rex Message-Id: <201203291835.q2TIZ115022644@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Thu, 29 Mar 2012 20:35:01 +0200 (MEST) In-Reply-To: <4F74A785.30301@pobox.com> from "Michael D'Errico" at Mar 29, 12 11:18:45 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] Backwards compatilbility problem with variant records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:35:06 -0000 Michael D'Errico wrote: > > This problem was discussed several years ago w.r.t. the SNI > extension. Please see: > > http://www6.ietf.org/mail-archive/web/tls/current/msg02663.html > http://www6.ietf.org/mail-archive/web/tls/current/msg02664.html > > Perhaps we need to update our notation to add a length-prefixed > variant record to be used wherever needed in the future. That > shouldn't affect backward-compatibility since only new protocol > elements and extensions would use it. OK, I see. There was text added to rfc6066 recognizing the problem and suggesting the workaround that was proposed in 2008: http://tools.ietf.org/html/rfc6066#page-7 2nd paragraph: Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document). The data structure associated with the host_name NameType is a variable-length vector that begins with a 16-bit length. For backward compatibility, all future data structures associated with new NameTypes MUST begin with a 16-bit length field. TLS MAY treat provided server names as opaque data and pass the names and types to the application. I agree with Yngve in respect to document updates not magically fixing the installed base. But the suggested workaround is really an approach that a sensible implementation should be able to cope with, and those quick'n'dirty hacks probably have more serious problems than this, so that they will have to be regularly updated anyway... -Martin From yngve@opera.com Thu Mar 29 12:16:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87B21E808E for ; Thu, 29 Mar 2012 12:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16k7a7fH14Op for ; Thu, 29 Mar 2012 12:16:58 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 511AE21E801B for ; Thu, 29 Mar 2012 12:16:57 -0700 (PDT) Received: from lessa-ii.oslo.os (dhcp-4397.meeting.ietf.org [130.129.67.151]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2TJGsLr030307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Mar 2012 19:16:56 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Martin Rex" References: <201203291819.q2TIJstB021782@fs4113.wdf.sap.corp> Date: Thu, 29 Mar 2012 21:17:05 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Organization: Opera Software ASA Message-ID: In-Reply-To: <201203291819.q2TIJstB021782@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.62 (Win32) Cc: tls@ietf.org Subject: Re: [TLS] Backwards compatilbility problem with variant recordsa X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 19:16:59 -0000 On Thu, 29 Mar 2012 20:19:54 +0200, Martin Rex wrote: > Yngve N. Pettersen wrote: >> >> On Thu, 29 Mar 2012 15:13:05 +0200, Martin Rex wrote: >> > >> > Yngve N. Pettersen wrote: >> >> >> >> If the client sends a Recs vector that includes a Wha1 variant, the >> >> server >> >> will not be able to read the Rec.payload field, and will likely >> crash or >> >> abandon the connection. >> > >> > A reasonable implementation would simply skip to the next TLS >> extension >> > (ignoring the rest of what it didn't understand). If it crashes, >> > it is probably an early beta version that should neither be >> distributed >> > nor used in production environments... >> >> Counterargument: SSL v3 and TLS 1.0+ required servers to ignore Client >> Hello content following the compression field. As we all know, a large >> number of servers did not implement it that way, causing the handshakes >> to >> fail. Similar problem exists for the version indication. > > No, the problem here was that the SSLv3 spec was retroactively changed, > and neither was that change clearly communicated, nor was an updated > SSLv3 spec prominently published and all prior variants of the SSLv3 > spec without that backwards-incompatible change killed! Most of the TLS Extension intolerant servers support TLS 1.0 as their highest version, not SSL v3. TLS 1.0, at least, is clear on this point. The most common failure scenario, as I recall, is that the connection is closed. > >> >> Maybe I am being pessimistic, but I am concerned about the possibility >> that implementations of the affected variants records will have failed >> in >> similar fashions. Only an extensive and detailed review of what existing >> implementations do will reveal what has been implemented. > > I agree that this ambiguity must be expected to cause interop problems > (in the fashion that new name types inserted by clients may cause servers > to entirely ignore the extension although the very same server would > understand a traditional TLS extension SNI. > > There is a certain likelyhood that for servers that need SNI badly > to pick the right cert, this would likely cause clients to barf on the > server picking the wrong cert when not understanding fancy names > sent by the client. > > What I do not understand is (a) servers crashing and (b) servers aborting > the handshake. It just does not make sense. > > > What confuses me here is that so many folks claim to have implemented > and shipped TLS extension SNI (and the RFC went through 2 revs!!), > and you're the first implementor to point out that there is a problem > with that part of the spec. Turns out I wasn't the first to discover the problem space. > If there is an ambiguity, then it is crystal clear from the spec and > it is impossible for a sensible implementor to MISS that fact and > request clarification. I'm disappointed. I would really appreciate > implementors to pay more attention and point out problems that they > encounter. > > The IETF mantra is "running code", and that does not include "crashing > code". "Running code" does not necessarily mean that it has been tested with unexpected, but valid data. As it was, the reason I (re)discovered the issue was that I was thinking specifically about how to parse and ignore an item with an unknown type when I was implementing a prototype decoder. If I had only followed the structure layout and coding exactly that, I might not have thought about future changes to the structure. > >> >> The syntax below is AFAIK currently not supported by RFC 5246, and this >> is >> IMO clearly indicated by the fact that similar variant records in TLS, >> such as Handshake and the Record Protocol records, are not coded in that >> fashion, but the one I am using above. >> >> Extending the syntax might be an option, but at present I don't think it >> is realistic. > > Where does rfc5246 say that variants (section 4.6.1) being a > variation of Constructed type (section 4.6) can not be defined as > variable > length vectors (section 4.3)? Just because there is no current > example / usage of this in the spec, I do not see anything that could > be interpreted to preclude this. The variant you suggest may make sense, but at present there is AFAIK no example of the Select construct being used in that fashion. I'd just prefer to have the example in the text of the protocol specification first, rather than adding it in a related specification. Even struct foo vectors are IIRC first declared as a structure type, then the typename is used to declare the vector. Select constructors are not type definitions, they are field definitions, which may be one reason why your construct have not been considered. Another reason it may not have been considered is that the <> vector construct is meant for *repeated* structures of the same type, not a single item of of a structure with variant length. To avoid confusion I would think that such a length determined variant construct should have a special name and/or textual representation that is different from the <> and [] constructs. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ********************************************************************