From d.sturek@att.net Thu Jan 6 06:35:08 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22DA93A6E1E for ; Thu, 6 Jan 2011 06:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[AWL=-1.065, BAYES_50=0.001, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH0K0IxFIvpV for ; Thu, 6 Jan 2011 06:35:04 -0800 (PST) Received: from smtp104.sbc.mail.ne1.yahoo.com (smtp104.sbc.mail.ne1.yahoo.com [98.138.84.215]) by core3.amsl.com (Postfix) with SMTP id 9DA3F3A6D3C for ; Thu, 6 Jan 2011 06:35:03 -0800 (PST) Received: (qmail 96895 invoked from network); 6 Jan 2011 14:37:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1294324630; bh=sroGfBW+6B2EF+eAn+PH2JG898Nxrzrl1Tz+K5g1CJk=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=2T5DJeNvm2s36AFzDRds4dyDzMVS4eXu6Lcwz+9NpRWjgwnoHjYzARCRCyInXrEuYDcSZ/BmybGsGFqt6q1tVrZ6L4CS5eUP4YCM6CZo9+idS9mYM/dgS7hO1KKOoG67kG2FYLt1saUrhDWiIJUXoDEQfYJE7bXG+/Ya5c6ct7Q= Received: from Studio (d.sturek@69.108.48.164 with login) by smtp104.sbc.mail.ne1.yahoo.com with SMTP; 06 Jan 2011 06:37:06 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: N2Y55O8VM1ktRTKfs1C.nikIBWKw4LY7htQRTpBEraT3KCI 9p6Q1PhdORsraw3lVcDLVebeOBY1EVDs_5MZv3oCVZufNp_dLquaMRcXRBAO C3cq_AkpUU1MUGFWrH7AROHPwIAydLEjRKKVXmp3m3Pi4bTaqs1FB4Z141n9 RBiQkjibA7ahWS4jQxhi_fkgDqfC6nIY4O6vrnW9LF5x2pwlJaNlCqDejAgu RlJcldqJfqy5TU6BBBB6icTZZ0hdlXo9PkVCO4P4w0i7WTgBSBGlQmFILqed 26rjyIedBAH9bBplMW8QU7kThqUh1HETpkE7uB8oaVIZiGQf0vWSGKcEPISb LBjjaJPZs_m3F7EqfT.q7p_ywU3Yf3UawBjg49gw- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: Date: Thu, 6 Jan 2011 06:36:59 -0800 Message-ID: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01CBAD6C.1FBFD550" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutryzjntI4kMGsQUurGynU7AP4LQ== Content-Language: en-us Subject: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "This is the mailing list 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, 06 Jan 2011 14:35:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_008E_01CBAD6C.1FBFD550 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I wanted to bring up the draft presented by David McGrew last July (in Maastricht) one more time. The draft (now expired I think) is "AES-CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00. I know there was a thread last summer on this. I am part of the ZigBee Alliance implementing TLS for an IEEE 802.15.4 application. We would like the TLS group to consider (or maybe re-consider though I never saw any formal disposition of this on the reflector) the use of David's draft for IEEE 802.15.4 networks. I think CCM is a common cipher suite for IEEE802 and this draft matches what is specified in IEEE (and implemented in hardware in millions of devices). Thanks, Don Sturek ------=_NextPart_000_008E_01CBAD6C.1FBFD550 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I wanted to bring = up the draft presented by David McGrew last July (in Maastricht) one = more time.  The draft (now expired I think) is  "AES-CCM = ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- = ecc-00.

 

I know there was = a thread last summer on this.  I am part of the ZigBee Alliance = implementing TLS for an IEEE 802.15.4 application.   We would = like the TLS group to consider (or maybe re-consider though I never saw = any formal disposition of this on the reflector) the use of = David’s draft for IEEE 802.15.4 = networks.

 

I think CCM is a = common cipher suite for IEEE802 and this draft matches what is specified = in IEEE (and implemented in hardware in millions of = devices).

 

Thanks,


Don = Sturek

 

------=_NextPart_000_008E_01CBAD6C.1FBFD550-- From agl@google.com Thu Jan 6 06:42:22 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9250D3A6F1F for ; Thu, 6 Jan 2011 06:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.662 X-Spam-Level: X-Spam-Status: No, score=-102.662 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJZuZW0IcMDw for ; Thu, 6 Jan 2011 06:42:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9E6733A6F19 for ; Thu, 6 Jan 2011 06:42:21 -0800 (PST) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p06EiMDO032491 for ; Thu, 6 Jan 2011 06:44:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294325068; bh=9eICSikKoaj2BqL9apH/478K5Dk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TesxSMmlZR2tdXwQtahl82i49xeqRoXhgkZcvtpo9qGelgZTAMhKq4rvkf/2N4z9X fXME1Hk4kGg2M0MN6VH7w== Received: from iyj17 (iyj17.prod.google.com [10.241.51.81]) by hpaq13.eem.corp.google.com with ESMTP id p06EiHC2018773 for ; Thu, 6 Jan 2011 06:44:21 -0800 Received: by iyj17 with SMTP id 17so15387885iyj.28 for ; Thu, 06 Jan 2011 06:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9EJBcQvTP0Y+9zj+MpEKsWbXCQEHNbKPXMmA8IwzZPY=; b=NHYWFSat24fX6IMEiJWzvJYUVdeT/B7T53BKVam2009hEG+68xNdZ8j6N07CqpJaX/ 3IF895A12wzg+jD1wFPA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QpsScJDf7Wpwjv+yp/SziNhjbtQf3G3HxPrvnnZ3+LXNbmrgVF29ZsKCf3+MAZprlA Lyz3+16zTpUZwJdRy84Q== MIME-Version: 1.0 Received: by 10.231.176.75 with SMTP id bd11mr8367841ibb.49.1294325060946; Thu, 06 Jan 2011 06:44:20 -0800 (PST) Received: by 10.231.16.193 with HTTP; Thu, 6 Jan 2011 06:44:20 -0800 (PST) In-Reply-To: <-9154083263273522078@unknownmsgid> References: <-9154083263273522078@unknownmsgid> Date: Thu, 6 Jan 2011 09:44:20 -0500 Message-ID: From: Adam Langley To: d.sturek@att.net Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 06 Jan 2011 14:42:22 -0000 On Thu, Jan 6, 2011 at 9:36 AM, Don Sturek wrote: > I think CCM is a common cipher suite for IEEE802 and this draft matches what > is specified in IEEE (and implemented in hardware in millions of devices). Although I think that GCM already covers this case, I don't feel that the WG should dictate what ciphersuites people can use with TLS. Since CCM mode is clearly reasonable and the request is made in good faith I support the speedy passage of such drafts. AGL From housley@vigilsec.com Thu Jan 6 06:43:09 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619A53A6F17 for ; Thu, 6 Jan 2011 06:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.354 X-Spam-Level: X-Spam-Status: No, score=-102.354 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E+LF7gYu2y1 for ; Thu, 6 Jan 2011 06:43:08 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 71F713A6F16 for ; Thu, 6 Jan 2011 06:43:08 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 664A29A47C2; Thu, 6 Jan 2011 09:45:29 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 4S8qmaGP7fg5; Thu, 6 Jan 2011 09:45:09 -0500 (EST) Received: from new-host.home (pool-96-231-58-190.washdc.fios.verizon.net [96.231.58.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id F2F7A9A47BE; Thu, 6 Jan 2011 09:45:27 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2-337818841 From: Russ Housley In-Reply-To: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> Date: Thu, 6 Jan 2011 09:45:14 -0500 Message-Id: <8BA5BA22-A7FC-4465-938B-D5BAF49EBDA6@vigilsec.com> References: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 06 Jan 2011 14:43:09 -0000 --Apple-Mail-2-337818841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am willing to work with David McGrew on this document if there is WG = interest in producing an RFC for this ciphersuite. Russ On Jan 6, 2011, at 9:36 AM, Don Sturek wrote: > =20 > I wanted to bring up the draft presented by David McGrew last July (in = Maastricht) one more time. The draft (now expired I think) is "AES-CCM = ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00. > =20 > I know there was a thread last summer on this. I am part of the = ZigBee Alliance implementing TLS for an IEEE 802.15.4 application. We = would like the TLS group to consider (or maybe re-consider though I = never saw any formal disposition of this on the reflector) the use of = David=92s draft for IEEE 802.15.4 networks. > =20 > I think CCM is a common cipher suite for IEEE802 and this draft = matches what is specified in IEEE (and implemented in hardware in = millions of devices). > =20 > Thanks, >=20 > Don Sturek --Apple-Mail-2-337818841 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = willing to work with David McGrew on this document if there is WG = interest in producing an RFC for this = ciphersuite.

Russ


On Jan 6, 2011, at 9:36 AM, Don Sturek wrote:

I wanted to bring up = the draft presented by David McGrew last July (in Maastricht) one more = time.  The draft (now expired I think) is  "AES-CCM ECC Cipher = Suites for TLS", draft-mcgrew-tls-aes-ccm- = ecc-00.
I know there was a = thread last summer on this.  I am part of the ZigBee Alliance = implementing TLS for an IEEE 802.15.4 application.   We would = like the TLS group to consider (or maybe re-consider though I never saw = any formal disposition of this on the reflector) the use of David=92s = draft for IEEE 802.15.4 networks.
 
 

Don = Sturek
<= br>= --Apple-Mail-2-337818841-- From juhovh@iki.fi Thu Jan 6 06:50:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1B2C3A6F16 for ; Thu, 6 Jan 2011 06:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_HELO_EQ_DSL_3=1.022, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDkkRV4WUKZl for ; Thu, 6 Jan 2011 06:50:49 -0800 (PST) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id 8D4733A6F02 for ; Thu, 6 Jan 2011 06:50:48 -0800 (PST) Received: from smtp.vaha-herttua.fi (88.192.241.223) by jenni2.inet.fi (8.5.133) id 4D061FFC00C6AE72; Thu, 6 Jan 2011 16:52:53 +0200 Received: from dsl-hkibrasgw3-ffffc000-19.dhcp.inet.fi (dsl-hkibrasgw3-ffffc000-19.dhcp.inet.fi [88.192.255.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id A52281FCFE; Thu, 6 Jan 2011 16:52:57 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-1-338275942; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> Date: Thu, 6 Jan 2011 16:52:51 +0200 Message-Id: References: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> To: tls@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 06 Jan 2011 14:50:51 -0000 --Apple-Mail-1-338275942 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 6.1.2011, at 16.36, Don Sturek wrote: > I wanted to bring up the draft presented by David McGrew last July (in = Maastricht) one more time. The draft (now expired I think) is "AES-CCM = ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00. > =20 > I know there was a thread last summer on this. I am part of the = ZigBee Alliance implementing TLS for an IEEE 802.15.4 application. We = would like the TLS group to consider (or maybe re-consider though I = never saw any formal disposition of this on the reflector) the use of = David=92s draft for IEEE 802.15.4 networks. The discussion thread can be seen in = http://www.ietf.org/mail-archive/web/tls/current/msg06716.html and the = main problems are pretty much mentioned in the later post = http://www.ietf.org/mail-archive/web/tls/current/msg06761.html Basically the proposed draft should probably be divided into smaller = parts. One part would define the AES-CCM cipher suites in a way that = would be interoperable with existing TLS cipher suites. Another part = would describe the use of TLS and AES-CCM in IEEE 802.15.4 networks, = including forbidding the use of other than ECDSA certificates and = forbidding the elliptic_curves and ec_point_formats extension. > I think CCM is a common cipher suite for IEEE802 and this draft = matches what is specified in IEEE (and implemented in hardware in = millions of devices). =46rom what I can tell, the draft was not interoperable with existing = cipher suites for no apparent reason (other than that's how ZigBee uses = it). But if that can be fixed then there should be no problem including = AES-CCM in TLS. Juho --Apple-Mail-1-338275942 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMTA2MTQ1MjUyWjAjBgkqhkiG9w0BCQQxFgQUUG0UtfQA+vC6b/N5E4+ynhdwZa0wgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEAJ326y2MM6Anxh4nmP9/rs6GQkuNrF6+jhpes/Moab5vIZeua6cylU0EikVdaTfFoR6AH SrogTfDwHX6VUUGabVPXsrVeUbOpNTtyT1apR/8+0B981ZM0SBp3x1ANdOnh0vc1fI+EZSQhsjGc 58wGSftuSG2YxO8ulNAX6yuKaRTFchfGr5IcxzGtQoFLz6RmvKaTVAHzjAwmxAsipgLn3TSYL9N3 iyYpEFUzYHNsX3jyIXogYFp34dMGrlTRqKZuVBTAq+5gj9viresSTk3eRBRQu5D1c1X9y9W0T1Dj P+i4J2dZcCVjsX/wJi11EBZAIj9VUJXg1lt58tR9v2YaewAAAAAAAA== --Apple-Mail-1-338275942-- From d.sturek@att.net Thu Jan 6 07:07:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393D83A6E28 for ; Thu, 6 Jan 2011 07:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1.449, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9zMQYB1-n9l for ; Thu, 6 Jan 2011 07:07:37 -0800 (PST) Received: from smtp105.sbc.mail.ne1.yahoo.com (smtp105.sbc.mail.ne1.yahoo.com [98.138.84.183]) by core3.amsl.com (Postfix) with SMTP id DE0F03A6C29 for ; Thu, 6 Jan 2011 07:07:36 -0800 (PST) Received: (qmail 62580 invoked from network); 6 Jan 2011 15:09:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1294326580; bh=j69wk2Jt/4sIhrEz6xNOWIRGr1ZYkB6Yo/3ZN4M9+ZA=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=HXlfZFYgaUQy3RQWqxS9yLcGciq2J9N0x6VhVvhT/1FtPPDshT+Utz4RMqAnINjVif/MVhvnZ3aOGWilrRRp6CDuMkoaIKkQWGcbUkD5hSmVOgbRtU30kF7WD+C7kqSLtwkeIhaP2C+BfD02HsMOmz8Xp7f6rsTgYqyHubZcGHY= Received: from Studio (d.sturek@69.108.48.164 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 06 Jan 2011 07:09:37 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: WjUKFmkVM1mhsKldzYcAPvEy9ndxabdtPKMjKvJh9fgpbPW VaLxYvcO1P2B.B2sa.utDtesekdvBsxooU0xTf89JucVoVbIHpR7DjlFxOm3 N9DtADPBVsVJy6Pppb1KH6CQWNHIHjSaIv6XhWZ1MqQPCUEFGViLgrrFN3aY mIkicnVdNyjcuyfyJ19o2iifAQqHULq3kgbULX6jIXEIOqXXan1oK4QUnNqH 3lLSjhAUOF92n4VanHD7kszdPCAL7RMVZjD9.WDBJbGDfth2nDzepbGqi7qB 0h1Y7w2_APYxQfd5p.X6DrrMqaYegQAhu0TKHLtmhSKlNyBBMqHT5fSz2dR7 ZRDwr X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: =?iso-8859-1?Q?'Juho_V=E4h=E4-Herttua'?= , References: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> In-Reply-To: Date: Thu, 6 Jan 2011 07:09:28 -0800 Message-ID: <00aa01cbadb3$b7c95f50$275c1df0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcutsWXdg1SoEO7NTkWcxjnF0acL9AAAMcGg Content-Language: en-us Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: "This is the mailing list 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, 06 Jan 2011 15:07:38 -0000 Hi Juho, On your very last sentence, could you elaborate on why you think the = draft is not interoperable with other cipher suites? I think topics like = those discussed in this part of the thread (http://www.ietf.org/mail-archive/web/tls/current/msg06718.html) are all very easy to resolve. =20 Picking up on parts of the thread noted above, I would say the main = reason to consider CCM rather than GCM is simply because it is part of the = IEEE802 standards and there is hardware support for CCM in currently deployed chipsets (many millions of them to date with many more millions on = order). To employ GCM, we would have to bypass the CCM hardware support and implement GCM in software then get IEEE to re-consider CCM for later revisions of standards. The only concern that I saw with the draft is the truncation issue in = this part of the thread: http://www.ietf.org/mail-archive/web/tls/current/msg06724.html. There = is even a suggestion within on how we might get around this issue for small = RAM size devices like IEEE 802.15.4 solutions. Don =20 -----Original Message----- From: Juho V=E4h=E4-Herttua [mailto:juhovh@iki.fi]=20 Sent: Thursday, January 06, 2011 6:53 AM To: tls@ietf.org Cc: d.sturek@att.net Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) On 6.1.2011, at 16.36, Don Sturek wrote: > I wanted to bring up the draft presented by David McGrew last July (in Maastricht) one more time. The draft (now expired I think) is "AES-CCM = ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- ecc-00. > =20 > I know there was a thread last summer on this. I am part of the = ZigBee Alliance implementing TLS for an IEEE 802.15.4 application. We would = like the TLS group to consider (or maybe re-consider though I never saw any formal disposition of this on the reflector) the use of David=92s draft = for IEEE 802.15.4 networks. The discussion thread can be seen in http://www.ietf.org/mail-archive/web/tls/current/msg06716.html and the = main problems are pretty much mentioned in the later post http://www.ietf.org/mail-archive/web/tls/current/msg06761.html Basically the proposed draft should probably be divided into smaller = parts. One part would define the AES-CCM cipher suites in a way that would be interoperable with existing TLS cipher suites. Another part would = describe the use of TLS and AES-CCM in IEEE 802.15.4 networks, including = forbidding the use of other than ECDSA certificates and forbidding the = elliptic_curves and ec_point_formats extension. > I think CCM is a common cipher suite for IEEE802 and this draft = matches what is specified in IEEE (and implemented in hardware in millions of devices). >From what I can tell, the draft was not interoperable with existing = cipher suites for no apparent reason (other than that's how ZigBee uses it). = But if that can be fixed then there should be no problem including AES-CCM in = TLS. Juho From juhovh@iki.fi Thu Jan 6 07:46:56 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BA43A6E31 for ; Thu, 6 Jan 2011 07:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_HELO_EQ_DSL_3=1.022] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IJkDhye3fIj for ; Thu, 6 Jan 2011 07:46:55 -0800 (PST) Received: from jenni1.inet.fi (mta-out.inet.fi [195.156.147.13]) by core3.amsl.com (Postfix) with ESMTP id 913263A6E1A for ; Thu, 6 Jan 2011 07:46:54 -0800 (PST) Received: from smtp.vaha-herttua.fi (88.192.241.223) by jenni1.inet.fi (8.5.133) id 4D060B9400C7A8AB; Thu, 6 Jan 2011 17:48:59 +0200 Received: from dsl-hkibrasgw3-ffffc000-19.dhcp.inet.fi (dsl-hkibrasgw3-ffffc000-19.dhcp.inet.fi [88.192.255.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.vaha-herttua.fi (Postfix) with ESMTPSA id 82E161FCFE; Thu, 6 Jan 2011 17:49:01 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-2-341640278; protocol="application/pkcs7-signature"; micalg=sha1 From: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= In-Reply-To: <00aa01cbadb3$b7c95f50$275c1df0$@sturek@att.net> Date: Thu, 6 Jan 2011 17:48:56 +0200 Message-Id: References: <008d01cbadaf$2de31550$89a93ff0$@sturek@att.net> <00aa01cbadb3$b7c95f50$275c1df0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] draft-mcgrew-tls-aes-ccm-ecc-00 (again) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 06 Jan 2011 15:46:56 -0000 --Apple-Mail-2-341640278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6.1.2011, at 17.09, Don Sturek wrote: > Hi Juho, >=20 > On your very last sentence, could you elaborate on why you think the = draft > is not interoperable with other cipher suites? I think topics like = those > discussed in this part of the thread > (http://www.ietf.org/mail-archive/web/tls/current/msg06718.html) are = all > very easy to resolve. =20 I think the issues are pretty easy to solve as well. The first thing = that came into my mind about not being interoperable was the extension = part: The client MUST NOT offer the elliptic_curves extension nor the ec_point_formats extension. The server MUST NOT expect to receive those extensions. The client offering AES-CCM cipher suites should be allowed to offer = other cipher suites as well. Those other cipher suites may need to = define elliptic_curves or ec_point_formats extensions, but AES-CCM draft = forbids offering them. That's a clear conflict. Another smaller issue = was the certificate part: The server's certificate MUST contain an ECDSA-capable public key, and it MUST be signed with ECDSA. If a client certificate is used, the same conditions apply to it. I don't see a reason why a cipher should restrict the type of = certificates, although requiring the ECDSA-capable public key in ECDSA = cipher suite is kind of obvious. This is not really conflicting, but it = would be much nicer if the AES-CCM would be defined as a generic cipher = that can be used with any kind of certificate and the additional IEEE = 802.15.4 related restrictions would be in a separate document. It works = for all the other ciphers and RSA, DHE_DSA or DHE_RSA or certificates = signed with some other signing algorithm are not really less secure than = ECDSA. I guess the reason for this is again to simplify the hardware = implementation by only using ECDSA for everything. Juho --Apple-Mail-2-341640278 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM+DCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGvDCCBaSg AwIBAgICC7kwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MDEwMDkxODQ4MjVaFw0xMjEwMDkyMzA0MjZaMIG6MSAwHgYDVQQNExcyNzE5OTktNTRMRzc2dUow TXMwQWs4eDELMAkGA1UEBhMCRkkxEDAOBgNVBAgTB1V1c2ltYWExDjAMBgNVBAcTBUVzcG9vMS0w KwYDVQQLEyRTdGFydENvbSBWZXJpZmllZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEUp1 aG8gVmFoYS1IZXJ0dHVhMRwwGgYJKoZIhvcNAQkBFg1qdWhvdmhAaWtpLmZpMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgecI8+NNG/D0e/PpHHJDPlVhR4mmAPZZUBA22yAf6OageO6 H9GUuuNq787QHvF87ySXb8uZMpC1EDqdkEweHdRMd8fPvHmhgLj4w3xO/pFG/d/ZUpQ3nUEF7yqm 94mgG1yW1ps3Q5eKuUE7m5XT3MKxDugb2GX/5u4LmVrC3YM6DDqdf7Fzof9F3I44EpeQfJx5jp8Y KerCRGEVTVfxcA8JxHT5ZAi3xG3lVBkYb45zHzKCGz32ol34L65IRkTt9wkNnkZYzDv3E8sweQpL 5U24kHUMxclWmGpvNuXyWdaFeg68bUXujoUfoTzSf3p1vx7PWMAHd4PnCuX5e4rAWwIDAQABo4IC 9jCCAvIwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBQOC6ocoJ57B8gH/dYfGyjmOl92tDAfBgNVHSMEGDAWgBSuVYNv7DHKufcd +q9rMfPIHeOsuzAYBgNVHREEETAPgQ1qdWhvdmhAaWtpLmZpMIIBQgYDVR0gBIIBOTCCATUwggEx BgsrBgEEAYG1NwECAjCCASAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0 ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlh YmlsaXR5LCBzZWUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNz bC5jb20vY3J0dTItY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTIt Y3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCunEi6zUK6IXC5vcyRBFVcZdpE QsYKVVKwS6T1NPxMVlLriKu27lG3tuxgwW4mR/FpyXf30RmP2/l3BMcrnBMVKqY9KQle7pzv1nDG Om2QSHUbgjMaOyvNeSwjkjP/2zfZ2gdot1S3K6PZl4SKx1H6tOqePPJAfCYb4WBj/vlIREmXzozd pzQu8G7fEuIni76Z0xIJVC50KDcry1lIsuZGUQ+fXuVkbNv7EO8tID6ylX/EWIMd2Pz/gq+0Jppz hIqo03Y03cPZAsqFtg+ZqukM/zdmapHK/ayVJaHsRbS7fvbC8aE6o0T6p5KwqQI0lcDyvugOw/pg FHSf/UgeAE2MMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kw CQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTEwMTA2MTU0ODU2WjAjBgkqhkiG9w0BCQQxFgQUaIHi87HrusiOxnjBd2GHQZM2etkwgaQGCSsG AQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgILuTCBpgYLKoZIhvcN AQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICC7kwDQYJKoZIhvcNAQEB BQAEggEATi0txHvCZMgPOsQQc99hrdiTRfViVYRCd7aUS8Cqi6g9uTaQhZBnBUQEl30B2SKV5caD FSAYAIy6Vx6Bws3GLU0scLFZahaOTxWr5pXZUz+mXxkijE/BXoUlCwy/VIIYh6SXZGZbUe1cSG+u 1mXUdBBX4em99uBnM18pYvaQ6S7Ay4ginc1g1YM5axiQNMKE+fvGYYsnOgrICN6xP7ycfGbKqyvc i73SaWPzoenhCdG3ucYKPRrOW3BE7SqS1m2bq6QMYIdfyGsRW/jspgftJy9g0nz+3aqtxB7grRaw sQyhuOX9nTptXGNwcf9B/OJIgZqMHMsK3U/WuSsppHGGKAAAAAAAAA== --Apple-Mail-2-341640278-- From matt@mattmccutchen.net Fri Jan 7 09:45:15 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F0E3A68D5 for ; Fri, 7 Jan 2011 09:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sjRO3tU76jq for ; Fri, 7 Jan 2011 09:45:14 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (mx1.spunky.mail.dreamhost.com [208.97.132.47]) by core3.amsl.com (Postfix) with ESMTP id 763F03A67D0 for ; Fri, 7 Jan 2011 09:45:14 -0800 (PST) Received: from homiemail-a62.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTP id 4E0A7634073 for ; Fri, 7 Jan 2011 09:47:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=CleYo6j4apVXdjVI69bDZWUMCocBpKmfLJ6fdJuezc+ OGA6OO5G00xxvEBm8pXZOb0Aro9vt8FiRIfvLHoqokJseZHmLxavoTJ+q9eE7WLG Dni81CW7VZOc339hwYbPteOSC9nDRyT4o98hXSMAQ+gK4xotGuyCPpD4EeMYvysA = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=DnhS2clETaLAx93HZShylLgjcrU=; b=QkZu8AuIw5 tP+yF5aUh/pSSTGIFxt2Wx5e2/NTwtOhJfOMvaMMxsZbot3gYOh8cStt1EPbhFDb bOjPhFwxlH1JhQ5ywjyNOw10+XGOZsNtqkRXgOGysIBLDDJTkwEBTF3H2lt9VXg6 12ga0QIZCuZIwF83BMm2cwCRhzmtaOP4E= Received: from [192.168.1.40] (pool-74-96-127-122.washdc.east.verizon.net [74.96.127.122]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a62.g.dreamhost.com (Postfix) with ESMTPA id E851163406C for ; Fri, 7 Jan 2011 09:47:20 -0800 (PST) From: Matt McCutchen To: tls@ietf.org In-Reply-To: <1281516049.16678.89.camel@mattlaptop2.local> References: <4C619C03.3060809@extendedsubset.com> <1281516049.16678.89.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Fri, 07 Jan 2011 12:47:19 -0500 Message-ID: <1294422439.1953.20.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Way to go everybody! TLS FTW! X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 07 Jan 2011 17:45:15 -0000 On Wed, 2010-08-11 at 01:40 -0700, Matt McCutchen wrote: > On Tue, 2010-08-10 at 13:35 -0500, Marsh Ray wrote: > > Today, this "Patch Tuesday", Microsoft releases KB980436 which adds > > support for RFC 5746 the Renegotiation Indication Extension > > http://www.microsoft.com/technet/security/bulletin/ms10-049.mspx > > This is a major accomplishment, Microsoft clearly has as many affected > > products and systems as anybody. Although they may be bringing up the > > rear among the vendors, the rear has clearly been brought up. > > No, alas, Debian still has OpenSSL with RFC 5746 available only in > testing: > > http://packages.debian.org/search?keywords=openssl&searchon=sourcenames&exact=1&suite=all§ion=all A DreamHost support technician has just pointed out to me that Debian has released openssl 0.9.8g-15+lenny10 with RFC 5746 support to stable. Hooray! -- Matt From wwwrun@rfc-editor.org Tue Jan 18 12:29:51 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C9428C151; Tue, 18 Jan 2011 12:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1CG45UCvPI8; Tue, 18 Jan 2011 12:29:51 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 13B4B28C108; Tue, 18 Jan 2011 12:29:51 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 59390E0732; Tue, 18 Jan 2011 12:32:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110118203229.59390E0732@rfc-editor.org> Date: Tue, 18 Jan 2011 12:32:29 -0800 (PST) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 6066 on Transport Layer Security (TLS) Extensions: Extension Definitions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2011 20:29:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6066 Title: Transport Layer Security (TLS) Extensions: Extension Definitions Author: D. Eastlake 3rd Status: Standards Track Stream: IETF Date: January 2011 Mailbox: d3e3e3@gmail.com Pages: 25 Characters: 55079 Obsoletes: RFC4366 I-D Tag: draft-ietf-tls-rfc4366-bis-12.txt URL: http://www.rfc-editor.org/rfc/rfc6066.txt This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK] This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From agl@google.com Tue Jan 18 14:18:36 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F0F43A6F61 for ; Tue, 18 Jan 2011 14:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.32 X-Spam-Level: X-Spam-Status: No, score=-104.32 tagged_above=-999 required=5 tests=[AWL=1.658, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4Myg2KGBy4b for ; Tue, 18 Jan 2011 14:18:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 059233A6D82 for ; Tue, 18 Jan 2011 14:18:34 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p0IMLCTi017120 for ; Tue, 18 Jan 2011 14:21:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295389272; bh=w0uH4kXqlLg4lyFhNkjoiHQ/mmw=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=agQrwkJ47ijzwZ1c6jIYDLXnBS95mAJMxuPLOpG35T+5D8KiMPr1xqS3ialie8NLD fdKNai7IpyCEuO4mjTKGA== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by wpaz21.hot.corp.google.com with ESMTP id p0IMLBxI008133 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 14:21:12 -0800 Received: by ywo7 with SMTP id 7so40371ywo.23 for ; Tue, 18 Jan 2011 14:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=JrlTNx5ef0sP/JYCh4Lnx5gxu+NkVrzaXZKIeHlasEg=; b=lPnsD/EdBzV36RSQB3zZ0WS4FHeX6+zeU5BP+4R2Uvl12BHjflRn/rj/SgREw2i5LZ QVKphoZGOgIb5kNj1VqA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=ydkkOSGgWRIOcEYH9PYwml1JtwJxcAJDVGjDRjVB9lYMOseezWKkVx0Dfi1xQBZVSb Ss14zZ/HZcglK2U3d76g== MIME-Version: 1.0 Received: by 10.150.192.18 with SMTP id p18mr1694327ybf.324.1295389271098; Tue, 18 Jan 2011 14:21:11 -0800 (PST) Received: by 10.151.153.7 with HTTP; Tue, 18 Jan 2011 14:21:11 -0800 (PST) Date: Tue, 18 Jan 2011 17:21:11 -0500 Message-ID: From: Adam Langley To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Subject: [TLS] Unfortunate current practices for HTTP over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 18 Jan 2011 22:18:36 -0000 The following is presented mostly for the member's enjoyment: Network Working Group A. Langley Internet-Draft Google Inc Expires: July 5, 2011 Jan 2011 Unfortunate current practices for HTTP over TLS draft-agl-tls-oppractices-00 Abstract This document describes some of the unfortunate current practices which are needed in order to transport HTTP over TLS on the public Internet. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 5, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Handshake message fragmentation . . . . . . . . . . . . . . . 4 3. Protocol Fallback . . . . . . . . . . . . . . . . . . . . . . 5 4. More implementation mistakes . . . . . . . . . . . . . . . . . 6 5. Certificate Chains . . . . . . . . . . . . . . . . . . . . . . 7 6. Insufficient Security . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction HTTP [RFC2616] is one of the most common application level protocols transported over TLS [RFC5246]. (This combination is commonly known as HTTPS based on the URL scheme used to indicate it.) HTTPS clients have to function with a huge range of TLS implementations, some of higher quality than others. This text aims to document some of the behaviours of existing HTTPS clients that are designed to ensure maximum interoperability. This text should not be taken as a recommendation that future HTTPS clients adopt these behaviours. The security implications of each need to be carefully considered by each implementation. However, these behaviours are common and the authors consider it better to document the state of practice than to simply wish it were otherwise. 2. Handshake message fragmentation Many servers will fail to process a handshake message that spans more than one record. These servers will close the connection when they encounter such a handshake message. HTTPS clients will commonly ensure against that by either packing all handshake messages in a flow into a single record, or by creating a single record for each handshake message. 3. Protocol Fallback Despite it being nearly twelve years since the publication of TLS 1.0 [RFC2246], around 3% of HTTPS servers will reject a valid TLS "ClientHello". These rejections can take the form of immediately closing the connection or a fatal alert. Intolerance to the following has been observed: Advertising version TLS 1.0. Advertising a TLS version greater than TLS 1.0 (around 2% for 1.1 or 1.2, around 3% for greater than 1.2). Advertising a version greater than 0x03ff (around 65% of servers) The presence of any extensions (around 7% of servers) The presence of specific extensions ("server_name" and "status_request" intolerance has been observed, although in very low numbers). The presence of any advertised compression algorithms Next, some servers will misbehave after processing the "ClientHello" message. Negotiating the use of "DEFLATE" compression can result in fatal "bad_record_mac", "decompression_failure" or "decryption_failed" alerts. Notably, OpenSSL prior to version 0.9.8c will intermittently fail to process compressed finished messages due to a work around of a previous padding bug. Lastly, some servers will negotiate the use of SSLv3 but select a TLS-only cipher suite. In all these cases, HTTPS clients will often enter a fallback mode. The connection is retried using only SSLv3 and without advertising any compression algorithms. (This is obviously an easy downgrade attack.) Also, the fallback can be triggered by transient network problems, which often manifest as an abruptly closed connection. Since SSLv3 does not provide any means of Server Name Indication [RFC3546], the fallback connection can use the wrong certificate chain, resulting in a very surprising certificate error. 4. More implementation mistakes Non-fatal errors in version negotiation also occur. Some 0.2% of servers use the version from the record header. Around 0.6% of servers require that the version in the "ClientHello" and record header match in order to respect the version in the "ClientHello". A very low number of servers echo whatever version the client advertises. In the event that the client supports a higher protocol version than the server, about 0.4% of servers require that the RSA "ClientKeyExchange" message include the server's protocol version. Some 30% of servers don't check the version in an RSA "ClientKeyExchange" at all. 5. Certificate Chains Certificate chains presented by servers will commonly be missing intermediate certificates, have certificates in the wrong order and will include unrelated, superfluous certificates. Servers have been observed presenting more than ten certificates in what we assume is a drive-by shooting approach to including the correct intermediate certificate. In order to validate chains which are missing certificates, some HTTPS clients will collect intermediate certificates from other servers. Clients will commonly put all the presented certificates into a set and try to validate a chain assuming only that the first certificate is the leaf. 6. Insufficient Security Some 65% of servers support SSLv2 (beyond just supporting the handshake in order to upgrade to SSLv3 or TLS). HTTPS clients will typically not support SSLv2, nor send SSLv2 handshakes by default. Of those servers, 80% support the export ciphersuites. (Although about 3% of those servers negotiate weak ciphersuites only to show a warning.) Some servers will choose very small multiplicative group sizes for their ephemeral Diffie-Hellman exchange (for example, 256-bits). Some HTTPS clients will reject all multiplicative group sizes smaller than 512-bits while others will retry after demoting DHE ciphersuites in their "ClientHello". 7. Acknowledgements Yngve Pettersen made significant contributions and many of the numbers in this document come from his scanning work. Other numbers were taken from Ivan Ristic's SSL Survey. Thanks to Wan Teh Chang for reviewing early drafts. 8. Normative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. From mrex@sap.com Tue Jan 18 15:31:34 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ACDB28C15C for ; Tue, 18 Jan 2011 15:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.157 X-Spam-Level: X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+ug3z-dNmaP for ; Tue, 18 Jan 2011 15:31:33 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 1580A28C13C for ; Tue, 18 Jan 2011 15:31:32 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0INY6ua007338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 00:34:07 +0100 (MET) From: Martin Rex Message-Id: <201101182334.p0INY6oQ013138@fs4113.wdf.sap.corp> To: agl@google.com (Adam Langley) Date: Wed, 19 Jan 2011 00:34:06 +0100 (MET) In-Reply-To: from "Adam Langley" at Jan 18, 11 05:21: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] Unfortunate current practices for HTTP over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 23:31:34 -0000 Nice collection -- thank you for the effort!. Do we need a new document category "WCP" (worst current practice)? :) Adam Langley wrote: > > 2. Handshake message fragmentation > > Many servers will fail to process a handshake message that spans more > than one record. These servers will close the connection when they > encounter such a handshake message. HTTPS clients will commonly > ensure against that by either packing all handshake messages in a > flow into a single record, or by creating a single record for each > handshake message. >From the SSLv3 draft302 document ("Work in progress" according to rfc5746): 5.2 Record layer The SSL Record Layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size. 5.2.1 Fragmentation The record layer fragments information blocks into SSLPlaintext records of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType may be coalesced into a single SSLPlaintext record). For experimentation I put together a few lines of code for a simple TCP communication relaying that shreds TLS records containing handshake messages into pathological fragments (1byte,2byte,3byte,...) And I'm actually having difficulties find TLS implementations that can cope with this. Some (record layer) TLS code I've looked at makes a number of flawed assumptions about fragmentation, and fixing that code to align with the _real_ specifiction requires a non-trivial change of the code modularization of the record layer... > > 3. Protocol Fallback > > Intolerance to the following has been observed: > > Advertising a version greater than 0x03ff (around 65% of servers) Keep in mind that this is about the first few bytes sent on a new network connection. The purpose of the check is a heuristic to distinguish a real TLS connection attempt (initial ClientHello) from arbitrary other protocols instead of letting the protocol parser engine produce a potentially confusing error message about data that obviously isn't meant to be TLS in the first place. Servers that tolerate >=4 versions ahead of what is currently defined SSLv3{0x03,0x00} -> TLSv1.2{0x03,0x03} provide sufficient slack that they are no problem for the evolution of the TLS protocol. TLS implementations that are completely agnostic to the version will AFAIK confuse DTLS and TLS. > > In all these cases, HTTPS clients will often enter a fallback mode. > The connection is retried using only SSLv3 and without advertising > any compression algorithms. (This is obviously an easy downgrade > attack.) Fallback mode is mostrly restricted to a few Web Browser that are curiously exploring bleeding-edge TLS extensions. Most programmatic clients don't have a fallback mode, because the fallback has to be performed at the application level over a new network connection, potentially including proxy traversals. Programmatic clients are more likely to send very feature-conservative ClientHellos from the beginning (no TLS extensions and either TLSv1.0 or SSLv3). > > Also, the fallback can be triggered by transient network > problems, which often manifest as an abruptly closed connection. > Since SSLv3 does not provide any means of Server Name Indication > [RFC3546], the fallback connection can use the wrong certificate > chain, resulting in a very surprising certificate error. Since a significant fraction of the installed base browsers and most of the programmatic clients do not send a server name indication in the first place, the effect is more of a common annoying certificate error pointing to an inconsiderate/misconfigured server. The majority where I've encountered such errors, it was with servers and hostnames belonging to the same organization, so the problem could be entirely avoided by a sensible admin through the simple use of adequate TLS server certs, listing all of the servers alternative hostnames. -Martin From mike-list@pobox.com Tue Jan 18 16:00:06 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DB1F28C0E1 for ; Tue, 18 Jan 2011 16:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYnJ8fQ83IYw for ; Tue, 18 Jan 2011 16:00:04 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 907433A6F57 for ; Tue, 18 Jan 2011 16:00:04 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 5DBF83457; Tue, 18 Jan 2011 19:03:28 -0500 (EST) 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=Ft2wETDg5XPK B9AtcP8kgmgJPM4=; b=Vj8L19Dnn/RAGFx2D5qnHNtu+2D6juJU3Mg2sqQeQP2d YbHp1G0JnrzbewX7+IiEoD0cmCsOf35mj0d8MDHRPbQrS7fUtsu94Z/u1g1ekfeA LAIBF7eKtHMbkwnKdgXpk6GRRVYP9iRqre/uq9TlJ7dZ+M3GiCEl7VS7zgPINio= 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=NTpeLx wb1BAbP5xECqQeBMjViSl0Ww/q1XcmZCgOhNuClsDL7rRaTLhtbbQPxlVind+jia 8f9cuVA6hcqWyG0RE+myOAfwWSXe7uJBfjZksR+aeMtk2oAPgPfm3c0ZejG9BKgy t6g+d5M5OAXn595hhASX5UY3eZuOxwiMKCvx8= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 4A77A3455; Tue, 18 Jan 2011 19:03:27 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (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 AE9D03450; Tue, 18 Jan 2011 19:03:25 -0500 (EST) Message-ID: <4D362A1E.9020509@pobox.com> Date: Tue, 18 Jan 2011 16:02:38 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Adam Langley References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 8A71716A-235F-11E0-928C-BC4EF3E828EC-38729857!a-pb-sasl-sd.pobox.com Cc: tls@ietf.org Subject: Re: [TLS] Unfortunate current practices for HTTP over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 00:00:06 -0000 Adam Langley wrote: > > 3. Protocol Fallback > > Lastly, some servers will negotiate the use of SSLv3 but select a > TLS-only cipher suite. Which cipher suites do you consider to be TLS-only? Mike From yngve@opera.com Tue Jan 18 16:13:46 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD603A6F57 for ; Tue, 18 Jan 2011 16:13:46 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hp0K0iEauFpN for ; Tue, 18 Jan 2011 16:13:46 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id BE8123A6EB8 for ; Tue, 18 Jan 2011 16:13:45 -0800 (PST) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0J0GMRd015736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Jan 2011 00:16:23 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <4D362A1E.9020509@pobox.com> Date: Wed, 19 Jan 2011 01:16:30 +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: <4D362A1E.9020509@pobox.com> User-Agent: Opera Mail/10.63 (Win32) X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81 Subject: Re: [TLS] Unfortunate current practices for HTTP over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 00:13:47 -0000 On Wed, 19 Jan 2011 01:02:38 +0100, Michael D'Errico wrote: > Adam Langley wrote: >> 3. Protocol Fallback >> Lastly, some servers will negotiate the use of SSLv3 but select a >> TLS-only cipher suite. The AES suites are AFAIK only defined for TLS 1.0 and higher. And there are also other ciphersuites that are defined for specific versions and higher, particularly the SHA-256 suites. See also -- 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 yngve@opera.com Tue Jan 18 16:13:50 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF8B928C103 for ; Tue, 18 Jan 2011 16:13:50 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3t24w7WgnDJI for ; Tue, 18 Jan 2011 16:13:50 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 9C65C28C0FF for ; Tue, 18 Jan 2011 16:13:49 -0800 (PST) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0J0GMRc015736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jan 2011 00:16:23 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Adam Langley" , "Martin Rex" References: <201101182334.p0INY6oQ013138@fs4113.wdf.sap.corp> Date: Wed, 19 Jan 2011 01:16:28 +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: <201101182334.p0INY6oQ013138@fs4113.wdf.sap.corp> User-Agent: Opera Mail/10.63 (Win32) X-Scanned-By: MIMEDefang 2.64 on 213.236.208.81 Cc: tls@ietf.org Subject: Re: [TLS] Unfortunate current practices for HTTP over TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 00:13:51 -0000 On Wed, 19 Jan 2011 00:34:06 +0100, Martin Rex wrote: >> 3. Protocol Fallback >> >> Intolerance to the following has been observed: >> >> Advertising a version greater than 0x03ff (around 65% of servers) > > Keep in mind that this is about the first few bytes sent on a > new network connection. The purpose of the check is a heuristic > to distinguish a real TLS connection attempt (initial ClientHello) > from arbitrary other protocols instead of letting the protocol > parser engine produce a potentially confusing error message about > data that obviously isn't meant to be TLS in the first place. > > Servers that tolerate >=4 versions ahead of what is currently > defined SSLv3{0x03,0x00} -> TLSv1.2{0x03,0x03} provide sufficient > slack that they are no problem for the evolution of the TLS protocol. We are not in this case talking about the *Record* protocol version, we are talking about the *Client Hello* version field. Therefore, the server would already have decided that the framework was a valid TLS Protocol record message before it could process the Client Hello (0x16 ), so there is no possibility of confusion, unless a protocol started using not just the record framing used by TLS, but also the same protocol record identifiers for the records and the handshake. I have no objection to a server refusing to accept a connection from a client specifying a Record protocol version higher than it supports; that is why the recommendation for that is something like "the lowest/earliest version the client knows the server supports". So a future client that do not want to talk to servers supporting protocol version 3.x could send 4.0, for example, and a 3.x server would be perfectly justified to send a unsupported version alert (or something similar) and shut down the connection. Most clients today signals 3.1 as the Record Protocol version to the server, except when they are in SSLv3-only version rollback mode (and for Opera, in the "TLS 1.0 with 3.0 as record protocol"-mode), which is not a real problem since only 1% of servers seem to be SSL v3-only, and only a very small fraction of those are version intolerant in the 3.x range. OTOH, servers are required, by all the versions of SSL and TLS, to accept that clients sends a higher version than the server supports. As I have mentioned earlier, the reason the 4.x+ intolerance could be a future issue is that it complicates a future migration to the next major protocol version, possibly leading a choice between blocking a security vulnerabilities and preserving interoperability. Currently 75-80% of Renego patched servers have this issue, vs. ~64% for all servers. > TLS implementations that are completely agnostic to the version > will AFAIK confuse DTLS and TLS. Given that the record protocol version field should indicate which type of TLS the client is attempting to initiate, I doubt there would be any confusion, quite aside from the fact that DTLS is AFAIK not intended for TCP style connections. >> In all these cases, HTTPS clients will often enter a fallback mode. >> The connection is retried using only SSLv3 and without advertising >> any compression algorithms. (This is obviously an easy downgrade >> attack.) > > Fallback mode is mostrly restricted to a few Web Browser that are > curiously exploring bleeding-edge TLS extensions. Most programmatic Version fallback was implemented long before TLS Extensions were implemented, for the simple reason that many SSL v3 servers did not tolerate TLS 1.0 being signaled, and there is still a small fraction (0.1%) of those servers around. > clients don't have a fallback mode, because the fallback has to > be performed at the application level over a new network connection, > potentially including proxy traversals. Programmatic clients are > more likely to send very feature-conservative ClientHellos from > the beginning (no TLS extensions and either TLSv1.0 or SSLv3). That is probably correct, but programmatic clients would probably also be used against a limited number of servers, and any intolerances that would cause a handshake failures would be diagnosed and fixed quickly. -- 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 mike-list@pobox.com Tue Jan 18 16:31:57 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7A993A706E for ; Tue, 18 Jan 2011 16:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r78BIx4Mxink for ; Tue, 18 Jan 2011 16:31:56 -0800 (PST) Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id 132353A6FDB for ; Tue, 18 Jan 2011 16:31:55 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id EC858373E for ; Tue, 18 Jan 2011 19:35:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=7rURSFhkQVN/ ubWRJzRpJ2TTcRc=; b=h/jBYZb33cB6fAmQFBYgljGfZCeMOd5lakd/S3cDGYB+ SKAWvaMq81KjbzHpiighmMofq6ksEHnzKfvF5xNap0kuY15Hi+OgUuDBmO8rSaZb sjWVoL2t9pwkCjzS1e4omgpqz9mpu8GW6wy5tI6QWKraUClh+t83tAtohiOgrkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=eKtZzX OOwqkOGu9rZc1R55VAYXSQNv9xKHmV/MDt5UXcQBiuSD09GNZ4V7dSf8LnYSXKuq WfyTW066zLV4jfAQFTcttQq0ijjlVKddVbEo1y5EbgsDzEd3pZ0NXxFpHieWHu8k yvJHTgKkHHZA0na5PZ/HElnkMHj4L8J9A/syo= Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id E67FD373D for ; Tue, 18 Jan 2011 19:35:19 -0500 (EST) Received: from iMac.local (unknown [24.234.114.35]) (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 9622C373C for ; Tue, 18 Jan 2011 19:35:19 -0500 (EST) Message-ID: <4D363198.2050301@pobox.com> Date: Tue, 18 Jan 2011 16:34:32 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: tls@ietf.org References: <4D362A1E.9020509@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: FE766954-2363-11E0-8DE7-BC4EF3E828EC-38729857!a-pb-sasl-sd.pobox.com Subject: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP over TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 00:31:57 -0000 The SHA-256 cipher suites aren't compatible with SSLv3 since the SSLv3 spec only shows what to do with MD5 and SHA-1. But there is nothing about AES which is incompatible with SSLv3, and indeed my server is able to negotiate non-SHA-256 AES_CBC cipher suites with SSLv3 clients that offer them. So my question is now: If a client offers AES cipher suites in a ClientHello with a version of 0300, why is it wrong to choose one of them? Mike Yngve N. Pettersen (Developer Opera Software ASA) wrote: > On Wed, 19 Jan 2011 01:02:38 +0100, Michael D'Errico > wrote: > >> Adam Langley wrote: >>> 3. Protocol Fallback >>> Lastly, some servers will negotiate the use of SSLv3 but select a >>> TLS-only cipher suite. > > The AES suites are AFAIK only defined for TLS 1.0 and higher. And there > are also other ciphersuites that are defined for specific versions and > higher, particularly the SHA-256 suites. From mrex@sap.com Tue Jan 18 17:10:45 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93D303A7080 for ; Tue, 18 Jan 2011 17:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.16 X-Spam-Level: X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnp108GUuo5e for ; Tue, 18 Jan 2011 17:10:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 83EEA3A7053 for ; Tue, 18 Jan 2011 17:10:44 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0J1DM7S020294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 02:13:22 +0100 (MET) From: Martin Rex Message-Id: <201101190113.p0J1DLPw018889@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 19 Jan 2011 02:13:21 +0100 (MET) In-Reply-To: <4D363198.2050301@pobox.com> from "Michael D'Errico" at Jan 18, 11 04:34:32 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] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2011 01:10:45 -0000 Michael D'Errico wrote: > > The SHA-256 cipher suites aren't compatible with SSLv3 since the SSLv3 > spec only shows what to do with MD5 and SHA-1. But there is nothing > about AES which is incompatible with SSLv3, and indeed my server is able > to negotiate non-SHA-256 AES_CBC cipher suites with SSLv3 clients that > offer them. > > So my question is now: > > If a client offers AES cipher suites in a ClientHello with a > version of 0300, why is it wrong to choose one of them? I'm not aware of _any_ reason why the ciphersuites defined in rfc-3268. In fact, if you look at rfc-3268: Cipher Usage The new ciphersuites proposed here are very similar to the following, defined in [TLS]: TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA and then look up these cipher suites in rfc-2246 and then in SSLv3 draft302.txt, you ought to realize that these "very similar" cipher suites are really SSLv3 cipher suites. Using and interoperating AES cipher suites from rfc-3268 with Firefox and OpenSSL works without any additional thoughts. (preventing it from working probably require additonal code). Since AES128 is faster than tripleDES it would be unreasonable to leave this cipher suite _not_ working with SSLv3. But I know of at least one TLS implementation shipped by a large vendor that aborts on the combination of rfc-3268 cipher suites and SSLv3. -Martin From wtc@google.com Tue Jan 18 17:52:13 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49A173A6FE1 for ; Tue, 18 Jan 2011 17:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5+QBdEGHpb2 for ; Tue, 18 Jan 2011 17:52:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 4A41B3A6F34 for ; Tue, 18 Jan 2011 17:52:12 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p0J1sosx014360 for ; Tue, 18 Jan 2011 17:54:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295402090; bh=vtIeQmz1oGdleqQyTbDKgGfv9yw=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Sll4tP81m8FI0NrCBENCm3/vEgMZbZiXb1QjmpB15VKM+G/Pbk2DFAyEI2EzhPNj/ LYTaUiAJaYWZsHHznWUhg== Received: from wwb39 (wwb39.prod.google.com [10.241.241.103]) by wpaz17.hot.corp.google.com with ESMTP id p0J1smQa010874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 17:54:49 -0800 Received: by wwb39 with SMTP id 39so339326wwb.4 for ; Tue, 18 Jan 2011 17:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mDpa7Efg4jWzdRzZWtdKcJdeOOHlwGSlfNAfDzu+cTY=; b=mmWs64xc8g0GuSVvgCzxNIawTi6sG6aCXtn9lZA6tacRVXa0voxbDalSlnIcKw2cjc A5HycFlIKoZmROIVLo7w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wRk9T6TtGKk2oobme3tkjF0RlcwPinm1XO1G4lnhiV/rJplilqOskR5StTLEqjgw6H jSXjuh+5LUyrMxUE56hw== MIME-Version: 1.0 Received: by 10.216.176.142 with SMTP id b14mr69897wem.32.1295402039583; Tue, 18 Jan 2011 17:53:59 -0800 (PST) Received: by 10.216.6.81 with HTTP; Tue, 18 Jan 2011 17:53:59 -0800 (PST) In-Reply-To: <201101190113.p0J1DLPw018889@fs4113.wdf.sap.corp> References: <4D363198.2050301@pobox.com> <201101190113.p0J1DLPw018889@fs4113.wdf.sap.corp> Date: Tue, 18 Jan 2011 17:53:59 -0800 Message-ID: From: Wan-Teh Chang To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 01:52:13 -0000 On Tue, Jan 18, 2011 at 5:13 PM, Martin Rex wrote: > > But I know of at least one TLS implementation shipped by a large vendor > that aborts on the combination of rfc-3268 cipher suites and SSLv3. Eric Lawrence explained this in the blog post "AES is not a valid cipher for SSLv3": http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx Wan-Teh From tdierks@gmail.com Tue Jan 18 18:23:02 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98463A70B8 for ; Tue, 18 Jan 2011 18:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzVejFGe9Jrb for ; Tue, 18 Jan 2011 18:23:01 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 567273A70B6 for ; Tue, 18 Jan 2011 18:23:00 -0800 (PST) Received: by iyi42 with SMTP id 42so308708iyi.31 for ; Tue, 18 Jan 2011 18:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=PWOD8vd65CE/29xzRX4674wGSZbE9ELAvIBW1lNPOfo=; b=N/PVA5AVSUtzyXvxzHIoV/Ina3mOx4u9d7BzQ6lFMXq1WSoald2Jt/Zceclg0xxl6q kUOn/J33YFplBKYJhyu/+Xbt+fFZ2KlFDHCo9GSfFcA5sMSsIPKlg1CfCE4DdWje5Ucs mNUmmEYwcSXUc9wyfd9XxPtKbU4vGfSQeIINc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=EP2G2ZR34WZZXLvy6y7Gm59CYcQ0jqyuXxPVkKGGxJCnSGS2LH5hhuv9p3idMjV3vZ wwpCppE1Qiv64P0K6u/mHObbQ0C2/RLnyekjDIRgMzHg2WKGyht2UY6aSuSbpx8Rtz0g JdR10nW2BFCL6/kQvdAkaOPSVOsrqOa5W9Z3Y= Received: by 10.231.37.138 with SMTP id x10mr79099ibd.192.1295403938984; Tue, 18 Jan 2011 18:25:38 -0800 (PST) MIME-Version: 1.0 Sender: tdierks@gmail.com Received: by 10.231.59.200 with HTTP; Tue, 18 Jan 2011 18:25:18 -0800 (PST) In-Reply-To: References: <4D363198.2050301@pobox.com> <201101190113.p0J1DLPw018889@fs4113.wdf.sap.corp> From: Tim Dierks Date: Tue, 18 Jan 2011 21:25:18 -0500 X-Google-Sender-Auth: olqIma88ep9swNiyNnCNt2i2kRc Message-ID: To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=000325572a729fb5c4049a29bb27 Cc: tls@ietf.org Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 02:23:02 -0000 --000325572a729fb5c4049a29bb27 Content-Type: text/plain; charset=ISO-8859-1 He asserted SSL3/AES was not valid, but he didn't explain his rationale. Given that there is no standards-body ownership of SSL3, the correctness of AES ciphersuites is a moot point. However, Postel's robustness principle would tend to indicate that when a server selects such a ciphersuite, it would be best for a client to play along, correct or not. I can't immediately see any security reason why you'd be willing to negotiate SSL3, but turn up your nose at an insufficiently blessed AES ciphersuite. - Tim On Tue, Jan 18, 2011 at 8:53 PM, Wan-Teh Chang wrote: > On Tue, Jan 18, 2011 at 5:13 PM, Martin Rex wrote: > > > > But I know of at least one TLS implementation shipped by a large vendor > > that aborts on the combination of rfc-3268 cipher suites and SSLv3. > > Eric Lawrence explained this in the blog post "AES is not a valid > cipher for SSLv3": > > http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx > > Wan-Teh > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000325572a729fb5c4049a29bb27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable He asserted SSL3/AES was not valid, but he didn't explain his rationale= .

Given that there is no standards-body ownership of SSL= 3, the correctness of AES ciphersuites is a moot point. However, Postel'= ;s robustness principle would tend to indicate that when a server selects s= uch a ciphersuite, it would be best for a client to play along, correct or = not. I can't immediately see any security reason why you'd be willi= ng to negotiate SSL3, but turn up your nose at an insufficiently blessed AE= S ciphersuite.

=A0- Tim

On Tue, Jan = 18, 2011 at 8:53 PM, Wan-Teh Chang <wtc@google.com> wrote:
On Tue, Jan 18, 2011 at 5:13 PM, Martin Rex <mrex@sap.com> wrote:
>
> But I know of at least one TLS implementation shipped by a large vendo= r
> that aborts on the combination of rfc-3268 cipher suites and SSLv3.
Eric Lawrence explained this in the blog post "AES is not a vali= d
cipher for SSLv3":
http://blogs.msdn.com/b/= ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx=

Wan-Teh
__________________________________= _____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--000325572a729fb5c4049a29bb27-- From mrex@sap.com Wed Jan 19 11:04:31 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C704D3A6F0B for ; Wed, 19 Jan 2011 11:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.163 X-Spam-Level: X-Spam-Status: No, score=-10.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG5rbQF8Jez3 for ; Wed, 19 Jan 2011 11:04:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 9D3883A7057 for ; Wed, 19 Jan 2011 11:04:29 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0JJ736M002330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 20:07:03 +0100 (MET) From: Martin Rex Message-Id: <201101191907.p0JJ723Z018557@fs4113.wdf.sap.corp> To: tim@dierks.org (Tim Dierks) Date: Wed, 19 Jan 2011 20:07:02 +0100 (MET) In-Reply-To: from "Tim Dierks" at Jan 18, 11 09:25:18 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] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2011 19:04:31 -0000 > Wan-Teh Chang wrote: > > > Martin Rex wrote: > > > > > > But I know of at least one TLS implementation shipped by a large vendor > > > that aborts on the combination of rfc-3268 cipher suites and SSLv3. > > > > Eric Lawrence explained this in the blog post "AES is not a valid > > cipher for SSLv3": > > > > http://blogs.msdn.com/b/ieinternals/archive/2009/12/08/aes-is-not-a-valid-cipher-for-sslv3.aspx The info in that blog is very disappointing and looks lame to me. Why didn't they fix this defect after noticing the interop problem? 4 years have passed and this annoying defect has persisted through 2 service packs and a major OS release. Tim Dierks wrote: > > He asserted SSL3/AES was not valid, but he didn't explain his rationale. > > Given that there is no standards-body ownership of SSL3, the correctness of > AES ciphersuites is a moot point. However, Postel's robustness principle > would tend to indicate that when a server selects such a ciphersuite, it > would be best for a client to play along, correct or not. I can't > immediately see any security reason why you'd be willing to negotiate SSL3, > but turn up your nose at an insufficiently blessed AES ciphersuite. I assume you're the one listed as "Tim Dirks, Consensus Development" :) as (co)author on the right top here: http://tools.ietf.org/html/rfc2246 and potentially involved in the cipher suite interim registration here: http://tools.ietf.org/html/draft-ietf-tls-protocol-02#page-51 The definition of cipher suites in the design of SSL and TLS is mostly orthogonal to the protocol version, and the change control was over the cipher suite registry was undoubtedly transferred to the TLS. If cipher suites had ever been conceived to be protocol-version-specific, they would have partitioned the cipher suite code points. Quite obviously, the cipher suite registry was _NOT_ partitioned for TLSv1.0. cipher suites were issued with no distinction whatsoever, so they were clearly meant to apply in a protocol-version-independent fashion, forwards and backwards. I agree that impairing interoperability without a convince rationale why doing otherwise would create a security problem is an extremely poor engineering decision (commonly referred to as "bug"). Unless there is a (currently undocumented) security problem when a client agrees to using an rfc-3268 cipher suite with protocol version {0x03,0x00}, when that very same client would successfully complete the handshake if the server chose a more traditional cipher suite (like TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }), then such a client is defective/interoperability-impaired, and it would be much more benficial to the community to fix the (probably trivial to fix code-wise) defect rather than documenting how long the problem has been known and ignored, fully aware of the usability problems it inflicts on the consumers of the technology. -Martin From tdierks@gmail.com Wed Jan 19 11:30:30 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48ECB3A71AD for ; Wed, 19 Jan 2011 11:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9c8StgL6xav3 for ; Wed, 19 Jan 2011 11:30:29 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2A4DB3A71A4 for ; Wed, 19 Jan 2011 11:30:29 -0800 (PST) Received: by iyi42 with SMTP id 42so1221232iyi.31 for ; Wed, 19 Jan 2011 11:33:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=bvSmWeZMKfPhiS1+PX58JZi2JImJ7JCM/UGXi1ztQf8=; b=ScaX4GCaHFIZJ9tTPcUEpDzrNSsIn+JvCn6wVOrI7rwsZMqFq+pmhQsKHD93kmavyY psTuyy/vhu7kBXVr8X92Uv53pTVG4O1mlhk76+Dc+pYZN5cM5eyqNnZNqvcbeLgLfHBq TffUfwzFJeoQGziM6ZN7pu5CO8ANjWL0UaJ5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=CS8woIYpAZtepTOFEZAX9tI6706wwGmYRp8Npw9jkC50hVYoghP36TQN18Zb0Wk6IB ntzoFVz6ePDBfPo+J+wytT4MagfQIK6RDJUzsR2mMShKCAcewDZd03Qa1UeFuRIUXtEe jAzTPJHCw4JRT4j3Lq3RpXboen4S6I8NHfLQE= Received: by 10.231.39.67 with SMTP id f3mr1349313ibe.42.1295465566837; Wed, 19 Jan 2011 11:32:46 -0800 (PST) MIME-Version: 1.0 Sender: tdierks@gmail.com Received: by 10.231.59.200 with HTTP; Wed, 19 Jan 2011 11:32:26 -0800 (PST) In-Reply-To: <201101191907.p0JJ723Z018557@fs4113.wdf.sap.corp> References: <201101191907.p0JJ723Z018557@fs4113.wdf.sap.corp> From: Tim Dierks Date: Wed, 19 Jan 2011 14:32:26 -0500 X-Google-Sender-Auth: PfTcNNSxpyVG79_6eFS8SfXgWwM Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=00032557635aee1c4a049a38149c Cc: tls@ietf.org Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 19:30:30 -0000 --00032557635aee1c4a049a38149c Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 19, 2011 at 2:07 PM, Martin Rex wrote: > Tim Dierks wrote: > > > > He asserted SSL3/AES was not valid, but he didn't explain his rationale. > > > > Given that there is no standards-body ownership of SSL3, the correctness > of > > AES ciphersuites is a moot point. However, Postel's robustness principle > > would tend to indicate that when a server selects such a ciphersuite, it > > would be best for a client to play along, correct or not. I can't > > immediately see any security reason why you'd be willing to negotiate > SSL3, > > but turn up your nose at an insufficiently blessed AES ciphersuite. > > I assume you're the one listed as "Tim Dirks, Consensus Development" :) > > as (co)author on the right top here: > http://tools.ietf.org/html/rfc2246 > and potentially involved in the cipher suite interim registration here: > http://tools.ietf.org/html/draft-ietf-tls-protocol-02#page-51 "Dierks", but yes, that's no coincidence. > The definition of cipher suites in the design of SSL and TLS is > mostly orthogonal to the protocol version, and the change control > was over the cipher suite registry was undoubtedly transferred > to the TLS. If cipher suites had ever been conceived to be > protocol-version-specific, they would have partitioned the > cipher suite code points. > > Quite obviously, the cipher suite registry was _NOT_ partitioned > for TLSv1.0. cipher suites were issued with no distinction whatsoever, > so they were clearly meant to apply in a protocol-version-independent > fashion, forwards and backwards. > I think I'm in a position of authority to say that we didn't seriously consider the issue and there was no intention one way or the other about whether newly-defined ciphersuites were valid in SSLv3 or not. Overlaps needed to be excluded to avoid negotiation issues, but other than that, the issue wasn't considered. That's why I say that arguments about what is "correct" or not are really moot, because there's no actual standard that specifies one way or the other. - Tim --00032557635aee1c4a049a38149c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 19, 2011 at 2:07 PM, Martin Rex <mrex@sap.com> wrote:
Tim Dierks wrote:
>
> He asserted SSL3/AES was not valid, but he didn't explain his rati= onale.
>
> Given that there is no standards-body ownership of SSL3, the correctne= ss of
> AES ciphersuites is a moot point. However, Postel's robustness pri= nciple
> would tend to indicate that when a server selects such a ciphersuite, = it
> would be best for a client to play along, correct or not. I can't<= br> > immediately see any security reason why you'd be willing to negoti= ate SSL3,
> but turn up your nose at an insufficiently blessed AES ciphersuite.
I assume you're the one listed as "Tim Dirks, Consensus Deve= lopment" =A0:)

=A0as (co)author on the right top here:
=A0 =A0 =A0 =A0http://tools.ietf.org/html/rfc2246
=A0and potentially involved in the cipher suite interim registration here:<= br> =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-tls-= protocol-02#page-51

"Dierks",= but yes, that's no coincidence.
=A0
The definition of cipher suit= es in the design of SSL and TLS is
mostly orthogonal to the protocol version, and the change control
was over the cipher suite registry was undoubtedly transferred
to the TLS. =A0If cipher suites had ever been conceived to be
protocol-version-specific, they would have partitioned the
cipher suite code points.

Quite obviously, the cipher suite registry was _NOT_ partitioned
for TLSv1.0. =A0cipher suites were issued with no distinction whatsoever, so they were clearly meant to apply in a protocol-version-independent
fashion, forwards and backwards.

I thin= k I'm in a position of authority to say that we didn't seriously co= nsider the issue and there was no intention one way or the other about whet= her newly-defined ciphersuites were valid in SSLv3 or not. Overlaps needed = to be excluded to avoid negotiation issues, but other than that, the issue = wasn't considered. That's why I say that arguments about what is &q= uot;correct" or not are really moot, because there's no actual sta= ndard that specifies one way or the other.

=A0- Tim

--00032557635aee1c4a049a38149c-- From marsh@extendedsubset.com Wed Jan 19 12:21:12 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A6D3A7014 for ; Wed, 19 Jan 2011 12:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lmx9z-LINj8 for ; Wed, 19 Jan 2011 12:21:11 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id B253A3A6F18 for ; Wed, 19 Jan 2011 12:21:11 -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 1PfeZM-0009n2-9X; Wed, 19 Jan 2011 20:23:52 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 9EF73603D; Wed, 19 Jan 2011 20:23: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: U2FsdGVkX182s1a51T0qEgAYoA3/NMrZLNE0qTgghgA= Message-ID: <4D374855.20207@extendedsubset.com> Date: Wed, 19 Jan 2011 14:23:49 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: mrex@sap.com References: <201101191907.p0JJ723Z018557@fs4113.wdf.sap.corp> In-Reply-To: <201101191907.p0JJ723Z018557@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] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 20:21:12 -0000 On 01/19/2011 01:07 PM, Martin Rex wrote: > > If cipher suites had ever been conceived to be > protocol-version-specific, they would have partitioned the > cipher suite code points. > > Quite obviously, the cipher suite registry was _NOT_ partitioned > for TLSv1.0. cipher suites were issued with no distinction whatsoever, > so they were clearly meant to apply in a protocol-version-independent > fashion, forwards and backwards. +1 We have to keep in mind that SSLv3 is deprecated abandon-ware, but this premise "AES ciphers are not valid choices for SSLv3" is wrong. If the client proposes advertises a range of protocol versions and the server picks a value from that range, and if the client proposes a set of ciphersuites and the server picks a ciphersuite from that set, then interoperability should ensue. Note the similarity with the servers that fail to handshake with clients who propose extensions. "SSLv3 does not allow extensions" was the justification given that time. SSL/TLS is an extensible protocol, just because some options weren't defined at the time of the core protocol version doesn't mean they're invalid to use. The handshake negotiation was designed to allow this. The problem is that the client is in some sort of "fall back to SSLv3" heuristic mode. The reason clients are forced to do that is the occasional presence of poorly interoperating servers. The root cause is thus the poorly interoperating servers. They are the stratospheric chlorofluorocarbons catalyzing away the ozone. They do damage to the ecosystem with a large multiplier effect. The only solution is to relentlessly pursue interoperability and be diligent about providing updates. - Marsh From wtc@google.com Wed Jan 19 13:56:43 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F41D3A71D6 for ; Wed, 19 Jan 2011 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UetM-mYs9dZr for ; Wed, 19 Jan 2011 13:56:42 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 346A03A71C5 for ; Wed, 19 Jan 2011 13:56:41 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p0JLxL2x021630 for ; Wed, 19 Jan 2011 13:59:22 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295474362; bh=CpidGTNPu6YC2RWBQEXAV5/V6m4=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=kSN+CE/M9dwuZmP0qp/HCTWPo7lBcLyA6VxQJGslHX+qQeeJpROXHnKLimlLf3axN Qw/tqKSAHBh1fJIquZw2g== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by wpaz1.hot.corp.google.com with ESMTP id p0JLxKHM030726 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Jan 2011 13:59:20 -0800 Received: by gyf1 with SMTP id 1so675991gyf.7 for ; Wed, 19 Jan 2011 13:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s/fG1qXMB85YnPPJqmPb23VfZ+MVkbnwYntVajsesho=; b=tMzO1NpDYIVaZfkdZGRVZxwYZm0x34rCeR4yAKO9jZVbTbNn67MCoIpBD1Yu1us+9o KkAOvIA4f8ZBZ+TDC8Lg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eU0AcKTUuDJiIGeO9eT6E5BxgpgUQfHHfzlN8QkzMMqFUo4YTPSmV7j6oFXkg7wAMR P54DAMwvsJBKJ0YRpI2Q== MIME-Version: 1.0 Received: by 10.216.22.131 with SMTP id t3mr1220344wet.2.1295474359747; Wed, 19 Jan 2011 13:59:19 -0800 (PST) Received: by 10.216.6.81 with HTTP; Wed, 19 Jan 2011 13:59:19 -0800 (PST) In-Reply-To: <4D374855.20207@extendedsubset.com> References: <201101191907.p0JJ723Z018557@fs4113.wdf.sap.corp> <4D374855.20207@extendedsubset.com> Date: Wed, 19 Jan 2011 13:59:19 -0800 Message-ID: From: Wan-Teh Chang To: Marsh Ray Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: tls@ietf.org Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 19 Jan 2011 21:56:43 -0000 On Wed, Jan 19, 2011 at 12:23 PM, Marsh Ray wrote: > > The problem is that the client is in some sort of "fall back to SSLv3" > heuristic mode. The reason clients are forced to do that is the occasional > presence of poorly interoperating servers. > > The root cause is thus the poorly interoperating servers. For the SSLv3 AES cipher suite problem, it is the client (in SChannel) that is poorly interoperating. Another problem is how an RFC of a TLS feature references TLS. It usually references the latest version of TLS only. For example, RFC 5746 (the TLS renegotiation indication extension) references the TLS 1.2 RFC (RFC 5246) only. An implementor could be misled into thinking the TLS feature is only applicable to that version of TLS. Wan-Teh From mrex@sap.com Wed Jan 19 14:13:16 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D165028C0CE for ; Wed, 19 Jan 2011 14:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.164 X-Spam-Level: X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmCZvmkR0RWx for ; Wed, 19 Jan 2011 14:13:16 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id CE4813A71E2 for ; Wed, 19 Jan 2011 14:13:15 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0JMFp12012228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 23:15:51 +0100 (MET) From: Martin Rex Message-Id: <201101192215.p0JMFotX029338@fs4113.wdf.sap.corp> To: wtc@google.com (Wan-Teh Chang) Date: Wed, 19 Jan 2011 23:15:50 +0100 (MET) In-Reply-To: from "Wan-Teh Chang" at Jan 19, 11 01:59:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 19 Jan 2011 22:13:16 -0000 Wan-Teh Chang wrote: > > Another problem is how an RFC of a TLS feature references TLS. It > usually references the latest version of TLS only. For example, RFC > 5746 (the TLS renegotiation indication extension) references the TLS > 1.2 RFC (RFC 5246) only. An implementor could be misled into thinking > the TLS feature is only applicable to that version of TLS. While you're correct about a number of TLS-related documents, RFC5746 is an exception to this tradition and refers to all existing versions of TLS explicitly, and to SSLv3 on top of that. http://tools.ietf.org/html/rfc5746 -Martin From mrex@sap.com Wed Jan 19 16:51:38 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F933A7069 for ; Wed, 19 Jan 2011 16:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHaYtTv4nOX0 for ; Wed, 19 Jan 2011 16:51:37 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 1C9BA3A7052 for ; Wed, 19 Jan 2011 16:51:36 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p0K0sCA3004685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 01:54:12 +0100 (MET) From: Martin Rex Message-Id: <201101200054.p0K0sBPh008067@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 20 Jan 2011 01:54:11 +0100 (MET) In-Reply-To: <201101192215.p0JMFotX029338@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 19, 11 11:15:50 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] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jan 2011 00:51:38 -0000 Martin Rex wrote: > > Wan-Teh Chang wrote: > > > > Another problem is how an RFC of a TLS feature references TLS. It > > usually references the latest version of TLS only. > > ... An implementor could be misled into thinking > > the TLS feature is only applicable to that version of TLS. > > While you're correct about a number of TLS-related documents ... I believe that some of the TLS related RFCs use the Obsolete/Update markers in a fashion quite different from how these markers are meant to be used. An a small error in that tagging, that appears to have started with rfc-4366, has propagated to other TLS-related RFCs. e.g. 4346, ->(4366), ->5246, ->6066 Quoting from RFC2223 "Instructions to RFC Authors" http://tools.ietf.org/html/rfc2223#section-12 Updates To be used as a reference from a new item that cannot be used alone (i.e., one that supplements a previous document), to refer to the previous document. The newer publication is a part that will supplement or be added on to the existing document; e.g., an addendum, or separate, extra information that is to be added to the original document. Obsoletes To be used to refer to an earlier document that is replaced by this document. This document contains either revised information, or else all of the same information plus some new information, however extensive or brief that new information is; i.e., this document can be used alone, without reference to the older document. For example, the defective "obsoletes" allegations of the base TLS protocol specs have adversely affected the third update of the TLS extensions document (rfc-6066). The second update transition of the TLS extensions document 3546->4366 was correct about the obsoletion (but is missing the update: marker) to implement TLSv1.0 with TLS extensions you can use RFCs 2246+4366 to implement TLSv1.1 with TLS extensions you can use RFCs 4346+4366 however 2246+6066 is insufficient to implement TLSv1.0 with TLS extensions and 4346+6066 is insufficient to implement TLSv1.1 with TLS extensions --you still need 4366 because the definition of the Extended Hello PDU is not part 6066. 6066 is an updated version of the "leftover parts" of 4366 that didn't make it into 5246--which bars it from obsoleting 4366. Overview of the header markings for some TLS documents: for the TLS Protocol documents: TLSv1.0 rfc-2246 - (OK) TLSv1.1 rfc-4346 shows (INVALID): Obsoletes: 2246 MISSING: Updates: 2246 TLSv1.1 rfc-5246 shows (INVALID): Obsoletes: 3268, 4346, 4366 shows (OK): Updates: 4492 MISSING: Updates: 2246, 3268, 4346, 4366 and for TLS Extensions documents: TLSext rfc-3546 shows (OK): Updates: 2246 TLSext rfc-4366 shows (OK): Obsoletes: 3546 MISSING: Updates: 2246, 4346 TLSext rfc-6066 shows (INVALID): Obsoletes: 4366 MISSING: Updates: 4366, 5246 TLS v1.0, TLSv1.1 and TLSv1.2 are protocol with small and subtle differences. But some of the information (like the Certificate handshake message PDU used by SSLv3,TLSv1.0,TLSv1.1) is not part of the TLS v1.2 spec (rfc-5246), so according to rfc-2223, the allegation of rfc-5246 to obsolete the TLSv1.0 and TLSv1.1 _spec_documents_ is clearly invalid. An example of correct obsoletion is the three (base) HTTP protocol specs: rfc1945 HTTP/1.0 @PROPOSED rfc2068 HTTP/1.1 @PROPOSED rfc2616 HTTP/1.1 @DRAFT (Obsoletes: 2068) to implement HTTP/1.0 you only need 1945, and to implement HTTP/1.1 you only need 2616, therefore 2068 meets the rfc2223 definition of Obsolete. Now there is an irony to this. The incorrect markers on rfc-4346 appear to have started the problem for the TLS-related documents. And it is exactly the document header of rfc-4346 with the invalid Obsolete: marker that gets used for illustration of document header formatting in rfc-5741: http://tools.ietf.org/html/rfc5741#page-4 -Martin From mrex@sap.com Thu Jan 20 05:59:47 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755633A7122 for ; Thu, 20 Jan 2011 05:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5SkCQ6K4pN8 for ; Thu, 20 Jan 2011 05:59:46 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 4B0063A7117 for ; Thu, 20 Jan 2011 05:59:46 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p0KE2IRs006905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 15:02:23 +0100 (MET) From: Martin Rex Message-Id: <201101201402.p0KE2HhW022434@fs4113.wdf.sap.corp> To: mrex@sap.com Date: Thu, 20 Jan 2011 15:02:17 +0100 (MET) In-Reply-To: <201101200054.p0K0sBPh008067@fs4113.wdf.sap.corp> from "Martin Rex" at Jan 20, 11 01:54: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] AES and SSLv3 (was Re: Unfortunate current practices for HTTP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jan 2011 13:59:47 -0000 Ooops. I meant CertificateRequest not Certificate. TLSv1.0: http://tools.ietf.org/html/rfc2246#section-7.4.4 TLSv1.1: http://tools.ietf.org/html/rfc4346#section-7.4.4 TLSv1.2: http://tools.ietf.org/html/rfc5246#section-7.4.4 There is a significant PDU change from TLSv1.1 -> TLSv1.2. (insertion of a SignatureAndHashAlgorithm list) The change between SSLv3/TLSv1.0 and TLSv1.1 is "fairly" small (unknown to some and many implementations have it wrong). -Martin From turners@ieca.com Thu Jan 20 10:12:54 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73C733A7041 for ; Thu, 20 Jan 2011 10:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlnVXc6JLnWu for ; Thu, 20 Jan 2011 10:12:53 -0800 (PST) Received: from nm16-vm0.bullet.mail.sp2.yahoo.com (nm16-vm0.bullet.mail.sp2.yahoo.com [98.139.91.210]) by core3.amsl.com (Postfix) with SMTP id CFC153A7011 for ; Thu, 20 Jan 2011 10:12:53 -0800 (PST) Received: from [98.139.91.64] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jan 2011 18:15:34 -0000 Received: from [98.139.91.52] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 20 Jan 2011 18:15:34 -0000 Received: from [127.0.0.1] by omp1052.mail.sp2.yahoo.com with NNFMP; 20 Jan 2011 18:15:34 -0000 X-Yahoo-Newman-Id: 756592.98900.bm@omp1052.mail.sp2.yahoo.com Received: (qmail 11676 invoked from network); 20 Jan 2011 18:15:34 -0000 Received: from thunderfish.local (turners@71.191.14.145 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 20 Jan 2011 10:15:33 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: c.yiVEcVM1nB.QR.0_9sUM0jzrsCSWeWKMv_rQx9jkttzQa R1Gr2wAMd5NxLYC9Fw7.1jm1y6j6ELTj0kTkwNZjJetd5S.VHPoxZYjY3aWi HJ2uUIdZKsoOQrfoQFWD2pW5WpBsqbR_oAw4iBNwACv8vJk6sYoypSyiomBp Sp_cs0rHTm5IgyKNeNhP3C9BRpxpe5aHYTSJXSH.tt50B3aQvsPN0W0NluiW L6LCFFqWO11BJGespcATaTAKLRBWowLtfakicbN3MQmiKb2G9lTqwooi8M_H B3_iPi4fV6trgVXcg9oWfr9HFafp9ohefMZpS8pRTBN2bh6wJvWyo4C4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D387BC5.5000103@ieca.com> Date: Thu, 20 Jan 2011 13:15:33 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org References: <20110118203229.59390E0732@rfc-editor.org> In-Reply-To: <20110118203229.59390E0732@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] RFC 6066 on Transport Layer Security (TLS) Extensions: Extension Definitions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 20 Jan 2011 18:12:54 -0000 On 1/18/11 3:32 PM, rfc-editor@rfc-editor.org wrote: > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6066 > > Title: Transport Layer Security (TLS) Extensions: > Extension Definitions > Author: D. Eastlake 3rd > Status: Standards Track > Stream: IETF > Date: January 2011 > Mailbox: d3e3e3@gmail.com > Pages: 25 > Characters: 55079 > Obsoletes: RFC4366 > > I-D Tag: draft-ietf-tls-rfc4366-bis-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc6066.txt Congrats to all those involved. spt From Jeff.Hodges@KingsMountain.com Fri Jan 21 17:09:21 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69B83A6889 for ; Fri, 21 Jan 2011 17:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwdinxwvfnsi for ; Fri, 21 Jan 2011 17:09:21 -0800 (PST) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id E43063A6884 for ; Fri, 21 Jan 2011 17:09:20 -0800 (PST) Received: (qmail 4606 invoked by uid 0); 22 Jan 2011 01:12:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy2.bluehost.com with SMTP; 22 Jan 2011 01:12:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=dj/wKyG+45ogwhAyDZjryPOrAC+fDxMHdZwndBNPzO89fjOzCPC9TOw4exFzXEQBLA5NQNq9P/LGtjt+D2wFHHvNCPyJZ6MEk0ZhiMP7ruplGKuAYDU1SsUd3kWgODQ7; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1PgS1P-000684-IX; Fri, 21 Jan 2011 18:12:07 -0700 Message-ID: <4D3A2EE5.4030804@KingsMountain.com> Date: Fri, 21 Jan 2011 17:12:05 -0800 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20101027) 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 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF Security Area Advisory Group Subject: [TLS] fyi: [certid] IESG approval of draft-saintandre-tls-server-id-check-14 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 22 Jan 2011 01:09:21 -0000 Subject: [certid] IESG approval of draft-saintandre-tls-server-id-check-14 From: Peter Saint-Andre Date: Thu, 20 Jan 2011 19:20:57 -0700 (18:20 PST) To: IETF cert-based identity During its telechat earlier today, the IESG approved version -14 of draft-saintandre-tls-server-id-check as a Proposed Standard (not BCP). I'll leave it to Alexey Melnikov, our sponsoring area director, to explain the details about where we go from here (e.g., possible incorporation of small text modifications resulting from the discussion thread between Matt McCutchen and Jeff Hodges over the last 3 days). For myself, I fully expect to be working on a bis draft at some point in the next few years, because I don't think that this I-D is quite the final word on the topic. However, I do think it brings us closer to wide consensus regarding application service identity, and that perhaps the bis draft could be a true BCP (developed, I would think, within the TLS WG). Thanks to everyone who contributed to and provided feedback on this document -- your input is very much appreciated! Peter -- Peter Saint-Andre https://stpeter.im/ From Internet-Drafts@ietf.org Thu Jan 27 03:45:03 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F6B03A6B31; Thu, 27 Jan 2011 03:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+7VZ-jekBZA; Thu, 27 Jan 2011 03:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DC03A6B2E; Thu, 27 Jan 2011 03:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110127114502.24680.73782.idtracker@localhost> Date: Thu, 27 Jan 2011 03:45:02 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2011 11:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension Author(s) : R. Seggelmann, et al. Filename : draft-ietf-tls-dtls-heartbeat-01.txt Pages : 8 Date : 2011-01-27 This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path maximum transmission unit (PMTU) discovery for DTLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls-heartbeat-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-dtls-heartbeat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-27033538.I-D@ietf.org> --NextPart-- From simon@josefsson.org Thu Jan 27 04:35:48 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9BF3A677C for ; Thu, 27 Jan 2011 04:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.846 X-Spam-Level: X-Spam-Status: No, score=-102.846 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4ElWwcMwqWi for ; Thu, 27 Jan 2011 04:35:47 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id 9BD693A6778 for ; Thu, 27 Jan 2011 04:35:46 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0RCchDZ003868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 27 Jan 2011 13:38:45 +0100 From: Simon Josefsson To: tls@ietf.org References: <20110127114502.24680.73782.idtracker@localhost> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110127:tls@ietf.org::I+ff0G2DNwepmwX5:0Jpv X-Hashcash: 1:22:110127:i-d-announce@ietf.org::QNnMJwejfPDo7qwa:6T/n X-Hashcash: 1:22:110127:internet-drafts@ietf.org::pFe9hRByS9olyXFb:RZ23 Date: Thu, 27 Jan 2011 13:38:43 +0100 In-Reply-To: <20110127114502.24680.73782.idtracker@localhost> (Internet-Drafts@ietf.org's message of "Thu, 27 Jan 2011 03:45:02 -0800") Message-ID: <874o8uplm4.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2011 12:35:48 -0000 This looks like a useful extension, it is similar to the unfortunately non-standard keepalive feature in SSH (that I happened to implement for libssh2 not long ago). I have one mild concern with permitting arbitrary payload. What is the rationale for this? It opens up for a side channel in TLS. It could also be abused to send non-standardized data. Further, is there any reason to allow arbitrary sized payload? In my opinion, the payload_length, payload and padding fields seems unnecessary to me. /Simon struct { HeartbeatMessageType type; uint16 payload_length; opaque payload[HeartbeatMessage.payload_length]; opaque padding[padding_length]; } HeartbeatMessage; The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]. type The message type, either heartbeat_request or heartbeat_response. payload_length The length of the payload. payload The payload consists of arbitrary content. From fweimer@bfk.de Thu Jan 27 04:57:25 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B56F3A67F0 for ; Thu, 27 Jan 2011 04:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH3BlB20JQYM for ; Thu, 27 Jan 2011 04:57:24 -0800 (PST) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 533223A67D4 for ; Thu, 27 Jan 2011 04:57:24 -0800 (PST) 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 1PiRSd-0007ru-5J for tls@ietf.org; Thu, 27 Jan 2011 13:00:27 +0000 Received: by bfk.de with local id 1PiRSd-0006PL-2Y for tls@ietf.org; Thu, 27 Jan 2011 13:00:27 +0000 To: tls@ietf.org References: <20110127114502.24680.73782.idtracker@localhost> From: Florian Weimer Date: Thu, 27 Jan 2011 13:00:27 +0000 In-Reply-To: <20110127114502.24680.73782.idtracker@localhost> (Internet-Drafts@ietf.org's message of "Thu\, 27 Jan 2011 03\:45\:02 -0800") Message-ID: <8239oeqz6c.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2011 12:57:25 -0000 > This document describes the Heartbeat Extension for the Transport > Layer Security (TLS) and Datagram Transport Layer Security (DTLS) > protocol. I think this paragraph | There MUST NOT be more than one HeartbeatRequest message in flight | at a time. should be changed to: | Retransmissions MUST use the same payload as the original | HeartbeatRequest message. The original requirement seems to be pretty much unimplementable because of transport layer characteristics. --=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 Michael.Tuexen@lurchi.franken.de Thu Jan 27 05:46:40 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B2D3A6842 for ; Thu, 27 Jan 2011 05:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFr9zBND1Mk6 for ; Thu, 27 Jan 2011 05:46:39 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 4D6A53A6838 for ; Thu, 27 Jan 2011 05:46:39 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id D95BF1C0B4612; Thu, 27 Jan 2011 14:49:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <8239oeqz6c.fsf@mid.bfk.de> Date: Thu, 27 Jan 2011 14:49:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4848B682-273F-4B52-B9E2-ACBFDFDAAB7F@lurchi.franken.de> References: <20110127114502.24680.73782.idtracker@localhost> <8239oeqz6c.fsf@mid.bfk.de> To: Florian Weimer X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2011 13:46:40 -0000 On Jan 27, 2011, at 2:00 PM, Florian Weimer wrote: >> This document describes the Heartbeat Extension for the Transport >> Layer Security (TLS) and Datagram Transport Layer Security (DTLS) >> protocol. >=20 > I think this paragraph >=20 > | There MUST NOT be more than one HeartbeatRequest message in flight > | at a time. >=20 > should be changed to: >=20 > | Retransmissions MUST use the same payload as the original > | HeartbeatRequest message. The intention of the sentence in the ID is that you can not send multiple HeartbeatRequest out. This could overload the network since DTLS uses transport layers which do not necessary provide a congestion control. That is why you can only have one request in flight. Please note that it is not in flight anymore if the corresponding HeartbeatReply has been received or the retransmission timer fires. >=20 > The original requirement seems to be pretty much unimplementable > because of transport layer characteristics. Not sure what problem you are thinking about. An implementation of the ID for OpenSSL is available at http://sctp.fh-muenster.de/dtls-patches.html Best regards Michael >=20 > --=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 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 From Michael.Tuexen@lurchi.franken.de Thu Jan 27 10:59:23 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31A428C14D for ; Thu, 27 Jan 2011 10:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEO+mjCJZ-DI for ; Thu, 27 Jan 2011 10:59:22 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 648F73A6828 for ; Thu, 27 Jan 2011 10:59:22 -0800 (PST) Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 851DE1C0B4626; Thu, 27 Jan 2011 20:02:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Michael_T=FCxen?= In-Reply-To: <874o8uplm4.fsf@latte.josefsson.org> Date: Thu, 27 Jan 2011 20:02:24 +0100 Content-Transfer-Encoding: 7bit Message-Id: <09E8BE99-3D69-4693-99DF-2DDD9D48B52B@lurchi.franken.de> References: <20110127114502.24680.73782.idtracker@localhost> <874o8uplm4.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1082) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-dtls-heartbeat-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 27 Jan 2011 18:59:23 -0000 On Jan 27, 2011, at 1:38 PM, Simon Josefsson wrote: > This looks like a useful extension, it is similar to the unfortunately > non-standard keepalive feature in SSH (that I happened to implement for > libssh2 not long ago). > > I have one mild concern with permitting arbitrary payload. What is the > rationale for this? It opens up for a side channel in TLS. It could For the payload: When receiving a HeartbeatResponse the node must check if it matches the current HeartbeatRequest. By using the simple reflection mode this is possible. It is possible to do this with a sequence number, but you might want to measure a round trip time, so you could put in a time stamp or something else. The point here is that for interoperability, it does not matter what the payload is, it is only important that it is reflected. For the padding: When doing path MTU discovery you send messages of a particular length. Since the MTU in one direction can be different from the MTU in the opposite direction, you can not just reflect the test messages used to perform path MTU discovery. The packets sent in the backwards direction need to be small. This can be done by sending a padding which is dropped by the receiver. So you could argue that you can use these fields for steganography. We can add such a statement to the security considerations. However, both fields are necessary. > also be abused to send non-standardized data. Further, is there any > reason to allow arbitrary sized payload? In my opinion, the > payload_length, payload and padding fields seems unnecessary to me. As explained above, I think both fields are necessary. Best regards Michael > > /Simon > > struct { > HeartbeatMessageType type; > uint16 payload_length; > opaque payload[HeartbeatMessage.payload_length]; > opaque padding[padding_length]; > } HeartbeatMessage; > > The length of a HeartbeatMessage in total MUST NOT exceed 2^14 or > max_fragment_length when negotiated as defined in [RFC6066]. > > type The message type, either heartbeat_request or > heartbeat_response. > > payload_length The length of the payload. > > payload The payload consists of arbitrary content. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From paul.hoffman@vpnc.org Mon Jan 31 08:32:23 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A263A3A6B32 for ; Mon, 31 Jan 2011 08:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.012 X-Spam-Level: X-Spam-Status: No, score=-101.012 tagged_above=-999 required=5 tests=[AWL=-0.455, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce-GChQl1bog for ; Mon, 31 Jan 2011 08:32:21 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id E5D9D3A6AE5 for ; Mon, 31 Jan 2011 08:32:20 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p0VGZYDv070144 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 31 Jan 2011 09:35:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D46E4D8.3090307@vpnc.org> Date: Mon, 31 Jan 2011 08:35:36 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] TLS 1.2 test clients? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Jan 2011 16:32:24 -0000 Greetings again. I would like to test how servers react to a TLS client that only does TLS 1.2. There are two browsers that can be put into this state (IE under Win 7, and Opera), but neither give very good diagnostics when a failure occurs. Further, Wireshark doesn't give good dumps for TLS 1.2. Thus, if anyone here has a TLS 1.2 client that has reasonable debugging of the TLS handshake and can do trivial HTTP (just send a "GET /" and receive the response would be fine) after setting up a tunnel, I'd greatly appreciate it. Also, if anyone has a Wireshark plugin (?) that brings its TLS decoding up to 1.2, that would be great as well. --Paul Hoffman, Director --VPN Consortium From alangley@gmail.com Mon Jan 31 09:50:58 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0383A69A9 for ; Mon, 31 Jan 2011 09:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+EhQC1UhbZP for ; Mon, 31 Jan 2011 09:50:57 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 4E4753A6844 for ; Mon, 31 Jan 2011 09:50:57 -0800 (PST) Received: by iyi42 with SMTP id 42so5598165iyi.31 for ; Mon, 31 Jan 2011 09:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TuLrZS1ZaiFngns1zQzyfxVWBWBR3s5aX5Tt6oVqpUQ=; b=q26bhRZ+dmTFbKiYNU9HuPI7X+jisOmTGbgpoF+e+Xc5iSKKYClI+7zbqafYFGJplv jpSJfxa5+Ec8QDAW5aGOfY43y4cBoPhV7gaQ/9Kjxh6NuBH4tFtseuvx+Xp4F5WaC7ar m4FqkjxrxlUwrBq1NUBSajsBJQnwzt7SB40+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=r7u+V682zPywtSDhU9Zu14UQYi+ANQybnAoU7YxvBWYeyP62nM9ZqpxoolBXBzgfmL jATEBUUjgn07N4EmU39Dkq53CE0VojBStHBpLfSbijF/dXiMCEkyR69ddS1Pp0Q/WYKh +TJp3LaXLP+dkGgQT4ggkImtXaCJOSI85nqb0= MIME-Version: 1.0 Received: by 10.42.220.73 with SMTP id hx9mr8126981icb.521.1296496451842; Mon, 31 Jan 2011 09:54:11 -0800 (PST) Sender: alangley@gmail.com Received: by 10.42.240.136 with HTTP; Mon, 31 Jan 2011 09:54:11 -0800 (PST) In-Reply-To: <4D46E4D8.3090307@vpnc.org> References: <4D46E4D8.3090307@vpnc.org> Date: Mon, 31 Jan 2011 12:54:11 -0500 X-Google-Sender-Auth: ufYPhz2d1nmRaZW5_4OZM1W3854 Message-ID: From: Adam Langley To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.2 test clients? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Jan 2011 17:50:58 -0000 On Mon, Jan 31, 2011 at 11:35 AM, Paul Hoffman wrote: > Thus, if anyone here has a TLS 1.2 client that has reasonable debugging of > the TLS handshake and can do trivial HTTP (just send a "GET /" and receive > the response would be fine) after setting up a tunnel, I'd greatly > appreciate it. Also, if anyone has a Wireshark plugin (?) that brings its > TLS decoding up to 1.2, that would be great as well. GnuTLS can do TLS 1.2 and their command line tools can dump pretty good debugging information. That's what I've used previously for TLS 1.2 matters. (However, you might want to grab the code from git as, some month's ago, their 1.2 Finished calculation had to be fixed.) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org From simon@josefsson.org Mon Jan 31 11:18:03 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B673A6B32 for ; Mon, 31 Jan 2011 11:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.982 X-Spam-Level: X-Spam-Status: No, score=-102.982 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eVv0l2lJyMc for ; Mon, 31 Jan 2011 11:18:02 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [213.115.69.139]) by core3.amsl.com (Postfix) with ESMTP id A14773A6C52 for ; Mon, 31 Jan 2011 11:18:01 -0800 (PST) Received: from latte.josefsson.org (c80-216-4-108.bredband.comhem.se [80.216.4.108]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p0VJL9PQ012813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Jan 2011 20:21:11 +0100 From: Simon Josefsson To: Paul Hoffman References: <4D46E4D8.3090307@vpnc.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:110131:paul.hoffman@vpnc.org::ScZ4FbU5K6V897qd:V/s X-Hashcash: 1:22:110131:tls@ietf.org::mUAvZQrkd9Ra9K7P:BlIV Date: Mon, 31 Jan 2011 20:21:09 +0100 In-Reply-To: <4D46E4D8.3090307@vpnc.org> (Paul Hoffman's message of "Mon, 31 Jan 2011 08:35:36 -0800") Message-ID: <87aaigg9qy.fsf@latte.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.5 at yxa-v X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.2 test clients? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list 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, 31 Jan 2011 19:18:03 -0000 Paul Hoffman writes: > Greetings again. I would like to test how servers react to a TLS > client that only does TLS 1.2. There are two browsers that can be put > into this state (IE under Win 7, and Opera), but neither give very > good diagnostics when a failure occurs. Further, Wireshark doesn't > give good dumps for TLS 1.2. > > Thus, if anyone here has a TLS 1.2 client that has reasonable > debugging of the TLS handshake and can do trivial HTTP (just send a > "GET /" and receive the response would be fine) after setting up a > tunnel, I'd greatly appreciate it. Also, if anyone has a Wireshark > plugin (?) that brings its TLS decoding up to 1.2, that would be great > as well. GnuTLS's gnutls-cli can act as a simple TLS 1.2 client, see transcript below. /Simon jas@latte:~$ gnutls-cli -p 443 www.mikestoolbox.net --priority NORMAL:-VERS-SSL3.0:-VERS-TLS1.1:-VERS-TLS1.0 Resolving 'www.mikestoolbox.net'... Connecting to '24.234.114.35:443'... - Successfully sent 0 certificate(s) to server. - Ephemeral Diffie-Hellman parameters - Using prime: 1024 bits - Secret key: 1023 bits - Peer's public key: 1024 bits - Server has requested a certificate. - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=US,O=Mike's Toolbox,CN=www.mikestoolbox.net', issuer `C=US,O=Mike's Toolbox,CN=Mike's Toolbox Test CA', RSA key 1024 bits, signed using RSA-SHA256, activated `2010-03-05 21:19:00 UTC', expires `2011-03-05 21:19:00 UTC', SHA-1 fingerprint `d250a3f337064b63c8288c6a5bb540af3c44be97' - Certificate[1] info: - subject `C=US,O=Mike's Toolbox,CN=Mike's Toolbox Test CA', issuer `C=US,O=Mike's Toolbox,CN=Mike's Toolbox Test CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2010-03-05 21:18:59 UTC', expires `2012-03-05 21:18:59 UTC', SHA-1 fingerprint `0e4fa65463bb38397bc24cc3259a803554963c79' - The hostname in the certificate matches 'www.mikestoolbox.net'. - Peer's certificate issuer is unknown - Peer's certificate is NOT trusted - Version: TLS1.2 - Key Exchange: DHE-RSA - Cipher: AES-128-CBC - MAC: SHA256 - Compression: NULL - Handshake was completed - Simple Client Mode: GET / HTTP/1.0 HTTP/1.0 200 Ok Date: Mon, 31 Jan 2011 19:19:23 GMT Server: Mike's-Toolbox-Custom-Web-Server/3.7+3.2i Content-Type: text/plain; charset=utf-8 Content-Length: 4458 ****************************************************************** *** Mike's Toolbox Enhanced Multi-Threaded SSL/TLS Test Server *** *** *** *** https://www.mikestoolbox.net/ *** *** https://www.mikestoolbox.org/ *** *** *** *** Mike's Toolbox contact info: *** *** *** *** EMAIL: mikestoolbox@pobox.com *** *** WEB: http://mikestoolbox.com/ *** *** TWITTER: @mikestoolbox *** *** *** *** Copyright (c) 2010 Michael D'Errico, All Rights Reserved *** ****************************************************************** Connection from: [80.216.4.108] Current time: Mon, 31 Jan 2011 19:19:20 GMT TLS negotiation time: 0.57711601 seconds Client Version: TLS 1.2 Client Random: 4D470B37F2873BC83EF553A79937F35A8F9E9EFB63FAC0B60D0A383B9131D738 Client Random Time: Mon, 31 Jan 2011 19:19:19 GMT Client Session ID: Client Cipher Suites: 0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 0033 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 0045 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA 006B TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 0039 TLS_DHE_RSA_WITH_AES_256_CBC_SHA 0088 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 0016 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 0040 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 0032 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 0044 TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA 006A TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 0038 TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0087 TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA 0013 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 0066 TLS_DHE_DSS_WITH_RC4_128_SHA 0090 TLS_DHE_PSK_WITH_AES_128_CBC_SHA 0091 TLS_DHE_PSK_WITH_AES_256_CBC_SHA 008F TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 008E TLS_DHE_PSK_WITH_RC4_128_SHA 003C TLS_RSA_WITH_AES_128_CBC_SHA256 002F TLS_RSA_WITH_AES_128_CBC_SHA 0041 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA 003D TLS_RSA_WITH_AES_256_CBC_SHA256 0035 TLS_RSA_WITH_AES_256_CBC_SHA 0084 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 000A TLS_RSA_WITH_3DES_EDE_CBC_SHA 0005 TLS_RSA_WITH_RC4_128_SHA 008C TLS_PSK_WITH_AES_128_CBC_SHA 008D TLS_PSK_WITH_AES_256_CBC_SHA 008B TLS_PSK_WITH_3DES_EDE_CBC_SHA 008A TLS_PSK_WITH_RC4_128_SHA Client Compression: 0 NULL Server Version: TLS 1.2 Server Random: 4D470B37F8BCDF0D263BC2415288665A08E162FD0519E210C14DC2000925D03B Server Random Time: Mon, 31 Jan 2011 19:19:19 GMT Server Session ID: Server Cipher Suite: 0067 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 Server Compression: 0 NULL Client Extensions ----------------- Server Name Indication: www.mikestoolbox.net Max Fragment Length: 16384 bytes Truncated HMAC: No Signature Algorithms: RSA/SHA-1, DSA/SHA-1, RSA/SHA-256, RSA/SHA-384, RSA/SHA-512 Session Ticket: Empty Renegotiation Info: Empty Server Extensions ----------------- Server Name Chosen: www.mikestoolbox.net Max Fragment Length: 16384 bytes Truncated HMAC: No Session Ticket: 264 Bytes Renegotiation Info: Empty Security Parameters ------------------- Client Finished: 0A6A46A0084820AD52F0A3A1 Server Finished: 3C1812F90DCC36207D610831 Master Secret: A09D0E9AAA1F752776E6DA6C578220671B87CB5A28773575\ 7EF13C5C658878D35B74C2329D8CA583155FC906E6E0B458 Handshake Details ----------------- Bytes Sent: 2615 Bytes Received: 325 - Peer has closed the GnuTLS connection jas@latte:~$ From Xuelei.Fan@oracle.com Mon Jan 31 20:36:41 2011 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B38163A6907 for ; Mon, 31 Jan 2011 20:36:41 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqns+J6lU3Q4 for ; Mon, 31 Jan 2011 20:36:40 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 546A93A6841 for ; Mon, 31 Jan 2011 20:36:40 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p114dsOW010541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Feb 2011 04:39:56 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p114QFMj019265; Tue, 1 Feb 2011 04:39:53 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 968979101296535109; Mon, 31 Jan 2011 20:38:29 -0800 Received: from [10.191.3.36] (/10.191.3.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 31 Jan 2011 20:38:29 -0800 Message-ID: <4D478E3E.9050604@Oracle.COM> Date: Tue, 01 Feb 2011 12:38:22 +0800 From: Xuelei Fan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Hoffman References: <4D46E4D8.3090307@vpnc.org> In-Reply-To: <4D46E4D8.3090307@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS 1.2 test clients? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 04:36:41 -0000 The recent JDK 7 snapshot releases support TLS 1.2 (see http://download.java.net/jdk7/). You're able to get and run the very simple sample code for simple HTTPS connections from http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#HTTPSSample. If you run Java with "-Djavax.net.debug=all -Dhttps.protocols=TLSv1.2" options, you would be able to find the detailed debugging log for TLS/SSL handshaking. About the detained tech guides, please refer to http://download.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html. Xuelei Fan Java Platform, Oracle On 2/1/2011 12:35 AM, Paul Hoffman wrote: > Greetings again. I would like to test how servers react to a TLS > client that only does TLS 1.2. There are two browsers that can be put > into this state (IE under Win 7, and Opera), but neither give very > good diagnostics when a failure occurs. Further, Wireshark doesn't > give good dumps for TLS 1.2. > > Thus, if anyone here has a TLS 1.2 client that has reasonable > debugging of the TLS handshake and can do trivial HTTP (just send a > "GET /" and receive the response would be fine) after setting up a > tunnel, I'd greatly appreciate it. Also, if anyone has a Wireshark > plugin (?) that brings its TLS decoding up to 1.2, that would be great > as well. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls