From jsalowey@cisco.com Tue Feb 5 13:20:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E5C21F86A2 for ; Tue, 5 Feb 2013 13:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBdcYYCFUD6w for ; Tue, 5 Feb 2013 13:20:22 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E319921F8688 for ; Tue, 5 Feb 2013 13:20:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=892; q=dns/txt; s=iport; t=1360099222; x=1361308822; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=lOZTyETuFV6WjjnkbzkYpxFwmtBSQLDIT13lG56NDpQ=; b=jvDlvgnQJATWv/OfmYHpR7FF5E21WvMVgyLUxc3gYQvozFQgZctbdmeE ShnABzBEsMrTJ8HHVNtwW5SNDjuHv19Fv4CDqTlhFoWhoyDGawIOpxUae IyWMUvcstG65a7xn7HYs7qB78k5Ydz3CsxH45F+se3SSGJwJBEVGYZYrO w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAOF2EVGtJXG//2dsb2JhbABFhgG5ZRZzgiEBBDpRASoUQicEGwGICAyZWpEVkCGNI4NXYQOmc4J+gW81 X-IronPort-AV: E=Sophos;i="4.84,609,1355097600"; d="scan'208";a="173696896" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 05 Feb 2013 21:20:15 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r15LKF2r023114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Feb 2013 21:20:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.149]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 15:20:14 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: TLS-PWD as working group item Thread-Index: AQHOA+aW2XTVFONJRUWfcUCIM/8Otw== Date: Tue, 5 Feb 2013 21:20:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS-PWD as working group item X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 21:20:23 -0000 I'm about to approve the draft draft-ietf-tls-pwd-00 as a working group ite= m. In the past few IETF meetings there has been interest in this work and = there was interest expressed in this item on the list a little more than a = year ago. The barrier for adoption was review and approval of the "drago= nfly" algorithm by CFRG. There is a draft, draft-irtf-cfrg-dragonfly-00, b= eing reviewed by the CFRG. There has been some discussion on the CFRG list= on the following thread: http://www.ietf.org/mail-archive/web/cfrg/current= /msg03258.html. It seems that review is well underway and it would be a g= ood time to bring this item into the working group to ensure there is prope= r review if the TLS aspects of the protocol. =20 If anyone has objections to taking this work on at this point please respon= d to the list by February, 15 2013. =20 Thanks, Joe= From sfriedl@cisco.com Tue Feb 5 19:10:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D669B21F89E9 for ; Tue, 5 Feb 2013 19:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSrXkgS-I-5M for ; Tue, 5 Feb 2013 19:10:23 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE3621F89D5 for ; Tue, 5 Feb 2013 19:10:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5507; q=dns/txt; s=iport; t=1360120223; x=1361329823; h=from:to:subject:date:message-id:mime-version; bh=iRyL4U/nBCW4oFYY89zt87Os/afLjtA0MAIRpa7f22A=; b=H6QgcP1CtmNA40eFzDIyrXfTu18DoTxK8ysjEpoCCrMzBWdZF0LucyWz x91jQuhlsDqVcMcCambC4RfaN7QXv6ETb/mZ7yG8kYWScNzy+PJPLSicZ 2sqlTxmUQ7NAhA698KVWkmyZj3I5XZE24W5MNwRHCX+122qMb0k6EMkIv g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEbIEVGtJV2d/2dsb2JhbABFgkm9IBZzgiEBBC1eASpWJgEEG4gJmWyTJo4DkHphA5JolAuCcQ2CJA X-IronPort-AV: E=Sophos;i="4.84,612,1355097600"; d="scan'208,217";a="173822819" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 06 Feb 2013 03:10:22 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r163AMn5016930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Feb 2013 03:10:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 5 Feb 2013 21:10:22 -0600 From: "Stephan Friedl (sfriedl)" To: "tls@ietf.org" Thread-Topic: Revision of draft-friedl-tls-applayerprotoneg posted Thread-Index: Ac4EF3brTia13etfR2Sso99Nw3fbAA== Date: Wed, 6 Feb 2013 03:09:27 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.122.147] Content-Type: multipart/alternative; boundary="_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5xmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 20:55:45 -0000 --_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, A revised version of 'Transport Layer Security (TLS) Application Layer Prot= ocol Negotiation Extension' (draft-friedl-tls-applayerprotoneg-01) has been= posted. This version includes a number of significant improvements to the= original draft including: 1. Use of a single extension for both the ClientHello and Server= Hello messages 2. Definition of ProtocolIdentifiers as opaque, non-empty byte s= trings and the list of protocols is serialized as a concatenation of 8-bit,= length prefixed byte strings 3. Clarification of the suggested order of client-side ProtocolI= dentifiers 4. Clarification that the server-side extension_data MUST contai= n exactly one ProtocolIdentifier 5. Should the server support none of the protocols advertised by= the client, then the server SHALL respond with a 'fatal handshake failure = alert'. 6. Addition of Andrei Popov of Microsoft as a co-author These changes were largely proposed by Andrei and have greatly improved the= draft. I would greatly appreciate any comments and feedback on the draft. Thanks and Best Wishes, Stephan --_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello All,

 

A revised version of ‘Transport Layer Security= (TLS) Application Layer Protocol Negotiation Extension’ (draft-fried= l-tls-applayerprotoneg-01) has been posted.  This version includes a n= umber of significant improvements to the original draft including:

 

1.        &n= bsp;   Use of a single extension for both the ClientHello and Ser= verHello messages

2.        &n= bsp;   Definition of ProtocolIdentifiers as opaque, non-empty byt= e strings and the list of protocols is serialized as a concatenation of 8-b= it, length prefixed byte strings

3.        &n= bsp;   Clarification of the suggested order of client-side Protoc= olIdentifiers

4.        &n= bsp;   Clarification that the server-side extension_data MUST con= tain exactly one ProtocolIdentifier

5.        &n= bsp;   Should the server support none of the protocols advertised= by the client, then the server SHALL respond with a ‘fatal handshake= failure alert’.

6.        &n= bsp;   Addition of Andrei Popov of Microsoft as a co-author<= /o:p>

 

These changes were largely proposed by Andrei and ha= ve greatly improved the draft.

 

I would greatly appreciate any comments and feedback= on the draft.

 

Thanks and Best Wishes,

 

Stephan

 

--_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5xmbalnx02ciscoc_-- From internet-drafts@ietf.org Wed Feb 6 14:42:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBDC21F8526; Wed, 6 Feb 2013 14:42:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXsqMNSswpNT; Wed, 6 Feb 2013 14:42:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8083221F855F; Wed, 6 Feb 2013 14:42:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130206224213.12055.20163.idtracker@ietfa.amsl.com> Date: Wed, 06 Feb 2013 14:42:13 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 22:42:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-04.txt Pages : 9 Date : 2013-02-06 Abstract: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-exte= nsion-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From agl@google.com Wed Feb 6 14:57:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6654A21F855D for ; Wed, 6 Feb 2013 14:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GmNaVCwu4hZ for ; Wed, 6 Feb 2013 14:57:32 -0800 (PST) Received: from mail-ie0-x22d.google.com (ie-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ED8F921F855C for ; Wed, 6 Feb 2013 14:57:31 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id 9so2703928iec.18 for ; Wed, 06 Feb 2013 14:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=LZC9kdfzZlEYGjH8ey9gyNTbCf/XZ0v7iCnNXg6Cdn4=; b=SQUWiRwJSpmXgGgbE/wcWHX/q3u/xkNIrzfk0LMUj6ONuN52FOf4KnuKFDH5hphEpo 0HJdY0ArtRATCJehqyFB4V69NXhXYGmuF9tan30jQKbWELyQZa5z3V/SIfBYPeQ/gjkR 2VagIkWDFtO2Pcx2FPgAGYETSah+hawhMh/1lY4DPEVc5IXLw15Wp4G94X9IcljWXTGH 0JXt2A2lfrDSppDUIwxxMmFK/PxxcnFPLY4X0s4opnT8mKBFP7uvsTFGpKGv9OlobxzX BZlIxOLaaYby+Ot3VmWYsyLTf1tWviGNjiOqxNCxkhH9aF+QOyzFTt254dXPQhC6lXNT gERg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=LZC9kdfzZlEYGjH8ey9gyNTbCf/XZ0v7iCnNXg6Cdn4=; b=SApVXZ8iBw0et0vOJbFnpdJWtH1N+Qvyq1hm0+SvfaxNqwcGSkHfHR3c1pboz1x11u p2sMq6kcO09LqfFluQLfAR1RJ3TSgm6GYIDK7zfu4X7q6O+uVmix87MAhqPt9k44ERIe gs1QqV+Pmp/5GGRa4hpLKJ3eG3CHHUvDRfo+tfYa0uxvQdH5S0+FHVcZ+1v4V7ofDPWX P4kuCiqSHyDj2xV2WgDRbQgRIkSvYYilMLF7LR5v/7lnFQpsobA2Ru3NuYalV8Uv5wE0 gS0Kbv5j1uNEnOVNicA+ioXwbknaCZMSQQ0wP+hv9tvewafa/92oFqb/oRbfJeZRNypK eUhg== MIME-Version: 1.0 X-Received: by 10.50.57.164 with SMTP id j4mr9793025igq.91.1360191451124; Wed, 06 Feb 2013 14:57:31 -0800 (PST) Received: by 10.231.241.201 with HTTP; Wed, 6 Feb 2013 14:57:31 -0800 (PST) In-Reply-To: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com> References: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com> Date: Wed, 6 Feb 2013 17:57:31 -0500 Message-ID: From: Adam Langley To: "Stephan Friedl (sfriedl)" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlZo4X0vMtxjT1wPtsafMto7+esqM1VBsfDAp6P8S7+hkjTN8U/kMi5iyAOVZv65rT8YhOFXTgpx5dqtq5X0Tmz9sDCw89qrLF4A3Tw11I9HZrr42b0js7hzK1GPnhgy8EyGT/yz7eMFbqzvs3nuBbSt3dFCi1fG2GlDfohIkuOpZaLxw+6SHbzphO/Mg6j9Bg954CQ Cc: "tls@ietf.org" Subject: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 22:57:32 -0000 On Tue, Feb 5, 2013 at 10:09 PM, Stephan Friedl (sfriedl) wrote: > These changes were largely proposed by Andrei and have greatly improved the > draft. If this draft were published as an RFC tomorrow, we would switch to it and start a deprecation plan for NPN. However, we still believe that NPN is the better answer. Take this paragraph from the draft: > History demonstrates that there exist a multiplicity of compelling needs for TCP/IP networks to provide > differentiated network treatment based on protocol. This differentiated treatment may include QOS > and/or firewalling to permit enterprises and carriers to manage the flows within their networks. QOS > requirements may be driven by the needs of real-time protocols or service provider SLAs or service > tiers. Firewalling is required to meet a variety of regulatory, compliance, appropriate use and security > mandates. (Removed from -01 I see, possibly because because of me.) We believe in the end-to-end principle. And we understand that we're having this discussion because middlebox interference has driven us to it: HTTPS is now often the only way to get bytes across the Internet because cryptography slowed the stultifying firewalls. We think that what can be encrypted, should be encrypted and are unenthusiastic about playing the same game with middleware, just one layer up. NPN is constrained by the round-trip requirement, but its greater complexity apparently hasn't been a problem for the numerous implementations. I also hope that the EncryptedExtensions message can serve as a basis for future extensions to also be under encryption. Cheers AGL From Andrei.Popov@microsoft.com Wed Feb 6 16:48:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D4E21F85B2 for ; Wed, 6 Feb 2013 16:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL9RYeyuI8RI for ; Wed, 6 Feb 2013 16:48:52 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 643F721F8569 for ; Wed, 6 Feb 2013 16:48:52 -0800 (PST) Received: from BY2FFO11FD006.protection.gbl (10.1.15.202) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.609.9; Thu, 7 Feb 2013 00:48:48 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.609.9 via Frontend Transport; Thu, 7 Feb 2013 00:48:48 +0000 Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 7 Feb 2013 00:48:31 +0000 Received: from mail213-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Thu, 7 Feb 2013 00:47:48 +0000 Received: from mail213-ch1 (localhost [127.0.0.1]) by mail213-ch1-R.bigfish.com (Postfix) with ESMTP id 0E44D1E01EF for ; Thu, 7 Feb 2013 00:47:48 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz98dI9371I542I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh8275bhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h9a9j1155h) Received-SPF: softfail (mail213-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ;.outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR03MB066; H:BLUPR03MB068.namprd03.prod.outlook.com; LANG:en; Received: from mail213-ch1 (localhost.localdomain [127.0.0.1]) by mail213-ch1 (MessageSwitch) id 1360198066156252_15219; Thu, 7 Feb 2013 00:47:46 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail213-ch1.bigfish.com (Postfix) with ESMTP id 22C7330024A; Thu, 7 Feb 2013 00:47:46 +0000 (UTC) Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 7 Feb 2013 00:47:45 +0000 Received: from BLUPR03MB066.namprd03.prod.outlook.com (10.255.209.154) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 7 Feb 2013 00:47:42 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com (10.255.209.156) by BLUPR03MB066.namprd03.prod.outlook.com (10.255.209.154) with Microsoft SMTP Server (TLS) id 15.0.614.5; Thu, 7 Feb 2013 00:47:41 +0000 Received: from BLUPR03MB068.namprd03.prod.outlook.com ([169.254.11.140]) by BLUPR03MB068.namprd03.prod.outlook.com ([169.254.11.140]) with mapi id 15.00.0614.003; Thu, 7 Feb 2013 00:47:29 +0000 From: Andrei Popov To: Adam Langley , "Stephan Friedl (sfriedl)" Thread-Topic: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted Thread-Index: Ac4EF3brTia13etfR2Sso99Nw3fbAAApeD2AAAOCalA= Date: Thu, 7 Feb 2013 00:47:28 +0000 Message-ID: <38ed71d3511e4e94b0623e83b268c7f6@BLUPR03MB068.namprd03.prod.outlook.com> References: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.156.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BLUPR03MB066.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377454001)(189002)(24454001)(13464002)(164054002)(76482001)(31966008)(16676001)(46102001)(47446002)(56816002)(20776003)(33646001)(80022001)(51856001)(63696002)(74662001)(74502001)(56776001)(47776003)(44976002)(6806001)(47976001)(59766001)(49866001)(5343635001)(23726001)(54316002)(5343655001)(46406002)(50986001)(79102001)(50466001)(4396001)(54356001)(65816001)(53806001)(47736001)(77982001)(59253001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:3; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0750463DC9 Cc: "tls@ietf.org" Subject: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 00:48:53 -0000 Cisco and Microsoft have co-authored the new ALPN draft to allow protocol n= egotiation without extra round-trips and to provide the following benefits: * Place ownership of protocol selection on the server, not the clie= nt. This allows the server to select an appropriate certificate based on th= e application protocol. * Support truly secure protocol negotiation through standard TLS re= negotiation. This introduces additional latency (only when hiding protocol= information is desired), but provides confidentiality guarantees. Thanks, Andrei -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Adam = Langley Sent: Wednesday, February 6, 2013 2:58 PM To: Stephan Friedl (sfriedl) Cc: tls@ietf.org Subject: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted On Tue, Feb 5, 2013 at 10:09 PM, Stephan Friedl (sfriedl) wrote: > These changes were largely proposed by Andrei and have greatly=20 > improved the draft. If this draft were published as an RFC tomorrow, we would switch to it and = start a deprecation plan for NPN. However, we still believe that NPN is the better answer. Take this paragrap= h from the draft: > History demonstrates that there exist a multiplicity of compelling=20 > needs for TCP/IP networks to provide differentiated network treatment=20 > based on protocol. This differentiated treatment may include QOS=20 > and/or firewalling to permit enterprises and carriers to manage the=20 > flows within their networks. QOS requirements may be driven by the=20 > needs of real-time protocols or service provider SLAs or service tiers. = Firewalling is required to meet a variety of regulatory, compliance, approp= riate use and security mandates. (Removed from -01 I see, possibly because because of me.) We believe in the end-to-end principle. And we understand that we're having= this discussion because middlebox interference has driven us to it: HTTPS is now often the only way to get bytes across the Internet becaus= e cryptography slowed the stultifying firewalls. We think that what can be encrypted, should be encrypted and are unenthusia= stic about playing the same game with middleware, just one layer up. NPN is constrained by the round-trip requirement, but its greater complexit= y apparently hasn't been a problem for the numerous implementations. I also= hope that the EncryptedExtensions message can serve as a basis for future = extensions to also be under encryption. Cheers AGL _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nick.lewis@usa.g4s.com Thu Feb 7 00:43:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E43021F860A for ; Thu, 7 Feb 2013 00:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.997 X-Spam-Level: X-Spam-Status: No, score=-3.997 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPqONiuZvACe for ; Thu, 7 Feb 2013 00:43:15 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB9F21F8596 for ; Thu, 7 Feb 2013 00:43:14 -0800 (PST) Received: from [85.158.140.195:12372] by server-6.bemta-14.messagelabs.com id 58/9F-12010-12963115; Thu, 07 Feb 2013 08:43:13 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-13.tower-193.messagelabs.com!1360226592!14210198!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26171 invoked from network); 7 Feb 2013 08:43:13 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-13.tower-193.messagelabs.com with RC4-SHA encrypted SMTP; 7 Feb 2013 08:43:13 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Thu, 7 Feb 2013 08:43:12 +0000 From: "Lewis, Nick" To: "'tls@ietf.org'" Date: Thu, 7 Feb 2013 08:43:11 +0000 Thread-Topic: TLS1.3 Thread-Index: Ac4FDy/edOkbgTmiQdegAlKQMafBUg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AAE0766F5AF36B46BAB7E0EFB9273206194A67DCD0GBTWK10E001Te_" MIME-Version: 1.0 Subject: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 08:43:16 -0000 --_000_AAE0766F5AF36B46BAB7E0EFB9273206194A67DCD0GBTWK10E001Te_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With confidence in the TLS being undermined once again as a result of probl= ems with its MAC-Pad-Encrypt mechanism are there any plans to adopt an alte= rnative mechanism such as Pad-MAC-Encrypt in TLS1.3? Nick Lewis nick.lewis@usa.g4s.com +44 1684 277137 www.g4stechnology.com New Challenge House, International Drive, Tewkesbury, Gloucestershire, GL20= 8UQ, UK P Please consider the environment before printing this email ________________________________ The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. --_000_AAE0766F5AF36B46BAB7E0EFB9273206194A67DCD0GBTWK10E001Te_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

With confidence in the TLS being undermined once aga= in as a result of problems with its MAC-Pad-Encrypt mechanism are there any= plans to adopt an alternative mechanism such as Pad-MAC-Encrypt in TLS1.3?=

 

Nick Lewis

nick.lewis@usa.g4s.com

+44 1684 277137

www.g4stec= hnology.com

New Cha= llenge House, International Drive, Tewkesbury, Gloucestershire, GL20 8UQ, U= K

 

P Please consider= the environment before printing this email

 


The details of this company = are as follows:
G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38.

This communication may contain information which is confidential, personal = and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
 --_000_AAE0766F5AF36B46BAB7E0EFB9273206194A67DCD0GBTWK10E001Te_-- From nick.lewis@usa.g4s.com Thu Feb 7 01:30:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE9021F85A4 for ; Thu, 7 Feb 2013 01:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.259 X-Spam-Level: X-Spam-Status: No, score=-4.259 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTtXUjRlPfaQ for ; Thu, 7 Feb 2013 01:30:05 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 04E5621F8599 for ; Thu, 7 Feb 2013 01:30:04 -0800 (PST) Received: from [85.158.137.19:36936] by server-7.bemta-3.messagelabs.com id A1/34-10367-B1473115; Thu, 07 Feb 2013 09:30:03 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-10.tower-39.messagelabs.com!1360229402!11474221!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23794 invoked from network); 7 Feb 2013 09:30:03 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-10.tower-39.messagelabs.com with RC4-SHA encrypted SMTP; 7 Feb 2013 09:30:03 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Thu, 7 Feb 2013 09:30:02 +0000 From: "Lewis, Nick" To: 'Peter Gutmann' , "tls@ietf.org" Date: Thu, 7 Feb 2013 09:30:02 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FE4Gn8VTUVV70S7y96B4k/17gyQAAFUmw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 09:30:06 -0000 >I already have the necessary draft 90% complete, you don't need a rev of T= LS, >just an extension "would you like to do encrypt-then-MAC" in the client he= llo, >and a corresponding "yes, let's do encrypt-then-MAC" in the server hello. >Works with any version of TLS. I'll post it in the next day or two. >Peter. Is this really ok for all cipher suites? In those cases that the hash is weak e.g. MD5-HMAC maybe the underlying key= could be exposed? Padding the plain text up to a multiple of the cipher block size (minus the= hash size) ahead of doing the MAC is a more modest change that may be more= widely applicable to existing cipher suites - with a "pad-then MAC" client= hello Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From n.mavrogiannopoulos@gmail.com Thu Feb 7 01:47:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B01921F84C0 for ; Thu, 7 Feb 2013 01:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id duCsa1ayaugd for ; Thu, 7 Feb 2013 01:47:22 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEC321F854C for ; Thu, 7 Feb 2013 01:47:22 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c10so3238025ieb.31 for ; Thu, 07 Feb 2013 01:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zpsivh42eEcVBaglSTPtOTrgLH4auAr07swVLPZTldw=; b=XA65KP/0sQenxMo+FMag2Au86LUucc2RQp05zN5WhmW6J5a/sxMUOTZ/CWNU7MsPtN kTzVsOle1M4ZnRPSgIIx7F1kWRLKt28Zm4+16SbKrPkiUWhZSvo7TdzlGyJpM74djA1f 41a0pTTBAT02DD34m8YyaXIJ6PVEni7+9KK4gVfAK7tcl4nwc3+FNk8xu9mg3OPJHq/M VsGXef/K47GjvDAwF9WMKz1INmNxGGh+NuRPdID/k0J+761FIdC6jDoGWZWB0dj01Tt1 K3lptOTcM9cfuAjk+nn3cVXbpjdI50OknnEqpwCqgEsvB6JRXuhPNPJcVh5nB6KDfja5 PP7w== MIME-Version: 1.0 X-Received: by 10.42.46.141 with SMTP id k13mr1062357icf.46.1360230441906; Thu, 07 Feb 2013 01:47:21 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.64.58.76 with HTTP; Thu, 7 Feb 2013 01:47:21 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 10:47:21 +0100 X-Google-Sender-Auth: SVBFav_yz6hit9bRXceIYrywfa0 Message-ID: From: Nikos Mavrogiannopoulos To: "Lewis, Nick" Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 09:47:24 -0000 On Thu, Feb 7, 2013 at 9:43 AM, Lewis, Nick wrote: > With confidence in the TLS being undermined once again as a result of > problems with its MAC-Pad-Encrypt mechanism are there any plans to adopt an > alternative mechanism such as Pad-MAC-Encrypt in TLS1.3? Indeed that would be useful. The current padding mechanism required 1-2 pages of code to solve the known issues and that may not even be sufficient, and have yet another attack next year. For that, in gnutls we have already implemented an extension to include the pad into the MAC'd data and avoid any padding oracle attacks. The extension defines a new padding mechanism for all ciphersuites (with the purpose of length hiding - Alfredo may add more information on that), that has the side effect of fixing the known TLS padding issues. The extension is described at: http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00 regards, Nikos From alfredo@pironti.eu Thu Feb 7 02:24:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3295C21F8569 for ; Thu, 7 Feb 2013 02:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbLAm0+a-CDk for ; Thu, 7 Feb 2013 02:24:31 -0800 (PST) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5BA21F846E for ; Thu, 7 Feb 2013 02:24:31 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id j1so2598876oag.21 for ; Thu, 07 Feb 2013 02:24:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=IBZH1uElY+EBO/4fmvzmh+XMFgg6Koj6pBzN5Jr+K4s=; b=V58jrJBm1bkxWSNNrH2CL+e8oLwCtRrJC+f2KIa9ImDA9VUVWrEJ8qj7F5UPlLtaH4 zRueZ2Wx+6eqIyxzmv+H8NitkVHQwQRGMx6EJv/LObQQChI3KhyKN8Zsv8esOUL6yw20 VKtDtdFGDvBNWjX1ak227A/eSTGKRrDf9n/9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=IBZH1uElY+EBO/4fmvzmh+XMFgg6Koj6pBzN5Jr+K4s=; b=mWaR+QpeUYxAAxs3qmji5zy3UgmWIyJY9LuHBjdqJpYh8iRHomPKld8lOR1Sz2j3px Xq866+N55O5es7TIuDYBWhRRscTVSvA7a9BmZjZkoUXIaXTIsE78gao3JXEWqFuZpjn8 Wqf9Aq/Xyb7u1+uGEPL55huYstOlwUK5f5it3H3UOLRQf4bz/Rpb48V9mPVjdVzeN+F5 SzPSHJQve1aVzl1FqdQ9ojAI/li9P/qyDeC5vzgoTyhW2M0fruvGpFR4YGhrmDsBjpLb vaza42SmkYSekOka0ag6625Bn56bWdb9YyQN46+yjYnNuXJdLgTCoONIqd/exMnTpIO+ SPcQ== MIME-Version: 1.0 X-Received: by 10.182.167.65 with SMTP id zm1mr541065obb.19.1360232670610; Thu, 07 Feb 2013 02:24:30 -0800 (PST) Sender: alfredo@pironti.eu Received: by 10.76.83.105 with HTTP; Thu, 7 Feb 2013 02:24:30 -0800 (PST) X-Originating-IP: [128.93.191.105] Date: Thu, 7 Feb 2013 11:24:30 +0100 X-Google-Sender-Auth: R3k3BBMYjFuv0xzO12rouLxrGXE Message-ID: From: Alfredo Pironti To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmb5wWvc5SIHqcPktmmJjSrdUsTWLpqD879ZWCsL957gaQV7qThIRn0yCOImZZzimBuhR/X Subject: [TLS] Upload of draft-pironti-tls-length-hiding-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 10:24:33 -0000 Dear all, I uploaded a draft that explains how to correctly use extra padding in TLS to effectively hide the plaintext length. The draft proposes an extension where length-hiding padding can be used with any cipher. Furthermore, by including the pad in the MAC computation, the proposed extension fixes the notorious padding oracle attacks on TLS block ciphers. The proposed extension and length-hiding mechanism are implemented in GnuTLS 3.1.7. I look forward to your comments and suggestions! Best regards, Alfredo From alfredo@pironti.eu Thu Feb 7 02:27:02 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0621F8472 for ; Thu, 7 Feb 2013 02:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 961+JNV8NCxI for ; Thu, 7 Feb 2013 02:27:02 -0800 (PST) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9E21F846E for ; Thu, 7 Feb 2013 02:27:01 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id v19so2515816obq.21 for ; Thu, 07 Feb 2013 02:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=lwZjGaEpvR26xmO9bSB19OV9HocOiHAFjWi0QWucNko=; b=I7VH4CxhgPCFAf+S31e9NtMqeky4au6ItflRGT+xHMQyvkhvUnP3uzZmkf+x5/blFP MV3hT31Kt384zjGiosRHGOzKyf6XN0nmWnuCfbSo4AB5CY8bWoHOTAvTDp/W4PkOnzcO uG5+G6VGiBiWlZcf0VnutAMSdZhCaSbhVRa/Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:x-originating-ip:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:x-gm-message-state; bh=lwZjGaEpvR26xmO9bSB19OV9HocOiHAFjWi0QWucNko=; b=ADLhTYPr2pfSa7OBSGXwSFVL3k3+5QQPT7skIILeNu7A1RL2GspotiPYMk2wku9Hb8 oQRUZcZfRDU2Yre8hAQFN83w67lM/+feZ3u9i/tEERNOSXjgDq6wG3Hk1q+NNpwGJuQU 3Qt8bGBdiOr60wqlw+Qhq/nGIAF6U/uWqCoCSv8rLWyFJGGsHEfLYvEiAogWYR7ASLX7 r8ymDsOd27ydXKMaiMGo/tCqHqH0C86xYBm5BH9vTW5bMIc9460BXWGTmKsV7uD2jHxY vFxwXnaBOd2Q+uQNOSGDGKuri6dzOMM6zh3g53Y6yGNswIffAVtbBEdOMdhvz/b+RJmu y96w== MIME-Version: 1.0 X-Received: by 10.182.167.65 with SMTP id zm1mr545526obb.19.1360232821506; Thu, 07 Feb 2013 02:27:01 -0800 (PST) Sender: alfredo@pironti.eu Received: by 10.76.83.105 with HTTP; Thu, 7 Feb 2013 02:27:01 -0800 (PST) X-Originating-IP: [128.93.191.105] In-Reply-To: References: Date: Thu, 7 Feb 2013 11:27:01 +0100 X-Google-Sender-Auth: vodrO6065xX-K4Xd5wMJOCtjcoI Message-ID: From: Alfredo Pironti To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmCNHad/rM+S2AqY3GKoOfQBxkLlNGxNsprGmho2KBeYZjQ0cOYPyPXilLFmuV+7dhMyF/Z Subject: Re: [TLS] Upload of draft-pironti-tls-length-hiding-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 10:27:02 -0000 PS: The draft is available at: http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00 On Thu, Feb 7, 2013 at 11:24 AM, Alfredo Pironti wrote: > Dear all, > > I uploaded a draft that explains how to correctly use extra padding in > TLS to effectively hide the plaintext length. The draft proposes an > extension where length-hiding padding can be used with any cipher. > > Furthermore, by including the pad in the MAC computation, the proposed > extension fixes the notorious padding oracle attacks on TLS block > ciphers. > > The proposed extension and length-hiding mechanism are implemented in > GnuTLS 3.1.7. > > I look forward to your comments and suggestions! > > Best regards, > Alfredo From ekr@rtfm.com Thu Feb 7 04:57:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D340721F846C for ; Thu, 7 Feb 2013 04:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYkedV-U7Y3s for ; Thu, 7 Feb 2013 04:57:07 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFAF21F8447 for ; Thu, 7 Feb 2013 04:57:06 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so1148595qen.18 for ; Thu, 07 Feb 2013 04:57:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=DO5gp8JXQ3tGQmJgAr2lD4ouq1Q3bEzCzW1BpBjl5cw=; b=blJvOn/nCQUzpxKEJx1SeMB4vWMw4OxYVs43qcQ+H/Ek/mkp4x394HWpanzCrupW4l UD7853UtG6e+7jhjiOiFH/cLTv/BiblGNatBPfbDHnh2oMKHghRJapJ35py3lhxK8L5F tM5Z71i0Lx0OGBeyDzK8Lr6McD88dSfjj2zSyd9Gj2DQZPPf+ngK5aE3i7NFjVybYreA KWoEcz/RHOUPxUMhBT/14fFZFAePb9bgA+vGUNmGpm5jLaLaPGH6W75DMovBOHa2Cedk Cs2z5/6YiViYZzgD0MnIymZL4zqzoWvK1/lYtYiGCg84ENXum4Wd1hapfpJRAAfxSSXX Q6uA== X-Received: by 10.224.53.7 with SMTP id k7mr632184qag.96.1360241826598; Thu, 07 Feb 2013 04:57:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.82.130 with HTTP; Thu, 7 Feb 2013 04:56:26 -0800 (PST) X-Originating-IP: [216.206.165.162] In-Reply-To: References: From: Eric Rescorla Date: Thu, 7 Feb 2013 04:56:26 -0800 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=20cf3074d9d8e20d9704d521fa44 X-Gm-Message-State: ALoCoQnXoYV8+8TJ8QW/LSfTMo1eot4pjHZOZT3t1qbudsLs65GCqgDUyfYXNy5C3KZiaipjHw4K Cc: "Lewis, Nick" , "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 12:57:07 -0000 --20cf3074d9d8e20d9704d521fa44 Content-Type: text/plain; charset=ISO-8859-1 There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes support for AEAD ciphers, so all that would be needed is to define an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2. Best, -Ekr On Thu, Feb 7, 2013 at 1:47 AM, Nikos Mavrogiannopoulos wrote: > On Thu, Feb 7, 2013 at 9:43 AM, Lewis, Nick > wrote: > > With confidence in the TLS being undermined once again as a result of > > problems with its MAC-Pad-Encrypt mechanism are there any plans to adopt > an > > alternative mechanism such as Pad-MAC-Encrypt in TLS1.3? > > Indeed that would be useful. The current padding mechanism required > 1-2 pages of code to solve the known issues and that may not even be > sufficient, and have yet another attack next year. > > For that, in gnutls we have already implemented an extension to > include the pad into the MAC'd data and avoid any padding oracle > attacks. The extension defines a new padding mechanism for all > ciphersuites (with the purpose of length hiding - Alfredo may add more > information on that), that has the side effect of fixing the known TLS > padding issues. > > The extension is described at: > http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00 > > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --20cf3074d9d8e20d9704d521fa44 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes<= div>support for AEAD ciphers, so all that would be needed is to define
an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2.

Best,
-Ekr


On Thu, Feb 7, 2013 at 1:47 AM, Nikos Mavrogiannopoul= os <nmav@gnutls.org> wrote:
On Thu, Feb 7, 2013 at 9:4= 3 AM, Lewis, Nick <nick.lewis@= usa.g4s.com> wrote:
> With confidence in the TLS being undermined once again as a result of<= br> > problems with its MAC-Pad-Encrypt mechanism are there any plans to ado= pt an
> alternative mechanism such as Pad-MAC-Encrypt in TLS1.3?

Indeed that would be useful. The current padding mechanism required 1-2 pages of code to solve the known issues and that may not even be
sufficient, and have yet another attack next year.

For that, in gnutls we have already implemented an extension to
include the pad into the MAC'd data and avoid any padding oracle
attacks. The extension defines a new padding mechanism for all
ciphersuites (with the purpose of length hiding - Alfredo may add more
information on that), that has the side effect of fixing the known TLS
padding issues.

The extension is described at:
http://tools.ietf.org/html/draft-pironti-tls-length-hiding= -00

regards,
Nikos
___________________________________= ____________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--20cf3074d9d8e20d9704d521fa44-- From nick.lewis@usa.g4s.com Thu Feb 7 05:10:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E1221F862D for ; Thu, 7 Feb 2013 05:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhCkbVhnKPMS for ; Thu, 7 Feb 2013 05:10:49 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A121F85F0 for ; Thu, 7 Feb 2013 05:10:49 -0800 (PST) Received: from [85.158.139.35:10733] by server-14.bemta-5.messagelabs.com id DE/14-06967-3D7A3115; Thu, 07 Feb 2013 13:10:43 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-12.tower-179.messagelabs.com!1360242643!25695145!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20621 invoked from network); 7 Feb 2013 13:10:43 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-12.tower-179.messagelabs.com with RC4-SHA encrypted SMTP; 7 Feb 2013 13:10:43 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Thu, 7 Feb 2013 13:10:43 +0000 From: "Lewis, Nick" To: 'Eric Rescorla' Date: Thu, 7 Feb 2013 13:10:42 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FMqwhQ8EunZMETJmGYQe7xkQ+CQAAGBLg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:10:55 -0000 >There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes >support for AEAD ciphers, so all that would be needed is to define >an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2. >Best, >-Ekr Is it possible to define TLS1.2 AEAD cipher suites for existing ciphers and= MACs? AEAD implies to me the use of the same key for both crypt and MAC. Can the = TLS1.2 AEAD specification allow different keys for each. I think many MACs such as the HMACs require a different key to the crypt be= cause there is no proof that sharing the key with the crypt does not weaken= it Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From n.mavrogiannopoulos@gmail.com Thu Feb 7 05:20:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60C21F8890 for ; Thu, 7 Feb 2013 05:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1+Xje9zRfJv for ; Thu, 7 Feb 2013 05:20:16 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCF221F8606 for ; Thu, 7 Feb 2013 05:20:16 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id j8so1153086qah.7 for ; Thu, 07 Feb 2013 05:20:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cufCLio1PEyWoZt8cV0geFezRIpY1bP6AOxHDU6q+kI=; b=zzEWC2XpWxSWukwjBrUVMVEn1i/xHLRKNIo78ztwwMJE3A1MCGfYdUU9mWKVroP5xY m3R8z/ifJfg9qKZl/GfuitDIoqDEsYykSrlxjDoR53kJScDBOn/qV8pVIwovazBYm68p kD3ZjK65gQyZrf4kQnsgItIzVEFwUiYERO5tQ66Gnnu3aeY9zddu+51mntLbXWBaT4L0 BfnVMh/QctQWH40r0BbfrVysZy5TaFRwWrFSDuSPfcjBcRlyKN9unR+6SOCIPS8R+y56 shZdD13E7HSW+yrvZK3XZW94TOwDTFTMtWR3FcTk4DVFsBNBe+xjxXhnhzl81qjLWvx+ ikFA== MIME-Version: 1.0 X-Received: by 10.49.1.47 with SMTP id 15mr532918qej.46.1360243215736; Thu, 07 Feb 2013 05:20:15 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.78.204 with HTTP; Thu, 7 Feb 2013 05:20:15 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 14:20:15 +0100 X-Google-Sender-Auth: 72RIlSCuHCKIS7opsLryGKXaB-o Message-ID: From: Nikos Mavrogiannopoulos To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:20:18 -0000 On Thu, Feb 7, 2013 at 1:56 PM, Eric Rescorla wrote: > There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes > support for AEAD ciphers, so all that would be needed is to define > an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2. I understand there are many ways to solve that (*), and there quite few ideas on the table already. What is needed however, is to agree on solution to be adopted for all. regards, Nikos (*). Nevertheless, I am a bit confused with what you propose. I fail to see the relation of a solution for the CBC padding issue with a new AEAD ciphersuite. Do you propose to deprecate CBC? From Kenny.Paterson@rhul.ac.uk Thu Feb 7 06:06:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE8021F8767 for ; Thu, 7 Feb 2013 06:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUD2oGT6VZcV for ; Thu, 7 Feb 2013 06:06:06 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11C21F85F0 for ; Thu, 7 Feb 2013 06:06:04 -0800 (PST) Received: from mail120-va3-R.bigfish.com (10.7.14.247) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Thu, 7 Feb 2013 14:06:03 +0000 Received: from mail120-va3 (localhost [127.0.0.1]) by mail120-va3-R.bigfish.com (Postfix) with ESMTP id 935E83402EC; Thu, 7 Feb 2013 14:06:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.197; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB03.cc.rhul.local; RD:exch-hub03.rhul.ac.uk; EFVD:NLI X-SpamScore: 6 X-BigFish: VPS6(zzc85fh6267irzz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail120-va3 (localhost.localdomain [127.0.0.1]) by mail120-va3 (MessageSwitch) id 1360245916320183_3916; Thu, 7 Feb 2013 14:05:16 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.244]) by mail120-va3.bigfish.com (Postfix) with ESMTP id 3C1CE40045D; Thu, 7 Feb 2013 14:05:16 +0000 (UTC) Received: from EXCH-HUB03.cc.rhul.local (134.219.208.197) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 7 Feb 2013 14:05:15 +0000 Received: from EXCH-CAS04.cc.rhul.local (134.219.208.162) by EXCH-HUB03.cc.rhul.local (134.219.208.197) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 7 Feb 2013 14:05:14 +0000 Received: from EXCH-MB01.cc.rhul.local ([169.254.3.31]) by EXCH-CAS04.cc.rhul.local ([2002:86db:d0a2::86db:d0a2]) with mapi id 14.02.0328.009; Thu, 7 Feb 2013 14:05:14 +0000 From: "Paterson, Kenny" To: Eric Rescorla , Nikos Mavrogiannopoulos Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FDy/edOkbgTmiQdegAlKQMafBUgACO/eAAAaaiQAAAlzdgA== Date: Thu, 7 Feb 2013 14:05:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.219.208.226] Content-Type: multipart/alternative; boundary="_000_B132B06E59C4A540A03C3393F53BC07C407C8C0CEXCHMB01ccrhull_" MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Cc: "Lewis, Nick" , "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 14:06:07 -0000 --_000_B132B06E59C4A540A03C3393F53BC07C407C8C0CEXCHMB01ccrhull_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01 provides a specification that could be rather easily adapted to the case in= hand. Kenny There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes support for AEAD ciphers, so all that would be needed is to define an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2. Best, -Ekr --_000_B132B06E59C4A540A03C3393F53BC07C407C8C0CEXCHMB01ccrhull_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

http://tools.ietf.org/= html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01

 <= /p>

provides a specification = that could be rather easily adapted to the case in hand.<= /p>

 <= /p>

Kenny

 <= /p>

There's not really any need to do a TLS 1.3 for this= . TLS 1.2 includes

support for AEAD ciphers, so all that would be neede= d is to define

an Enrypt-Then-Mac AEAD cipher and it will drop into= TLS 1.2.

 

Best,

-Ekr=

--_000_B132B06E59C4A540A03C3393F53BC07C407C8C0CEXCHMB01ccrhull_-- From nick.lewis@usa.g4s.com Thu Feb 7 06:10:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2DF21F856E for ; Thu, 7 Feb 2013 06:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.934 X-Spam-Level: X-Spam-Status: No, score=-3.934 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xwr4V+6Gi-WJ for ; Thu, 7 Feb 2013 06:10:22 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 8C52921F855F for ; Thu, 7 Feb 2013 06:10:21 -0800 (PST) Received: from [85.158.140.195:8314] by server-3.bemta-14.messagelabs.com id 99/C6-22141-AC5B3115; Thu, 07 Feb 2013 14:10:18 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-7.tower-193.messagelabs.com!1360246218!13350510!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23603 invoked from network); 7 Feb 2013 14:10:18 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-7.tower-193.messagelabs.com with RC4-SHA encrypted SMTP; 7 Feb 2013 14:10:18 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Thu, 7 Feb 2013 14:10:18 +0000 From: "Lewis, Nick" To: 'Peter Gutmann' Date: Thu, 7 Feb 2013 14:10:16 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FN0k+L9EEb9TUQLayXM91M4TrhAAAdt+g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 14:10:22 -0000 >>Padding the plain text up to a multiple of the cipher block size (minus >>the hash size) ahead of doing the MAC is a more modest change that may >>be more widely applicable to existing cipher suites - with a "pad-then >>MAC" client hello >That won't help against the current attack. My understanding is that the current attack is due to the MAC revealing the= length of the plaintext. If the plaintext is pre-padded to a full crypt block then a MAC can reveal = no more than does the ciphertext itself Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From nick.lewis@usa.g4s.com Thu Feb 7 06:19:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46421F8431 for ; Thu, 7 Feb 2013 06:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.081 X-Spam-Level: X-Spam-Status: No, score=-4.081 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMcd5VYY4uSg for ; Thu, 7 Feb 2013 06:19:58 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7D96421F8428 for ; Thu, 7 Feb 2013 06:19:58 -0800 (PST) Received: from [85.158.137.19:30360] by server-6.bemta-3.messagelabs.com id 62/4C-29959-C08B3115; Thu, 07 Feb 2013 14:19:56 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-7.tower-39.messagelabs.com!1360246796!14797652!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18691 invoked from network); 7 Feb 2013 14:19:56 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-7.tower-39.messagelabs.com with RC4-SHA encrypted SMTP; 7 Feb 2013 14:19:56 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Thu, 7 Feb 2013 14:19:55 +0000 From: "Lewis, Nick" To: "'Paterson, Kenny'" Date: Thu, 7 Feb 2013 14:19:55 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FDy/edOkbgTmiQdegAlKQMafBUgACO/eAAAaaiQAAAlzdgAAAT+Tg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 14:19:59 -0000 >Hi, >http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01 >provides a specification that could be rather easily adapted to the case i= n hand. >Kenny I like the way it overcomes the unproven security of using the same key for= aes-cbc and hmac by simply concatenating two keys into the one supported b= y TLS1.2 AEAD Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From ekr@rtfm.com Thu Feb 7 06:30:13 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB01121F86BA for ; Thu, 7 Feb 2013 06:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L88uzFoi5wmu for ; Thu, 7 Feb 2013 06:30:13 -0800 (PST) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 326B821F84D9 for ; Thu, 7 Feb 2013 06:30:13 -0800 (PST) Received: by mail-qe0-f48.google.com with SMTP id 3so1183919qea.21 for ; Thu, 07 Feb 2013 06:30:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=CjkmEC4nLMJGm2rcScflU1T0G9RAoksOrgYJc8KJgv8=; b=hQm8SQ4gA4N0QCH9VNEF0s7gEoLRag+XPVaQZqTN+aCvWQ4SLCNoiINCsZZKePdCOR YZdsSe7t4slBisFVu0imWyaX2yWJh03UXPIaRePHRJH7c5zc6MKGKgOoXvSKAsEonsix 8UzlQ4qrafLkQuSeKRY3iGzhBlMekzIRGCwBVjyOTvL6RIu+SYNJyWDFKTTiwqQ2GfrE NQy3poaulRoxodN7Frx/CFKz7gmB2TlT9QPvSFzEOkcKc8L1YAkv8spQH7h6RPxMLQIe i7G9VMTeBgtbjYpcvzsZ93CVej7PEwOuw5bkHZmCydfTCwtDB/jQCTByxcVq/OYxblIk DMWw== X-Received: by 10.229.196.138 with SMTP id eg10mr130861qcb.93.1360247412642; Thu, 07 Feb 2013 06:30:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.82.130 with HTTP; Thu, 7 Feb 2013 06:29:32 -0800 (PST) X-Originating-IP: [155.212.214.60] In-Reply-To: References: From: Eric Rescorla Date: Thu, 7 Feb 2013 06:29:32 -0800 Message-ID: To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=00504501424bd653ac04d52347c7 X-Gm-Message-State: ALoCoQnXsbBYbX6Gtwm8lNrAGNdR37lcymk+fKdXwulZ6n2iqZBoqnvShflBvog/flhSfBFtClrR Cc: "Lewis, Nick" , "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 14:30:14 -0000 --00504501424bd653ac04d52347c7 Content-Type: text/plain; charset=ISO-8859-1 Yes, this is basically what I had in mind -Ekr On Thu, Feb 7, 2013 at 6:05 AM, Paterson, Kenny wrote: > Hi,**** > > ** ** > > http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01**** > > ** ** > > provides a specification that could be rather easily adapted to the case > in hand.**** > > ** ** > > Kenny**** > > ** ** > > There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes**** > > support for AEAD ciphers, so all that would be needed is to define**** > > an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2.**** > > ** ** > > Best,**** > > -Ekr**** > --00504501424bd653ac04d52347c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, this is basically what I had in mind

-Ekr


On Thu, Feb 7, 2013 at 6:05 AM, Paterso= n, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:

Hi,<= /p>

=A0<= /p>

http= ://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01=

=A0<= /p>

provides a specification = that could be rather easily adapted to the case in hand.

=A0<= /p>

Kenny

=A0<= /p>

There's not really any need to do a TLS 1.3 for = this. TLS 1.2 includes

support for AEAD ciphers, so all that would be neede= d is to define

an Enrypt-Then-Mac AEAD cipher and it will drop into= TLS 1.2.

=A0

Best,

-Ekr


--00504501424bd653ac04d52347c7-- From nick.lewis@usa.g4s.com Thu Feb 7 07:00:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FF321F8783 for ; Thu, 7 Feb 2013 07:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+tasC5+bJjF for ; Thu, 7 Feb 2013 07:00:35 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id EA90221F84F2 for ; Thu, 7 Feb 2013 07:00:34 -0800 (PST) Received: from [85.158.139.35:39402] by server-6.bemta-5.messagelabs.com id F5/0D-01489-191C3115; Thu, 07 Feb 2013 15:00:33 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-15.tower-179.messagelabs.com!1360249233!28810316!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5490 invoked from network); 7 Feb 2013 15:00:33 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-15.tower-179.messagelabs.com with RC4-SHA encrypted SMTP; 7 Feb 2013 15:00:33 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Thu, 7 Feb 2013 15:00:33 +0000 From: "Lewis, Nick" To: 'Eric Rescorla' Date: Thu, 7 Feb 2013 15:00:32 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FP7AtFxVcKv4JQ7GFbZg707M9DgAAK9Sw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:00:36 -0000 >Yes, this is basically what I had in mind >-Ekr +1 It moves the responsibility for ensuring the security of the mechanism for = combining padding, MACing and crypting from TLS to the individual cipher su= ites. This conveniently sidesteps the poor way it is done in TLS but also m= akes it easier to disable any other mechanisms that are found to be poor in= the future (such as MAC-then-Crypt if it is ever found that SHA256 has Kra= wczyk weakness) . All useful cipher suites could be ported across to this w= ay of working. My only slight concern is the use of the term AEAD for this which implies t= he use of the same key for MAC and crypt. From a TLS perspective it may loo= k like AEAD but the ported cipher suites themselves need to take care not t= o use a single key inappropriately Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From ynir@checkpoint.com Thu Feb 7 07:19:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF8F21F851F for ; Thu, 7 Feb 2013 07:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2upCOdT0tH3m for ; Thu, 7 Feb 2013 07:19:05 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id CA0B021F84E6 for ; Thu, 7 Feb 2013 07:19:04 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r17FIxHv007348; Thu, 7 Feb 2013 17:19:00 +0200 X-CheckPoint: {5113C21B-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Thu, 7 Feb 2013 17:18:59 +0200 From: Yoav Nir To: "Stephan Friedl (sfriedl)" Thread-Topic: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted Thread-Index: Ac4EF3brTia13etfR2Sso99Nw3fbAABHbiqA Date: Thu, 7 Feb 2013 15:18:58 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199E346@IL-EX10.ad.checkpoint.com> References: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com> In-Reply-To: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B65AB5@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.154] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC30277211199E346ILEX10adcheckpo_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 15:19:06 -0000 --_000_4613980CFC78314ABFD7F85CC30277211199E346ILEX10adcheckpo_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi I support the adoption of this draft. I think it solves the problem of mult= iplexing multiple protocols on a single TLS-protected port. I prefer it to= NPN for the following reasons: 1. It is a simpler solution - just another extension and a simple select= ion mechanism on the server. Implementing this would require less LoC in pr= etty much any implementation. 2. I do not believe that the choice of HTTP/1, HTTP/2 or various version= s of SPDY (which should be experimental anyway) needs to be secret. The val= ue space is small enough that whatever advantage an attacker might get by h= aving the protocol revealed, can be gotten by trial and error as well. 3. More similar to existing TLS, so less surprises by proxies and middle= ware, so less need to fall back. 4. More friendly to middleware - TLS proxies that will anyway drop HTTP/= 2 can do so earlier. I realize some will not consider this an advantage=85 Reading through it, I have a few suggestions: I think there should be a special alert message to note that none of the ap= plications are supported. Call it no_application_chosen, rather than use ha= ndshake_failure. I think the SPDY variants should be prefixed by exp and not registered by I= ANA Also, I think there should be a prefix for private protocols, not marked as= experimental. For example, we could have it say P-author_identifier-name. = So if Microsoft wanted to negotiate the sue of SSTP, they could mark it as = P-MSFT-SSTP Yoav On Feb 6, 2013, at 5:09 AM, Stephan Friedl (sfriedl) > wrote: Hello All, A revised version of =91Transport Layer Security (TLS) Application Layer Pr= otocol Negotiation Extension=92 (draft-friedl-tls-applayerprotoneg-01) has = been posted. This version includes a number of significant improvements to= the original draft including: 1. Use of a single extension for both the ClientHello and Server= Hello messages 2. Definition of ProtocolIdentifiers as opaque, non-empty byte s= trings and the list of protocols is serialized as a concatenation of 8-bit,= length prefixed byte strings 3. Clarification of the suggested order of client-side ProtocolI= dentifiers 4. Clarification that the server-side extension_data MUST contai= n exactly one ProtocolIdentifier 5. Should the server support none of the protocols advertised by= the client, then the server SHALL respond with a =91fatal handshake failur= e alert=92. 6. Addition of Andrei Popov of Microsoft as a co-author These changes were largely proposed by Andrei and have greatly improved the= draft. I would greatly appreciate any comments and feedback on the draft. Thanks and Best Wishes, Stephan --_000_4613980CFC78314ABFD7F85CC30277211199E346ILEX10adcheckpo_ Content-Type: text/html; charset="Windows-1252" Content-ID: <710746F78F5CBE4DBF5C7DB247F96FDB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi

I support the adoption of this draft. I think it solves the problem of= multiplexing multiple protocols on a single TLS-protected port.  I pr= efer it to NPN for the following reasons:
  1. It is a simpler solution - just another extension and a simple selectio= n mechanism on the server. Implementing this would require less LoC in pret= ty much any implementation. 
  2. I do not believe that the choice = of HTTP/1, HTTP/2 or various versions of SPDY (which should be experimental= anyway) needs to be secret. The value space is small enough that whatever = advantage an attacker might get by having the protocol revealed, can be gotten by trial and error as well.
  3. More similar to existing TLS, s= o less surprises by proxies and middleware, so less need to fall back.
    4. =
  4. More friendly to middleware - TLS proxies that will anyway drop HTTP/2 = can do so earlier. I realize some will not consider this an advantage=85

Reading through it, I have a few suggestions:

I think there should be a special alert message to note that none of t= he applications are supported. Call it no_application_chosen, rather than u= se handshake_failure.

I think the SPDY variants should be prefixed by exp and not registered= by IANA

Also, I think there should be a prefix for private protocols, not mark= ed as experimental. For example, we could have it say P-author_identifier-n= ame. So if Microsoft wanted to negotiate the sue of SSTP, they could mark i= t as P-MSFT-SSTP

Yoav


On Feb 6, 2013, at 5:09 AM, Stephan Friedl (sfriedl) <sfriedl@cisco.com> wrote:

Hello All,
 
A revised version of =91Transport Layer Security (TLS) Application Layer Pr= otocol Negotiation Extension=92 (draft-friedl-tls-applayerprotoneg-01) has = been posted.  This version includes a number of significant improvemen= ts to the original draft including:
 
1.            Use of= a single extension for both the ClientHello and ServerHello messages<= /o:p>
2.            Defini= tion of ProtocolIdentifiers as opaque, non-empty byte strings and the list = of protocols is serialized as a concatenation of 8-bit, length prefixed byt= e strings
3.            Clarif= ication of the suggested order of client-side ProtocolIdentifiers
4.            Clarif= ication that the server-side extension_data MUST contain exactly one Protoc= olIdentifier
5.            Should= the server support none of the protocols advertised by the client, then th= e server SHALL respond with a =91fatal handshake failure alert=92.
6.            Additi= on of Andrei Popov of Microsoft as a co-author
 
These changes were largely proposed by Andrei and have greatly improved the= draft.
 
I would greatly appreciate any comments and feedback on the draft.
 
Thanks and Best Wishes,
 
Stephan
 
--_000_4613980CFC78314ABFD7F85CC30277211199E346ILEX10adcheckpo_-- From dharkins@lounge.org Thu Feb 7 09:19:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5026D21F85CB for ; Thu, 7 Feb 2013 09:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTRfF0rtUW1J for ; Thu, 7 Feb 2013 09:19:40 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D519E21F8599 for ; Thu, 7 Feb 2013 09:19:40 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4AA6E10224050; Thu, 7 Feb 2013 09:19:40 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 7 Feb 2013 09:19:40 -0800 (PST) Message-ID: <47202ff6bb1b967f9b3d2de1251697d5.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 7 Feb 2013 09:19:40 -0800 (PST) From: "Dan Harkins" To: "Lewis, Nick" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 17:19:41 -0000 On Thu, February 7, 2013 7:00 am, Lewis, Nick wrote: > My only slight concern is the use of the term AEAD for this which implies > the use of the same key for MAC and crypt. From a TLS perspective it may > look like AEAD but the ported cipher suites themselves need to take care > not to use a single key inappropriately RFC 5116 defines a uniform interface for cipher modes that use the term AEAD and RFC 5297 is an AEAD scheme that takes a double-wide key (half for cipher, half for mac) and fits into the uniform interface (with the assigned numbers 15, 16, and 17). Your concern is misplaced; we're already doing this. Dan. From ekr@rtfm.com Thu Feb 7 15:29:23 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180C31F0CFF for ; Thu, 7 Feb 2013 15:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfnW4gG-87Or for ; Thu, 7 Feb 2013 15:29:21 -0800 (PST) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id AC0C421F8D37 for ; Thu, 7 Feb 2013 15:29:20 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id b4so1432203qen.4 for ; Thu, 07 Feb 2013 15:29:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=rofuB7OSQeje3DJBfvcyeQLEjMjM5hmDu3U58+y/qXQ=; b=N926w03BbnIhSW69WgM0Dcl4YMAeUvALAlOIv7kogDbpu6jx76XCYQJamQBFT9QP5Q 3xQkJzfg6JtTwAcdqQrkUZnzCD7nZXq70miG63i9nSFD/5rfKdOWhzCUtUhjuMGDsSPf bh6omY1PUeXI8Ber3WQ2lTJsByWmCFoTT6X9PQ9vb4x8LSdLgcJbFFY9QYta5NnW4Xub vueoyV4EtcPFoG6aDXMEIp3x/wATqnoBjBhnJ6epOcI0ljoAvwZhIsCsP8zmXkYrAyzX /K89yd/yadxXnep7lkGak6RXCuAIHTt+hY3W/SPgbg3fmC/AnceVbIVNXlNyVRw6Y1mr DlpQ== X-Received: by 10.49.74.198 with SMTP id w6mr1340591qev.57.1360279760219; Thu, 07 Feb 2013 15:29:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.130.198 with HTTP; Thu, 7 Feb 2013 15:28:40 -0800 (PST) X-Originating-IP: [216.206.165.162] From: Eric Rescorla Date: Thu, 7 Feb 2013 15:28:40 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7bb04cf2e72dfb04d52acf3c X-Gm-Message-State: ALoCoQk26yJN7uzu/8k4IUZEzvGix1XkVkv/01LKtO6OmaNufjDZLZkUJh+ztOy9V7dSkvdYbb/g Subject: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 23:29:23 -0000 --047d7bb04cf2e72dfb04d52acf3c Content-Type: text/plain; charset=ISO-8859-1 TLS WG Members, As discussed in Atlanta, we received a request from the HTTP WG to work on the problem of negotiating the upper-layer protocol versions (in particular HTTP 1.1 versus HTTP 2.0, but presumably we would like a more general mechanism.) There was strong consensus to work on this problem in Atlanta, as well as strong support from our AD. This message is intended to (a) confirm that consensus and (b) solicit proposals for discussion in Orlando. Currently, we have two such proposals: http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04 http://tools.ietf.org/html/draft-friedl-tls-applayerprotoneg-01 We intend to have presentations on these (and any other proposals that come in) in Orlando. Depending on list discussion and what other proposals appear, we may attempt to select a proposal in Orlando. WG members, please provide any comments on whether we should take this work on by February 21. Additionally, if you wish to propose an alternative, it would be nice if you could do so soon or at least provide an indication of interest. -Ekr [For the chairs.] --047d7bb04cf2e72dfb04d52acf3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
TLS WG Members,
=

As discusse= d in Atlanta, we received a request from the HTTP WG
to work on the problem of negotiating the upper-layer protocol versions
(in particular HTTP= 1.1 versus HTTP 2.0, but presumably we would
like a more general m= echanism.)

There was s= trong consensus to work on this problem in Atlanta, as
well as strong support from our AD. This message is intended to
(a) confirm that consensus = and (b) solicit proposals for discussion
in Orlando. Currently= , we have two such proposals:


We intend to have presentations on these (and any other proposals
that come in) in Orlando.= Depending on list discussion and what
other proposals appea= r, we may attempt to select a proposal in
Orlando.

WG members, please provide any comments on whether we should
take this work on by February = 21. Additionally, if you wish to propose
an alternative, it wo= uld be nice if you could do so soon or at least
provide an indication of interest.

-Ekr
[For the ch= airs.]
--047d7bb04cf2e72dfb04d52acf3c-- From agl@google.com Thu Feb 7 15:31:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CB921F8939 for ; Thu, 7 Feb 2013 15:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYkpWyF+gkGo for ; Thu, 7 Feb 2013 15:31:19 -0800 (PST) Received: from mail-ia0-x231.google.com (ia-in-x0231.1e100.net [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 77D7F21F8938 for ; Thu, 7 Feb 2013 15:31:15 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id h8so3572798iaa.36 for ; Thu, 07 Feb 2013 15:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rhYrjNu0pBUBmzp6FLLPkNFeKDd0/kgfh08nGLY10fY=; b=JfanjybQuMyXwt2inZ1KTZfa233Ss3QjHEA5FSEWl+9yhSt8D054aXjiF3HR59FlDl wyuDGhlPFZZ/Bv9SixgMPCsChhEDJV1VjzP4IPXWC1/yZYGe9N9hT0+DwrQtKsTI1lgj Wnhdtl7KAlBYdICJhJ0AxLN4QT9GL30W4u++Kx1wRd8troANO3U9C52nG9hSXCGeqSqT 9IWUjPwLWLdQy5xKSiywlWmSIDqPfLJw84IBtMaamhZot/rjiG3DrYn/IZLGsA+pCxRw 4HZbM86SeX9duIj7hJORQfOyNNQ+8AYwiOxBkPJoT5cLe8RLH4+oY2aeSnXrbXMG4GAM 2kbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=rhYrjNu0pBUBmzp6FLLPkNFeKDd0/kgfh08nGLY10fY=; b=bbRJB7fixp+9HWJVdyMhEiwP+Jb9GB9+j1MOcj0h0Ao+Zm4nDYjfroLRadc7RY/+Te wghBUywSlTU/C73kR1a00pz2MGyXRIpiaT5qV3iPzm+RqzYvAKaTNnjdwkzen70e/QRz cqZoEis0PhAP/BFBBap4joMUkvhhXE3MdBWvHn0NYgSbIO3h3nOaQlLVUO9KO3lOiD3x Y7SxO+xEuo8s2NpvP/s/Hd4vfNFewvPJXHaf/5J0l4nPmOUs2F+GZJ4zgeTY4KQfmqYy klKtSDIIkiUTjMasj2ayL8L+eET/KTjG1TkE+Zi7xRrxr7PRMZLLMuNRwvJ3INwZn5D2 Q+Pg== MIME-Version: 1.0 X-Received: by 10.50.184.164 with SMTP id ev4mr18180873igc.91.1360279874905; Thu, 07 Feb 2013 15:31:14 -0800 (PST) Received: by 10.231.241.201 with HTTP; Thu, 7 Feb 2013 15:31:14 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Feb 2013 18:31:14 -0500 Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnm8ZxZgxNi3xBiYQm864XBkveG7BE0nrMNRA4J2BNAy5Z4LTTqR3tqJ4jEHvm4fVHZqDW7T21nlK83WymqLkYuow4TYqQlxN2EeUc8VH5QC+Uk4oqEmkpEuA4TAxELYsivHa6AjTSHQ4nMzsPf4zIPz2t8/HjUdQ6ykSH+JA72Y8D5408m2WTPo2DOsYftya7C3W+J Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 23:31:19 -0000 On Thu, Feb 7, 2013 at 6:28 PM, Eric Rescorla wrote: > WG members, please provide any comments on whether we should > take this work on by February 21. Unsurprisingly, perhaps, I support the WG taking this work on. Cheers AGL From paul.hoffman@vpnc.org Thu Feb 7 16:30:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23B721F89C3 for ; Thu, 7 Feb 2013 16:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yf3EHAAvqBpZ for ; Thu, 7 Feb 2013 16:30:44 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3679021F89B9 for ; Thu, 7 Feb 2013 16:30:44 -0800 (PST) Received: from [10.20.30.90] (50-1-98-243.dsl.dynamic.sonic.net [50.1.98.243]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r180UfNU064529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Feb 2013 17:30:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Thu, 7 Feb 2013 16:30:41 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: To: "tls@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 00:30:44 -0000 On Feb 7, 2013, at 3:31 PM, Adam Langley wrote: > On Thu, Feb 7, 2013 at 6:28 PM, Eric Rescorla wrote: >> WG members, please provide any comments on whether we should >> take this work on by February 21. > > Unsurprisingly, perhaps, I support the WG taking this work on. +1 From nick.lewis@usa.g4s.com Fri Feb 8 01:35:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B837821F8551 for ; Fri, 8 Feb 2013 01:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-h8K2iKtjUr for ; Fri, 8 Feb 2013 01:35:28 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id D2F0721F84D5 for ; Fri, 8 Feb 2013 01:35:27 -0800 (PST) Received: from [85.158.137.3:28134] by server-10.bemta-3.messagelabs.com id 7F/15-10609-DD6C4115; Fri, 08 Feb 2013 09:35:25 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-8.tower-38.messagelabs.com!1360316125!12758435!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8646 invoked from network); 8 Feb 2013 09:35:25 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-8.tower-38.messagelabs.com with RC4-SHA encrypted SMTP; 8 Feb 2013 09:35:25 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Fri, 8 Feb 2013 09:35:24 +0000 From: "Lewis, Nick" To: 'Dan Harkins' Date: Fri, 8 Feb 2013 09:35:24 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FWHbymWiYQiTSTRWm8AwdtA5vKAAgyqvQ Message-ID: References: <47202ff6bb1b967f9b3d2de1251697d5.squirrel@www.trepanning.net> In-Reply-To: <47202ff6bb1b967f9b3d2de1251697d5.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 09:35:28 -0000 >RFC 5116 defines a uniform interface for cipher modes that use the term AE= AD >and RFC 5297 is an AEAD scheme that takes a double-wide key (half for ciph= er, half for mac) >and fits into the uniform interface (with the assigned numbers 15, 16, and= 17). >Your concern is misplaced; we're already doing this. >Dan. Thanks - seeing another example of concatenated keys helps to allay my fear= s (though ironically RFC5297 seems to specify a variant of CCM that may be = secure with the same key for crypt and mac) Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From pgut001@cs.auckland.ac.nz Fri Feb 8 02:48:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954AB21F8700 for ; Fri, 8 Feb 2013 02:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyKYECBzEGlG for ; Fri, 8 Feb 2013 02:48:10 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id B113B21F86C9 for ; Fri, 8 Feb 2013 02:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320490; x=1391856490; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CypfN7YOjn4+TQmbgDLWdOC8lufjOywOYbDVxZoVFCw=; b=C7/2VGNJFmcecF4jhbSqJcl4oshZtihOL12rFufCOLpFwTHpPHI05tVA RvqyuxNJci9277A5V8Ev2kTw9jIQ2CLkRhtQea7WeVGJOJc+x7X6tEIRt aAyCKWQIzEtncQhqi8w2IqxjYPQ6UQZ8LNijAz8s4HrXqcoCGBnw5uApY U=; X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577741" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Feb 2013 23:48:08 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:48:07 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4F6cbtIE+MqVp3Re6RvPh+tAOp0w== Date: Fri, 8 Feb 2013 10:48:06 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEAE3@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 10:48:11 -0000 [Repost of a series of emails which don't seem to have made it to the list]= =0A= =0A= "Lewis, Nick" writes:=0A= =0A= >With confidence in the TLS being undermined once again as a result of=0A= >problems with its MAC-Pad-Encrypt mechanism are there any plans to adopt a= n=0A= >alternative mechanism such as Pad-MAC-Encrypt in TLS1.3?=0A= =0A= I already have the necessary draft 90% complete, you don't need a rev of TL= S,=0A= just an extension "would you like to do encrypt-then-MAC" in the client hel= lo,=0A= and a corresponding "yes, let's do encrypt-then-MAC" in the server hello.= =0A= Works with any version of TLS. I'll post it in the next day or two.=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Fri Feb 8 02:48:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079E921F8700 for ; Fri, 8 Feb 2013 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.323 X-Spam-Level: X-Spam-Status: No, score=-1.323 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDI++j9cgD3u for ; Fri, 8 Feb 2013 02:48:54 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 600F521F86C9 for ; Fri, 8 Feb 2013 02:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320534; x=1391856534; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Oh52+2djwXQuk37rkgiAanNi1zxUF+lEWByl32FQsoY=; b=XO8qb5IYUroTMKHKUUv98zoNYDx+X9r0dD7PEaV/1WRdxj2DHpe6oNVD nYbl+SbEEWWJaDK9Z81fqOAOW3NFsN+GA1e6a25eqiJc/8VVvY7JwN9Q2 wu51WVTm2oSOt2o9UPQ1gGApghlbiI83TBp7g7G+JyDxuITOC8eCPgrNc U=; X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577775" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Feb 2013 23:48:53 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:48:53 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4F6eKT/YVINa7TTgWA4EvE46WVCA== Date: Fri, 8 Feb 2013 10:48:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 10:48:55 -0000 "Lewis, Nick" writes:=0A= =0A= >Is this really ok for all cipher suites?=0A= =0A= Can't see why it wouldn't be.=0A= =0A= >In those cases that the hash is weak e.g. MD5-HMAC maybe the underlying ke= y=0A= >could be exposed?=0A= =0A= Problems with MD5 don't affect HMAC-MD5.=0A= =0A= >Padding the plain text up to a multiple of the cipher block size (minus th= e=0A= >hash size) ahead of doing the MAC is a more modest change that may be more= =0A= >widely applicable to existing cipher suites - with a "pad-then MAC" client= =0A= >hello=0A= =0A= That won't help against the current attack. The only proper fix for the=0A= various attacks that target the encryption is to protect everything with th= e=0A= MAC, i.e. switch to encrypt-then-MAC. The definitive reference for this is= =0A= Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting= =0A= Communications (Or: How Secure is SSL?)".=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Fri Feb 8 02:49:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91A821F8700 for ; Fri, 8 Feb 2013 02:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ys3Fn4U04k4 for ; Fri, 8 Feb 2013 02:49:39 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6F33C21F86C9 for ; Fri, 8 Feb 2013 02:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320578; x=1391856578; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Q72+NO8V4ZqTOm02Gfe59IjBaIG9FiaKeppconIsFc0=; b=eIbr0tg0yAAq5ekGEVCDLgy0+C9xUso3ALTV36udEiDsWixBzffv42GM H+KuYhebVtHmrpth1/Cn66JKLGCFWTJAWtVJ+zt8S+WF0nRWSmeceumpp m24C2odOmhGQ1Dmeog3IAQweFdcRB2iwRw3PJbQXMInVIuWyN+gJhirY2 8=; X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577793" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Feb 2013 23:49:37 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:49:37 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4F6fygZdSmOMX5RNWqCeZ5aQDRXQ== Date: Fri, 8 Feb 2013 10:49:36 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEAFD@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 10:49:40 -0000 So here's the first cut, if there's anything that needs clarifying/changing= =0A= let me know before I upload it.=0A= =0A= Peter.=0A= =0A= -- Snip --=0A= =0A= TLS Working Group P. Gutmann=0A= Internet-Draft University of Auckland=0A= Intended status: Standards Track February 7, 2013=0A= Expires: August 11, 2013=0A= =0A= =0A= Encrypt-then-MAC for TLS=0A= draft-gutmann-tls-encrypt-then-mac-00.txt=0A= =0A= Abstract=0A= =0A= This document describes a means of negotiating the use of the=0A= encrypt-then-MAC security mechanism in place of TLS' existing MAC-=0A= then-encrypt one, which has been the subject of a number of security=0A= vulnerabilities over a period of many years.=0A= =0A= Status of this Memo=0A= =0A= This Internet-Draft is submitted in full conformance with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF). Note that other groups may also distribute=0A= working documents as Internet-Drafts. The list of current Internet-=0A= Drafts is at http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= This Internet-Draft will expire on August 11, 2013.=0A= =0A= Copyright Notice=0A= =0A= Copyright (c) 2013 IETF Trust and the persons identified as the=0A= document authors. All rights reserved.=0A= =0A= This document is subject to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF Documents=0A= (http://trustee.ietf.org/license-info) in effect on the date of=0A= publication of this document. Please review these documents=0A= carefully, as they describe your rights and restrictions with respect=0A= to this document. Code Components extracted from this document must=0A= include Simplified BSD License text as described in Section 4.e of=0A= the Trust Legal Provisions and are provided without warranty as=0A= described in the Simplified BSD License.=0A= =0A= =0A= =0A= =0A= Gutmann Expires August 11, 2013 [Page 1]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3=0A= 2. Negotiating Encrypt-then-MAC . . . . . . . . . . . . . . . . . 4=0A= 3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . . 5=0A= 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6=0A= 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7=0A= 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8=0A= 6.2. Informative References . . . . . . . . . . . . . . . . . . 8=0A= Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= =0A= Gutmann Expires August 11, 2013 [Page 2]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= 1. Introduction=0A= =0A= [TLS] uses a MAC-then-encrypt construction that was regarded as=0A= secure at the time the original SSL protocol was specified in the=0A= mid-1990s, but that is no longer regarded as secure=0A= [EncryptThenAuth]. This construction, as used in TLS, has been the=0A= subject of numerous security vulnerabilities and attacks stretching=0A= over a period of many years. This document specifies a means of=0A= switching to the more secure encrypt-then-MAC construction as part of=0A= the TLS handshake, replacing the current MAC-then-encrypt=0A= construction.=0A= =0A= 1.1. Conventions Used in This Document=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [RFC2119].=0A= =0A= Gutmann Expires August 11, 2013 [Page 3]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= 2. Negotiating Encrypt-then-MAC=0A= =0A= The use of encrypt-then-MAC is negotiated via TLS extensions as=0A= defined in [TLS]. On connecting, the client includes the=0A= encrypt_then_MAC extension in its client_hello if it wishes to use=0A= encrypt-then-MAC rather than the default MAC-then-encrypt. If the=0A= server is capable of meeting this requirement, it responds with an=0A= encrypt_then_MAC in its server_hello. The "extension_type" value for=0A= this extension is [TBD] and the "extension_data" field of this=0A= extension SHALL be empty.=0A= =0A= =0A= Gutmann Expires August 11, 2013 [Page 4]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= 3. Applying Encrypt-then-MAC=0A= =0A= Once the use of encrypt-then-MAC has been negotiated, processing of=0A= TLS packets switches from the standard:=0A= =0A= encrypt( data || MAC || pad )=0A= =0A= to the new:=0A= =0A= encrypt( data || pad ) || MAC=0A= =0A= with the MAC covering the entire packet up to the start of the MAC=0A= value. In other words the MAC calculation is run over the packet=0A= header and metadata in the usual manner as specified in [TLS], and=0A= then over the encrypted data and padding. The final MAC value is=0A= then appended to the encrypted data and padding.=0A= =0A= Decryption reverses this processing. The MAC SHALL be evaluated=0A= before any further processing such as decryption is performed, and if=0A= the MAC verification fails then processing SHALL terminate=0A= immediately. This eliminates any timing channels that may be=0A= available through the use of manipulated packet data.=0A= =0A= Gutmann Expires August 11, 2013 [Page 5]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= 4. Security Considerations=0A= =0A= This document defines an improved security mechanism encrypt-then-MAC=0A= to replace the current MAC-then-encrypt one. This is regarded as=0A= more secure than the current mechanism [EncryptThenAuth], and should=0A= mitigate or eliminate a number of attacks on the current mechanism,=0A= provided that the instructions on MAC processing given in Section 3=0A= are applied.=0A= =0A= Gutmann Expires August 11, 2013 [Page 6]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= 5. IANA Considerations=0A= =0A= This document defines a new extension for TLS.=0A= =0A= =0A= Gutmann Expires August 11, 2013 [Page 7]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= 6. References=0A= =0A= 6.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security=0A= (TLS) Protocol Version 1.2", RFC 5246, August 2008.=0A= =0A= [TLS-Ext] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,=0A= and T. Wright, "Transport Layer Security (TLS)=0A= Extensions", RFC 4366, April 2006.=0A= =0A= 6.2. Informative References=0A= =0A= [EncryptThenAuth]=0A= Krawczyk, H., "The Order of Encryption and Authentication=0A= for Protecting Communications (or: How Secure Is SSL?)",=0A= Springer-Verlag LNCS 2139, August 2001.=0A= =0A= Gutmann Expires August 11, 2013 [Page 8]=0A= ^L=0A= Internet-Draft Encrypt-then-MAC-for-TLS February 2013=0A= =0A= =0A= Author's Address=0A= =0A= Peter Gutmann=0A= University of Auckland=0A= Department of Computer Science=0A= New Zealand=0A= =0A= Email: pgut001@cs.auckland.ac.nz=0A= =0A= Gutmann Expires August 11, 2013 [Page 9]=0A= From pgut001@cs.auckland.ac.nz Fri Feb 8 02:50:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875E621F8CDE for ; Fri, 8 Feb 2013 02:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw2+iFPmoyvQ for ; Fri, 8 Feb 2013 02:50:15 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48B21F8AC8 for ; Fri, 8 Feb 2013 02:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320614; x=1391856614; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ynNoU65rlRin0B6+ZPxAikCQsRbS30KE8ZalOWb74TE=; b=rc767J3y52JabKZQgvlRPdJgh1nDZq3caBqwh6nBdz9cO/fy8uNTzq7f /QU5tGg/vDcR+nLGiwJPE9JD7lCrYHxZgEm2k0/nK9eWWIqnsFR/4ccq8 R6ilW+RNSRLgSMlOfjEe+kDMjrdn+iw0qB5wd/kOhvVZQzyTmVTp6S/N/ k=; X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577828" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Feb 2013 23:50:13 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:50:13 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4F6hJal/eDxHaMSPWvK83bryz+Xw== Date: Fri, 8 Feb 2013 10:50:12 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEB0A@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 10:50:17 -0000 "Lewis, Nick" writes:=0A= =0A= >My understanding is that the current attack is due to the MAC revealing th= e=0A= >length of the plaintext. If the plaintext is pre-padded to a full crypt bl= ock=0A= >then a MAC can reveal no more than does the ciphertext itself=0A= =0A= >From a very quick read of the paper in an airport lounge (i.e. not a very= =0A= detailed one) it looked like the crucial factor was whether you cross a 64-= =0A= byte HMAC block or not. The padding size is dependent on low-level interna= ls=0A= of the MAC algorithm that's used. In addition while it will stop the curre= nt=0A= attack (which, in the case of straight TLS, isn't terribly practical anyway= ),=0A= it won't stop other attacks. Using encrypt-then-MAC OTOH stops a whole ran= ge=0A= of attacks, including a number of ones that haven't been dreamed up yet,=0A= because the encryption is no longer a possible target.=0A= =0A= Peter.=0A= From pgut001@cs.auckland.ac.nz Fri Feb 8 02:51:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9921F889A for ; Fri, 8 Feb 2013 02:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGHY0XKwTjKq for ; Fri, 8 Feb 2013 02:51:48 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8EF21F8A77 for ; Fri, 8 Feb 2013 02:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360320707; x=1391856707; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Fj4rJT3DuVN9cVgsmSbKKmlS7VEpFBLZ2oMmPEarLOI=; b=si8qQjuKf2Iy+NBfV7WyjOzaTZHxvaQ1gMbP2UbnNSQZqjqB8xXzmhmf Nzd2AnUl80CHb1k2QoZHHO1EPWfjccRlelM6vG2eOWbo24OnBnTnItVMV GUgU5MtPq0kQkcSh8lXge4MDGNG/vjrX/cSDcYsFUBJ7LPRliaad3IRW2 s=; X-IronPort-AV: E=Sophos;i="4.84,628,1355050800"; d="scan'208";a="169577877" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 08 Feb 2013 23:51:20 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 8 Feb 2013 23:51:19 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 23:51:19 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: Ac4F6jk6Zmu1a+kQQaWFt75kxJaZdg== Date: Fri, 8 Feb 2013 10:51:18 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 10:51:51 -0000 Eric Rescorla writes:=0A= =0A= >WG members, please provide any comments on whether we should take this wor= k=0A= >on by February 21. Additionally, if you wish to propose an alternative, it= =0A= >would be nice if you could do so soon or at least provide an indication of= =0A= >interest.=0A= =0A= A comment on both of these proposals, to encode their protocols they use an= =0A= ad-hoc, non-TLS-style encoding whose form is rather unclear:=0A= =0A= Protocols are named by IANA registered, opaque, non-empty byte strings an= d=0A= the list of protocols is serialized as a concatenation of 8-bit, length= =0A= prefixed byte strings.=0A= =0A= Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or= =0A= neither? What's wrong with:=0A= =0A= opaque ProtocolName<1..2^16-1>;=0A= =0A= struct {=0A= ProtocolName protocol_name_list<1..2^16-1>=0A= } ProtocolNameList;=0A= =0A= which fits the way everything else is done in TLS?=0A= =0A= Peter.= From ynir@checkpoint.com Fri Feb 8 03:41:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B84D21F8887 for ; Fri, 8 Feb 2013 03:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS7hGm4r+sdv for ; Fri, 8 Feb 2013 03:41:50 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8B65421F8815 for ; Fri, 8 Feb 2013 03:41:49 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r18BfSkm021139; Fri, 8 Feb 2013 13:41:33 +0200 X-CheckPoint: {5114E094-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Fri, 8 Feb 2013 13:41:28 +0200 From: Yoav Nir To: Peter Gutmann Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: Ac4F6jk6GL86wqFuI0yIDZn7ET3rH///7HeA Date: Fri, 8 Feb 2013 11:41:27 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199F3E9@IL-EX10.ad.checkpoint.com> References: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.6] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <39A46A3011F8904388517EEB2C9D9DA6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 11:41:50 -0000 On Feb 8, 2013, at 12:51 PM, Peter Gutmann wrot= e: > Eric Rescorla writes: >=20 >> WG members, please provide any comments on whether we should take this w= ork >> on by February 21. Additionally, if you wish to propose an alternative, = it >> would be nice if you could do so soon or at least provide an indication = of >> interest. >=20 > A comment on both of these proposals, to encode their protocols they use = an > ad-hoc, non-TLS-style encoding whose form is rather unclear: >=20 > Protocols are named by IANA registered, opaque, non-empty byte strings a= nd > the list of protocols is serialized as a concatenation of 8-bit, length > prefixed byte strings. >=20 > Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, = or > neither? What's wrong with: I agree that it's not clean, but I took it to mean ...serialized as a conca= tenation of (((8-bit length) prefixed) byte strings) So a byte length followed by that many bytes of string, followed by another= byte length, and so on. From ynir@checkpoint.com Fri Feb 8 03:43:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBBC21F8887 for ; Fri, 8 Feb 2013 03:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTyIAcXt+l-x for ; Fri, 8 Feb 2013 03:43:14 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D614A21F8901 for ; Fri, 8 Feb 2013 03:43:13 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r18Bh9iS021296; Fri, 8 Feb 2013 13:43:09 +0200 X-CheckPoint: {5114E0F9-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Fri, 8 Feb 2013 13:43:10 +0200 From: Yoav Nir To: Adam Langley Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: AQHOBYr9GL86wqFuI0yIDZn7ET3rH5hu6dMAgADMeoA= Date: Fri, 8 Feb 2013 11:43:09 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199F41A@IL-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.6] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <93271CAB0C38D04E80F239981AE52AD9@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 11:43:14 -0000 On Feb 8, 2013, at 1:31 AM, Adam Langley wrote: > On Thu, Feb 7, 2013 at 6:28 PM, Eric Rescorla wrote: >> WG members, please provide any comments on whether we should >> take this work on by February 21. >=20 > Unsurprisingly, perhaps, I support the WG taking this work on. +1 (although I think we're not in agreement on which proposal should be sel= ected) From ynir@checkpoint.com Fri Feb 8 03:47:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6B421F84F6 for ; Fri, 8 Feb 2013 03:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.53 X-Spam-Level: X-Spam-Status: No, score=-10.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+GIq8vJv1AR for ; Fri, 8 Feb 2013 03:47:29 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1257421F854C for ; Fri, 8 Feb 2013 03:47:28 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r18BlO7H022039; Fri, 8 Feb 2013 13:47:24 +0200 X-CheckPoint: {5114E1F7-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Fri, 8 Feb 2013 13:47:24 +0200 From: Yoav Nir To: Peter Gutmann Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4F6fygdOkbgTmiQdegAlKQMafBUv//7piA Date: Fri, 8 Feb 2013 11:47:23 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277211199F46C@IL-EX10.ad.checkpoint.com> References: <9A043F3CF02CD34C8E74AC1594475C73333FEAFD@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEAFD@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.6] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 11:47:30 -0000 Hi Peter It would help to explain why this is better than just defining some new enc= rypt-then-MAC ciphersuites. Cartesian explosion is a good argument. Are the= re others? Yoav On Feb 8, 2013, at 12:49 PM, Peter Gutmann wrot= e: > So here's the first cut, if there's anything that needs clarifying/changi= ng > let me know before I upload it. >=20 > Peter. >=20 > -- Snip -- >=20 > TLS Working Group P. Gutmann > Internet-Draft University of Auckland > Intended status: Standards Track February 7, 2013 > Expires: August 11, 2013 >=20 >=20 > Encrypt-then-MAC for TLS > draft-gutmann-tls-encrypt-then-mac-00.txt >=20 > Abstract >=20 > This document describes a means of negotiating the use of the > encrypt-then-MAC security mechanism in place of TLS' existing MAC- > then-encrypt one, which has been the subject of a number of security > vulnerabilities over a period of many years. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > 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." >=20 > This Internet-Draft will expire on August 11, 2013. >=20 > Copyright Notice >=20 > Copyright (c) 2013 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > 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 Simplified BSD License. >=20 >=20 >=20 >=20 > Gutmann Expires August 11, 2013 [Page 1] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 > 2. Negotiating Encrypt-then-MAC . . . . . . . . . . . . . . . . . 4 > 3. Applying Encrypt-then-MAC . . . . . . . . . . . . . . . . . . . 5 > 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 > 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 > 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 >=20 > Gutmann Expires August 11, 2013 [Page 2] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > 1. Introduction >=20 > [TLS] uses a MAC-then-encrypt construction that was regarded as > secure at the time the original SSL protocol was specified in the > mid-1990s, but that is no longer regarded as secure > [EncryptThenAuth]. This construction, as used in TLS, has been the > subject of numerous security vulnerabilities and attacks stretching > over a period of many years. This document specifies a means of > switching to the more secure encrypt-then-MAC construction as part of > the TLS handshake, replacing the current MAC-then-encrypt > construction. >=20 > 1.1. Conventions Used in This Document >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. >=20 > Gutmann Expires August 11, 2013 [Page 3] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > 2. Negotiating Encrypt-then-MAC >=20 > The use of encrypt-then-MAC is negotiated via TLS extensions as > defined in [TLS]. On connecting, the client includes the > encrypt_then_MAC extension in its client_hello if it wishes to use > encrypt-then-MAC rather than the default MAC-then-encrypt. If the > server is capable of meeting this requirement, it responds with an > encrypt_then_MAC in its server_hello. The "extension_type" value for > this extension is [TBD] and the "extension_data" field of this > extension SHALL be empty. >=20 >=20 > Gutmann Expires August 11, 2013 [Page 4] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > 3. Applying Encrypt-then-MAC >=20 > Once the use of encrypt-then-MAC has been negotiated, processing of > TLS packets switches from the standard: >=20 > encrypt( data || MAC || pad ) >=20 > to the new: >=20 > encrypt( data || pad ) || MAC >=20 > with the MAC covering the entire packet up to the start of the MAC > value. In other words the MAC calculation is run over the packet > header and metadata in the usual manner as specified in [TLS], and > then over the encrypted data and padding. The final MAC value is > then appended to the encrypted data and padding. >=20 > Decryption reverses this processing. The MAC SHALL be evaluated > before any further processing such as decryption is performed, and if > the MAC verification fails then processing SHALL terminate > immediately. This eliminates any timing channels that may be > available through the use of manipulated packet data. >=20 > Gutmann Expires August 11, 2013 [Page 5] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > 4. Security Considerations >=20 > This document defines an improved security mechanism encrypt-then-MAC > to replace the current MAC-then-encrypt one. This is regarded as > more secure than the current mechanism [EncryptThenAuth], and should > mitigate or eliminate a number of attacks on the current mechanism, > provided that the instructions on MAC processing given in Section 3 > are applied. >=20 > Gutmann Expires August 11, 2013 [Page 6] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > 5. IANA Considerations >=20 > This document defines a new extension for TLS. >=20 >=20 > Gutmann Expires August 11, 2013 [Page 7] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > 6. References >=20 > 6.1. Normative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security > (TLS) Protocol Version 1.2", RFC 5246, August 2008. >=20 > [TLS-Ext] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., > and T. Wright, "Transport Layer Security (TLS) > Extensions", RFC 4366, April 2006. >=20 > 6.2. Informative References >=20 > [EncryptThenAuth] > Krawczyk, H., "The Order of Encryption and Authentication > for Protecting Communications (or: How Secure Is SSL?)", > Springer-Verlag LNCS 2139, August 2001. >=20 > Gutmann Expires August 11, 2013 [Page 8] > ^L > Internet-Draft Encrypt-then-MAC-for-TLS February 2013 >=20 >=20 > Author's Address >=20 > Peter Gutmann > University of Auckland > Department of Computer Science > New Zealand >=20 > Email: pgut001@cs.auckland.ac.nz >=20 > Gutmann Expires August 11, 2013 [Page 9] > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Email secured by Check Point From nick.lewis@usa.g4s.com Fri Feb 8 03:48:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4313021F854C for ; Fri, 8 Feb 2013 03:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.094 X-Spam-Level: X-Spam-Status: No, score=-5.094 tagged_above=-999 required=5 tests=[AWL=1.504, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szUMUVzeCNxK for ; Fri, 8 Feb 2013 03:48:44 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF1E21F8955 for ; Fri, 8 Feb 2013 03:48:44 -0800 (PST) Received: from [85.158.140.195:20068] by server-10.bemta-14.messagelabs.com id 05/B3-12679-B16E4115; Fri, 08 Feb 2013 11:48:43 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-7.tower-193.messagelabs.com!1360324123!13544186!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15784 invoked from network); 8 Feb 2013 11:48:43 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-7.tower-193.messagelabs.com with RC4-SHA encrypted SMTP; 8 Feb 2013 11:48:43 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Fri, 8 Feb 2013 11:48:43 +0000 From: "Lewis, Nick" To: "tls@ietf.org" Date: Fri, 8 Feb 2013 11:48:42 +0000 Thread-Topic: Re: [TLS] TLS1.3 Thread-Index: Ac4F8kVNx4hExgXuSR+yTxN28WBR5A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 11:48:45 -0000 >So here's the first cut, if there's anything that needs clarifying/changin= g let me know before I upload it. >Peter. While I believe that the responsibility for the mechanism that combines mac= , crypt and pad should move from TLS to the cipher suites in the longer ter= m, this extension seems to give most of the benefits without needing to por= t any cipher suites to AEAD The document could be a little clearer if it used the same terminology as u= sed in [TLS] such as "+" for concatenation and if it was more explict about= the MAC e.g. MAC(MAC_write_key, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + ENC(TLSCompressed.fragment + padding + padding_length)); where "+" denotes concatenation. -- Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From mcgrew@cisco.com Fri Feb 8 04:22:20 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B689E21F8633 for ; Fri, 8 Feb 2013 04:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE+9HV2PjNNb for ; Fri, 8 Feb 2013 04:22:19 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AD1C021F8617 for ; Fri, 8 Feb 2013 04:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7422; q=dns/txt; s=iport; t=1360326139; x=1361535739; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Vgrf/f6A1J8eEgNva8MF+F0LJgtEYgkqAmsupZwdQ9U=; b=R+ed1tKZGyJd1eiedERh3Af/oH1XrYqsE1qbvAuN5/sHEV51IjHFtvOq B8FbnNIAaT3J5UcZD1aWlLDZ8Hw49Og7s01VZ5ki6Cu7CsLmVuSXE7Ff9 j9H2nI9g+6jIjqsXoYZwS57ecABFcWpc6gGmm7TxrlwFW5NQUrEvsf8jr Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFAKHsFFGtJXHB/2dsb2JhbABFDoI7tRQBiTEWc4IfAQEBBC1MEgEIEQMBAgsdORQJCAEBBAENBQiICQzAf5B7YQOXQY81gkI+giQ X-IronPort-AV: E=Sophos;i="4.84,629,1355097600"; d="scan'208,217";a="174888301" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 08 Feb 2013 12:22:19 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r18CMJTP018988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 12:22:19 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 06:22:18 -0600 From: "David McGrew (mcgrew)" To: "Paterson, Kenny" , Eric Rescorla , Nikos Mavrogiannopoulos Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4FDy/edOkbgTmiQdegAlKQMafBUgAOzp2AAAaaigAAAmb4gAAkN6cA Date: Fri, 8 Feb 2013 12:22:18 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183D064B@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B183D064Bxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: "Lewis, Nick" , "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 12:22:20 -0000 --_000_747787E65E3FBD4E93F0EB2F14DB556B183D064Bxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 If there is a need for TLS to adopt an authenticated encryption method that= uses AES-CBC and HMAC, then draft is already written, as Kenny points out.= It is also fairly mature and stable, and has seen a good amount of revi= ew. There are four implementations that I've heard of so far, and a set of= test cases thanks to John Foley and James Manger, which will be added in t= he update to the draft. David From: , Kenny > Date: Thursday, February 7, 2013 9:05 AM To: Eric Rescorla >, Nikos Mavrogiannopou= los > Cc: "Lewis, Nick" >, = "tls@ietf.org" > Subject: Re: [TLS] TLS1.3 Hi, http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01 provides a specification that could be rather easily adapted to the case in= hand. Kenny There's not really any need to do a TLS 1.3 for this. TLS 1.2 includes support for AEAD ciphers, so all that would be needed is to define an Enrypt-Then-Mac AEAD cipher and it will drop into TLS 1.2. Best, -Ekr --_000_747787E65E3FBD4E93F0EB2F14DB556B183D064Bxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
+1   

If there is a need for TLS to adopt an authenticated encryption method= that uses AES-CBC and HMAC, then draft is already written, as Kenny points= out.    It is also fairly mature and stable, and has seen a good= amount of review.  There are four implementations that I've heard of so far, and a set of test cases thanks to John Foley an= d James Manger, which will be added in the update to the draft.  

David

From: <Paterson>, Kenny <<= a href=3D"mailto:Kenny.Paterson@rhul.ac.uk">Kenny.Paterson@rhul.ac.uk&g= t;
Date: Thursday, February 7, 2013 9:= 05 AM
To: Eric Rescorla <ekr@rtfm.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>
Cc: "Lewis, Nick" <nick.lewis@usa.g4s.com>, &quo= t;tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS1.3

Hi,

 

http://tools.ietf.org/html/draf= t-mcgrew-aead-aes-cbc-hmac-sha2-01

 

provides a specification that coul= d be rather easily adapted to the case in hand.

 

Kenny

 

There's not really any need to do a TLS 1.3 for this= . TLS 1.2 includes

support for AEAD ciphers, so all that would be neede= d is to define

an Enrypt-Then-Mac AEAD cipher and it will drop into= TLS 1.2.

 

Best,

-Ekr=

--_000_747787E65E3FBD4E93F0EB2F14DB556B183D064Bxmbrcdx04ciscoc_-- From pgut001@cs.auckland.ac.nz Fri Feb 8 04:39:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A7B21F86C3 for ; Fri, 8 Feb 2013 04:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y51LnBe9t1pQ for ; Fri, 8 Feb 2013 04:39:26 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 204AB21F86B6 for ; Fri, 8 Feb 2013 04:39:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360327166; x=1391863166; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=2b8oxnr7/+uTlb0iCAKL5cAVYh22xt9xMEXpuvhK7J0=; b=W8+5yBcYqfiavrb9/KeL9fpaKvQKmCVjKDEtlBpmZjezU6sDhUnt/R8K Bk81CvPhwMe7B5cEcIbdP8ueC9JJjcOr54zRsDGHWys1ckvMAsn8PiRXf x57aaxUeI5F4911gMLzKwsmDMoIgT/BPWQP2yXKhoQlrWejbo9XRPedHX A=; X-IronPort-AV: E=Sophos;i="4.84,629,1355050800"; d="scan'208";a="169586259" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Feb 2013 01:39:24 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Sat, 9 Feb 2013 01:39:23 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-gutmann-tls-encrypt-then-mac-00.txt Thread-Index: Ac4F+VKx9aHOHfIcTWWIN9ze88/icA== Date: Fri, 8 Feb 2013 12:39:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEC30@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] New Version Notification for draft-gutmann-tls-encrypt-then-mac-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:39:27 -0000 Thanks to everyone who provided feedback on the strawman version (I've chan= ged=0A= the subject line to keep the discussion separate), I've (hopefully) correct= ed=0A= the issues that people pointed out and posted the result:=0A= =0A= -- Snip --=0A= =0A= A new version of I-D, draft-gutmann-tls-encrypt-then-mac-00.txt has been=0A= successfully submitted by Peter Gutmann and posted to the IETF repository.= =0A= =0A= Filename: draft-gutmann-tls-encrypt-then-mac=0A= Revision: 00=0A= Title: Encrypt-then-MAC for TLS=0A= Creation date: 2013-02-08=0A= WG ID: Individual Submission=0A= Number of pages: 10=0A= URL: http://www.ietf.org/internet-drafts/draft-gutmann-tls-encr= ypt-then-mac-00.txt=0A= Status: http://datatracker.ietf.org/doc/draft-gutmann-tls-encrypt-= then-mac=0A= Htmlized: http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-= mac-00=0A= =0A= Abstract:=0A= =0A= This document describes a means of negotiating the use of the encrypt-th= en-=0A= MAC security mechanism in place of TLS' existing MAC- then-encrypt one,= =0A= which has been the subject of a number of security vulnerabilities over = a=0A= period of many years.=0A= =0A= -- Snip --=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Fri Feb 8 04:47:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF0D21F8887 for ; Fri, 8 Feb 2013 04:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpW6XQ59pjwR for ; Fri, 8 Feb 2013 04:47:10 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4C21F8810 for ; Fri, 8 Feb 2013 04:47:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360327630; x=1391863630; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=OCem90DrgUMA3tIZW38IJAdgbp+q47FS+3fsK0QMAco=; b=CkGPaJdyiGtdVme2pjhPHaxko0PnuWmthOB7PjjPJe5CTQqVQWDJtN0x wRTWkPJdDkCHxkAnf2sz3qyzyh8ADORAzS2HERwO44fBBfVUubJI6Kd5O KkhTxUWtErM84XBvtkoC8YOkTbaBcQIqAvE9jLYv/GT1lJ5gAd/AtSQfE 0=; X-IronPort-AV: E=Sophos;i="4.84,629,1355050800"; d="scan'208";a="169586505" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Feb 2013 01:47:09 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 9 Feb 2013 01:47:09 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: Ac4F+mh4DbKYHv4GTn60O7uOKM+kWg== Date: Fri, 8 Feb 2013 12:47:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FEC55@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 12:47:16 -0000 Yoav Nir writes:=0A= >On Feb 8, 2013, at 12:51 PM, Peter Gutmann = wrote:=0A= >> Eric Rescorla writes:=0A= >> =0A= >>> WG members, please provide any comments on whether we should take this = work=0A= >>> on by February 21. Additionally, if you wish to propose an alternative,= it=0A= >>> would be nice if you could do so soon or at least provide an indication= of=0A= >>> interest.=0A= >> =0A= >> A comment on both of these proposals, to encode their protocols they use= an=0A= >> ad-hoc, non-TLS-style encoding whose form is rather unclear:=0A= >> =0A= >> Protocols are named by IANA registered, opaque, non-empty byte strings = and=0A= >> the list of protocols is serialized as a concatenation of 8-bit, length= =0A= >> prefixed byte strings.=0A= >> =0A= >> Does this mean the strings use 8-bit chars, the lengths are 8 bit, both,= or=0A= >> neither? What's wrong with:=0A= >=0A= >I agree that it's not clean, but I took it to mean ...serialized as a=0A= >concatenation of (((8-bit length) prefixed) byte strings)=0A= =0A= Yeah, I'd sorta guessed that, but I'd really prefer it if they used the=0A= standard TLS format for things. At the moment I have to drop use of standa= rd=0A= TLS PDU parsing and switch to an ad-hoc custom-written parser for that one= =0A= data blob, I can't see any good reason to use the nonstandard format when= =0A= everything else in TLS uses the standard one.=0A= =0A= Peter.= From n.mavrogiannopoulos@gmail.com Fri Feb 8 04:50:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE0B21F8815 for ; Fri, 8 Feb 2013 04:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.727 X-Spam-Level: X-Spam-Status: No, score=-2.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8DY9xh+5d4g for ; Fri, 8 Feb 2013 04:50:02 -0800 (PST) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2962821F88BE for ; Fri, 8 Feb 2013 04:50:02 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id z24so1398702qcq.19 for ; Fri, 08 Feb 2013 04:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=PuuGA7mIv2XOiAQPPQfmHdGTCQuRW67wBgVktckd530=; b=TtV6SgTs0CoryUtJZP9uFzZa/8LoIVKt0Zf6PVmw3M9sTWfFIN3KRe4ZELrpfiuOIA oH/r66IXcKOf2hj4RfVt6ROlcvvabeogTDxdZ4IxG0Hzf0IkSshopsyQLlZC7+M6ShZT +T6SBTG/D9kfKjy36nZDkdky2ITvV0EWm+3rend4/8gkq1p94VSPJCCDgkCj/3i4h6Q+ SJmpubI0+rqidc8Z3atMJUDvTT/hP3HcNyFzT3Txx5yKOWlEZX3faL9FzsBpOvmufGFN cwJbqWoob2RZsyaqYPV2YVnlvPCTAboF+dLRr4/VDk6z8JfvvtWLaMkq9sTuJ72JQh2i +pWg== MIME-Version: 1.0 X-Received: by 10.229.171.84 with SMTP id g20mr439969qcz.73.1360327801523; Fri, 08 Feb 2013 04:50:01 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.78.204 with HTTP; Fri, 8 Feb 2013 04:50:01 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> Date: Fri, 8 Feb 2013 13:50:01 +0100 X-Google-Sender-Auth: LKSA1WjRM7qcHvRSWKajDFdpZC4 Message-ID: From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 12:50:03 -0000 On Fri, Feb 8, 2013 at 11:48 AM, Peter Gutmann wrote: >>Padding the plain text up to a multiple of the cipher block size (minus the >>hash size) ahead of doing the MAC is a more modest change that may be more >>widely applicable to existing cipher suites - with a "pad-then MAC" client >>hello > That won't help against the current attack. This family of attacks relies on the fact that padding isn't authenticated, i.e, you can play with it without being detected. If pad is part of the MAC there is no issue. > The only proper fix for the > various attacks that target the encryption is to protect everything with the > MAC, i.e. switch to encrypt-then-MAC. The definitive reference for this is > Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting > Communications (Or: How Secure is SSL?)". Using encrypt-then-MAC to counter the attack is as radical change as using the GCM or CCM modes. This isn't a small fix, it is an upgrade which changes the protocol semantics (e.g. MAC is no longer encrypted - whatever that may mean). Moreover, encrypt-then-MAC isn't a panacea. There is nothing wrong with MAC-then-encrypt, it is TLS that applied it incorrectly by keeping the pad unauthenticated. I'd prefer a fix that keeps the current protocol semantics. regards, Nikos From Kenny.Paterson@rhul.ac.uk Fri Feb 8 05:03:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905D321F8A0C for ; Fri, 8 Feb 2013 05:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gAYs2nRks6s for ; Fri, 8 Feb 2013 05:03:50 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id D46E021F86BB for ; Fri, 8 Feb 2013 05:03:49 -0800 (PST) Received: from mail16-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 13:03:49 +0000 Received: from mail16-va3 (localhost [127.0.0.1]) by mail16-va3-R.bigfish.com (Postfix) with ESMTP id 11E473A01BC; Fri, 8 Feb 2013 13:03:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.107; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB01.cc.rhul.local; RD:exch-hub01.rhul.ac.uk; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail16-va3 (localhost.localdomain [127.0.0.1]) by mail16-va3 (MessageSwitch) id 1360328623262609_21180; Fri, 8 Feb 2013 13:03:43 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.245]) by mail16-va3.bigfish.com (Postfix) with ESMTP id 0D76422026B; Fri, 8 Feb 2013 13:03:43 +0000 (UTC) Received: from EXCH-HUB01.cc.rhul.local (134.219.208.107) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 13:03:42 +0000 Received: from EXCH-MB01.cc.rhul.local ([169.254.3.31]) by EXCH-HUB01.cc.rhul.local ([2002:86db:d06b::86db:d06b]) with mapi id 14.02.0328.009; Fri, 8 Feb 2013 13:03:41 +0000 From: "Paterson, Kenny" To: Nikos Mavrogiannopoulos , "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4F6eKTdOkbgTmiQdegAlKQMafBUgAEOw+AAABCC5A= Date: Fri, 8 Feb 2013 13:03:40 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.219.208.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 13:03:50 -0000 Nikos, all > Using encrypt-then-MAC to counter the attack is as radical change as > using the GCM or CCM modes.=20 I agree. It will take work. But it's time for that kind of change. > This isn't a small fix, it is an upgrade > which changes the protocol semantics (e.g. MAC is no longer encrypted > - whatever that may mean). Moreover, encrypt-then-MAC isn't a panacea. It fixes every problem I can conceive of. And I've thought about the analys= is of TLS's current MAC-pad-encrypt construction long and hard, believe me. > There is nothing wrong with MAC-then-encrypt,=20 I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000 and Hug= o Krawczyk's paper from Crypto 2001 both demonstrate good reasons to be sus= picious of MAC-then-encrypt from a theoretical perspective.=20 And in practice, time and again it's proven to be problematic. And not just= in TLS (see for example my paper with Jean Paul Degabriele at ACM-CCS 2010= about MAC-then-encrypt configurations of IPsec. TL;DR: we broke them all). Cheers Kenny From agl@google.com Fri Feb 8 05:23:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9049921F8574 for ; Fri, 8 Feb 2013 05:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGAUxWDIcjh1 for ; Fri, 8 Feb 2013 05:23:21 -0800 (PST) Received: from mail-ia0-x229.google.com (ia-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3221F8497 for ; Fri, 8 Feb 2013 05:23:20 -0800 (PST) Received: by mail-ia0-f169.google.com with SMTP id j5so4260548iaf.0 for ; Fri, 08 Feb 2013 05:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ect3m9dRtxMfEJ4ha5tGRvBMG/d2B08W8O3jTI02Nus=; b=Vrf2LC1fWpisQqDQ6xi9n0LpZj8oagUb60CIDAYW71EZNpTjQs/Suo3dPmz+Rym2Uw lhaXct93btIgGktD0s8rZiwotbeGpGfOnI9ACTkbcxhr/0D7iNG8BzgP/4zHkQzbyE9/ iYSwS9rND7TOO1/9CXb4DdphYzM08ecjkQPrevROzpfFCctYnYvTflIQkKgtnRfNGd6k OFctMa2nd7+MC9W+74X7s9EI5G0kJL/BPqJjdp9mnEr4p0BOho+d05EXEU3xGaVALGAK NN0QhgmcPwYBRd/wSAW7bA13VRiT1lxOpy8onjR5f2GQT1Ndc6TaL6ONLcN3leXbcIhV 9QJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ect3m9dRtxMfEJ4ha5tGRvBMG/d2B08W8O3jTI02Nus=; b=otNqAAWAv/QDnV6hUkNeyoe8c9AkctH2htCMng8k0zeSujx2IYr2mNnuy3v0vNMpo+ pc7WPnGZIwg5kwYDDt6Fjn7obmyJeg7uvFEq2uqxBIexhixCIwqPcg58vX7V5H9neh7I THQ81ddEvo24Qh8a/XraIEWOvQnmPIcYs4tLSrkxuEtH3wDFsqDRiBk0Uq5e4B5g9bUg LTQbGN+I0gmUryEeGIW3eKiyXcFpC/qeXpLHeDBkcj+tphLqcNQfXJjfXFXZOQU1256s mqSPfOd2Kuyc+9lSCrCZ2MtOjBGj6c2uO9SGK/oN85sT7tWjUCCiM5sDCRjyQblRJNgH VbpQ== MIME-Version: 1.0 X-Received: by 10.50.57.164 with SMTP id j4mr2141542igq.91.1360329800217; Fri, 08 Feb 2013 05:23:20 -0800 (PST) Received: by 10.231.241.201 with HTTP; Fri, 8 Feb 2013 05:23:20 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEC55@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73333FEC55@uxcn10-2.UoA.auckland.ac.nz> Date: Fri, 8 Feb 2013 08:23:20 -0500 Message-ID: From: Adam Langley To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlVPy6g+0CFg3IUKLdhs04hR9Lnxcc/QIc0CvrN9EN7dNIC6Y8wxuC44NaSTczQM/TiW645GyXeGbRxBYLbb4IkiVS7tssPgb/EVZXthSNoe678kPj0ajssl/IdCeWhJkRiLuq0dOxxHxvnv/jHfZTJUBRTIyzozlPv0duukGTFn9H4gFNuG9+th8ZSj5J23gmzG1q8 Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 13:23:22 -0000 On Fri, Feb 8, 2013 at 7:47 AM, Peter Gutmann wrote: > Yeah, I'd sorta guessed that, but I'd really prefer it if they used the > standard TLS format for things. At the moment I have to drop use of standard > TLS PDU parsing and switch to an ad-hoc custom-written parser for that one > data blob, I can't see any good reason to use the nonstandard format when > everything else in TLS uses the standard one. The difference between the wording and using the TLS presentation format is the addition of an extra length prefix. Since the extension already has a length, it's a little sad that using the presentation format requires adding another one - it's not as if these structures are ever extended with extra, optional fields. None the less, in the interests of being uniform, maybe we should have another length. Cheers AGL From mrex@sap.com Fri Feb 8 11:04:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F342021F88CA for ; Fri, 8 Feb 2013 11:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.307 X-Spam-Level: X-Spam-Status: No, score=-10.307 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhnxp-T0C9ec for ; Fri, 8 Feb 2013 11:04:16 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D0CC621F882A for ; Fri, 8 Feb 2013 11:04:14 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r18J444l023992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2013 20:04:04 +0100 (MET) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> To: Peter Gutmann Date: Fri, 8 Feb 2013 20:04:04 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20130208190404.9D00B1A52E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:04:17 -0000 Peter Gutmann wrote: > "Lewis, Nick" writes: >>=20 >>Padding the plain text up to a multiple of the cipher block size (minus t= he >>hash size) ahead of doing the MAC is a more modest change that may be more >>widely applicable to existing cipher suites - with a "pad-then MAC" client >>hello >=20 > That won't help against the current attack. The only proper fix for the > various attacks that target the encryption is to protect everything with = the > MAC, i.e. switch to encrypt-then-MAC. The definitive reference for this = is > Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting > Communications (Or: How Secure is SSL?)". I disagree. What you're saying is that the countermeasures that are currently being adopted would not help against the current attack. I do believe that pad, hash, encrypt would be sufficient (while still being sensitive about ensuring the same codepath). Looking at the original Paper from Sergey Vaudenay from 2001: http://infoscience.epfl.ch/record/52417/files/IC_TECH_REPORT_200150.pdf Section 5.1 SSL/TLS 2nd paragraph (page 6): TLS v1.0 also provides an optional MAC which failed to thwart the attack: when the server =AFgures out that the MAC is wrong, it yields the bad_rec= ord_mac error. However, the message padding is performed after the MAC algorithm,= so the MAC does not preclude our attack since it cannot be checked before the padding in the decryption. explains that TLS has is susceptible to the timing attack due to MAC-then-pad, and then describes in Section 6.5 CBC-PAD with Integrity Check One can propose to add a cryptographic checkable redundancy code (crypto-CRC) of the whole padded message (like a hashed value) in the plaintext and encrypt message|padding|h(message|padding) This way, any forged ciphertext will have a negligible probability to be accepted as a valid ciphertext. Basically, attackers are no longer able to forge valid cipher-texts, so the scheme is virtually resistant against chosen ciphertext attacks. Obviously it is important to pad before hashing: padding after hashing would lead to the a similar attack. The right enciphering sequence is thus pad, hash, encrypt Conversely, the right deciphering sequence consists of decrypting, checking the hashed value, then checking the padding value. Invalid hashed value must abort the decipherment. Making the code use the same CPU cycles would definitely _much_ easier with TLS doing pad-MAC-encrypt, then with the original MAC-pad-encrypt. I'm actually slightly puzzled why this change was not made in TLSv1.1 along with backwards-incompatible change of the GenericBlockCipher PDU that added an explicit IV. -Martin From openpgp@brainhub.org Fri Feb 8 11:13:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44A21F8B13 for ; Fri, 8 Feb 2013 11:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qu12stAUDRjq for ; Fri, 8 Feb 2013 11:13:03 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECD221F8B81 for ; Fri, 8 Feb 2013 11:12:59 -0800 (PST) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta03.emeryville.ca.mail.comcast.net with comcast id xpgc1k0050vp7WLA3vCz1f; Fri, 08 Feb 2013 19:12:59 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta05.emeryville.ca.mail.comcast.net with comcast id xvCx1k00Y2g33ZR8RvCyxw; Fri, 08 Feb 2013 19:12:58 +0000 Message-ID: <51154DCF.4090407@brainhub.org> Date: Fri, 08 Feb 2013 11:11:11 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360350779; bh=98YDsimmkF/jE7umkr0LotBgzc/rP8zALpiWBOtuPrM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lK0632RPFyGJeBx/ml8d8zSOx2KPUSXP/v7Rhg2qTQgvCCMUKFY1Dldg7a2dBxL/k 1h3n76Rbkyj6jnmavEHRIquIVo4po+X6+DHEfptC8nfAeCtFE1ltqVQ/NW82ywgdVe Ay6IyqCajguzqraXVZXrmvqVTbT+9759lWJb9sN0La7ImliLevZot6rP7TXgrcYJMB QgepqGesxm/6P7cVIVZ3oUJSklt0Laft0lcx7rfg+6IHjW4FzRcvqK9rU/x9VcdnAk CDunsflOoM3KBuyKHBSrjkGw1qE417CFs0yhbCA7avoiXmCXvsCmtSBtwDUU3xjXOU 4fpKN1QRskxdA== X-Mailman-Approved-At: Fri, 08 Feb 2013 11:17:08 -0800 Subject: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 19:13:04 -0000 I ran into an interoperability problem between our TLS implementation and another very popular one. The question is what exactly is the formatting for the RFC224 sec. 8.1.2 "Diffie-Hellman" shared secret 'Z' ? The problem arises when the most significant byte of the Z is zero. Let's say that the field prime's size is 256. There are two possibilities: 1. export the Z in the big endian format, padding it to 256 (first byte in the buffer is zero) 2. export the Z in the big endian format, placing the result in a 255 byte buffer. I would say that this should be #1, because it is the natural representation of the Z. If there is a language specifying the canonical encoding for the Z, I would appreciate the reference. ( Apparently, this problem doesn't clearly manifest itself in real deployments because ~ the 1/256 failure rate is masked by re-negotiations at the higher protocol level. ) Thank you. From lloyd@randombit.net Fri Feb 8 11:23:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C321F8BC9 for ; Fri, 8 Feb 2013 11:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBVRM5tQDyvN for ; Fri, 8 Feb 2013 11:23:01 -0800 (PST) Received: from chihiro.randombit.net (chihiro.randombit.net [69.48.226.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF8721F8BE7 for ; Fri, 8 Feb 2013 11:23:01 -0800 (PST) Received: by chihiro.randombit.net (Postfix, from userid 1000) id 034C41249AF0; Fri, 8 Feb 2013 14:22:59 -0500 (EST) Date: Fri, 8 Feb 2013 14:22:59 -0500 From: Jack Lloyd To: tls@ietf.org Message-ID: <20130208192259.GA31819@randombit.net> Mail-Followup-To: tls@ietf.org References: <51154DCF.4090407@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51154DCF.4090407@brainhub.org> X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 19:23:05 -0000 On Fri, Feb 08, 2013 at 11:11:11AM -0800, Andrey Jivsov wrote: > I ran into an interoperability problem between our TLS implementation > and another very popular one. > > The question is what exactly is the formatting for the RFC224 sec. > 8.1.2 "Diffie-Hellman" shared secret 'Z' ? Both TLS 1.1 and 1.2 RFCs say in this section "Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret." and it is my understanding that while left unstated, this is also the case for SSLv3/TLS 1.0 DH. -Jack From mrex@sap.com Fri Feb 8 11:23:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748A621F8BFD for ; Fri, 8 Feb 2013 11:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.303 X-Spam-Level: X-Spam-Status: No, score=-10.303 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U97lZnSyMcCC for ; Fri, 8 Feb 2013 11:23:57 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8621F8BF8 for ; Fri, 8 Feb 2013 11:23:56 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r18JNt7H026768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2013 20:23:55 +0100 (MET) In-Reply-To: <51154DCF.4090407@brainhub.org> To: Andrey Jivsov Date: Fri, 8 Feb 2013 20:23:55 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130208192355.359111A52E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:23:57 -0000 It appears to have been retroactively clarified as being (2) from your choices: TLSv1.1 http://tools.ietf.org/html/rfc4346#section-8.1.2 TLSv1.2 http://tools.ietf.org/html/rfc5246#section-8.1.2 Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret. -Martin Andrey Jivsov wrote: > I ran into an interoperability problem between our TLS implementation > and another very popular one. > > The question is what exactly is the formatting for the RFC2246 sec. > 8.1.2 "Diffie-Hellman" shared secret 'Z' ? > > The problem arises when the most significant byte of the Z is zero. > Let's say that the field prime's size is 256. There are two possibilities: > > 1. export the Z in the big endian format, padding it to 256 (first byte > in the buffer is zero) > 2. export the Z in the big endian format, placing the result in a 255 > byte buffer. > > I would say that this should be #1, because it is the natural > representation of the Z. If there is a language specifying the canonical > encoding for the Z, I would appreciate the reference. > > ( Apparently, this problem doesn't clearly manifest itself in real > deployments because ~ the 1/256 failure rate is masked by > re-negotiations at the higher protocol level. ) > > Thank you. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From Andrei.Popov@microsoft.com Fri Feb 8 11:37:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DCC21F8A67 for ; Fri, 8 Feb 2013 11:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6X+lkNrsE8P for ; Fri, 8 Feb 2013 11:37:57 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id C9D0221F8640 for ; Fri, 8 Feb 2013 11:37:57 -0800 (PST) Received: from BY2FFO11HUB037.protection.gbl (10.1.14.120) by BY2FFO11HUB001.protection.gbl (10.1.14.143) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Feb 2013 19:37:56 +0000 Received: from BY2FFO11FD007.protection.gbl (10.1.15.200) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.609.9; Fri, 8 Feb 2013 19:37:13 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 8 Feb 2013 19:37:13 +0000 Received: from CO9EHSOBE013.bigfish.com (157.54.51.80) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 8 Feb 2013 19:36:27 +0000 Received: from mail107-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE013.bigfish.com (10.236.130.76) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Feb 2013 19:33:45 +0000 Received: from mail107-co9 (localhost [127.0.0.1]) by mail107-co9-R.bigfish.com (Postfix) with ESMTP id 2E8A12C0389 for ; Fri, 8 Feb 2013 19:33:45 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zz9371I542I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h9a9j1155h) Received-SPF: softfail (mail107-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Andrei.Popov@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BN1PR03MB069; H:BN1PR03MB072.namprd03.prod.outlook.com; LANG:en; Received: from mail107-co9 (localhost.localdomain [127.0.0.1]) by mail107-co9 (MessageSwitch) id 1360352018192758_2721; Fri, 8 Feb 2013 19:33:38 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.251]) by mail107-co9.bigfish.com (Postfix) with ESMTP id 0A9E2C005A; Fri, 8 Feb 2013 19:33:38 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Feb 2013 19:33:37 +0000 Received: from BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.263.1; Fri, 8 Feb 2013 19:33:36 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) with Microsoft SMTP Server (TLS) id 15.0.620.10; Fri, 8 Feb 2013 19:33:35 +0000 Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.10.107]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.10.107]) with mapi id 15.00.0620.005; Fri, 8 Feb 2013 19:33:35 +0000 From: Andrei Popov To: Peter Gutmann , "tls@ietf.org" Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: Ac4F6jk6vZcw997fQUyk2Kk+6rQABQASGu0g Date: Fri, 8 Feb 2013 19:33:34 +0000 Message-ID: <2a0dba490ca94ad69a386d1d695256fc@BN1PR03MB072.namprd03.prod.outlook.com> References: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BN1PR03MB069.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CS.AUCKLAND.AC.NZ$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(164054002)(13464002)(47736001)(74502001)(23726001)(5343635001)(50986001)(59766001)(77982001)(44976002)(20776003)(31966008)(63696002)(49866001)(74662001)(54316002)(56816002)(16676001)(47776003)(51856001)(46102001)(65816001)(33646001)(53806001)(5343655001)(76482001)(47976001)(80022001)(79102001)(50466001)(4396001)(46406002)(6806001)(56776001)(54356001)(47446002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Forefront-PRVS: 0751474A44 X-OriginatorOrg: microsoft.onmicrosoft.com Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 19:37:58 -0000 I agree that the current language is unclear; Peter's suggestion looks good= to me. Thanks, Andrei -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter= Gutmann Sent: Friday, February 8, 2013 2:51 AM To: tls@ietf.org Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols Eric Rescorla writes: >WG members, please provide any comments on whether we should take this=20 >work on by February 21. Additionally, if you wish to propose an=20 >alternative, it would be nice if you could do so soon or at least=20 >provide an indication of interest. A comment on both of these proposals, to encode their protocols they use an= ad-hoc, non-TLS-style encoding whose form is rather unclear: Protocols are named by IANA registered, opaque, non-empty byte strings an= d the list of protocols is serialized as a concatenation of 8-bit, length prefixed byte strings. Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or= neither? What's wrong with: opaque ProtocolName<1..2^16-1>; struct { ProtocolName protocol_name_list<1..2^16-1> } ProtocolNameList; which fits the way everything else is done in TLS? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From sfriedl@cisco.com Fri Feb 8 13:19:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B9921F8B07 for ; Fri, 8 Feb 2013 13:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzjRrws++HXS for ; Fri, 8 Feb 2013 13:19:35 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8342421F8B02 for ; Fri, 8 Feb 2013 13:19:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1878; q=dns/txt; s=iport; t=1360358375; x=1361567975; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QAGXiSJZv6IweKuCG4+LV7wvQOT/vrATzRmDPDFpI38=; b=F5HBSgkx6VLOBU/vEixD95FNV7nCrTiLvFEZgxlas43qG0YAWDiBh7/s +G5JAezOkjIGI+/LK/Ao1gmLUhq8XBI66O2UPJcxX8RVh8NplmCc0vnh+ TDQxnDKWFKzAlqr81Uhxy0xYDxV6+5K755beAN4ilxxQMONsoFeP2LHBU s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAE5rFVGtJXG9/2dsb2JhbABFDsB+FnOCHwEBAQQBAQE3NBcEAgEIDgMEAQELFAkHJwsUCQgBAQQBEgiICQy/OQSQe2EDpneCQj6CJA X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; d="scan'208";a="175073354" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 08 Feb 2013 21:19:32 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r18LJW2r004037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Feb 2013 21:19:32 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.197]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 15:19:31 -0600 From: "Stephan Friedl (sfriedl)" To: Peter Gutmann , "tls@ietf.org" Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: Ac4F6jk6vZcw997fQUyk2Kk+6rQABQASGu0gAAOUwoA= Date: Fri, 8 Feb 2013 21:18:23 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B66280@xmb-aln-x02.cisco.com> References: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> <2a0dba490ca94ad69a386d1d695256fc@BN1PR03MB072.namprd03.prod.outlook.com> In-Reply-To: <2a0dba490ca94ad69a386d1d695256fc@BN1PR03MB072.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.37.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 21:19:36 -0000 Though I wasn't in Atlanta, taking on this work seems to make plenty of sen= se. Also, agreed on using a more standard TLS encoding - that also makes plenty= of sense. Thanks! Stephan -----Original Message----- From: Andrei Popov [mailto:Andrei.Popov@microsoft.com]=20 Sent: Friday, February 08, 2013 12:34 PM To: Peter Gutmann; tls@ietf.org Cc: Stephan Friedl (sfriedl) Subject: RE: [TLS] Confirming Consensus: Negotiating upper layer protocols I agree that the current language is unclear; Peter's suggestion looks good= to me. Thanks, Andrei -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter= Gutmann Sent: Friday, February 8, 2013 2:51 AM To: tls@ietf.org Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols Eric Rescorla writes: >WG members, please provide any comments on whether we should take this=20 >work on by February 21. Additionally, if you wish to propose an=20 >alternative, it would be nice if you could do so soon or at least=20 >provide an indication of interest. A comment on both of these proposals, to encode their protocols they use an= ad-hoc, non-TLS-style encoding whose form is rather unclear: Protocols are named by IANA registered, opaque, non-empty byte strings an= d the list of protocols is serialized as a concatenation of 8-bit, length prefixed byte strings. Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or= neither? What's wrong with: opaque ProtocolName<1..2^16-1>; struct { ProtocolName protocol_name_list<1..2^16-1> } ProtocolNameList; which fits the way everything else is done in TLS? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Feb 8 14:33:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39BB21F8AB6 for ; Fri, 8 Feb 2013 14:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyGIRQYhp8Wl for ; Fri, 8 Feb 2013 14:33:17 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1694A21F8AB4 for ; Fri, 8 Feb 2013 14:33:16 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r18MXAIc028346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Feb 2013 23:33:10 +0100 (MET) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73333FEB17@uxcn10-2.UoA.auckland.ac.nz> To: Peter Gutmann Date: Fri, 8 Feb 2013 23:33:10 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130208223310.2F3611A533@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 22:33:17 -0000 Peter Gutmann wrote: > Eric Rescorla writes: > > >WG members, please provide any comments on whether we should take this work > >on by February 21. Additionally, if you wish to propose an alternative, it > >would be nice if you could do so soon or at least provide an indication of > >interest. > > A comment on both of these proposals, to encode their protocols they use an > ad-hoc, non-TLS-style encoding whose form is rather unclear: > > Protocols are named by IANA registered, opaque, non-empty byte strings and > the list of protocols is serialized as a concatenation of 8-bit, length > prefixed byte strings. > > Does this mean the strings use 8-bit chars, the lengths are 8 bit, both, or > neither? What's wrong with: > > opaque ProtocolName<1..2^16-1>; > > struct { > ProtocolName protocol_name_list<1..2^16-1> > } ProtocolNameList; > > which fits the way everything else is done in TLS? Do we really need ProtocolNames > 255 chars? Btw. the lower bounds of container elements are usually set to the minimum possible length. In your example, the lower bounds of protocol_name_list would be 3, I believe. How about opaque ProtocolName<1..2^8-1>; struct { ProtocolName protocol_name_list<2..2^16-1> } ProtocolNameList; -Martin From n.mavrogiannopoulos@gmail.com Fri Feb 8 14:51:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA95021F8814 for ; Fri, 8 Feb 2013 14:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzQYjUvsKKMC for ; Fri, 8 Feb 2013 14:51:14 -0800 (PST) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6121F87B6 for ; Fri, 8 Feb 2013 14:51:14 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id dq12so3443874wgb.24 for ; Fri, 08 Feb 2013 14:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=aQEgJYwmDUO5bOcyH+0S5g4URi/Yy7woZ+cFdEm4B5w=; b=HAGh5H8ltUER57CLTokvdhB+Kwuj4O4ij+Q8rFhaMVC67zGhxeZfEv9+0lV9YYNZCO SfWUQDFmXED+57zxk2TZ/Fz7VBa/kWXanoBXejkfipFvA2W+/dIcrzLsLMPM454uDQ9J cQ+KEyP1I1z9CNxDaS7WJohVTHd7mkKGJVroflogqyHGFkZuUZkVtibYYnOAKkBUF0jf 9o5HuGszftk+tB9QFUmPNF1t9YA3a5P0kEXA08V+kGar8ZWLD+dlAkKLVk3PiA8J9deI AfeljKKkREQq8cDg4j+mDUH3c5KrxeR+ns4Yt+O0mr/wHrOn9d3K3O8/v0ELMTOJ9dH1 jaRA== X-Received: by 10.180.104.10 with SMTP id ga10mr5212458wib.23.1360363873314; Fri, 08 Feb 2013 14:51:13 -0800 (PST) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id s8sm16861209wif.9.2013.02.08.14.51.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 14:51:12 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <5115815B.5000909@gnutls.org> Date: Fri, 08 Feb 2013 23:51:07 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: "Paterson, Kenny" References: <9A043F3CF02CD34C8E74AC1594475C73333FEAF0@uxcn10-2.UoA.auckland.ac.nz> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 22:51:15 -0000 On 02/08/2013 02:03 PM, Paterson, Kenny wrote: >> There is nothing wrong with MAC-then-encrypt, > > I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000 > and Hugo Krawczyk's paper from Crypto 2001 both demonstrate good > reasons to be suspicious of MAC-then-encrypt from a theoretical > perspective. It could be, and I cannot offer any insight on whether these theoretical weaknesses, have any practical effect. However, the switch from MAC-then-Encrypt to Encrypt-then-MAC mode of operation is a radical move that does not affect only the CBC ciphers (e.g. RC4-SHA1 is also MAC-then-Encrypt). > And in practice, time and again it's proven to be problematic. And > not just in TLS (see for example my paper with Jean Paul Degabriele > at ACM-CCS 2010 about MAC-then-encrypt configurations of IPsec. > TL;DR: we broke them all). I understand, and such attacks can indeed occur if there are encrypted data that are left unauthenticated by the MAC (e.g., as the pad is in TLS now). My sentence referred to a MAC-then-encrypt operation that encrypts and authenticates all data (including any pads). regards, Nikos From pgut001@cs.auckland.ac.nz Fri Feb 8 16:12:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF9B21F87A4 for ; Fri, 8 Feb 2013 16:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDTcgHTzSPt6 for ; Fri, 8 Feb 2013 16:12:55 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 40D9121F853E for ; Fri, 8 Feb 2013 16:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360368775; x=1391904775; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=oERNiHQrIJQd8OYy/udLlHY/synFwMj5lJadGKI3WZk=; b=rPMWwIINGVVwwWB5SDOTJ82dCLR24xTe9KA5yzPpDDskwbNNZK9+KYls 2SsjGd8LF2Upomteg692XxfUnEuZDSf9OxOtt8kL+IEH6YfNX37P9FUj9 IFc56JwVyYe7Ny66NAIySUEcv2oWHeC/b9+BxJ/GgTMzYAgXJw0eLULtp k=; X-IronPort-AV: E=Sophos;i="4.84,633,1355050800"; d="scan'208";a="169634809" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Feb 2013 13:12:53 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 9 Feb 2013 13:12:53 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4GWjPkE3BF8LyaSYCDpZZUaIXB7w== Date: Sat, 9 Feb 2013 00:12:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FFF9A@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 00:12:57 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >However, the switch from MAC-then-Encrypt to Encrypt-then-MAC mode of=0A= >operation is a radical move that does not affect only the CBC ciphers (e.g= .=0A= >RC4-SHA1 is also MAC-then-Encrypt).=0A= =0A= It's actually pretty trivial. Just to provide a data point on the effects = of=0A= this change, I've done a preliminary implementation and found that it's abo= ut=0A= 30 minutes work to add support for the MAC outside the encryption (I just= =0A= change the position of one function call and tweak a few things here and=0A= there). In addition the net change in code is so significant (due to remov= ing=0A= the masses of gunk I have in there to deal with side-channel attacks) that= =0A= I've created a separate function unwrapPacketTLSMAC() that's a tiny fractio= n=0A= of the size and complexity of the original unwrapPacketSSL() and its=0A= associated side-channel functions. I estimate that, if I were to remove al= l=0A= the legacy code, there'd be a net increase of -500 to -1000 lines of code f= rom=0A= adding encrypt-then-MAC, as well as taking a whole pile of potentially erro= r-=0A= prone cruft out of the code path. As Martin has pointed out, this is such = a=0A= no-brainer it could have been made years ago with TLS 1.1's explicit IV.=0A= =0A= If anyone wants to do some interop testing, let me know. Currently I just= =0A= hardcode in e-then-M via a compile option for testing purposes, I haven't d= one=0A= the extension-negotiation bit yet, although that should be pretty trivial i= n=0A= any case.=0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Fri Feb 8 16:16:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0874221F8C49 for ; Fri, 8 Feb 2013 16:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tsp69tdIfToQ for ; Fri, 8 Feb 2013 16:16:52 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 36ED021F8C46 for ; Fri, 8 Feb 2013 16:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360369012; x=1391905012; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=3s3OCOmSuZE2VV+TFceJeVU2AQpbHaGHyV+IXN9oPyg=; b=F87awDeNsKpP40TVmPz2aJln48QHppBzMhnnYrUVDybFxoDni+KB5JXl EsAANm5HeRvN8H+6c8Lr3dIVpbc+84/fnsmRBiqAvw5pq9UdCAUqYIwKC K1Vy7QeL/z6fD+ZmHewDZzB3RvcMqfx9dgLoAizs1olX1JYChtLZKgNRS Q=; X-IronPort-AV: E=Sophos;i="4.84,633,1355050800"; d="scan'208";a="169635030" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Feb 2013 13:16:51 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 9 Feb 2013 13:16:50 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Sat, 9 Feb 2013 13:16:50 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Confirming Consensus: Negotiating upper layer protocols Thread-Index: Ac4GWsGhpsaQqPW9SVqEFxhW42EWfg== Date: Sat, 9 Feb 2013 00:16:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73333FFFA7@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Confirming Consensus: Negotiating upper layer protocols X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 00:16:53 -0000 Martin Rex writes:=0A= =0A= >Do we really need ProtocolNames > 255 chars?=0A= =0A= No, not really, it was a cut-and-paste-and-edit from elsewhere :-).=0A= =0A= >Btw. the lower bounds of container elements are usually set to the minimum= =0A= >possible length. In your example, the lower bounds of protocol_name_list= =0A= >would be 3, I believe.=0A= =0A= Sure.=0A= =0A= >How about=0A= >=0A= > opaque ProtocolName<1..2^8-1>;=0A= >=0A= > struct {=0A= > ProtocolName protocol_name_list<2..2^16-1>=0A= > } ProtocolNameList;=0A= =0A= Looks good.=0A= =0A= Peter.= From mrex@sap.com Fri Feb 8 17:29:13 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E80921F89FC for ; Fri, 8 Feb 2013 17:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.296 X-Spam-Level: X-Spam-Status: No, score=-10.296 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4df26In0o5k for ; Fri, 8 Feb 2013 17:29:12 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id E07E121F8867 for ; Fri, 8 Feb 2013 17:29:11 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r191T7Xk025946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Feb 2013 02:29:08 +0100 (MET) In-Reply-To: To: Nikos Mavrogiannopoulos Date: Sat, 9 Feb 2013 02:29:07 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130209012907.D1C891A533@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 01:29:13 -0000 Nikos Mavrogiannopoulos wrote: > > Peter Gutmann wrote: > > > >>Padding the plain text up to a multiple of the cipher block size (minus the > >>hash size) ahead of doing the MAC is a more modest change that may be more > >>widely applicable to existing cipher suites - with a "pad-then MAC" client > >>hello > > > > That won't help against the current attack. > > This family of attacks relies on the fact that padding isn't > authenticated, i.e, you can play with it without being detected. If > pad is part of the MAC there is no issue. I agree with Nikos. The problem of TLS is that it does not authenticate the entire decryption output (i.e. uses MAC-pad-encrypt rather than pad-MAC-encrypt). > > > The only proper fix for the > > various attacks that target the encryption is to protect everything with the > > MAC, i.e. switch to encrypt-then-MAC. The definitive reference for this is > > Hugo Krawczyk's "The Order of Encryption and Authentication for Protecting > > Communications (Or: How Secure is SSL?)". To me, Hugo's "proof" that AtE would have a "general weakness" is misleading (and slightly bordering on lame). He proofs a security problem *ONLY* for a MAC-extend-encrypt scheme, and only under the condition of the availablility of a decryption oracle that will blissfully answer a huge amount of chosen ciphertext attacks. Potentially not realizing that the existing MAC-pad-encrypt approach in SSL/TLS is one incarnation of the dangerous MAC-extend-encrypt schemes, Hugo's paper incorrectly asserts this (last paragraph on page 3): The security of AtE with specific encryption modes. This paper does not bring just bad news. We also show that the authenticate-then-encrypt method is secure under two very common forms of encryption: CBC mode (with an underlying secure block cipher) and stream ciphers (that xor the data with a random or pseudorandom pad). We provide a (near optimal) quantified security analysis of these methods. While these positive results do not resolve the "generic weakness" of the authenticate-then-encrypt method (and of SSL), they do show that the common implementations currently in use do result in a secure channels protocol. CBC-padding is simply an incarnation of "extend" in MAC-extend-encrypt. And the addition of unauthenticated-but-encrypted information may allow breaking the confidentiality of the cipher, given sufficient responses from the decryption oracle, frobbing the ciphertext block covering the unauthenticated part and getting the de-padding function to oracle about characteristics of the resulting plaintext block. > > Using encrypt-then-MAC to counter the attack is as radical change as > using the GCM or CCM modes. This isn't a small fix, it is an upgrade > which changes the protocol semantics (e.g. MAC is no longer encrypted > - whatever that may mean). Moreover, encrypt-then-MAC isn't a panacea. > There is nothing wrong with MAC-then-encrypt, it is TLS that applied > it incorrectly by keeping the pad unauthenticated. I'd prefer a fix > that keeps the current protocol semantics. Personally, I also feel somewhat uncomfortable with a "radical" change to encrypt-then-MAC rather than the simply using the obvious pad-MAC-encrypt, as originally suggested by Serge Vaudenay. When the encryption scheme that is used is bijective, then it will not matter (to the confidentiality of the encryption) whether AtE or EtA is used, as long as authentication covers the exact same information in both cases, i.e. *ALL* of it, padding included. However, in the EtA scheme, we would have a naked keyed hash. And would an attack on the keyed hash become somehow feasible, that attack might be easier on a naked keyed hash than on an encrypted keyed hash. -Martin From pgut001@cs.auckland.ac.nz Sat Feb 9 18:52:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BA521F8581 for ; Sat, 9 Feb 2013 18:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.053 X-Spam-Level: X-Spam-Status: No, score=-2.053 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4ogGYdfTE2d for ; Sat, 9 Feb 2013 18:52:02 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBAE21F8574 for ; Sat, 9 Feb 2013 18:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360464722; x=1392000722; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sBNApKAnb/qXBpQd+XsGAWnInNfjUojUab4ABf8SOuM=; b=BtULKedNqEhFiUVER05L2N6faOubTqZh0kJsSHj5SyjjrTYW5dnua0ii 8T3pG9UTcWlaThvg5BQwt/H6v9Ofm+vZV2jkCRoQhBNdw8qpidjS2Scrs nZkv8JV8a25wSqoeICjlCgjU/7cmuedL2ez2l2LVTmgxJhG4dBCTi4z6+ s=; X-IronPort-AV: E=Sophos;i="4.84,636,1355050800"; d="scan'208";a="169706841" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Feb 2013 15:51:32 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sun, 10 Feb 2013 15:51:32 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4HOYfom6WOGAD6TVephREdBcO15A== Date: Sun, 10 Feb 2013 02:51:31 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7333400716@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 02:52:04 -0000 Martin Rex writes:=0A= =0A= >Personally, I also feel somewhat uncomfortable with a "radical" change to= =0A= >encrypt-then-MAC rather than the simply using the obvious pad-MAC-encrypt,= as=0A= >originally suggested by Serge Vaudenay.=0A= =0A= It's hardly a radical change, in terms of code complexity (at least in my= =0A= code) it came down to (comments and error checking removed) this:=0A= =0A= checkMacTLS( sessionInfoPtr, data, length, length - sessionInfoPtr->authB= locksize, packetType );=0A= decryptData( sessionInfoPtr, data, length - sessionInfoPtr->authBlocksize= , &length );=0A= =0A= In other words I swapped two lines of code.=0A= =0A= (See my earlier note about what it really entailed, which was creating a=0A= separate code path that removed several hundred lines of kludging to try an= d=0A= defend against side-channel attacks. So really it's a two-line swap and=0A= hundreds of lines removed, at least for the encrypt-then-MAC option).=0A= =0A= >When the encryption scheme that is used is bijective, then it will not mat= ter=0A= >(to the confidentiality of the encryption) whether AtE or EtA is used, as= =0A= >long as authentication covers the exact same information in both cases, i.= e.=0A= >*ALL* of it, padding included.=0A= =0A= However you do need to to MAC the IV. If you treat it as part of the=0A= ciphertext then it's trivial, MAC the entire packet in its bits-on-the-wire= =0A= form. If you're MAC'ing the plaintext then you need to special-case the IV= =0A= vs. the plaintext and suddenly you're adding all sorts of kludgery to handl= e=0A= that. Authenticating the exact bits on the wire is both cleaner conceptual= ly/=0A= security-wise (you're authenticating the exact data that the attacker has= =0A= access to, not some bits as seen by the attacker and some bits as seen by y= ou=0A= after further processing), and implementation-wise (you just swap the bits = of=0A= code that do auth. vs. encrypt). To quote Kenny Paterson's recent message:= =0A= =0A= It fixes every problem I can conceive of. And I've thought about the=0A= analysis of TLS's current MAC-pad-encrypt construction long and hard,=0A= believe me.=0A= =0A= That's pretty unambiguous.=0A= =0A= >However, in the EtA scheme, we would have a naked keyed hash. And would a= n=0A= >attack on the keyed hash become somehow feasible, that attack might be eas= ier=0A= >on a naked keyed hash than on an encrypted keyed hash.=0A= =0A= That's going to be pretty unlikely, if someone can break HMAC then we've go= t=0A= more serious things to worry about than forging of TLS packets.=0A= =0A= Peter.=0A= =0A= PS: Still keen to interop-test with anyone else who's made this change :-).= From prvs=575395df64=uri@ll.mit.edu Sat Feb 9 19:13:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F39521F84B9 for ; Sat, 9 Feb 2013 19:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4h7a18OUBLx for ; Sat, 9 Feb 2013 19:13:05 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id B1C7021F8425 for ; Sat, 9 Feb 2013 19:13:05 -0800 (PST) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r1A3CxYZ026589; Sat, 9 Feb 2013 22:12:59 -0500 From: "Blumenthal, Uri - 0558 - MITLL" To: "'pgut001@cs.auckland.ac.nz'" , "'tls@ietf.org'" Date: Sat, 9 Feb 2013 22:12:58 -0500 Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4HOYfom6WOGAD6TVephREdBcO15AAAvusn In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7333400716@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327, 1.0.431, 0.0.0000 definitions=2013-02-10_01:2013-02-08, 2013-02-10, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=7 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1211240000 definitions=main-1302090366 Message-Id: <20130210031305.B1C7021F8425@ietfa.amsl.com> Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 03:13:06 -0000 I worry much less about attacks against "naked" keyed hash (such as HMAC, o= r in fact any other cryptographic MAC) than against attacks against encrypt= ed padding, etc. Pad->Encrypt->MAC is the most straightforward solution, IMHO, and I see no = reason doing something else. -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz] Sent: Saturday, February 09, 2013 09:51 PM=0A= To: tls@ietf.org Subject: Re: [TLS] TLS1.3 Martin Rex writes: >Personally, I also feel somewhat uncomfortable with a "radical" change to >encrypt-then-MAC rather than the simply using the obvious pad-MAC-encrypt,= as >originally suggested by Serge Vaudenay. It's hardly a radical change, in terms of code complexity (at least in my code) it came down to (comments and error checking removed) this: checkMacTLS( sessionInfoPtr, data, length, length - sessionInfoPtr->authB= locksize, packetType ); decryptData( sessionInfoPtr, data, length - sessionInfoPtr->authBlocksize= , &length ); In other words I swapped two lines of code. (See my earlier note about what it really entailed, which was creating a separate code path that removed several hundred lines of kludging to try an= d defend against side-channel attacks. So really it's a two-line swap and hundreds of lines removed, at least for the encrypt-then-MAC option). >When the encryption scheme that is used is bijective, then it will not mat= ter >(to the confidentiality of the encryption) whether AtE or EtA is used, as >long as authentication covers the exact same information in both cases, i.= e. >*ALL* of it, padding included. However you do need to to MAC the IV. If you treat it as part of the ciphertext then it's trivial, MAC the entire packet in its bits-on-the-wire form. If you're MAC'ing the plaintext then you need to special-case the IV vs. the plaintext and suddenly you're adding all sorts of kludgery to handl= e that. Authenticating the exact bits on the wire is both cleaner conceptual= ly/ security-wise (you're authenticating the exact data that the attacker has access to, not some bits as seen by the attacker and some bits as seen by y= ou after further processing), and implementation-wise (you just swap the bits = of code that do auth. vs. encrypt). To quote Kenny Paterson's recent message: It fixes every problem I can conceive of. And I've thought about the analysis of TLS's current MAC-pad-encrypt construction long and hard, believe me. That's pretty unambiguous. >However, in the EtA scheme, we would have a naked keyed hash. And would a= n >attack on the keyed hash become somehow feasible, that attack might be eas= ier >on a naked keyed hash than on an encrypted keyed hash. That's going to be pretty unlikely, if someone can break HMAC then we've go= t more serious things to worry about than forging of TLS packets. Peter. PS: Still keen to interop-test with anyone else who's made this change :-). _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nick.lewis@usa.g4s.com Mon Feb 11 00:45:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B73721F8611 for ; Mon, 11 Feb 2013 00:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2ZP8l8rkOao for ; Mon, 11 Feb 2013 00:45:10 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 2522921F860A for ; Mon, 11 Feb 2013 00:45:08 -0800 (PST) Received: from [85.158.139.19:21056] by server-4.bemta-5.messagelabs.com id 62/BF-29496-49FA8115; Mon, 11 Feb 2013 08:45:08 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-12.tower-178.messagelabs.com!1360572307!27965092!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13558 invoked from network); 11 Feb 2013 08:45:08 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-12.tower-178.messagelabs.com with RC4-SHA encrypted SMTP; 11 Feb 2013 08:45:08 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Mon, 11 Feb 2013 08:45:07 +0000 From: "Lewis, Nick" To: "tls@ietf.org" Date: Mon, 11 Feb 2013 08:45:05 +0000 Thread-Topic: Re: [TLS] TLS1.3 Thread-Index: Ac4INB+Y6uTk/rHmRy+FKd4Cb7zB7A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 08:45:11 -0000 >> There is nothing wrong with MAC-then-encrypt, > > I disagree. The paper by Bellare and Namprempre from Asiacrypt 2000 > and Hugo Krawczyk's paper from Crypto 2001 both demonstrate good > reasons to be suspicious of MAC-then-encrypt from a theoretical > perspective. The focus of this work was showing that a secure crypt and secure mac could= be combined in such a way that the combination was insecure unless Encrypt= -then-Mac were used. The reality of TLS though is that there are many MACs = in everyday use that are not secure (based on hashes of 80bits or even 64 b= its). These are currently protected from attack by being behind strong (112= bit or 128 bit) crypt. Flipping round crypt and mac for all of TLS would ex= pose these currently "good enough" cipher suites and result in further bad = press from collision attacks. I would be more comfortable with a pre-padding fix for the side-channel att= acks (via a TLS extension) and then leave any decisions on flipping of the = crypt and mac to a cipher suite by cipher suite basis when porting each to = the aead api -- Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From Kenny.Paterson@rhul.ac.uk Mon Feb 11 01:26:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC2921F869B for ; Mon, 11 Feb 2013 01:26:44 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2t+S1DfyF9H for ; Mon, 11 Feb 2013 01:26:43 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id BE85221F8659 for ; Mon, 11 Feb 2013 01:26:43 -0800 (PST) Received: from mail195-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 09:26:43 +0000 Received: from mail195-tx2 (localhost [127.0.0.1]) by mail195-tx2-R.bigfish.com (Postfix) with ESMTP id EC5832601EA for ; Mon, 11 Feb 2013 09:26:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.108; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB02.cc.rhul.local; RD:exch-hub02.rhul.ac.uk; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail195-tx2 (localhost.localdomain [127.0.0.1]) by mail195-tx2 (MessageSwitch) id 1360574800556163_32161; Mon, 11 Feb 2013 09:26:40 +0000 (UTC) Received: from TX2EHSMHS033.bigfish.com (unknown [10.9.14.251]) by mail195-tx2.bigfish.com (Postfix) with ESMTP id 8253FC004A; Mon, 11 Feb 2013 09:26:40 +0000 (UTC) Received: from EXCH-HUB02.cc.rhul.local (134.219.208.108) by TX2EHSMHS033.bigfish.com (10.9.99.133) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Feb 2013 09:26:40 +0000 Received: from EXCH-CAS04.cc.rhul.local (134.219.208.162) by EXCH-HUB02.cc.rhul.local (134.219.208.108) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 11 Feb 2013 09:26:39 +0000 Received: from EXCH-MB01.cc.rhul.local ([169.254.3.31]) by EXCH-CAS04.cc.rhul.local ([2002:86db:d0a2::86db:d0a2]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 09:26:39 +0000 From: "Paterson, Kenny" To: "Lewis, Nick" Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnkM5Cm91Ib2Ua7186ZEOcKag== Date: Mon, 11 Feb 2013 09:26:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.147.250.120] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 09:26:44 -0000 Nick, > The reality of TLS though is that there are many MACs in everyday use th= at are not secure (based on hashes of 80bits or even 64 bits). These are cu= rrently protected from attack by being behind strong (112bit or 128 bit) cr= ypt.=20 The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA-25= 6 (HMAC-SHA-384 is also a possibility). These all have MAC tags of at least= 128 bits. RFC 6066 standardises "truncated" MAC tags for TLS, but these are known to = be dangerous when used in combination with TLS's variable length padding (s= ee the distinguishing attack in my Asiacrypt 2011 paper with Ristenpart and= Shrimpton). However, I was not aware of anyone actually using these truncated MAC tags,= or any other short-output MAC algorithms in TLS.=20 Can you provide specific examples in support of your argument? Thanks, Kenny From nick.lewis@usa.g4s.com Mon Feb 11 02:03:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75F21F86D9 for ; Mon, 11 Feb 2013 02:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-1.702, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dfc0JuaMsG0F for ; Mon, 11 Feb 2013 02:03:16 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2C79121F86AF for ; Mon, 11 Feb 2013 02:03:15 -0800 (PST) Received: from [85.158.140.211:26381] by server-9.bemta-14.messagelabs.com id C6/5D-30867-3E1C8115; Mon, 11 Feb 2013 10:03:15 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-8.tower-194.messagelabs.com!1360576994!11029735!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20650 invoked from network); 11 Feb 2013 10:03:14 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-8.tower-194.messagelabs.com with RC4-SHA encrypted SMTP; 11 Feb 2013 10:03:14 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Mon, 11 Feb 2013 10:03:14 +0000 From: "Lewis, Nick" To: "'Paterson, Kenny'" Date: Mon, 11 Feb 2013 10:03:14 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnkM5Cm91Ib2Ua7186ZEOcKaph0ZRRQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:03:17 -0000 >> The reality of TLS though is that there are many MACs in everyday use th= at are not secure (based on hashes of 80bits or even 64 bits). >> These are currently protected from attack by being behind strong (112bit= or 128 bit) crypt. >> The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA= -256 (HMAC-SHA-384 is also a possibility). >> These all have MAC tags of at least 128 bits. >RFC 6066 standardises "truncated" MAC tags for TLS, but these are known to= be dangerous when used in combination with TLS's variable length padding >(see the distinguishing attack in my Asiacrypt 2011 paper with Ristenpart = and Shrimpton). >However, I was not aware of anyone actually using these truncated MAC tags= , or any other short-output MAC algorithms in TLS. >Can you provide specific examples in support of your argument? Sorry I meant to say "bits of security" (as in a birthday attack) rather th= an leave an impression of bit length According to NIST HMAC-MD5 and HMAC-SHA-1 are vulnerable and should not be = used hence forth http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf -- Nick The details of this company are as follows: G4S Technology Limited, Registered Office: Challenge House, International D= rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823= 38. This communication may contain information which is confidential, personal = and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution= , forwarding, copying or use of this communication or the information in it= is strictly prohibited. Any personal views expressed in this e-mail are those of the individual sen= der and the company does not endorse or accept responsibility for them. Prior to taking any action based upon this e-mail message, you should seek = appropriate confirmation of its authenticity. This e-mail has been scanned for all viruses by MessageLabs. From Kenny.Paterson@rhul.ac.uk Mon Feb 11 02:15:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6121221F875C for ; Mon, 11 Feb 2013 02:15:10 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLg73NTqNM0K for ; Mon, 11 Feb 2013 02:15:09 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3E14A21F8751 for ; Mon, 11 Feb 2013 02:15:09 -0800 (PST) Received: from mail224-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 10:15:08 +0000 Received: from mail224-tx2 (localhost [127.0.0.1]) by mail224-tx2-R.bigfish.com (Postfix) with ESMTP id B6367940177 for ; Mon, 11 Feb 2013 10:15:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.107; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB01.cc.rhul.local; RD:exch-hub01.rhul.ac.uk; EFVD:NLI X-SpamScore: -7 X-BigFish: VPS-7(zz98dIc89bhc857hzz1f42h1ee6h1de0h1d18h1202h1e76h1d1ah1d2ahzz17326ah30d1K18c673h5eeeKz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail224-tx2 (localhost.localdomain [127.0.0.1]) by mail224-tx2 (MessageSwitch) id 1360577706369902_24065; Mon, 11 Feb 2013 10:15:06 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.249]) by mail224-tx2.bigfish.com (Postfix) with ESMTP id 5814ECC007D; Mon, 11 Feb 2013 10:15:06 +0000 (UTC) Received: from EXCH-HUB01.cc.rhul.local (134.219.208.107) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 11 Feb 2013 10:15:05 +0000 Received: from exch-cas01.cc.rhul.local (134.219.208.109) by EXCH-HUB01.cc.rhul.local (134.219.208.107) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 11 Feb 2013 10:15:03 +0000 Received: from EXCH-MB01.cc.rhul.local ([169.254.3.31]) by exch-cas01.cc.rhul.local ([2002:86db:d06d::86db:d06d]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 10:15:03 +0000 From: "Paterson, Kenny" To: "Lewis, Nick" Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnkM5Cm91Ib2Ua7186ZEOcKaph0ZRRQgAALxYA= Date: Mon, 11 Feb 2013 10:15:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.147.250.120] Content-Type: multipart/alternative; boundary="_000_B132B06E59C4A540A03C3393F53BC07C40818C02EXCHMB01ccrhull_" MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:15:10 -0000 --_000_B132B06E59C4A540A03C3393F53BC07C40818C02EXCHMB01ccrhull_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmljaywNCg0KSSB0aGluayB5b3UndmUgbWlzLXJlYWQgdGhlIE5JU1QgZG9jdW1lbnQuDQoNClNI QS0xIGlzIHN0aWxsICJhY2NlcHRhYmxlIiBmb3IgYXBwbGljYXRpb25zIG5vdCByZWxhdGVkIHRv IGRpZ2l0YWwgc2lnbmF0dXJlIGdlbmVyYXRpb24gKHNlZSBUYWJsZSA5KS4gVGhhdCBpbmNsdWRl cyBNQUNpbmcgLSBzZWUgSE1BQyBlbnRyeSwgVGFibGUgMTAsIGFuZCB0aGUgZW5zdWluZyB0ZXh0 Og0KDQoiSE1BQyBHZW5lcmF0aW9uOiBBbnkgYXBwcm92ZWQgaGFzaCBmdW5jdGlvbiBtYXkgYmUg dXNlZC4NClRoZSB1c2Ugb2Yga2V5IGxlbmd0aHMg4omlIDgwIGJpdHMsIGJ1dCA8IDExMiBiaXRz IGlzIGFjY2VwdGFibGUgdGhyb3VnaCBEZWNlbWJlciAzMSwgMjAxMC4NCkZyb20gSmFudWFyeSAx LCAyMDExIHRocm91Z2ggRGVjZW1iZXIgMzEsIDIwMTMsIHRoZSB1c2Ugb2Yga2V5IGxlbmd0aHMg 4omlIDgwIGJpdHMsIGJ1dCA8IDExMiBiaXRzIGlzIGRlcHJlY2F0ZWQuDQpBZnRlciBEZWNlbWJl ciAzMSwgMjAxMywga2V5IGxlbmd0aHMgPCAxMTIgYml0cyBzaGFsbCBub3QgYmUgdXNlZC4NClRo ZSB1c2Ugb2Yga2V5IGxlbmd0aHMg4omlIDExMiBiaXRzIGlzIGFjY2VwdGFibGUuIg0KDQpGb3Ig dGhlIGRlZmluaXRpb24gb2YgYWNjZXB0YWJsZSwgdGhlIGRvY3VtZW50IHNheXM6DQoNCiJBY2Nl cHRhYmxlIGlzIHVzZWQgdG8gbWVhbiB0aGF0IHRoZSBhbGdvcml0aG0gYW5kIGtleSBsZW5ndGgg aXMgc2FmZSB0byB1c2U7IG5vIHNlY3VyaXR5IHJpc2sgaXMgY3VycmVudGx5IGtub3duLiINCg0K UmVnYXJkcywNCg0KS2VubnkNCg0KDQpPbiAxMSBGZWIgMjAxMywgYXQgMTA6MDMsIExld2lzLCBO aWNrIHdyb3RlOg0KDQoNClRoZSByZWFsaXR5IG9mIFRMUyB0aG91Z2ggaXMgdGhhdCB0aGVyZSBh cmUgbWFueSBNQUNzIGluIGV2ZXJ5ZGF5IHVzZSB0aGF0IGFyZSBub3Qgc2VjdXJlIChiYXNlZCBv biBoYXNoZXMgb2YgODBiaXRzIG9yIGV2ZW4gNjQgYml0cykuDQpUaGVzZSBhcmUgY3VycmVudGx5 IHByb3RlY3RlZCBmcm9tIGF0dGFjayBieSBiZWluZyBiZWhpbmQgc3Ryb25nICgxMTJiaXQgb3Ig MTI4IGJpdCkgY3J5cHQuDQpUaGUgInVzdWFsIiBNQUMgYWxnb3JpdGhtcyBmb3IgVExTIGFyZSBI TUFDLU1ENSwgSE1BQy1TSEEtMSBhbmQgSE1BQy1TSEEtMjU2IChITUFDLVNIQS0zODQgaXMgYWxz byBhIHBvc3NpYmlsaXR5KS4NClRoZXNlIGFsbCBoYXZlIE1BQyB0YWdzIG9mIGF0IGxlYXN0IDEy OCBiaXRzLg0KDQpSRkMgNjA2NiBzdGFuZGFyZGlzZXMgInRydW5jYXRlZCIgTUFDIHRhZ3MgZm9y IFRMUywgYnV0IHRoZXNlIGFyZSBrbm93biB0byBiZSBkYW5nZXJvdXMgd2hlbiB1c2VkIGluIGNv bWJpbmF0aW9uIHdpdGggVExTJ3MgdmFyaWFibGUgbGVuZ3RoIHBhZGRpbmcNCihzZWUgdGhlIGRp c3Rpbmd1aXNoaW5nIGF0dGFjayBpbiBteSBBc2lhY3J5cHQgMjAxMSBwYXBlciB3aXRoIFJpc3Rl bnBhcnQgYW5kIFNocmltcHRvbikuDQpIb3dldmVyLCBJIHdhcyBub3QgYXdhcmUgb2YgYW55b25l IGFjdHVhbGx5IHVzaW5nIHRoZXNlIHRydW5jYXRlZCBNQUMgdGFncywgb3IgYW55IG90aGVyIHNo b3J0LW91dHB1dCBNQUMgYWxnb3JpdGhtcyBpbiBUTFMuDQpDYW4geW91IHByb3ZpZGUgc3BlY2lm aWMgZXhhbXBsZXMgaW4gc3VwcG9ydCBvZiB5b3VyIGFyZ3VtZW50Pw0KDQpTb3JyeSBJIG1lYW50 IHRvIHNheSAiYml0cyBvZiBzZWN1cml0eSIgKGFzIGluIGEgYmlydGhkYXkgYXR0YWNrKSByYXRo ZXIgdGhhbiBsZWF2ZSBhbiBpbXByZXNzaW9uIG9mIGJpdCBsZW5ndGgNCkFjY29yZGluZyB0byBO SVNUIEhNQUMtTUQ1IGFuZCBITUFDLVNIQS0xIGFyZSB2dWxuZXJhYmxlIGFuZCBzaG91bGQgbm90 IGJlIHVzZWQgaGVuY2UgZm9ydGgNCmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9u aXN0cHVicy84MDAtMTMxQS9zcDgwMC0xMzFBLnBkZg0KDQotLSBOaWNrDQoNCg0KDQpUaGUgZGV0 YWlscyBvZiB0aGlzIGNvbXBhbnkgYXJlIGFzIGZvbGxvd3M6DQpHNFMgVGVjaG5vbG9neSBMaW1p dGVkLCBSZWdpc3RlcmVkIE9mZmljZTogQ2hhbGxlbmdlIEhvdXNlLCBJbnRlcm5hdGlvbmFsIERy aXZlLCBUZXdrZXNidXJ5LCBHbG91Y2VzdGVyc2hpcmUgR0wyMCA4VVEsIFJlZ2lzdGVyZWQgaW4g RW5nbGFuZCBOby4gMjM4MjMzOC4NCg0KVGhpcyBjb21tdW5pY2F0aW9uIG1heSBjb250YWluIGlu Zm9ybWF0aW9uIHdoaWNoIGlzIGNvbmZpZGVudGlhbCwgcGVyc29uYWwgYW5kL29yIHByaXZpbGVn ZWQuDQoNCkl0IGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpLg0KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwgcGxlYXNl IG5vdGUgdGhhdCBhbnkgZGlzdHJpYnV0aW9uLCBmb3J3YXJkaW5nLCBjb3B5aW5nIG9yIHVzZSBv ZiB0aGlzIGNvbW11bmljYXRpb24gb3IgdGhlIGluZm9ybWF0aW9uIGluIGl0IGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuDQoNCkFueSBwZXJzb25hbCB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBlLW1h aWwgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgdGhlIGNvbXBhbnkgZG9l cyBub3QgZW5kb3JzZSBvciBhY2NlcHQgcmVzcG9uc2liaWxpdHkgZm9yIHRoZW0uDQoNClByaW9y IHRvIHRha2luZyBhbnkgYWN0aW9uIGJhc2VkIHVwb24gdGhpcyBlLW1haWwgbWVzc2FnZSwgeW91 IHNob3VsZCBzZWVrIGFwcHJvcHJpYXRlIGNvbmZpcm1hdGlvbiBvZiBpdHMgYXV0aGVudGljaXR5 Lg0KDQpUaGlzIGUtbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciBhbGwgdmlydXNlcyBieSBNZXNz YWdlTGFicy4NCg0KDQo= --_000_B132B06E59C4A540A03C3393F53BC07C40818C02EXCHMB01ccrhull_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu IiBmYWNlPSJBcmlhbCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250 LXNpemU6IDEycHg7Ij5OaWNrLDwvc3Bhbj48L2ZvbnQ+DQo8ZGl2Pjxmb250IGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4i IHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxzcGFuIGNsYXNz PSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+SSB0aGluayB5b3Un dmUgbWlzLXJlYWQgdGhlIE5JU1QgZG9jdW1lbnQuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+ PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj48c3BhbiBjbGFzcz0i QXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPjxicj4NCjwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJB cmlhbCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDEy cHg7Ij5TSEEtMSBpcyBzdGlsbCAmcXVvdDthY2NlcHRhYmxlJnF1b3Q7IGZvciBhcHBsaWNhdGlv bnMgbm90IHJlbGF0ZWQgdG8gZGlnaXRhbCBzaWduYXR1cmUgZ2VuZXJhdGlvbiAoc2VlIFRhYmxl IDkpLiBUaGF0IGluY2x1ZGVzIE1BQ2luZyAtIHNlZSBITUFDIGVudHJ5LCBUYWJsZSAxMCwNCiBh bmQgdGhlIGVuc3VpbmcgdGV4dDo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdodDogMHB4 OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IGZvbnQ6IG5vcm1hbCBub3Jt YWwgbm9ybWFsIDEycHgvbm9ybWFsICdUaW1lcyBOZXcgUm9tYW4nOyAiPg0KPGZvbnQgY2xhc3M9 IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj4mcXVvdDtITUFDIEdlbmVyYXRpb246IEFu eSA8Yj5hcHByb3ZlZCA8L2I+DQpoYXNoIGZ1bmN0aW9uIG1heSBiZSB1c2VkLjwvZm9udD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdp bi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgZm9udDogbm9ybWFsIG5vcm1hbCBub3Jt YWwgMTJweC9ub3JtYWwgJ1RpbWVzIE5ldyBSb21hbic7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPlRoZSB1c2Ugb2Yga2V5IGxlbmd0aHMgPHNwYW4gc3R5 bGU9ImZvbnQ6IDEyLjBweCBTeW1ib2wiPg0K4omlIDwvc3Bhbj44MCBiaXRzLCBidXQgJmx0OyAx MTIgYml0cyBpcyA8Yj5hY2NlcHRhYmxlIDwvYj50aHJvdWdoIERlY2VtYmVyIDMxLCAyMDEwLjwv Zm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgZm9udDogbm9ybWFsIG5v cm1hbCBub3JtYWwgMTJweC9ub3JtYWwgJ1RpbWVzIE5ldyBSb21hbic7ICI+DQo8Zm9udCBjbGFz cz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPkZyb20gSmFudWFyeSAxLCAyMDExIHRo cm91Z2ggRGVjZW1iZXIgMzEsIDIwMTMsIHRoZSB1c2Ugb2Yga2V5IGxlbmd0aHMNCjxzcGFuIHN0 eWxlPSJmb250OiAxMi4wcHggU3ltYm9sIj7iiaUgPC9zcGFuPjgwIGJpdHMsIGJ1dCAmbHQ7IDEx MiBiaXRzIGlzIDxiPmRlcHJlY2F0ZWQ8L2I+LjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDBweDsgZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgMTJweC9ub3JtYWwgJ1Rp bWVzIE5ldyBSb21hbic7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0i QXJpYWwiPkFmdGVyIERlY2VtYmVyIDMxLCAyMDEzLCBrZXkgbGVuZ3RocyAmbHQ7IDExMiBiaXRz DQo8Yj5zaGFsbCBub3QgPC9iPmJlIHVzZWQuPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJn aW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCAxMnB4L25vcm1hbCAnVGlt ZXMgTmV3IFJvbWFuJzsgIj4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJB cmlhbCI+VGhlIHVzZSBvZiBrZXkgbGVuZ3RocyA8c3BhbiBzdHlsZT0iZm9udDogMTIuMHB4IFN5 bWJvbCI+DQriiaUgPC9zcGFuPjExMiBiaXRzIGlzIDxiPmFjY2VwdGFibGU8L2I+LiZxdW90Ozwv Zm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4t cmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBmb250OiBu b3JtYWwgbm9ybWFsIG5vcm1hbCAxMnB4L25vcm1hbCAnVGltZXMgTmV3IFJvbWFuJzsgIj4NCjxm b250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PGJyPg0KPC9mb250Pjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5v cm1hbCAxMnB4L25vcm1hbCAnVGltZXMgTmV3IFJvbWFuJzsgIj4NCjxmb250IGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+Rm9yIHRoZSBkZWZpbml0aW9uIG9mIGFjY2VwdGFi bGUsIHRoZSBkb2N1bWVudCBzYXlzOjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10 b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxl ZnQ6IDBweDsgZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgMTJweC9ub3JtYWwgJ1RpbWVzIE5l dyBSb21hbic7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwi Pjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgZm9udDog bm9ybWFsIG5vcm1hbCBub3JtYWwgMTJweC9ub3JtYWwgJ1RpbWVzIE5ldyBSb21hbic7ICI+DQo8 Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPg0KPGRpdiBzdHlsZT0i bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBt YXJnaW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCAxMnB4L25vcm1hbCAn VGltZXMgTmV3IFJvbWFuJzsgIj4NCjxiPiZxdW90O0FjY2VwdGFibGUgPC9iPmlzIHVzZWQgdG8g bWVhbiB0aGF0IHRoZSBhbGdvcml0aG0gYW5kIGtleSBsZW5ndGggaXMgc2FmZSB0byB1c2U7IG5v IHNlY3VyaXR5IHJpc2sgaXMgY3VycmVudGx5IGtub3duLiZxdW90OzwvZGl2Pg0KPC9mb250Pjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5v cm1hbCAxMnB4L25vcm1hbCAnVGltZXMgTmV3IFJvbWFuJzsgIj4NCjxmb250IGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyBtYXJnaW4tbGVmdDogMHB4OyBmb250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCAxMnB4L25vcm1h bCAnVGltZXMgTmV3IFJvbWFuJzsgIj4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBm YWNlPSJBcmlhbCI+UmVnYXJkcyw8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9w OiAwcHg7IG1hcmdpbi1yaWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0 OiAwcHg7IGZvbnQ6IG5vcm1hbCBub3JtYWwgbm9ybWFsIDEycHgvbm9ybWFsICdUaW1lcyBOZXcg Um9tYW4nOyAiPg0KPGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj48 YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1y aWdodDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7IGZvbnQ6IG5v cm1hbCBub3JtYWwgbm9ybWFsIDEycHgvbm9ybWFsICdUaW1lcyBOZXcgUm9tYW4nOyAiPg0KPGZv bnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj5LZW5ueTwvZm9udD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdp bi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsgZm9udDogbm9ybWFsIG5vcm1hbCBub3Jt YWwgMTJweC9ub3JtYWwgJ1RpbWVzIE5ldyBSb21hbic7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsg bWFyZ2luLWxlZnQ6IDBweDsgZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgMTJweC9ub3JtYWwg J1RpbWVzIE5ldyBSb21hbic7ICI+DQo8Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFj ZT0iQXJpYWwiPjxicj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxzcGFuIGNsYXNzPSJBcHBsZS1z dHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyAiPk9uIDExIEZlYiAyMDEzLCBhdCAx MDowMywgTGV3aXMsIE5pY2sgd3JvdGU6PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxmb250IGNsYXNz PSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmUiPg0KPC9zcGFuPjwvZm9udD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGRpdj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxzcGFuIGNs YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KPC9z cGFuPjwvZm9udD4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj48c3BhbiBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPlRoZSByZWFs aXR5IG9mIFRMUyB0aG91Z2ggaXMgdGhhdCB0aGVyZSBhcmUgbWFueSBNQUNzIGluIGV2ZXJ5ZGF5 IHVzZSB0aGF0IGFyZSBub3Qgc2VjdXJlIChiYXNlZCBvbiBoYXNoZXMgb2YgODBiaXRzIG9yIGV2 ZW4gNjQgYml0cykuPGJyPg0KPC9zcGFuPjwvZm9udD48L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxm b250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PHNwYW4gY2xhc3M9IkFw cGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5UaGVzZSBhcmUgY3VycmVu dGx5IHByb3RlY3RlZCBmcm9tIGF0dGFjayBieSBiZWluZyBiZWhpbmQgc3Ryb25nICgxMTJiaXQg b3IgMTI4IGJpdCkgY3J5cHQuPGJyPg0KPC9zcGFuPjwvZm9udD48L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PHNwYW4gY2xh c3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5UaGUgJnF1b3Q7 dXN1YWwmcXVvdDsgTUFDIGFsZ29yaXRobXMgZm9yIFRMUyBhcmUgSE1BQy1NRDUsIEhNQUMtU0hB LTEgYW5kIEhNQUMtU0hBLTI1NiAoSE1BQy1TSEEtMzg0IGlzIGFsc28gYSBwb3NzaWJpbGl0eSku PGJyPg0KPC9zcGFuPjwvZm9udD48L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxmb250IGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNw YW4iIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5UaGVzZSBhbGwgaGF2ZSBNQUMgdGFncyBvZiBh dCBsZWFzdCAxMjggYml0cy48YnI+DQo8L3NwYW4+PC9mb250PjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJBcmlhbCI+PHNw YW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij48YnI+ DQo8L3NwYW4+PC9mb250Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFw cGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3Bh biIgc3R5bGU9ImZvbnQtc2l6ZTogMTJweDsiPlJGQyA2MDY2IHN0YW5kYXJkaXNlcyAmcXVvdDt0 cnVuY2F0ZWQmcXVvdDsgTUFDIHRhZ3MgZm9yIFRMUywgYnV0IHRoZXNlIGFyZSBrbm93biB0byBi ZSBkYW5nZXJvdXMgd2hlbiB1c2VkIGluIGNvbWJpbmF0aW9uIHdpdGggVExTJ3MgdmFyaWFibGUN CiBsZW5ndGggcGFkZGluZzxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkFy aWFsIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJw eDsiPihzZWUgdGhlIGRpc3Rpbmd1aXNoaW5nIGF0dGFjayBpbiBteSBBc2lhY3J5cHQgMjAxMSBw YXBlciB3aXRoIFJpc3RlbnBhcnQgYW5kIFNocmltcHRvbikuPGJyPg0KPC9zcGFuPjwvZm9udD48 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48Zm9udCBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBz dHlsZT0iZm9udC1zaXplOiAxMnB4OyI+SG93ZXZlciwgSSB3YXMgbm90IGF3YXJlIG9mIGFueW9u ZSBhY3R1YWxseSB1c2luZyB0aGVzZSB0cnVuY2F0ZWQgTUFDIHRhZ3MsIG9yIGFueSBvdGhlciBz aG9ydC1vdXRwdXQgTUFDIGFsZ29yaXRobXMgaW4gVExTLjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0 eWxlLXNwYW4iIGZhY2U9IkFyaWFsIj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5 bGU9ImZvbnQtc2l6ZTogMTJweDsiPkNhbiB5b3UgcHJvdmlkZSBzcGVjaWZpYyBleGFtcGxlcyBp biBzdXBwb3J0IG9mIHlvdXIgYXJndW1lbnQ/PGJyPg0KPC9zcGFuPjwvZm9udD48L2Jsb2NrcXVv dGU+DQo8Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgZmFjZT0iQXJpYWwiPjxzcGFuIGNs YXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+PGJyPg0KU29y cnkgSSBtZWFudCB0byBzYXkgJnF1b3Q7Yml0cyBvZiBzZWN1cml0eSZxdW90OyAoYXMgaW4gYSBi aXJ0aGRheSBhdHRhY2spIHJhdGhlciB0aGFuIGxlYXZlIGFuIGltcHJlc3Npb24gb2YgYml0IGxl bmd0aDxicj4NCkFjY29yZGluZyB0byBOSVNUIEhNQUMtTUQ1IGFuZCBITUFDLVNIQS0xIGFyZSB2 dWxuZXJhYmxlIGFuZCBzaG91bGQgbm90IGJlIHVzZWQgaGVuY2UgZm9ydGg8YnI+DQo8YSBocmVm PSJodHRwOi8vY3NyYy5uaXN0Lmdvdi9wdWJsaWNhdGlvbnMvbmlzdHB1YnMvODAwLTEzMUEvc3A4 MDAtMTMxQS5wZGYiPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9uaXN0cHVicy84 MDAtMTMxQS9zcDgwMC0xMzFBLnBkZjwvYT48YnI+DQo8YnI+DQotLSBOaWNrPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KVGhlIGRldGFpbHMgb2YgdGhpcyBjb21wYW55IGFyZSBhcyBmb2xsb3dzOjxi cj4NCkc0UyBUZWNobm9sb2d5IExpbWl0ZWQsIFJlZ2lzdGVyZWQgT2ZmaWNlOiBDaGFsbGVuZ2Ug SG91c2UsIEludGVybmF0aW9uYWwgRHJpdmUsIFRld2tlc2J1cnksIEdsb3VjZXN0ZXJzaGlyZSBH TDIwIDhVUSwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIE5vLiAyMzgyMzM4Ljxicj4NCjxicj4NClRo aXMgY29tbXVuaWNhdGlvbiBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB3aGljaCBpcyBjb25maWRl bnRpYWwsIHBlcnNvbmFsIGFuZC9vciBwcml2aWxlZ2VkLjxicj4NCjxicj4NCkl0IGlzIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLjxicj4NCklmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBub3RlIHRoYXQgYW55 IGRpc3RyaWJ1dGlvbiwgZm9yd2FyZGluZywgY29weWluZyBvciB1c2Ugb2YgdGhpcyBjb21tdW5p Y2F0aW9uIG9yIHRoZSBpbmZvcm1hdGlvbiBpbiBpdCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLjxi cj4NCjxicj4NCkFueSBwZXJzb25hbCB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBlLW1haWwgYXJl IHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgdGhlIGNvbXBhbnkgZG9lcyBub3Qg ZW5kb3JzZSBvciBhY2NlcHQgcmVzcG9uc2liaWxpdHkgZm9yIHRoZW0uPGJyPg0KPGJyPg0KUHJp b3IgdG8gdGFraW5nIGFueSBhY3Rpb24gYmFzZWQgdXBvbiB0aGlzIGUtbWFpbCBtZXNzYWdlLCB5 b3Ugc2hvdWxkIHNlZWsgYXBwcm9wcmlhdGUgY29uZmlybWF0aW9uIG9mIGl0cyBhdXRoZW50aWNp dHkuPGJyPg0KPGJyPg0KVGhpcyBlLW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgYWxsIHZpcnVz ZXMgYnkgTWVzc2FnZUxhYnMuPGJyPg0KPGJyPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B132B06E59C4A540A03C3393F53BC07C40818C02EXCHMB01ccrhull_-- From ynir@checkpoint.com Mon Feb 11 02:18:33 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5359021F86F4 for ; Mon, 11 Feb 2013 02:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywD+aTNa9Gbd for ; Mon, 11 Feb 2013 02:18:32 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7D221F871C for ; Mon, 11 Feb 2013 02:18:31 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r1BAITDZ004921; Mon, 11 Feb 2013 12:18:29 +0200 X-CheckPoint: {5118C175-1-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 12:18:29 +0200 From: Yoav Nir To: "Lewis, Nick" Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnybhYkpvGYYkWDbn2O0eUKMZh0TAcAgAAEQYA= Date: Mon, 11 Feb 2013 10:18:29 +0000 Message-ID: <4613980CFC78314ABFD7F85CC3027721119A294D@IL-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_4613980CFC78314ABFD7F85CC3027721119A294DILEX10adcheckpo_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:18:33 -0000 --_000_4613980CFC78314ABFD7F85CC3027721119A294DILEX10adcheckpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Feb 11, 2013, at 12:03 PM, "Lewis, Nick" > wrote: The reality of TLS though is that there are many MACs in everyday use that = are not secure (based on hashes of 80bits or even 64 bits). These are currently protected from attack by being behind strong (112bit or= 128 bit) crypt. The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA-25= 6 (HMAC-SHA-384 is also a possibility). These all have MAC tags of at least 128 bits. RFC 6066 standardises "truncated" MAC tags for TLS, but these are known to = be dangerous when used in combination with TLS's variable length padding (see the distinguishing attack in my Asiacrypt 2011 paper with Ristenpart a= nd Shrimpton). However, I was not aware of anyone actually using these truncated MAC tags,= or any other short-output MAC algorithms in TLS. Can you provide specific examples in support of your argument? Sorry I meant to say "bits of security" (as in a birthday attack) rather th= an leave an impression of bit length According to NIST HMAC-MD5 and HMAC-SHA-1 are vulnerable and should not be = used hence forth http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf That's using SHA-1 as a signature hash. As for other uses (emphasis theirs= ): SHA-1 for non-digital signature applications: For all other hash function applications, the use of SHA-1 is acceptable. T= he other applications include HMAC, Key Derivation Functions (KDFs), Random= Number Generation (RNGs and RBGs), and hash-only applications (e.g., hashi= ng passwords and using SHA-1 to compute a checksum, such as the approved in= tegrity technique specified in Section 4.6.1 of [FIPS 140-2]). --_000_4613980CFC78314ABFD7F85CC3027721119A294DILEX10adcheckpo_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 11, 2013, at 12:03 PM, "Lewis, Nick" <nick.lewis@usa.g4s.com> wrote:


The reality of TLS though is that there are many = MACs in everyday use that are not secure (based on hashes of 80bits or even= 64 bits).
These are currently protected from attack by being behind strong (112bit or= 128 bit) crypt.
The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and H= MAC-SHA-256 (HMAC-SHA-384 is also a possibility).
These all have MAC tags of at least 128 bits.

RFC 6066 standardises "truncated" MAC t= ags for TLS, but these are known to be dangerous when used in combination w= ith TLS's variable length padding
(see the distinguishing attack in my Asiacrypt 2011 paper with Ristenpart a= nd Shrimpton).
However, I was not aware of anyone actually using these truncated MAC tags,= or any other short-output MAC algorithms in TLS.
Can you provide specific examples in support of your argument?

Sorry I meant to say "bits of security" (as in a birthday attack)= rather than leave an impression of bit length
According to NIST HMAC-MD5 and HMAC-SHA-1 are vulnerable and should not be = used hence forth
http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf<= br>

That's using SHA-1 as a signature hash.  As for other uses (empha= sis theirs):

SHA-1 for non-digital signature applications:

For all other hash function applications, the use of SHA-1 is . The other applications include HMAC, = Key Derivation Functions (KDFs), Random Number Generation (RNGs and RBGs), and hash-only applications (e.g., hashi= ng passwords and using SHA-1 to compute a checksum, such as the approved in= tegrity technique specified in Section 4.6.1 of [FIPS 140-2]).


 


--_000_4613980CFC78314ABFD7F85CC3027721119A294DILEX10adcheckpo_-- From nick.lewis@usa.g4s.com Mon Feb 11 02:39:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F1721F8775 for ; Mon, 11 Feb 2013 02:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04BjSW-wwOWj for ; Mon, 11 Feb 2013 02:39:27 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id B89E921F876E for ; Mon, 11 Feb 2013 02:39:26 -0800 (PST) Received: from [85.158.137.3:61485] by server-15.bemta-3.messagelabs.com id 53/FF-25405-D5AC8115; Mon, 11 Feb 2013 10:39:25 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-6.tower-38.messagelabs.com!1360579164!11591561!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10201 invoked from network); 11 Feb 2013 10:39:25 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-6.tower-38.messagelabs.com with RC4-SHA encrypted SMTP; 11 Feb 2013 10:39:25 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Mon, 11 Feb 2013 10:39:24 +0000 From: "Lewis, Nick" To: "'Paterson, Kenny'" Date: Mon, 11 Feb 2013 10:39:24 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnkM5Cm91Ib2Ua7186ZEOcKaph0ZRRQgAALxYCAAAOYoA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:39:28 -0000 PlNIQS0xIGlzIHN0aWxsICJhY2NlcHRhYmxlIiBmb3IgYXBwbGljYXRpb25zIG5vdCByZWxhdGVk IHRvIGRpZ2l0YWwgc2lnbmF0dXJlIGdlbmVyYXRpb24gKHNlZSBUYWJsZSA5KS4NCg0KT29wcyBT b3JyeSBJIGZvcmdvdCB0aGF0IHRoZSBib3VuZGFyeSBpcyAiZ3JlYXRlciB0aGFuIG9yIGVxdWFs IHRvIiB0aGUgMTEyYml0IHNlY3VyaXR5IG9mIFNIQS0xIHJhdGhlciB0aGFuIGp1c3QgImdyZWF0 ZXIgdGhhbiINCihJdCBsb29rcyBhcyBpZiBOU1MgaGF2ZSB1bnRpbCAyMDMwIGJlZm9yZSB0aGV5 IG5lZWQgdG8gc3VwcG9ydCBUTFMxLjIgd2l0aCBITUFDLVNIQTI1NikNCg0KLS0gTmljaw0KDQpU aGUgZGV0YWlscyBvZiB0aGlzIGNvbXBhbnkgYXJlIGFzIGZvbGxvd3M6DQpHNFMgVGVjaG5vbG9n eSBMaW1pdGVkLCBSZWdpc3RlcmVkIE9mZmljZTogQ2hhbGxlbmdlIEhvdXNlLCBJbnRlcm5hdGlv bmFsIERyaXZlLCBUZXdrZXNidXJ5LCBHbG91Y2VzdGVyc2hpcmUgR0wyMCA4VVEsIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCBOby4gMjM4MjMzOC4NCg0KVGhpcyBjb21tdW5pY2F0aW9uIG1heSBjb250 YWluIGluZm9ybWF0aW9uIHdoaWNoIGlzIGNvbmZpZGVudGlhbCwgcGVyc29uYWwgYW5kL29yIHBy aXZpbGVnZWQuDQoNCkl0IGlzIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50KHMpLg0KSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSwg cGxlYXNlIG5vdGUgdGhhdCBhbnkgZGlzdHJpYnV0aW9uLCBmb3J3YXJkaW5nLCBjb3B5aW5nIG9y IHVzZSBvZiB0aGlzIGNvbW11bmljYXRpb24gb3IgdGhlIGluZm9ybWF0aW9uIGluIGl0IGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuDQoNCkFueSBwZXJzb25hbCB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyBlLW1haWwgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlciBhbmQgdGhlIGNvbXBh bnkgZG9lcyBub3QgZW5kb3JzZSBvciBhY2NlcHQgcmVzcG9uc2liaWxpdHkgZm9yIHRoZW0uDQoN ClByaW9yIHRvIHRha2luZyBhbnkgYWN0aW9uIGJhc2VkIHVwb24gdGhpcyBlLW1haWwgbWVzc2Fn ZSwgeW91IHNob3VsZCBzZWVrIGFwcHJvcHJpYXRlIGNvbmZpcm1hdGlvbiBvZiBpdHMgYXV0aGVu dGljaXR5Lg0KDQpUaGlzIGUtbWFpbCBoYXMgYmVlbiBzY2FubmVkIGZvciBhbGwgdmlydXNlcyBi eSBNZXNzYWdlTGFicy4NCg== From nick.lewis@usa.g4s.com Mon Feb 11 02:48:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2246321F86A2 for ; Mon, 11 Feb 2013 02:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.095 X-Spam-Level: X-Spam-Status: No, score=-4.095 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWNm717xWmGc for ; Mon, 11 Feb 2013 02:48:25 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1982621F8430 for ; Mon, 11 Feb 2013 02:48:24 -0800 (PST) Received: from [85.158.137.3:35396] by server-4.bemta-3.messagelabs.com id D3/37-12802-87CC8115; Mon, 11 Feb 2013 10:48:24 +0000 X-Env-Sender: nick.lewis@usa.g4s.com X-Msg-Ref: server-16.tower-38.messagelabs.com!1360579703!17508952!1 X-Originating-IP: [89.206.228.155] X-StarScan-Received: X-StarScan-Version: 6.7; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11330 invoked from network); 11 Feb 2013 10:48:24 -0000 Received: from unallocated.star.net.uk (HELO gbtwk10s038.Technology.local) (89.206.228.155) by server-16.tower-38.messagelabs.com with RC4-SHA encrypted SMTP; 11 Feb 2013 10:48:24 -0000 Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s038.Technology.local ([10.234.1.40]) with mapi; Mon, 11 Feb 2013 10:48:23 +0000 From: "Lewis, Nick" To: "'tls@ietf.org'" Date: Mon, 11 Feb 2013 10:48:23 +0000 Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnkM5Cm91Ib2Ua7186ZEOcKaph0ZRRQgAALxYCAAAOYoIAABH4w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:48:26 -0000 VWg/IENhbiBzb21lIG9uZSBoZWxwIG1lIGhlcmU/DQpTSEEtMSBoYXMgODAgYml0IG9mIHNlY3Vy aXR5IGFjY29yZGluZyB0byBCLjIgYW5kIGFjY29yZGluZyB0byBUYWJsZSA5IGFuIEhNQUMgb2Yg ODAgYml0cyBjYW5ub3QgYmUgdXNlZCBidXQgZWxzZXdoZXJlIHRoZSBOSVNUIGRvY3VtZW50IHN0 YXRlcyB0aGF0IEhNQUMtU0hBMSBpcyBhY2NlcHRhYmxlDQoNCi0tIE5pY2sNCg0KVGhlIGRldGFp bHMgb2YgdGhpcyBjb21wYW55IGFyZSBhcyBmb2xsb3dzOg0KRzRTIFRlY2hub2xvZ3kgTGltaXRl ZCwgUmVnaXN0ZXJlZCBPZmZpY2U6IENoYWxsZW5nZSBIb3VzZSwgSW50ZXJuYXRpb25hbCBEcml2 ZSwgVGV3a2VzYnVyeSwgR2xvdWNlc3RlcnNoaXJlIEdMMjAgOFVRLCBSZWdpc3RlcmVkIGluIEVu Z2xhbmQgTm8uIDIzODIzMzguDQoNClRoaXMgY29tbXVuaWNhdGlvbiBtYXkgY29udGFpbiBpbmZv cm1hdGlvbiB3aGljaCBpcyBjb25maWRlbnRpYWwsIHBlcnNvbmFsIGFuZC9vciBwcml2aWxlZ2Vk Lg0KDQpJdCBpcyBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVu dChzKS4NCklmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocyksIHBsZWFzZSBu b3RlIHRoYXQgYW55IGRpc3RyaWJ1dGlvbiwgZm9yd2FyZGluZywgY29weWluZyBvciB1c2Ugb2Yg dGhpcyBjb21tdW5pY2F0aW9uIG9yIHRoZSBpbmZvcm1hdGlvbiBpbiBpdCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLg0KDQpBbnkgcGVyc29uYWwgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgZS1tYWls IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIgYW5kIHRoZSBjb21wYW55IGRvZXMg bm90IGVuZG9yc2Ugb3IgYWNjZXB0IHJlc3BvbnNpYmlsaXR5IGZvciB0aGVtLg0KDQpQcmlvciB0 byB0YWtpbmcgYW55IGFjdGlvbiBiYXNlZCB1cG9uIHRoaXMgZS1tYWlsIG1lc3NhZ2UsIHlvdSBz aG91bGQgc2VlayBhcHByb3ByaWF0ZSBjb25maXJtYXRpb24gb2YgaXRzIGF1dGhlbnRpY2l0eS4N Cg0KVGhpcyBlLW1haWwgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgYWxsIHZpcnVzZXMgYnkgTWVzc2Fn ZUxhYnMuDQo= From ynir@checkpoint.com Mon Feb 11 03:02:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C612821F87BB for ; Mon, 11 Feb 2013 03:02:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpMjRkT6rQNj for ; Mon, 11 Feb 2013 03:02:13 -0800 (PST) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03121F87BA for ; Mon, 11 Feb 2013 03:02:13 -0800 (PST) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r1BB284R014690; Mon, 11 Feb 2013 13:02:11 +0200 X-CheckPoint: {5118CBAF-3-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.18]) by DAG-EX10.ad.checkpoint.com ([169.254.3.103]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 13:02:07 +0200 From: Yoav Nir To: "Lewis, Nick" Thread-Topic: [TLS] TLS1.3 Thread-Index: AQHOCDnybhYkpvGYYkWDbn2O0eUKMZh0TAcAgAADUICAAAbLAIAAAoOAgAAD0gA= Date: Mon, 11 Feb 2013 11:02:07 +0000 Message-ID: <4613980CFC78314ABFD7F85CC3027721119A2B12@IL-EX10.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <6D369EB7B56BD846857CC27669864809@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:02:14 -0000 A naive attack to find collisions in SHA-1 would require hashing 2^80 buffe= rs. Another way of saying this is that is has 80-bit strength in collision = resistance. In fact it's weaker than that, because there are more efficient= attacks. However, having a 2^80 or 2^64 collision attack does not make it any easier= to find a second pre-image or to break HMAC-SHA-1. The HMAC construction i= s specifically aimed at preventing collision weakness from affecting MAC st= rength. You can read about this in section 6 of RFC 2104 or the references = from there.=20 Hope this helps Yoav On Feb 11, 2013, at 12:48 PM, "Lewis, Nick" wrote: > Uh? Can some one help me here? > SHA-1 has 80 bit of security according to B.2 and according to Table 9 an= HMAC of 80 bits cannot be used but elsewhere the NIST document states that= HMAC-SHA1 is acceptable >=20 > -- Nick >=20 > The details of this company are as follows: > G4S Technology Limited, Registered Office: Challenge House, International= Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 238= 2338. >=20 > This communication may contain information which is confidential, persona= l and/or privileged. >=20 > It is for the exclusive use of the intended recipient(s). > If you are not the intended recipient(s), please note that any distributi= on, forwarding, copying or use of this communication or the information in = it is strictly prohibited. >=20 > Any personal views expressed in this e-mail are those of the individual s= ender and the company does not endorse or accept responsibility for them. >=20 > Prior to taking any action based upon this e-mail message, you should see= k appropriate confirmation of its authenticity. >=20 > This e-mail has been scanned for all viruses by MessageLabs. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Email secured by Check Point From n.mavrogiannopoulos@gmail.com Mon Feb 11 07:14:42 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB8D21F8AB1 for ; Mon, 11 Feb 2013 07:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWJkeSdjg3dY for ; Mon, 11 Feb 2013 07:14:41 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 83F8321F8AB4 for ; Mon, 11 Feb 2013 07:14:41 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so2271924qcs.27 for ; Mon, 11 Feb 2013 07:14:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GMS5oGTLwUOAJ1wrRSzlvdsMJJKsFBLG2iOuAxtBrP0=; b=Ib7D3YW9lvFC1B+Kyg3xQ2BHs8qIriCd6oy6pfHoLbBx32dxZ/2dLximNNg4SABMEs FwF7N3t7V7pfMhJFcg6SFqV8cyJycnDCstME0N+9cJptt4I7qi7CCTbazQIxwIfO5K8Z eMgnSCxkJtVWLgneKzNU8fF59CdhLsFNlUoX4G4zmxauDmg6HvDIxzxox9dgQlmGXvTV DR8GpLuZvgSgXx+k+IjWyeUxuqZ3c9DxDiJYIZbro6lPq4zU7o6uhTcOuZ+tuZB7yHJ1 3OvzK5vZaihYfwGcXiQXXvkRl3jXPAoJ1p20nNOEiFNBHbn20dODnLkciI3V1jI5eyRj Sv1A== MIME-Version: 1.0 X-Received: by 10.49.71.204 with SMTP id x12mr6225488qeu.47.1360595680808; Mon, 11 Feb 2013 07:14:40 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.78.204 with HTTP; Mon, 11 Feb 2013 07:14:40 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 16:14:40 +0100 X-Google-Sender-Auth: xAldgepON5G-Wat5nmC9tyjofGE Message-ID: From: Nikos Mavrogiannopoulos To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Lewis, Nick" , "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:14:42 -0000 On Mon, Feb 11, 2013 at 10:26 AM, Paterson, Kenny wrote: >> The reality of TLS though is that there are many MACs in everyday use t= hat are not secure (based on hashes of 80bits or even 64 bits). These are c= urrently protected from attack by being behind strong (112bit or 128 bit) c= rypt. > The "usual" MAC algorithms for TLS are HMAC-MD5, HMAC-SHA-1 and HMAC-SHA-= 256 (HMAC-SHA-384 is also a possibility). These all have MAC tags of at lea= st 128 bits. Indeed but note that today we have key recovery attacks on HMAC-MD4 [1,0]. Partial key recovery attacks exist on HMAC-MD5, too. It may be long until such an attack applies to an encrypt-then-authenticate setup, but could someone rule that possibility out? The current authenticate-then-encrypt mode would most likely prevent such attacks. The encrypt-then-authenticate modes would provide any adversary with the MACed data and the MAC in plain. It seems like a tradeoff between concealment and integrity. Personally, I do believe that any fix to a protocol with such deployment should be targeted at the problem in question, unless there are serious reasons to believe that the old mechanism is beyond repair. I do think we are not in that case yet and a mechanism to make the pad part of the MAC as I proposed in an earlier e-mail is sufficient. However, I also believe any solution is better than no solution at all, and I do think that this WG should decide on a document to update RFC5246, which either fixes the issue or replaces the CBC ciphersuites. regards, Nikos [0]. Contini, Scott, and Yiqun Yin. "Forgery and partial key-recovery attacks on HMAC and NMAC using hash collisions." Advances in Cryptology=E2=80=93ASIACRYPT 2006 (2006): 37-53. [1]. Fouque, Pierre-Alain, Ga=C3=ABtan Leurent, and Phong Nguyen. "Full key-recovery attacks on HMAC/NMAC-MD4 and NMAC-MD5." Advances in Cryptology-CRYPTO 2007 (2007): 13-30. From mrex@sap.com Mon Feb 11 07:29:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A18321F8920 for ; Mon, 11 Feb 2013 07:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.993 X-Spam-Level: X-Spam-Status: No, score=-9.993 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsw2AQDW9mIG for ; Mon, 11 Feb 2013 07:29:44 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6C16621F8891 for ; Mon, 11 Feb 2013 07:29:43 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r1BFTZl9025649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Feb 2013 16:29:35 +0100 (MET) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7333400716@uxcn10-2.UoA.auckland.ac.nz> To: Peter Gutmann Date: Mon, 11 Feb 2013 16:29:34 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130211152934.ED58A1A542@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:29:45 -0000 Peter Gutmann wrote: > Martin Rex writes: > > > >Personally, I also feel somewhat uncomfortable with a "radical" change to > >encrypt-then-MAC rather than the simply using the obvious pad-MAC-encrypt, as > >originally suggested by Serge Vaudenay. > > It's hardly a radical change, in terms of code complexity (at least in my > code) it came down to (comments and error checking removed) this: > > checkMacTLS( sessionInfoPtr, data, length, length - sessionInfoPtr->authBlocksize, packetType ); > decryptData( sessionInfoPtr, data, length - sessionInfoPtr->authBlocksize, &length ); > > In other words I swapped two lines of code. But this sounds like your changing the semantics for all ciphersuites, including the GenericStreamCipher PDU, which includes ciphers such as TLS_RSA_WITH_RC4_128_MD5, and AEAD ciphersuites. Personally, I would prefer to limit this change to the processing of the GenericBlockCipher PDU of TLS. > > >When the encryption scheme that is used is bijective, then it will not matter > >(to the confidentiality of the encryption) whether AtE or EtA is used, as > >long as authentication covers the exact same information in both cases, i.e. > >*ALL* of it, padding included. > > However you do need to to MAC the IV. Correct. > If you treat it as part of the ciphertext then it's trivial, > MAC the entire packet in its bits-on-the-wire > form. If you're MAC'ing the plaintext then you need to special-case the IV > vs. the plaintext and suddenly you're adding all sorts of kludgery to handle > that. Authenticating the exact bits on the wire is both cleaner conceptually/ > security-wise (you're authenticating the exact data that the attacker has > access to, not some bits as seen by the attacker and some bits as seen by you > after further processing), and implementation-wise (you just swap the bits of > code that do auth. vs. encrypt). To quote Kenny Paterson's recent message: > > It fixes every problem I can conceive of. And I've thought about the > analysis of TLS's current MAC-pad-encrypt construction long and hard, > believe me. > > That's pretty unambiguous. > > >However, in the EtA scheme, we would have a naked keyed hash. And would an > >attack on the keyed hash become somehow feasible, that attack might be easier > >on a naked keyed hash than on an encrypted keyed hash. > > That's going to be pretty unlikely, if someone can break HMAC then we've got > more serious things to worry about than forging of TLS packets. I would really hate having to add a black-list of cipher suites that must not be used with the new scheme (such as TLS_RSA_WITH_RC4_128_MD5) in a few years, when it turns out that an HMAC-MD5 is too weak. -Martin From nico@cryptonector.com Mon Feb 11 07:30:47 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A0B21F892B for ; Mon, 11 Feb 2013 07:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.067 X-Spam-Level: X-Spam-Status: No, score=-4.067 tagged_above=-999 required=5 tests=[AWL=-2.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCFNK6KAVw1w for ; Mon, 11 Feb 2013 07:30:47 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 5163221F8920 for ; Mon, 11 Feb 2013 07:30:47 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 183C31006D for ; Mon, 11 Feb 2013 07:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=F0Aey2k+BM6AQ4W+dDNv eBgzV8M=; b=Sp/lMCNHYLpo2mfPXDhOoMi7aqSGt3vjyV00FzAaVeZQ4f/ylidE r2CIGlGC5msfpMo7JYsFYG83BnMXirwbsw0YLJtpACayaYMCQFkZCR6batfbM8hy fuVpyBgZNrWAqI82EIMBl571fYy8sUn4K+tIbYxlx5TKWA7OfFHK+jI= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id B757A10041 for ; Mon, 11 Feb 2013 07:30:46 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so4789764wgi.27 for ; Mon, 11 Feb 2013 07:30:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.216.5 with SMTP id om5mr24851266wjc.27.1360596645335; Mon, 11 Feb 2013 07:30:45 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 07:30:45 -0800 (PST) In-Reply-To: <4613980CFC78314ABFD7F85CC30277211199F46C@IL-EX10.ad.checkpoint.com> References: <9A043F3CF02CD34C8E74AC1594475C73333FEAFD@uxcn10-2.UoA.auckland.ac.nz> <4613980CFC78314ABFD7F85CC30277211199F46C@IL-EX10.ad.checkpoint.com> Date: Mon, 11 Feb 2013 09:30:45 -0600 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:30:47 -0000 On Fri, Feb 8, 2013 at 5:47 AM, Yoav Nir wrote: > Hi Peter > > It would help to explain why this is better than just defining some new encrypt-then-MAC ciphersuites. Cartesian explosion is a good argument. Are there others? I think that argument is sufficient. And maybe it's time to start thinking about a general solution to the cipher suite cartesian product of algorithms problem -- perhaps along the same lines as Peter's I-D. FWIW, I support Peter's approach here. Nico -- From mrex@sap.com Mon Feb 11 07:33:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0895221F8849 for ; Mon, 11 Feb 2013 07:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoZp1wxSaPSG for ; Mon, 11 Feb 2013 07:33:35 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92621F87D4 for ; Mon, 11 Feb 2013 07:33:35 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1BFXRYx002906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Feb 2013 16:33:27 +0100 (MET) In-Reply-To: <20130211152934.ED58A1A542@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Mon, 11 Feb 2013 16:33:27 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130211153327.6EE941A546@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:33:36 -0000 Martin Rex wrote: > > > > >When the encryption scheme that is used is bijective, then it will not matter > > >(to the confidentiality of the encryption) whether AtE or EtA is used, as > > >long as authentication covers the exact same information in both cases, i.e. > > >*ALL* of it, padding included. > > > > However you do need to to MAC the IV. > > Correct. Re-thinking it, I believe it would be OK to _not_ cover the CBC-IV in the AtE, while you *MUST* cover the IV in the EtA case. The reason being that the IV does not impact the bijectivity of the cipher, and is not part of the plaintext. -Martin From wwwrun@rfc-editor.org Fri Feb 8 14:01:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F2C21F8BE2 for ; Fri, 8 Feb 2013 14:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk3eMqjj-2h8 for ; Fri, 8 Feb 2013 14:01:30 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29E21F8BEB for ; Fri, 8 Feb 2013 14:01:30 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 1011DB1E004; Fri, 8 Feb 2013 14:01:22 -0800 (PST) To: tdierks@certicom.com, pck@netcom.com, relyea@netscape.com, jar@netscape.com, msabin@netcom.com, dansimon@microsoft.com, tomw@netscape.com, hugo@watson.ibm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20130208220123.1011DB1E004@rfc-editor.org> Date: Fri, 8 Feb 2013 14:01:22 -0800 (PST) X-Mailman-Approved-At: Mon, 11 Feb 2013 08:08:48 -0800 Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC2246 (3481) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 08 Feb 2013 22:01:30 -0000 The following errata report has been submitted for RFC2246, "The TLS Protocol Version 1.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2246&eid=3481 -------------------------------------- Type: Technical Reported by: Martin Rex Section: 8.1.2 Original Text ------------- 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Corrected Text -------------- 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret. Notes ----- Adopting the clarification from rfc4346 Section 8.1.2. Not stripping the leading zero bits of Z will cause interop problems (handshake failures) with the installed base. Rfc2246 is still the authoritative spec for TLSv1.0. One can not implement TLSv1.0 from rfc4346. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2246 (no draft string recorded) -------------------------------------- Title : The TLS Protocol Version 1.0 Publication Date : January 1999 Author(s) : T. Dierks, C. Allen Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Mon Feb 11 06:55:35 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDF621F8955 for ; Mon, 11 Feb 2013 06:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.077 X-Spam-Level: X-Spam-Status: No, score=-102.077 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT2xxPPw76Sv for ; Mon, 11 Feb 2013 06:55:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0512221F892C for ; Mon, 11 Feb 2013 06:55:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id D59B2B1E002; Mon, 11 Feb 2013 06:55:17 -0800 (PST) To: tdierks@certicom.com, pck@netcom.com, relyea@netscape.com, jar@netscape.com, msabin@netcom.com, dansimon@microsoft.com, tomw@netscape.com, hugo@watson.ibm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20130211145517.D59B2B1E002@rfc-editor.org> Date: Mon, 11 Feb 2013 06:55:17 -0800 (PST) X-Mailman-Approved-At: Mon, 11 Feb 2013 08:08:48 -0800 Cc: florian.maury@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC2246 (3482) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 14:55:35 -0000 The following errata report has been submitted for RFC2246, "The TLS Protocol Version 1.0". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=2246&eid=3482 -------------------------------------- Type: Editorial Reported by: Florian Maury Section: 7.4.9. Original Text ------------- The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the certificate verify message (if sent). Also, the handshake_messages for the finished message sent by the client will be different from that for the finished message sent by the server, because the one which is sent second will include the prior one. Corrected Text -------------- The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the certificate verify message (if sent). Also, the handshake_messages for the finished message sent by the client will be different from that for the finished message sent by the server, because the one which is sent second will include the prior one. Notes ----- The sentence about Sender.client and Sender.server is a remainder from the draft 2 and previous versions. The verification computation changed between draft 2 and draft 3 (as showed by rfcdiff http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-protocol-03.txt ) but the sentence remained. It should be stripped as the Sender enumerated type is not even declared anymore. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2246 (no draft string recorded) -------------------------------------- Title : The TLS Protocol Version 1.0 Publication Date : January 1999 Author(s) : T. Dierks, C. Allen Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From openpgp@brainhub.org Mon Feb 11 09:26:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF0D21F86F5 for ; Mon, 11 Feb 2013 09:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOsp3nWPis3m for ; Mon, 11 Feb 2013 09:26:41 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0615221F8681 for ; Mon, 11 Feb 2013 09:26:40 -0800 (PST) Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta12.emeryville.ca.mail.comcast.net with comcast id z1kN1k00A1wfjNsAC5SgKR; Mon, 11 Feb 2013 17:26:40 +0000 Received: from [127.0.0.1] ([69.181.162.123]) by omta23.emeryville.ca.mail.comcast.net with comcast id z5Sf1k00C2g33ZR8j5Sg54; Mon, 11 Feb 2013 17:26:40 +0000 Message-ID: <5119296B.80702@brainhub.org> Date: Mon, 11 Feb 2013 09:24:59 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20130208192355.359111A52E@ld9781.wdf.sap.corp> In-Reply-To: <20130208192355.359111A52E@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360603600; bh=uh1Spodz9Bhi6TlnOQ6Q7/mWnV7iIcm62sV857Eci7A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kVeCSgv34Hw44tmwUftpGvyRlq7aKwpF7ape3JtFGOU7sJfHhPSNxovPqsRb+u/r9 pd+uQYAVHqVA8ghlPivqdBoFGH0UFTZTIxu0hLkHHzKSAyYmOkkIBLdxABJ9S0Bjdn cOkESWLagmKxD2HTzr3d/4KMYLNBFk8NWkitzN5LE/TpTRr/0XFOs5LqT/Ydt1H3vb 2FBPCQpC1ueBzivUGI+Uctb8Okc7RHcdFVx/55s+sGQGXPl9gOijJLUqxuxzbnZZlE KTw581CdWOs0Ng37fnv2ulqU/C6j6mjx8oZ/PGtCfaBXthLFEpYzytWCasn2d/HJuE la3CXqIUDKTnw== Subject: Re: [TLS] Pre-master secret formatting for master secret calculation with DH in TLS 1.x X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 17:26:41 -0000 Thank you, Martin. I will assume that the TLS >= 1.1 style it the right way to encode the shared secret of the DH exchange. This seems like an odd way to represent a finite field element with implicit length. Unlike strings, here we know the maximum size. On 02/08/2013 11:23 AM, Martin Rex wrote: > It appears to have been retroactively clarified as being (2) > from your choices: > > TLSv1.1 http://tools.ietf.org/html/rfc4346#section-8.1.2 > TLSv1.2 http://tools.ietf.org/html/rfc5246#section-8.1.2 > > Leading bytes of Z that > contain all zero bits are stripped before it is used as the > pre_master_secret. > > -Martin > > Andrey Jivsov wrote: >> I ran into an interoperability problem between our TLS implementation >> and another very popular one. >> >> The question is what exactly is the formatting for the RFC2246 sec. >> 8.1.2 "Diffie-Hellman" shared secret 'Z' ? >> >> The problem arises when the most significant byte of the Z is zero. >> Let's say that the field prime's size is 256. There are two possibilities: >> >> 1. export the Z in the big endian format, padding it to 256 (first byte >> in the buffer is zero) >> 2. export the Z in the big endian format, placing the result in a 255 >> byte buffer. >> >> I would say that this should be #1, because it is the natural >> representation of the Z. If there is a language specifying the canonical >> encoding for the Z, I would appreciate the reference. >> >> ( Apparently, this problem doesn't clearly manifest itself in real >> deployments because ~ the 1/256 failure rate is masked by >> re-negotiations at the higher protocol level. ) >> >> Thank you. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From pascal.urien@gmail.com Mon Feb 11 12:21:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4EA21F8A6B for ; Mon, 11 Feb 2013 12:21:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTrKhIMIAyrR for ; Mon, 11 Feb 2013 12:21:21 -0800 (PST) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0EE21F8992 for ; Mon, 11 Feb 2013 12:21:20 -0800 (PST) Received: by mail-bk0-f53.google.com with SMTP id j10so2760411bkw.40 for ; Mon, 11 Feb 2013 12:21:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=YSyodiicLZfw2JUN0zEjGv+/gd3vbLoIY7Z+lvReavU=; b=P4IIN8wweSTpnCVvpyhR/p9o4WchAlWak8ATq50pQyH3s35n5gwUJi7wZdMFo1xtmj 2i9eTUlIazszUuYTMNNrcgCMp3MnSyO2nyDpUK6HfizyzPJ90NSiabkP5TYHZBZrpMrK jo+rbEe6lcHXnFeyleDcAIar+ZreERSXqbp7MOBFbRWVFLIa3WpoTXDpK7Mt5vtjen03 WQddnTtE/J8FMaoMadt1XVJFUUvn8are/kKmfVk+sWUZL8absXD0IHMylERYz5L1+RBc r84yeu7Jz9sfoJAAFdSt2wsPqSbEGkWm4XwCb9159QO+kTdCp3k1ceTuipKojl1xo6ah y0dA== MIME-Version: 1.0 X-Received: by 10.204.149.87 with SMTP id s23mr4523371bkv.33.1360614079531; Mon, 11 Feb 2013 12:21:19 -0800 (PST) Received: by 10.204.49.19 with HTTP; Mon, 11 Feb 2013 12:21:19 -0800 (PST) In-Reply-To: <20130207152728.28131.43175.idtracker@ietfa.amsl.com> References: <20130207152728.28131.43175.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2013 21:21:19 +0100 Message-ID: From: Pascal Urien To: tls@ietf.org Content-Type: multipart/alternative; boundary=0015175cae2ee3093d04d578a669 Subject: [TLS] Fwd: New Version Notification for draft-urien-tls-llcp-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 20:21:22 -0000 --0015175cae2ee3093d04d578a669 Content-Type: text/plain; charset=ISO-8859-1 Hi All A new version of the LLCPS is available at : http://www.ietf.org/internet-drafts/draft-urien-tls-llcp-01.txt LLCPS describes the support of TLS over the NFC P2P protocol (LLCP) About one million of NFC smartphone are sold evedry week. LLCPS targets security for IoT applications (access control, ticketting, ...) A demonstration of the first implementation (connected mode) was made in january at the CES 2013 and during the IEEE CCNC 2013 conference see http://www.youtube.com/watch?v=CVWHlxoi3eU Regards Pascal Urien ---------- Forwarded message ---------- From: Date: 2013/2/7 Subject: New Version Notification for draft-urien-tls-llcp-01.txt To: pascal.urien@gmail.com Cc: pascal.urien@telecom-paristech.fr A new version of I-D, draft-urien-tls-llcp-01.txt has been successfully submitted by Pascal Urien and posted to the IETF repository. Filename: draft-urien-tls-llcp Revision: 01 Title: LLCPS Creation date: 2013-02-07 WG ID: Individual Submission Number of pages: 41 URL: http://www.ietf.org/internet-drafts/draft-urien-tls-llcp-01.txt Status: http://datatracker.ietf.org/doc/draft-urien-tls-llcp Htmlized: http://tools.ietf.org/html/draft-urien-tls-llcp-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-urien-tls-llcp-01 Abstract: This document describes the implementation, named LLCPS, of the TLS protocol over the NFC (Near Field Communication) LLCP (Logical Link Control Protocol) layer. The NFC peer to peer (P2P) protocol may be used by any application that needs communication between two devices at very small distances (a few centimeters). LLCPS enforces a strong security in NFC P2P exchanges, and may be deployed for many services, in the Internet Of Things ecosystem, such as access control or ticketing operations. The IETF Secretariat --0015175cae2ee3093d04d578a669 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All
=A0
=A0=A0 A new version of the LLCPS is available at :=A0=A0 http://www.ietf.org/internet-drafts/draft-urien-tls-llcp-01.txt<= br>
=A0=A0 LLCPS=A0 describes the support of TLS over the NFC P2P protocol= (LLCP)
=A0
=A0=A0 About one million of NFC smartphone are sold evedry week. LLCPS= targets security for IoT applications (access control,=A0ticketting, ...)<= /div>
=A0
A=A0demonstration of the first implementation (connected mode) =A0was = made in january at the CES=A02013 and during the IEEE CCNC 2013 conference = see
=A0
=A0
Regards
=A0
Pascal Urien
=A0

---------- Forwarded message ----------
From:= <internet-drafts@ietf.org>
Date: = 2013/2/7
Subject: New Version Notification for draft-urien-tls-llcp-01.txt
To: pascal.urien@gmail.com
Cc: <= a href=3D"mailto:pascal.urien@telecom-paristech.fr">pascal.urien@telecom-pa= ristech.fr



A new version of I-D, draft-urien-tls-llcp-01.txt
has been s= uccessfully submitted by Pascal Urien and posted to the
IETF repository.=

Filename: =A0 =A0 =A0 =A0draft-urien-tls-llcp
Revision: =A0 =A0 = =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 LLCPS
Creation date: =A0 2013-02-07
WG ID:= =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 41
URL: = =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-dra= fts/draft-urien-tls-llcp-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-ur= ien-tls-llcp
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/ht= ml/draft-urien-tls-llcp-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?url2= =3Ddraft-urien-tls-llcp-01

Abstract:
=A0 =A0This document des= cribes the implementation, named LLCPS, of the TLS
=A0 =A0protocol over the NFC (Near Field Communication) LLCP (Logical Link<= br>=A0 =A0Control Protocol) layer. The NFC peer to peer (P2P) protocol may = be
=A0 =A0used by any application that needs communication between two d= evices
=A0 =A0at very small distances (a few centimeters). LLCPS enforces a strong=
=A0 =A0security in NFC P2P exchanges, and may be deployed for many
= =A0 =A0services, in the Internet Of Things ecosystem, such as access
=A0= =A0control or ticketing operations.





The IETF Secretariat


--0015175cae2ee3093d04d578a669-- From pgut001@cs.auckland.ac.nz Mon Feb 11 15:13:45 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADD221F872E for ; Mon, 11 Feb 2013 15:13:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii4nuPvEGmyr for ; Mon, 11 Feb 2013 15:13:44 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id A0BF421F871C for ; Mon, 11 Feb 2013 15:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360624425; x=1392160425; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=pfNh2jOjNXnYAyYn/DZEdQEvOdEjGLd6La+qQTuQKss=; b=eVKW/hMRCDZbUhtONQsw2PpEZh/PjzujpmsgCW2fgFjHqemd4SmzJ4d4 y2DvAXxsODcZBdSNZpXyNaMode2ottfgHrMADaIdgeIFfRXFbkR5MOh99 +79fhrQk8mMoE06e0IjhO70R1Uplg3Vf7stETI1iW4Op7GTdfc6gfoCNF Y=; X-IronPort-AV: E=Sophos;i="4.84,646,1355050800"; d="scan'208";a="170008307" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Feb 2013 12:13:42 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 12 Feb 2013 12:13:41 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.181]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 12:13:42 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4Iq/Fr62D5ot6XS+mVrO5UN0v4ew== Date: Mon, 11 Feb 2013 23:13:41 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73334013EB@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 23:13:45 -0000 [CC'd to Hugo Krawczyk, we really need another cryptographer in on this =0A= alongside Kenny Paterson since the rest of us are mostly just guessing/=0A= speculating. So the debate is about switching TLS to use encrypt-then-=0A= MAC from its current vulnerability-prone MAC-then-encrypt]=0A= =0A= Martin Rex writes:=0A= =0A= >But this sounds like your changing the semantics for all ciphersuites,=0A= >including the GenericStreamCipher PDU, which includes ciphers such as =0A= >TLS_RSA_WITH_RC4_128_MD5, and AEAD ciphersuites.=0A= =0A= OK, there are two more lines of code I didn't show (since they're in the = =0A= calling function), the code there is something like:=0A= =0A= switch( protection_type )=0A= case classic_SSL: wrapPacketSSL();=0A= case AEAD: wrapPacketAEAD();=0A= case encrypt_then_MAC: wrapPacketEthenM();=0A= =0A= So it's really two lines added and two lines swapped (+syntactic sugar=0A= and comments). And several hundred lines of ad-hockery to deal with=0A= MAC-then-encrypt vulnerabilities sidelined.=0A= =0A= >I would really hate having to add a black-list of cipher suites that must = =0A= >not be used with the new scheme (such as TLS_RSA_WITH_RC4_128_MD5) in a = =0A= >few years, when it turns out that an HMAC-MD5 is too weak.=0A= =0A= In what way would HMAC-MD5 be "too weak"? I agree that HMAC-SHA1/=0A= SHA256 are a better proposition, but using HMAC-MD5 should be up to=0A= the implementer in any case. I've deprecated it for some years now, the=0A= minimum I'll do is HMAC-SHA1. It's not as if there's a shortage of suites= =0A= to choose from, and I've never found anything that does only -MD5 and=0A= not -SHA1.=0A= =0A= Peter.=0A= From housley@vigilsec.com Mon Feb 11 15:24:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB69521F8856 for ; Mon, 11 Feb 2013 15:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVwtdZBfSoLN for ; Mon, 11 Feb 2013 15:24:50 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id C5B3021F8849 for ; Mon, 11 Feb 2013 15:24:49 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9759A9A400E; Mon, 11 Feb 2013 18:24:50 -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 hBHL-hcL7mM4; Mon, 11 Feb 2013 18:24:25 -0500 (EST) Received: from [172.26.32.175] (65-123-3-106.dia.static.qwest.net [65.123.3.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 29CF09A4027; Mon, 11 Feb 2013 18:23:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Mon, 11 Feb 2013 17:02:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4C4B9FB4-64EB-4D32-B914-FFD0F251E1BF@vigilsec.com> References: To: "Lewis, Nick" X-Mailer: Apple Mail (2.1085) Cc: IETF TLS Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 23:24:50 -0000 >> SHA-1 is still "acceptable" for applications not related to digital = signature generation (see Table 9). >=20 > Oops Sorry I forgot that the boundary is "greater than or equal to" = the 112bit security of SHA-1 rather than just "greater than" > (It looks as if NSS have until 2030 before they need to support TLS1.2 = with HMAC-SHA256) No. That is the date that we want to complete the migration, so support = needed to be added 5 to 10 years prior to that. Russ= From mrex@sap.com Mon Feb 11 22:04:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFC521F8C16 for ; Mon, 11 Feb 2013 22:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.228 X-Spam-Level: X-Spam-Status: No, score=-10.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCmqUhCmBp07 for ; Mon, 11 Feb 2013 22:04:55 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4302421F8884 for ; Mon, 11 Feb 2013 22:04:55 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1C64n4N001983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Feb 2013 07:04:49 +0100 (MET) In-Reply-To: To: Alfredo Pironti Date: Tue, 12 Feb 2013 07:04:49 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130212060449.4C7711A53E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Upload of draft-pironti-tls-length-hiding-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 06:04:56 -0000 Alfredo Pironti wrote: > > I uploaded a draft that explains how to correctly use extra padding in > TLS to effectively hide the plaintext length. The draft proposes an > extension where length-hiding padding can be used with any cipher. > > Furthermore, by including the pad in the MAC computation, the proposed > extension fixes the notorious padding oracle attacks on TLS block > ciphers. > > The proposed extension and length-hiding mechanism are implemented in > GnuTLS 3.1.7. > > I look forward to your comments and suggestions! Since TLS implementations will likely need to support interop for the original ciphersuites and GenericBlockCipher, GenericStreamCipher and GenericAEADCipher for many years to come, I would personally prefer to keep the PDU changes to a minimum. Is there any specific benefit or necessity for the padding to be inserted before the plaintext, rather than directly trailing the plaintext? -Martin From n.mavrogiannopoulos@gmail.com Tue Feb 12 00:34:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E5621F8B4C for ; Tue, 12 Feb 2013 00:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2cpf+zLVAAU for ; Tue, 12 Feb 2013 00:33:59 -0800 (PST) Received: from mail-ee0-f48.google.com (mail-ee0-f48.google.com [74.125.83.48]) by ietfa.amsl.com (Postfix) with ESMTP id BFBFC21F8B5E for ; Tue, 12 Feb 2013 00:33:57 -0800 (PST) Received: by mail-ee0-f48.google.com with SMTP id t10so3837846eei.35 for ; Tue, 12 Feb 2013 00:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=sFpg7lh27TRN9qECb8os5rrPoQ22sdUsNr1EOtd3FtY=; b=xsa366fuIzqy5vDDP7ODv4QRiN6ge49ePzfdrbT8nMZ0fHw6+VijQR9KFylDY448ye X2UJYinTpKyap/zrTH6QQSAPWwY9Ftte+TSmRpPYMCint5O5KcwaC2ESQAtcEB895O6k w5InySLnEdV3QLCfSwuh9Kxe1BEnpWJkP4j/hLOEXAaGM7zph+ZonowEbdTfKr3RCntJ vfDRlD3A3FY9lg9AxYoID4y1g9FV/vedcvZ+t6nGh1p7AOQMLDtwlHwtExB/+x2Vwox7 Ih2H0hHilCj1qov/fd81ezr7aZVsm1CttrJfZtRT7k7bh0L9jcHKEdDQhsnHM5ZFt4tr 3urw== X-Received: by 10.14.179.5 with SMTP id g5mr60118900eem.41.1360658036834; Tue, 12 Feb 2013 00:33:56 -0800 (PST) Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id d47sm7767596eem.9.2013.02.12.00.33.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 00:33:55 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <5119FE6D.6050400@gnutls.org> Date: Tue, 12 Feb 2013 09:33:49 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 To: tls@ietf.org References: <20130212060449.4C7711A53E@ld9781.wdf.sap.corp> In-Reply-To: <20130212060449.4C7711A53E@ld9781.wdf.sap.corp> X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Upload of draft-pironti-tls-length-hiding-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 08:34:00 -0000 On 02/12/2013 07:04 AM, Martin Rex wrote: > Alfredo Pironti wrote: >> I uploaded a draft that explains how to correctly use extra padding in >> TLS to effectively hide the plaintext length. The draft proposes an >> extension where length-hiding padding can be used with any cipher. > Since TLS implementations will likely need to support interop > for the original ciphersuites and GenericBlockCipher, GenericStreamCipher > and GenericAEADCipher for many years to come, I would personally prefer > to keep the PDU changes to a minimum. > Is there any specific benefit or necessity for the padding to be inserted > before the plaintext, rather than directly trailing the plaintext? The main reason is that it is much easier to remove this padding using the current TLS parsing methods (i.e. two bytes the length, and data follow). The alternative would be to put the two length bytes at the end and the padding data would be just before that. That would require a custom parser for that packet that isn't used anywhere in TLS. regards, Nikos From omh1835@g.rit.edu Tue Feb 12 08:04:28 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D496421F8F1B for ; Tue, 12 Feb 2013 08:04:27 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu7VVx3vlpAk for ; Tue, 12 Feb 2013 08:04:27 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 27CCD21F8F16 for ; Tue, 12 Feb 2013 08:04:27 -0800 (PST) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI400MU27BDEW@smtp-server.rit.edu> for tls@ietf.org; Tue, 12 Feb 2013 11:04:26 -0500 (EST) Received: by mail-ob0-f198.google.com with SMTP id dn14so1140541obc.5 for ; Tue, 12 Feb 2013 08:04:25 -0800 (PST) Received: by 10.42.245.2 with HTTP; Tue, 12 Feb 2013 08:04:24 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr4374595igc.12.1360685064878; Tue, 12 Feb 2013 08:04:24 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr4374576igc.12.1360685064709; Tue, 12 Feb 2013 08:04:24 -0800 (PST) Date: Tue, 12 Feb 2013 19:04:24 +0300 From: "OMAR HASSAN (RIT Student)" Sender: omh1835@rit.edu To: tls@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=14dae9340b65eee6a304d5892de4 X-RIT-Received-From: 209.85.214.198 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=B10ulZGk/yeD0sxSLTkYiIENJFi6P4+NtkVSGuYcCU8=; b=eraKWkp4/sjQzE8MMmTWnklsT8g8x0RwD1HZgcZPtmJ9ETi5S8PlYRxVO5HSFThFdV wZ01QiouMhKcP0qWNxP7vAxLWaZIZlyb6YiQq11hzkQs9y21ZM3C1LJX8udfMqPqfNmM h1ngmHe4+XIEMxhLCgLgjYSZenvaiChVS3jvev/CPNRAz/W0TlazKJ9386GaKs5cxsZJ a+SlPoZTB0u22QQVvUWkjCwG9yjze7tr35lbp9gjlNjYTUPMfftz1J9ncFdRaHrBQRfh YWpVmSkvSrDWCuJJN2OyojbBR1pXpfL/9xmD9ddOEuFe6+wlQgFTAhmqFdzvLoDysTY1 bdyQ== X-Google-Sender-Auth: uqu0mvLO7TK5B5WtmajbwFTyH7Y X-Gm-Message-State: ALoCoQlJQXvfOKpQzBMkCdAXgQCSmRKXV4OHb8BQAimXzM3QnPCx/WXpD77KOBgfcv4ehK6J12xRhC1e+alXGp/Ta5ClOprs8CPoJi9o+Tlp5GyequeN6bVHYtkgFS+WxxWWs/c58N7T Subject: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2013 16:32:06 -0000 --14dae9340b65eee6a304d5892de4 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have submitted a new internet draft that aims to build a secured tunnel between the client and the server without the need to involve Certificate Authorities or any other third party in this process. it is based on the assumption that in most cases there is a registered profile for the user on the server; a profile that includes among a lot of things the username and the password that the user uses to authenticate to the server, the proposed protocol will make use of the username and the password to create a key pair for the user on the fly at the client side (inside the browser), and it will use this key pair as the starting point for creating the secured tunnel instead of taking the server certificate as the starting point. Additionally the proposed protocol has self-protection against phishing attacks. I will be appreciated if you had a look at the document and told me your thoughts about the idea. You can find the document under the following link: http://tools.ietf.org/html/draft-omar-tls-udkp-00 Thank You --14dae9340b65eee6a304d5892de4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi All,
=A0
I have submitted a new internet draft= that aims to build a secured tunnel between the client and the server with= out the need to involve Certificate Authorities or any other third party in= this process. it is based on the assumption that in most cases there is a = registered profile for the user on the server; a profile that includes amon= g a lot of things the username and the password that the user uses to authe= nticate to the server, the proposed protocol will make use of the username = and the password to create a key pair for the user on the fly at the client= side (inside the browser), and it will use this key pair as the starting p= oint for creating the secured tunnel instead of taking the server certifica= te as the=A0=A0 starting point. Additionally the proposed protocol has self= -protection against phishing attacks.

I will be appreciated if you had a look at the document and told me yo= ur thoughts about the idea. You can find the document under the following l= ink:
=A0
=A0

Thank You

--14dae9340b65eee6a304d5892de4-- From omh1835@g.rit.edu Tue Feb 12 08:32:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDBD21F8E2D for ; Tue, 12 Feb 2013 08:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.065, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRvIRg+r7+lK for ; Tue, 12 Feb 2013 08:32:55 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id C03AA21F8E3C for ; Tue, 12 Feb 2013 08:32:55 -0800 (PST) Received: from mail-ie0-f199.google.com (mail-ie0-f199.google.com [209.85.223.199]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI40018M8MUDC@smtp-server.rit.edu> for tls@ietfa.amsl.com; Tue, 12 Feb 2013 11:32:55 -0500 (EST) Received: by mail-ie0-f199.google.com with SMTP id c13so1164416ieb.10 for ; Tue, 12 Feb 2013 08:32:54 -0800 (PST) Received: by 10.42.245.2 with HTTP; Tue, 12 Feb 2013 08:32:54 -0800 (PST) X-Received: by 10.50.7.204 with SMTP id l12mr4447999iga.103.1360686774336; Tue, 12 Feb 2013 08:32:54 -0800 (PST) X-Received: by 10.50.7.204 with SMTP id l12mr4447984iga.103.1360686774217; Tue, 12 Feb 2013 08:32:54 -0800 (PST) Date: Tue, 12 Feb 2013 19:32:54 +0300 From: "OMAR HASSAN (RIT Student)" Sender: omh1835@rit.edu To: tls@ietfa.amsl.com Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=f46d04446b0bd3ead904d58993a4 X-RIT-Received-From: 209.85.223.199 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type:x-gm-message-state; bh=4TA7vSY5ap/3B9ecGyMYnIJC/cZ+bdh7UIdthFGLoT0=; b=WCzgoiAE4wS/f+3lc5Say67Ykb06G+EaC9n96ByTHd7WTScb6gTi11hvFijye6X6D1 YOlMMp0bKDb8PJAJH6UNc/BHDGVgmZnJ1k8k73x7zjTxDiPttBXKzaBcsgHF+Zupbh/X bIg53M+0Q1TR1hSHoLmRshbSHWqKAnPFSw9btR+2hTZLtxObPSnFWJ7Ngx3QIfKvNwVw oVIBgrEcLOhjTWqo+ElOdHk84v+yGxBCqYQyOKKHYVYFe1WFzUQ2aVyKh1UlZaDfVZQF qhigzUdkGrd4nFiFs37KjIR4YKv1rvOCBiZJYCz19PchwxmoN9QM/NLNsSIfIqtN0Nm4 GCOg== X-Google-Sender-Auth: wWaEpi7FgRsUv1UIr_L-VbUzK-g X-Gm-Message-State: ALoCoQmjZq0LitC86/rHUjyazc02NPG1mmWgQ/UsvOiuUAbGGrYtbNzEfMUiUVPvaw9UYSE8jYCdIaLND1GIa6hiDVaghl93ohafkBEI0Ixg6bWBV6EF03iFmVWyK8oirF/eaEf/Nc7AI/oCvHipODxJjTYE8Mt+Pw== Subject: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2013 16:32:56 -0000 --f46d04446b0bd3ead904d58993a4 Content-Type: text/plain; charset=ISO-8859-1 --f46d04446b0bd3ead904d58993a4 Content-Type: text/html; charset=ISO-8859-1
--f46d04446b0bd3ead904d58993a4-- From housley@vigilsec.com Tue Feb 12 11:02:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08F21F90CF for ; Tue, 12 Feb 2013 11:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1+KDGv0XP-d for ; Tue, 12 Feb 2013 11:02:06 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9093021F90E5 for ; Tue, 12 Feb 2013 11:02:05 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 8C8459A4007; Tue, 12 Feb 2013 14:02:18 -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 ZTSgrRdwD40C; Tue, 12 Feb 2013 14:01:31 -0500 (EST) Received: from [64.170.98.199] (unknown [64.170.98.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 632179A4005; Tue, 12 Feb 2013 14:02:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-157-136426607 From: Russ Housley In-Reply-To: Date: Tue, 12 Feb 2013 14:01:55 -0500 Message-Id: References: To: OMAR HASSAN (RIT Student) X-Mailer: Apple Mail (2.1085) Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2013 19:02:07 -0000 --Apple-Mail-157-136426607 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Doesn't the use of DANE to authenticate the public key of the server = make this a much stronger solution? Russ On Feb 12, 2013, at 11:04 AM, OMAR HASSAN (RIT Student) wrote: > Hi All, > =20 > I have submitted a new internet draft that aims to build a secured = tunnel between the client and the server without the need to involve = Certificate Authorities or any other third party in this process. it is = based on the assumption that in most cases there is a registered profile = for the user on the server; a profile that includes among a lot of = things the username and the password that the user uses to authenticate = to the server, the proposed protocol will make use of the username and = the password to create a key pair for the user on the fly at the client = side (inside the browser), and it will use this key pair as the starting = point for creating the secured tunnel instead of taking the server = certificate as the starting point. Additionally the proposed protocol = has self-protection against phishing attacks. >=20 > I will be appreciated if you had a look at the document and told me = your thoughts about the idea. You can find the document under the = following link: > =20 > http://tools.ietf.org/html/draft-omar-tls-udkp-00 > =20 > Thank You >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-157-136426607 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Hi All,
 
I have submitted = a new internet draft that aims to build a secured tunnel between the = client and the server without the need to involve Certificate = Authorities or any other third party in this process. it is based on the = assumption that in most cases there is a registered profile for the user = on the server; a profile that includes among a lot of things the = username and the password that the user uses to authenticate to the = server, the proposed protocol will make use of the username and the = password to create a key pair for the user on the fly at the client side = (inside the browser), and it will use this key pair as the starting = point for creating the secured tunnel instead of taking the server = certificate as the   starting point. Additionally the proposed = protocol has self-protection against phishing attacks.

I will be appreciated if you had a look at the document and told me = your thoughts about the idea. You can find the document under the = following link:
 
 

Thank You

_______________________________________________
TLS mailing = list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls

= --Apple-Mail-157-136426607-- From omh1835@g.rit.edu Tue Feb 12 12:42:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B4C21F8B69 for ; Tue, 12 Feb 2013 12:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.933 X-Spam-Level: X-Spam-Status: No, score=-2.933 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAkZaaG5NVAk for ; Tue, 12 Feb 2013 12:42:14 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id A061121F8B66 for ; Tue, 12 Feb 2013 12:42:14 -0800 (PST) Received: from mail-ia0-f200.google.com (mail-ia0-f200.google.com [209.85.210.200]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI4005YXK6CK1@smtp-server.rit.edu> for tls@ietf.org; Tue, 12 Feb 2013 15:42:13 -0500 (EST) Received: by mail-ia0-f200.google.com with SMTP id o25so1497666iad.3 for ; Tue, 12 Feb 2013 12:42:12 -0800 (PST) Received: by 10.42.245.2 with HTTP; Tue, 12 Feb 2013 12:42:11 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr6283357igc.12.1360701732246; Tue, 12 Feb 2013 12:42:12 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr6283337igc.12.1360701732069; Tue, 12 Feb 2013 12:42:12 -0800 (PST) Date: Tue, 12 Feb 2013 12:42:11 -0800 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu To: Russ Housley Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=14dae9340b6562a2b904d58d0f45 X-RIT-Received-From: 209.85.210.200 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:in-reply-to:references :date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=h/GzWbugyT0PnqNqOT8M4dyCAiO5olaKKrkOqpHbVCg=; b=Z4wV4wLiT2cENi1RUhMtmXhqCwyDumcdbGVgiyp7nQGNGuUM/G/9N43TYjOki1WV3q f+xFAz3m48W6d9wFPhmFz1gtedxsZlcvCGSGHwWVY7jYDQmwtFKeSUPxc3VKrEHzwFZs nvSkBhs2AoqVP+gqWzcwWDYth9Kc0P3pZQ+AYUA9xkiGG7JuGvJcHQX4Wl0mXfyWNJcs CDDdrGL1Txjc4Mof3ZZhXKMEoHYAOH9a6V916nWvvlfGvfLiK+DrKALPFddfgQp6aQJD PxU+248M4OwYV/OU/0D0VaUgnAK/WT+74LJV1puQqBfBL4E7X8JnLOLkKd+7XVyovVUJ yfEg== X-Google-Sender-Auth: RDFmCfc2Kl9KmhNPQqLLnp2pHnk X-Gm-Message-State: ALoCoQkGLCHdXbajuxq8tHxxm9A05rsEq7kXvi5nXrbawzr72oESyIVs2aDBJKJzWeO37P1xWTE1dNFi4e8XqhmL6IWbvEce8NPdPeDNLBQJRy+DFTM4WB0LmPRYzNYvCGRyMvIZ2Z4v References: Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 12 Feb 2013 20:42:15 -0000 --14dae9340b6562a2b904d58d0f45 Content-Type: text/plain; charset=ISO-8859-1 Hi Russ, Thank you for being interesting in the draft. When I start thinking in that approach, I was highly motivated by the desire to achieve my golden goal; to make the security of my connection to my internet bank is the ultimate responsibility of me and my internet bank not anyone else. In the original implementation of the TLS my connection is as secure as all Certificate Authorities that are trusted by my browser. If any of those CAs betrayed this trust relationship either intentionally or by being attacked or even by any insider employee, my connection to my internet bank will be at risk, so my connection security depends on hundreds or may be thousands factors that are outside the control of me and my internet bank as the communication parties. This is the philosophy behind my idea. Many workarounds that have been discussed to reduce the risk of this issue, but they couldn't achieve my golden goal for being independent on any third party. Of those attempts are: Certification Authority Authorization (CAA) , and DNS-based Authentication of Named Entities (DANE). These approaches are DNS based and can prevent any untrustworthy signer from compromising anyone's keys except those in their own sub domains, but unfortunately domains security are based on the security of the DNSSEC; which means these approaches are vulnerable to the DNS keys integrity corruption if the registrar for that domain compromised, so registrars still have the power theoretically to abuse their position because they're responsible for your communication to the root servers. So for dane, instead of being dependent on the security of Certificate Authorities, you will be dependent on the security of the domain registrars. I hope I was able to clear my point, and feel free to ask if you need more explanation of any of the above. On Tue, Feb 12, 2013 at 10:01 PM, Russ Housley wrote: > Doesn't the use of DANE to authenticate the public key of the server make > this a much stronger solution? > > Russ > > > On Feb 12, 2013, at 11:04 AM, OMAR HASSAN (RIT Student) wrote: > > Hi All, > > I have submitted a new internet draft that aims to build a secured tunnel > between the client and the server without the need to involve Certificate > Authorities or any other third party in this process. it is based on the > assumption that in most cases there is a registered profile for the user on > the server; a profile that includes among a lot of things the username and > the password that the user uses to authenticate to the server, the proposed > protocol will make use of the username and the password to create a key > pair for the user on the fly at the client side (inside the browser), and > it will use this key pair as the starting point for creating the secured > tunnel instead of taking the server certificate as the starting point. > Additionally the proposed protocol has self-protection against phishing > attacks. > I will be appreciated if you had a look at the document and told me your > thoughts about the idea. You can find the document under the following link: > > http://tools.ietf.org/html/draft-omar-tls-udkp-00 > > > Thank You > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --14dae9340b6562a2b904d58d0f45 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Russ,

Thank you for being= interesting in the draft.=A0

When I start thinkin= g in that approach, I was highly motivated by the desire to achieve my gold= en goal; to make the security of my connection to my internet bank is the u= ltimate responsibility of me and my internet bank not anyone else. In the o= riginal implementation of the TLS my connection is as secure as all Certifi= cate Authorities that are trusted by my browser. If any of those CAs betray= ed this trust relationship either intentionally or by being attacked or eve= n by any insider employee, my connection to my internet bank will be at ris= k, so my connection security depends on hundreds or may be thousands factor= s that are outside the control of me and my internet bank as the communicat= ion parties. This is the=A0philosophy behind my idea.

Many=A0workarounds=A0that have been discussed to reduce= the risk of this issue, but they=A0couldn't=A0achieve my golden goal f= or being independent on any third party. Of those attempts are: Certificati= on Authority Authorization (CAA) , and=A0DNS-based Authentication of Named Entities (DANE).=A0These approaches are DNS based and can= prevent any untrustworthy signer from compromising anyone's keys excep= t those in their own sub domains, but unfortunately domains security are ba= sed on the security of the DNSSEC; which means these approaches are vulnera= ble to the DNS keys integrity corruption if the registrar for that domain c= ompromised, so registrars still have the power theoretically to abuse their= position because they're responsible for your communication to the roo= t servers.

So for dane, instead of being dependent on the security of Certificate= Authorities, you will be dependent on the security of the domain registrar= s.=A0

=
I hope I was able to clear my point, and=A0feel free to ask if you need more expl= anation of any of the=A0above= .



On Tue, Feb 12= , 2013 at 10:01 PM, Russ Housley <housley@vigilsec.com> w= rote:
Doesn't the use of DANE to authenticate the public key of the server = make this a much stronger solution?

Russ

On Feb 12, 2013, at 11:04 AM, OMAR HASSAN (RIT Student) wrote:=

Hi All,
=A0
I have submitted a new internet draft that aims to bui= ld a secured tunnel between the client and the server without the need to i= nvolve Certificate Authorities or any other third party in this process. it= is based on the assumption that in most cases there is a registered profil= e for the user on the server; a profile that includes among a lot of things= the username and the password that the user uses to authenticate to the se= rver, the proposed protocol will make use of the username and the password = to create a key pair for the user on the fly at the client side (inside the= browser), and it will use this key pair as the starting point for creating= the secured tunnel instead of taking the server certificate as the=A0=A0 s= tarting point. Additionally the proposed protocol has self-protection again= st phishing attacks.

I will be appreciated if you had a look at the document and told me yo= ur thoughts about the idea. You can find the document under the following l= ink:
=A0
=A0

Thank You

_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls


--14dae9340b6562a2b904d58d0f45-- From housley@vigilsec.com Tue Feb 12 20:49:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFDC21F89D8 for ; Tue, 12 Feb 2013 20:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXr1KTdQ+AmG for ; Tue, 12 Feb 2013 20:49:03 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 588CA21F8950 for ; Tue, 12 Feb 2013 20:49:03 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id AB17B9A4007; Tue, 12 Feb 2013 23:49:11 -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 ma4mmx4wa+Mj; Tue, 12 Feb 2013 23:49:01 -0500 (EST) Received: from [192.168.4.175] (ip-64-134-226-216.public.wayport.net [64.134.226.216]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 03F9B9A4005; Tue, 12 Feb 2013 23:49:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-188-171647140 From: Russ Housley In-Reply-To: Date: Tue, 12 Feb 2013 23:48:56 -0500 Message-Id: References: To: "OMAR HASSAN (RIT Student)" X-Mailer: Apple Mail (2.1085) Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 04:49:04 -0000 --Apple-Mail-188-171647140 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Omar: > So for dane, instead of being dependent on the security of Certificate = Authorities, you will be dependent on the security of the domain = registrars.=20 You cannot avoid that dependency. The DNS provides the IP address for = the server. The admin at the bank needs to make sure the right IP = address is in the DNS, and it is not a big additional burden to include = the public key of that server at the same time. This adds no further = trust relationships than are needed to get the IP address in the first = place. Russ --Apple-Mail-188-171647140 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
So for = dane, instead of being dependent on the security of Certificate = Authorities, you will be dependent on the security of the domain = registrars. 

Yo= u cannot avoid that dependency.  The DNS provides the IP address = for the server.  The admin at the bank needs to make sure the right = IP address is in the DNS, and it is not a big additional burden to = include the public key of that server at the same time.  This adds = no further trust relationships than are needed to get the IP address in = the first place.

Russ

= --Apple-Mail-188-171647140-- From peter.sylvester@edelweb.fr Tue Feb 12 22:56:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7212121F8A71 for ; Tue, 12 Feb 2013 22:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hilRIiiJsdiB for ; Tue, 12 Feb 2013 22:56:44 -0800 (PST) Received: from mx1.on-x.com (mx1.on-x.com [92.103.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id AA7E321F8A69 for ; Tue, 12 Feb 2013 22:56:43 -0800 (PST) Received: from mx1.on-x.com (localhost [127.0.0.1]) by mx1.on-x.com (Postfix) with ESMTP id 4957F5E0F8 for ; Wed, 13 Feb 2013 07:55:40 +0100 (CET) Received: from mail1.on-x.com (mail1.on-x.com [192.168.10.66]) by mx1.on-x.com (Postfix) with ESMTP id 2F0105E08E for ; Wed, 13 Feb 2013 07:55:40 +0100 (CET) Received: from mail1.on-x.com (localhost [127.0.0.1]) by mail1.on-x.com (Postfix) with ESMTP id E7C325E13C for ; Wed, 13 Feb 2013 07:55:38 +0100 (CET) Received: from smtps.on-x.com (imaps.on-x.com [192.168.14.34]) by mail1.on-x.com (Postfix) with ESMTP id D1F955E0A5 for ; Wed, 13 Feb 2013 07:55:38 +0100 (CET) Received: from [192.168.0.37] (unknown [82.227.163.182]) by smtps.on-x.com (Postfix) with ESMTPSA id D5BB15E17A for ; Wed, 13 Feb 2013 07:55:19 +0100 (CET) Message-ID: <511B3927.5070106@edelweb.fr> Date: Wed, 13 Feb 2013 07:56:39 +0100 From: Peter Sylvester User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030305020800010201010006" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 06:56:44 -0000 This is a multi-part message in MIME format. --------------030305020800010201010006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/13/2013 05:48 AM, Russ Housley wrote: > Omar: > >> So for dane, instead of being dependent on the security of Certificate Authorities, you will be >> dependent on the security of the domain registrars. > > You cannot avoid that dependency. The DNS provides the IP address for the server. The admin at > the bank needs to make sure the right IP address is in the DNS, and it is not a big additional > burden to include the public key of that server at the same time. This adds no further trust > relationships than are needed to get the IP address in the first place. > rfc 5054 also does (real) mutual authentication without need of certificates local (client) trust base. --------------030305020800010201010006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/13/2013 05:48 AM, Russ Housley wrote:
Omar:

So for dane, instead of being dependent on the security of Certificate Authorities, you will be dependent on the security of the domain registrars. 

You cannot avoid that dependency.  The DNS provides the IP address for the server.  The admin at the bank needs to make sure the right IP address is in the DNS, and it is not a big additional burden to include the public key of that server at the same time.  This adds no further trust relationships than are needed to get the IP address in the first place.


rfc 5054 also does (real) mutual authentication
without need of certificates local (client) trust base.


--------------030305020800010201010006-- From pgut001@cs.auckland.ac.nz Wed Feb 13 04:36:20 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4A521F85EB for ; Wed, 13 Feb 2013 04:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LI8+Bc5sNm5V for ; Wed, 13 Feb 2013 04:36:19 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5D36E21F8614 for ; Wed, 13 Feb 2013 04:36:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1360758979; x=1392294979; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=VXTMqPPw/eiYUlHhda6RSlu8FkB/P9IT05BSgSyBE64=; b=SyseDfspz0QVYCYINglQGB8sqKTixgsX/JT+1Jkfx6Ihh12JF/0kfRHl 2P5ibTgWuPyYvSDtPa9Lk9bY9szlFO9/N9diuh3gohnBP/kT984k6ylyD JlSLXkmk215fGh7dzu+foMyfdf+SKpFgObtA0TrylU1AztqQByqJqCqFY 0=; X-IronPort-AV: E=Sophos;i="4.84,657,1355050800"; d="scan'208";a="170350278" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Feb 2013 01:36:17 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 01:36:17 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Certificate Authorities are not required anymore Thread-Index: Ac4J5rfaR7zeCPHvTHKJ/NLLkcr1IA== Date: Wed, 13 Feb 2013 12:36:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7333407720@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 12:36:20 -0000 "OMAR HASSAN (RIT Student)" writes:=0A= =0A= >it is based on the assumption that in most cases there is a registered=0A= >profile for the user on the server; a profile that includes among a lot of= =0A= >things the username and the password that the user uses to authenticate to= =0A= >the server, the proposed protocol will make use of the username and the=0A= >password to create a key pair for the user on the fly at the client side= =0A= >(inside the browser), and it will use this key pair as the starting point = for=0A= >creating the secured tunnel instead of taking the server certificate as th= e=0A= >starting point. Additionally the proposed protocol has self-protection=0A= >against phishing attacks.=0A= =0A= How does this improve on TLS-SRP and TLS-PSK, which already do the same thi= ng?=0A= =0A= Peter.=0A= From omh1835@g.rit.edu Wed Feb 13 07:47:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3FF21F86D9 for ; Wed, 13 Feb 2013 07:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.032, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v4YqXJeVB30 for ; Wed, 13 Feb 2013 07:47:23 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4641E21F861F for ; Wed, 13 Feb 2013 07:47:17 -0800 (PST) Received: from mail-ob0-f199.google.com (mail-ob0-f199.google.com [209.85.214.199]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI6004PJ16RGE@smtp-server.rit.edu> for tls@ietf.org; Wed, 13 Feb 2013 10:47:16 -0500 (EST) Received: by mail-ob0-f199.google.com with SMTP id wd20so6761511obb.6 for ; Wed, 13 Feb 2013 07:47:15 -0800 (PST) Received: by 10.42.245.2 with HTTP; Wed, 13 Feb 2013 07:47:14 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr11956387igc.12.1360770435285; Wed, 13 Feb 2013 07:47:15 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr11956361igc.12.1360770435110; Wed, 13 Feb 2013 07:47:15 -0800 (PST) Date: Wed, 13 Feb 2013 07:47:14 -0800 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu To: Russ Housley Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=14dae9340b6567daef04d59d0e2f X-RIT-Received-From: 209.85.214.199 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:in-reply-to:references :date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=xcbO7x05JwLAFm/dCPTEqdibBR8uWTwz/83MaMk+384=; b=c6DQgTYd1d8vn8pS9KNG4elrGG6fO+E8WkM94Dgo4Xuyvr1rk1poBpe+gvJ7njV2lk ho0wp62YZg+7ebS/0Nzm51ogUbxojPqsqfIp9YqofFFxQl7wWkgeyWQeU+AhE9yMmZ/4 cC2AjDHjg6G1KB3TaEWiFYEzDelIn0lN3YTmPmKiYLFALCVGQ+SAV4KYYWjoq/jV5CzY G/pxXrS/P9HIAJzGcWnux7ZTAGgKf1BsERf8Ey3OiPRJNyB0h+zavtTjLE3/UZLudaIz SnRCKsTemYtIo1kL+pLb0xJeQErQ2bReedmAZHnAa5llnuzLfliKlAyzapjbM0KZs8l9 VXdw== X-Google-Sender-Auth: 0pcNXji4TNJWSsFPgDki7KB9Nmg X-Gm-Message-State: ALoCoQn7bW8MJX6lUvEoFDkMSGBzHv1b02+Z5es0BvRVOaDgH2cW6Y0rcOOwTGiSZm+ujODTRpDI/HDPlxxYJzobxLKXutuU42uMrVqxVLAuC7KIyOURp1y2Z74Zup/Fyml8gj/HAtQi References: Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 15:47:24 -0000 --14dae9340b6567daef04d59d0e2f Content-Type: text/plain; charset=ISO-8859-1 Russ : You cannot avoid that dependency. Actually that what I am trying to prove with my draft; that we can completely avoid forcing e-business applications to have trust relationships with domain registrars, certificate authorities, or any other third party. The root cause that fails the current TLS implementation to achieve the expected security protection even after using dane, is that the client encrypts the premaster secret using the server certificate it receives from someone who claims to be the server; this claim is supported by the attestation of a third party; the third party could be CA, or Domain Registrar, and the e-business is as secure as this relationship to the third party is trusted. the new approach is based on benefiting from the existing account for the user on the server (internet bank) by reversing the TLS process, the server will receive a message from the client signed by the user private key, and he doesn't have to validate the signed message from any third party as it has the related public key as a part of the user account, and then the server will use that public key to encrypt the premaster and send it to the client who will read it using its private key. For the sake of demonstrating the functionality and proofing the concept behind UDKP protocol, I have made a simple implementation for the proposed protocol. In this implementation I have modified the TLS implementation to reflect the new changes in the handshake messages. I have not written any application from scratch for this proof of concept; instead, I have modified On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley wrote: > Omar: > > So for dane, instead of being dependent on the security of Certificate > Authorities, you will be dependent on the security of the domain > registrars. > > > You cannot avoid that dependency. The DNS provides the IP address for the > server. The admin at the bank needs to make sure the right IP address is > in the DNS, and it is not a big additional burden to include the public key > of that server at the same time. This adds no further trust relationships > than are needed to get the IP address in the first place. > > Russ > > --14dae9340b6567daef04d59d0e2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Russ :

You cannot avoid that= dependency.


Actually that what I am try= ing to prove with my draft; that we can completely avoid forcing e-business= applications to have trust relationships with domain registrars, certifica= te authorities, or any other third party.

The root cause that fails the current TLS implementation to = achieve the expected security protection even after using dane, is that the= client encrypts the premaster secret using the server certificate it recei= ves from someone who claims to be the server; this claim is supported by th= e attestation of a third party; the third party could be CA, or Domain Regi= strar, and the e-business is as secure as this relationship to the third pa= rty is trusted.

the new approach is based on benefiting from the existi= ng account for the user on the server (internet bank) by reversing the TLS = process, the server will receive a message from the client=A0signed by the = user private key, and he doesn't have to validate the signed message fr= om any third party as it has the related public key as a part of the user a= ccount, and then the server will use that public key to encrypt the premast= er and send it to the client who will read it using its private key.

For the sake of demonstrating the functionality and pro= ofing the concept behind UDKP protocol, I have made a simple implementation= for the proposed protocol. In this implementation I have modified the TLS = implementation to reflect the new changes in the handshake messages.=A0I ha= ve not written any application from scratch for this proof of concept; inst= ead, I have modified=A0



On Wed, Feb 13,= 2013 at 7:48 AM, Russ Housley <housley@vigilsec.com> wro= te:
Omar:

So for da= ne, instead of being dependent on the security of Certificate Authorities, = you will be dependent on the security of the domain registrars.=A0

You cannot avoid that dependency. = =A0The DNS provides the IP address for the server. =A0The admin at the bank= needs to make sure the right IP address is in the DNS, and it is not a big= additional burden to include the public key of that server at the same tim= e. =A0This adds no further trust relationships than are needed to get the I= P address in the first place.

Russ


--14dae9340b6567daef04d59d0e2f-- From omh1835@g.rit.edu Wed Feb 13 07:48:55 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDD21F8758 for ; Wed, 13 Feb 2013 07:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.026, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arqwfvHj4rgF for ; Wed, 13 Feb 2013 07:48:54 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id E1F0F21F86E8 for ; Wed, 13 Feb 2013 07:48:53 -0800 (PST) Received: from mail-oa0-f71.google.com (mail-oa0-f71.google.com [209.85.219.71]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI600KW419FKO@smtp-server.rit.edu> for tls@ietf.org; Wed, 13 Feb 2013 10:48:52 -0500 (EST) Received: by mail-oa0-f71.google.com with SMTP id o6so6987615oag.6 for ; Wed, 13 Feb 2013 07:48:51 -0800 (PST) Received: by 10.42.245.2 with HTTP; Wed, 13 Feb 2013 07:48:51 -0800 (PST) X-Received: by 10.50.222.226 with SMTP id qp2mr12014481igc.103.1360770531216; Wed, 13 Feb 2013 07:48:51 -0800 (PST) X-Received: by 10.50.222.226 with SMTP id qp2mr12014468igc.103.1360770531105; Wed, 13 Feb 2013 07:48:51 -0800 (PST) Date: Wed, 13 Feb 2013 07:48:51 -0800 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu To: Russ Housley Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=14dae934089d209bb404d59d14cb X-RIT-Received-From: 209.85.219.71 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:in-reply-to:references :date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=zE/6/iejRbov4TP5fMbFDIo5v3xkzaJZZRY0StUbBCc=; b=mJsR41QTq3PD3Mm0oEk9hMKhnJWk5hmeIhfE0yIvMk+0zn802D0CCtPi/hmT/1dbjq NIhCkr4WVM8ozVvK/o16ChRtcNZN5hv8kdGnInXWFlPCRx7TYAfFy0GP+rfTxOz5Nq0s 5qILIQOIEbBHl2TeaRA6+Ozd27D/0o2WSOHMsp3wR5JzLJD1TY8aCXpwZLz0F6GlqHxM XukFnSjcuM4o/FpAcTdOlkhA0JS5O3Ca9pPLfFIBFwf2CTgJLWSeFEQ0gcLakofL8GfA 5WsjFIxDHXFMr4yPv4ftUAoZSYwgHr3WPciJ5ByMS5ZJ64YCJRV4uxx1yrOAMfXa1B+v n7dw== X-Google-Sender-Auth: U3bkpe5LmsHVMVz86URsBW-NFEM X-Gm-Message-State: ALoCoQlVnzcVDgNgRtc6UpRvlmL2ae8HW/W/HC9HcveBeO+jjAbGwEHyLJa0k9l181uFSlStk0sk6haBH8Gak6OiYTQ7FI8uT5DNndAGRAkUvVU77QOKi/0xS8QXXs+T1gTTY8LyPDEc References: Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 15:48:55 -0000 --14dae934089d209bb404d59d14cb Content-Type: text/plain; charset=ISO-8859-1 Russ : You cannot avoid that dependency. Actually that what I am trying to prove with my draft; that we can completely avoid forcing e-business applications to have trust relationships with domain registrars, certificate authorities, or any other third party. The root cause that fails the current TLS implementation to achieve the expected security protection even after using dane, is that the client encrypts the premaster secret using the server certificate it receives from someone who claims to be the server; this claim is supported by the attestation of a third party; the third party could be CA, or Domain Registrar, and the e-business is as secure as this relationship to the third party is trusted. the new approach is based on benefiting from the existing account for the user on the server (internet bank) by reversing the TLS process, the server will receive a message from the client signed by the user private key, and he doesn't have to validate the signed message from any third party as it has the related public key as a part of the user account, and then the server will use that public key to encrypt the premaster and send it to the client who will read it using its private key. For the sake of demonstrating the functionality and proofing the concept behind UDKP protocol, I have made a simple implementation for the proposed protocol. In this implementation I have modified the TLS implementation to reflect the new changes in the handshake messages. I have not written any application from scratch for this proof of concept; instead, I have modified the following open source applications: 1. Tomcat 7 application server (open source written in java). 2. Lobo web browser (open source written in java). 3. OpenJDK Java Run Time Environment 6 (open source written in java). 4. JForum web application (open source forum written in java). On Wed, Feb 13, 2013 at 7:47 AM, OMAR HASSAN (RIT Student) wrote: > Russ : > > You cannot avoid that dependency. > > > Actually that what I am trying to prove with my draft; that we can > completely avoid forcing e-business applications to have trust > relationships with domain registrars, certificate authorities, or any other > third party. > > The root cause that fails the current TLS implementation to achieve the > expected security protection even after using dane, is that the client > encrypts the premaster secret using the server certificate it receives from > someone who claims to be the server; this claim is supported by the > attestation of a third party; the third party could be CA, or Domain > Registrar, and the e-business is as secure as this relationship to the > third party is trusted. > > the new approach is based on benefiting from the existing account for the > user on the server (internet bank) by reversing the TLS process, the server > will receive a message from the client signed by the user private key, and > he doesn't have to validate the signed message from any third party as it > has the related public key as a part of the user account, and then the > server will use that public key to encrypt the premaster and send it to the > client who will read it using its private key. > > For the sake of demonstrating the functionality and proofing the concept > behind UDKP protocol, I have made a simple implementation for the proposed > protocol. In this implementation I have modified the TLS implementation to > reflect the new changes in the handshake messages. I have not written any > application from scratch for this proof of concept; instead, I have > modified > > > > On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley wrote: > >> Omar: >> >> So for dane, instead of being dependent on the security of Certificate >> Authorities, you will be dependent on the security of the domain >> registrars. >> >> >> You cannot avoid that dependency. The DNS provides the IP address for >> the server. The admin at the bank needs to make sure the right IP address >> is in the DNS, and it is not a big additional burden to include the public >> key of that server at the same time. This adds no further trust >> relationships than are needed to get the IP address in the first place. >> >> Russ >> >> > --14dae934089d209bb404d59d14cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Russ :

You cannot avoid that dependency.

<= /div>

Actually that what I am trying to prove with my dr= aft; that we can completely avoid forcing e-business applications to have t= rust relationships with domain registrars, certificate authorities, or any = other third party.

The root cause that fails the current TLS implementatio= n to achieve the expected security protection even after using dane, is tha= t the client encrypts the premaster secret using the server certificate it = receives from someone who claims to be the server; this claim is supported = by the attestation of a third party; the third party could be CA, or Domain= Registrar, and the e-business is as secure as this relationship to the thi= rd party is trusted.

the new approach is based on benefiting from the existi= ng account for the user on the server (internet bank) by reversing the TLS = process, the server will receive a message from the client signed by the us= er private key, and he doesn't have to validate the signed message from= any third party as it has the related public key as a part of the user acc= ount, and then the server will use that public key to encrypt the premaster= and send it to the client who will read it using its private key.

For the sake of demonstrating the functionality and pro= ofing the concept behind UDKP protocol, I have made a simple implementation= for the proposed protocol. In this implementation I have modified the TLS = implementation to reflect the new changes in the handshake messages. I have= not written any application from scratch for this proof of concept; instea= d, I have modified the following open source applications:

1. Tomcat 7 application server (open source written in java).=
2. Lobo web browser (open source written in java).
3. Ope= nJDK Java Run Time Environment 6 (open source written in java).
4= . JForum we= b application (open source forum written in java).



On Wed, = Feb 13, 2013 at 7:47 AM, OMAR HASSAN (RIT Student) <omh1835@rit.edu><= /span> wrote:
Russ :

You cannot avoid that dependency.

Actually that what I am trying to prove with my draft;= that we can completely avoid forcing e-business applications to have trust= relationships with domain registrars, certificate authorities, or any othe= r third party.

The root cause that fails the current TLS implementation to = achieve the expected security protection even after using dane, is that the= client encrypts the premaster secret using the server certificate it recei= ves from someone who claims to be the server; this claim is supported by th= e attestation of a third party; the third party could be CA, or Domain Regi= strar, and the e-business is as secure as this relationship to the third pa= rty is trusted.

the new approach is based on benefiting from the existi= ng account for the user on the server (internet bank) by reversing the TLS = process, the server will receive a message from the client=A0signed by the = user private key, and he doesn't have to validate the signed message fr= om any third party as it has the related public key as a part of the user a= ccount, and then the server will use that public key to encrypt the premast= er and send it to the client who will read it using its private key.

For the sake of demonstrating the functionality and pro= ofing the concept behind UDKP protocol, I have made a simple implementation= for the proposed protocol. In this implementation I have modified the TLS = implementation to reflect the new changes in the handshake messages.=A0I ha= ve not written any application from scratch for this proof of concept; inst= ead, I have modified=A0



On Wed, Feb 13,= 2013 at 7:48 AM, Russ Housley <housley@vigilsec.com> wro= te:
Omar:

So for da= ne, instead of being dependent on the security of Certificate Authorities, = you will be dependent on the security of the domain registrars.=A0

You cannot avoid that dependency. = =A0The DNS provides the IP address for the server. =A0The admin at the bank= needs to make sure the right IP address is in the DNS, and it is not a big= additional burden to include the public key of that server at the same tim= e. =A0This adds no further trust relationships than are needed to get the I= P address in the first place.

Russ



--14dae934089d209bb404d59d14cb-- From piyush@ditenity.com Wed Feb 13 08:49:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17421F8A7E for ; Wed, 13 Feb 2013 08:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHzFYLqG2G9Y for ; Wed, 13 Feb 2013 08:49:19 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3B78421F8996 for ; Wed, 13 Feb 2013 08:49:16 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so1458867obb.1 for ; Wed, 13 Feb 2013 08:49:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language:x-gm-message-state; bh=F1biPkOhfIcOMr1PZGMzKtZ4atxdoKQbO56kAnvxR5I=; b=Wl2acyectEtyvqDtznu7Hs0IOj2vRRNBwf/eMj4kk+yqrVfXCEmgPWW/7xgrV7ccuA HyemphnlTDZxpS1UNuflSjJ4qU/SKeadK2dmZIba5CidMXC4P6Z/QfSXSEkY/kTvseh+ 1C5AjkrBUI9tQASbNpfxAYm0C/65FgOnOZEQKuPcgdHTtEF4FHjVlNGLhZ7IrHC/mBog UWLmGJWig/vEpNGl+pS8Uy8zxDs/UAdD6vnXg5PWHxgzAmM2eGVaqMaULfjsRQA1nDVS 4W0Hqbnx9N4i+2VTr+jT0vOa8aDyzZJsZ3l9ohvF0JlKx3hDbQL31e5+sb/owU8j8vv+ MJug== X-Received: by 10.182.127.47 with SMTP id nd15mr16682704obb.11.1360774155507; Wed, 13 Feb 2013 08:49:15 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id p2sm57374684obb.6.2013.02.13.08.49.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 13 Feb 2013 08:49:14 -0800 (PST) From: "Piyush Jain" To: "'OMAR HASSAN \(RIT Student\)'" , "'Russ Housley'" References: In-Reply-To: Date: Wed, 13 Feb 2013 08:49:12 -0800 Message-ID: <005401ce0a0a$0e3f4020$2abdc060$@ditenity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01CE09C7.001E7120" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwxbKvUmF81N+v3ruJiEmZo81eZgFdgZPEAuhyaIgBOHBhqAFemcKqAbg6/BqXbd1MoA== Content-Language: en-us X-Gm-Message-State: ALoCoQlHdmAtzWxMoIiGDdJiS95HUyvbXOyxulPDKyhawMYphqna2yBWitFBMuuRpVLZIWrUcZ53 Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 16:49:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01CE09C7.001E7120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit How does the user public key gets to the server? Out of band? The registration part of your specification is the problem. The client cannot register its public key safely with the server because it has no way of knowing that it is talking to the right server. -Piyush From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of OMAR HASSAN (RIT Student) Sent: Wednesday, February 13, 2013 7:49 AM To: Russ Housley Cc: tls@ietf.org Subject: Re: [TLS] Certificate Authorities are not required anymore Russ : You cannot avoid that dependency. Actually that what I am trying to prove with my draft; that we can completely avoid forcing e-business applications to have trust relationships with domain registrars, certificate authorities, or any other third party. The root cause that fails the current TLS implementation to achieve the expected security protection even after using dane, is that the client encrypts the premaster secret using the server certificate it receives from someone who claims to be the server; this claim is supported by the attestation of a third party; the third party could be CA, or Domain Registrar, and the e-business is as secure as this relationship to the third party is trusted. the new approach is based on benefiting from the existing account for the user on the server (internet bank) by reversing the TLS process, the server will receive a message from the client signed by the user private key, and he doesn't have to validate the signed message from any third party as it has the related public key as a part of the user account, and then the server will use that public key to encrypt the premaster and send it to the client who will read it using its private key. For the sake of demonstrating the functionality and proofing the concept behind UDKP protocol, I have made a simple implementation for the proposed protocol. In this implementation I have modified the TLS implementation to reflect the new changes in the handshake messages. I have not written any application from scratch for this proof of concept; instead, I have modified the following open source applications: 1. Tomcat 7 application server (open source written in java). 2. Lobo web browser (open source written in java). 3. OpenJDK Java Run Time Environment 6 (open source written in java). 4. JForum web application (open source forum written in java). On Wed, Feb 13, 2013 at 7:47 AM, OMAR HASSAN (RIT Student) wrote: Russ : You cannot avoid that dependency. Actually that what I am trying to prove with my draft; that we can completely avoid forcing e-business applications to have trust relationships with domain registrars, certificate authorities, or any other third party. The root cause that fails the current TLS implementation to achieve the expected security protection even after using dane, is that the client encrypts the premaster secret using the server certificate it receives from someone who claims to be the server; this claim is supported by the attestation of a third party; the third party could be CA, or Domain Registrar, and the e-business is as secure as this relationship to the third party is trusted. the new approach is based on benefiting from the existing account for the user on the server (internet bank) by reversing the TLS process, the server will receive a message from the client signed by the user private key, and he doesn't have to validate the signed message from any third party as it has the related public key as a part of the user account, and then the server will use that public key to encrypt the premaster and send it to the client who will read it using its private key. For the sake of demonstrating the functionality and proofing the concept behind UDKP protocol, I have made a simple implementation for the proposed protocol. In this implementation I have modified the TLS implementation to reflect the new changes in the handshake messages. I have not written any application from scratch for this proof of concept; instead, I have modified On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley wrote: Omar: So for dane, instead of being dependent on the security of Certificate Authorities, you will be dependent on the security of the domain registrars. You cannot avoid that dependency. The DNS provides the IP address for the server. The admin at the bank needs to make sure the right IP address is in the DNS, and it is not a big additional burden to include the public key of that server at the same time. This adds no further trust relationships than are needed to get the IP address in the first place. Russ ------=_NextPart_000_0055_01CE09C7.001E7120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How does the user public key gets to the server? Out of = band?

 

The registration part of your specification is the problem. The = client cannot register its public key safely with the server because it = has no way of knowing that it is talking to the right = server.

 

-Piyush

From:= = tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = OMAR HASSAN (RIT Student)
Sent: Wednesday, February 13, = 2013 7:49 AM
To: Russ Housley
Cc: = tls@ietf.org
Subject: Re: [TLS] Certificate Authorities are = not required anymore

 

Russ :

 

You cannot avoid that = dependency.

 

 

Actually that what I am trying to prove with my draft; = that we can completely avoid forcing e-business applications to have = trust relationships with domain registrars, certificate authorities, or = any other third party.

 

The root cause that fails the current TLS = implementation to achieve the expected security protection even after = using dane, is that the client encrypts the premaster secret using the = server certificate it receives from someone who claims to be the server; = this claim is supported by the attestation of a third party; the third = party could be CA, or Domain Registrar, and the e-business is as secure = as this relationship to the third party is = trusted.

 

the new approach is based on benefiting from the = existing account for the user on the server (internet bank) by reversing = the TLS process, the server will receive a message from the client = signed by the user private key, and he doesn't have to validate the = signed message from any third party as it has the related public key as = a part of the user account, and then the server will use that public key = to encrypt the premaster and send it to the client who will read it = using its private key.

 

For the sake of demonstrating the functionality and = proofing the concept behind UDKP protocol, I have made a simple = implementation for the proposed protocol. In this implementation I have = modified the TLS implementation to reflect the new changes in the = handshake messages. I have not written any application from scratch for = this proof of concept; instead, I have modified the following open = source applications:

 

1.       = Tomcat 7 application server (open source written in = java).

2.       Lobo = web browser (open source written in java).

3.       = OpenJDK Java Run Time Environment 6 (open source written in = java).

4.       = JForum web application (open source forum written in = java).

 

 

 

On Wed, = Feb 13, 2013 at 7:47 AM, OMAR HASSAN (RIT Student) <omh1835@rit.edu> = wrote:

Russ = :

 

You cannot avoid that = dependency.

 

 

Actually that what I am trying to prove with my draft; = that we can completely avoid forcing e-business applications to have = trust relationships with domain registrars, certificate authorities, or = any other third party.

 

The root cause that fails the current TLS = implementation to achieve the expected security protection even after = using dane, is that the client encrypts the premaster secret using the = server certificate it receives from someone who claims to be the server; = this claim is supported by the attestation of a third party; the third = party could be CA, or Domain Registrar, and the e-business is as secure = as this relationship to the third party is = trusted.

 

the new approach is based on benefiting from the = existing account for the user on the server (internet bank) by reversing = the TLS process, the server will receive a message from the = client signed by the user private key, and he doesn't have to = validate the signed message from any third party as it has the related = public key as a part of the user account, and then the server will use = that public key to encrypt the premaster and send it to the client who = will read it using its private key.

 

For the sake of demonstrating the functionality and = proofing the concept behind UDKP protocol, I have made a simple = implementation for the proposed protocol. In this implementation I have = modified the TLS implementation to reflect the new changes in the = handshake messages. I have not written any application from scratch = for this proof of concept; instead, I have = modified 

 

 

 

On Wed, = Feb 13, 2013 at 7:48 AM, Russ Housley <housley@vigilsec.com> = wrote:

Omar:



So for = dane, instead of being dependent on the security of Certificate = Authorities, you will be dependent on the security of the domain = registrars. 

 

You cannot avoid that dependency.  The DNS = provides the IP address for the server.  The admin at the bank = needs to make sure the right IP address is in the DNS, and it is not a = big additional burden to include the public key of that server at the = same time.  This adds no further trust relationships than are = needed to get the IP address in the first = place.

 

Russ

 

 

 

------=_NextPart_000_0055_01CE09C7.001E7120-- From benl@google.com Wed Feb 13 08:57:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4C021F8AD4 for ; Wed, 13 Feb 2013 08:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILsndiV5koBs for ; Wed, 13 Feb 2013 08:57:08 -0800 (PST) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE1D21F8A89 for ; Wed, 13 Feb 2013 08:57:08 -0800 (PST) Received: by mail-ia0-f171.google.com with SMTP id z13so1390408iaz.2 for ; Wed, 13 Feb 2013 08:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=s9hXkF5Bf+4yyi3mEttxA3BQBKRXupW7pAx8CauI3e0=; b=pCbhuIYuRiaMCMBnOK393gNyZbVlrCZcYXWdDqkJDR2hej0V4pnQ//XEyPb8XwU7fy bbm+j1prw4L5FWz9OekylVcYcSSSzHKhhroFvwOJ3OdKDDUIYNdO6gZTaVcmN+w/hx/P 9zEaTUp6wpz8Bj9tEgdKHhiRJj4QMxtLCGQ23RPYpAd/9eZM4hlkwrWI3Ej2i72dZHhs n4ajOECFuxUlJDe5RzEXRMP9OHAkWC4bW3uX3gd+kk/yUvYFakMZd/h1SE6KEy4lqATw sPV4At6l38pint6VxMP19mfKNhbJq91BBQ4LIENs9ALypWW1NcBYW7uECqMYbd7+dZu1 GzBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=s9hXkF5Bf+4yyi3mEttxA3BQBKRXupW7pAx8CauI3e0=; b=X2aSLJwhRIBK5/3ezk+ubWESZjvQQ0NxE4VY0WiwrRUY9dRm6R24+jZx6mVcTNeZ1L mMJ8TVrVErhxvJ8pedVElxNWKgAReNLCrMOwDyxqtiN1BUrieZDyWSpbVygVytBDFcnh ADF4dZaDJnTaV56bRkLjtgJNcFhGethxM4/jK/9I9DjbhHlX9xtxpV/DRJ4QPXqxS+yO Dx2gqZOu3CcaxjPFq1IOY/sKJ43iS/3VVAnRd9pFrv+HbZygmX3m4Nyu7bdUu6SFv1vM IxbFR4FnvBQtSq7nPw7Lzn3Mfmf9iDna60Iw/pnFIiapTFN2La6HF+ekj7AakZ/1vQY/ 8Yrg== MIME-Version: 1.0 X-Received: by 10.50.187.134 with SMTP id fs6mr12253275igc.61.1360774627826; Wed, 13 Feb 2013 08:57:07 -0800 (PST) Received: by 10.64.8.14 with HTTP; Wed, 13 Feb 2013 08:57:07 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 08:57:07 -0800 Message-ID: From: Ben Laurie To: Russ Housley Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmMl2/fPpYWab9X8E9g3/lK7rMaoPWD7VVCJWi324oQpD1UYU9hPaz379bxJVSQu1ccktO/wPGnAh768ajwlRO8L+GgtSpIHM2yx1J4hhMJAr8huCN+c6jvUVQqz0RsDUnf9Zmx9+uVzBI1YR2nUC6tB14rvNx7+5r18rlyGQFp0wmtpHxGfXp8V4JWUVC0+zZQkGSa Cc: "OMAR HASSAN \(RIT Student\)" , "tls@ietf.org" Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 13 Feb 2013 16:57:09 -0000 On 12 February 2013 20:48, Russ Housley wrote: > Omar: > > So for dane, instead of being dependent on the security of Certificate > Authorities, you will be dependent on the security of the domain registrars. > > > You cannot avoid that dependency. The DNS provides the IP address for the > server. And if it is wrong, the server won't have the correct private key. Isn't that the whole (alleged) point of CAs? > The admin at the bank needs to make sure the right IP address is in > the DNS, and it is not a big additional burden to include the public key of > that server at the same time. This adds no further trust relationships than > are needed to get the IP address in the first place. > > Russ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From omh1835@g.rit.edu Wed Feb 13 17:34:26 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C702D21F869E for ; Wed, 13 Feb 2013 17:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.022, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GLTDsVa1lVQ for ; Wed, 13 Feb 2013 17:34:24 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 79F2F21F869A for ; Wed, 13 Feb 2013 17:34:24 -0800 (PST) Received: from mail-ob0-f198.google.com (mail-ob0-f198.google.com [209.85.214.198]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI60097YSDAAX@smtp-server.rit.edu> for tls@ietf.org; Wed, 13 Feb 2013 20:34:23 -0500 (EST) Received: by mail-ob0-f198.google.com with SMTP id dn14so9366682obc.1 for ; Wed, 13 Feb 2013 17:34:22 -0800 (PST) Received: by 10.42.245.2 with HTTP; Wed, 13 Feb 2013 17:34:21 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr15614833igc.12.1360805662117; Wed, 13 Feb 2013 17:34:22 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr15614814igc.12.1360805661952; Wed, 13 Feb 2013 17:34:21 -0800 (PST) Date: Wed, 13 Feb 2013 17:34:21 -0800 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu To: tls@ietf.org Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=14dae9340b6516cbac04d5a54238 X-RIT-Received-From: 209.85.214.198 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:in-reply-to:references :date:x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=xcPNImvo7oCv8unm4/MXYe1HdZtZlgq9igFcOtaHhVo=; b=PK1w/P4x6pVRL3vJB1wyzrOcx9HCOFe9Txz3sk04OZ7vygPLPWwsRKeKSC3XrLGpQh cX+s9PWkwgSMvJL4fqq/jZmzSnDxaohNRJidHGef1eGbNcoST62W++Hnlb21qrCQ4wL0 8IB+C38plWIe+ZsUAyv+LWvZa5FSFHFCsLhkPVPrQLQbP0AJ1zFmQmxz97wDUrI0JwHc paRkBp7pALycs+wM3VxrO8Ht3ieofCIGwqi09v4C2bNK4935emo38KBNEfQnNl81uUMp maZWgpwmcc8GaKeBDaQzbNMSiLmTp7TQzN5RFfpVItJ+24evObfZx983xWgC+9+F1CSN Urlw== X-Google-Sender-Auth: aXh8TzjBQKIBvs35mQ9of5jfKCk X-Gm-Message-State: ALoCoQkNlrYrpf03pwRkd2Y68+Pe2hRaUO7eWIDyoc9qsmcQYRpuVUWh7Hl395Vx3vl7WynZIA0H0wHnyySEwgAEk4JUhDnGnhYCN0myTSyK+j+AHEDlSGzNG1D0ggi2WrFjN0p4OlZf References: Subject: Re: [TLS] TLS Digest, Vol 103, Issue 17 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 14 Feb 2013 01:34:26 -0000 --14dae9340b6516cbac04d5a54238 Content-Type: text/plain; charset=ISO-8859-1 Regarding the user of the SRP; it has the following issues that make it not widely used in websites: 1) The server needs to store the username, v (which is based on the user chosen password), and s(salt) SRP didn't mention how these values will be saved in the first time, most probably when SRP is deployed with websites, websites will have to depend on the Certificate Authority to secure this communication for the first user registration, or the registration will be out of the internet band. 2) If v is compromised, an attacker can spoof as Server and fool the user to log in, and attacker could have full transparently access over the traffic. 3) the handshake part of SRP needs heavy computation at the server side each time the user log in, which cannot be afforded by all websites. In the new approach; the public/private key pair will be generated inside the browser plugin using heavy computations (but this computation complexity will be distributed at the client machines during the handshake), the public, key could be transferred in clear during registration for the first time, without much dangerous on revealing the user private key, or user password, as it's generated using heavy computation based on the user name and user password, and the user password will never leave the browser. so the registration message will be: struct{ UDKP_private-key-encrypted Random user_token; UserName user_name; UserPubliKey user_public_key; } UserAuthentication; where the user_token will be constructed by encrypting the ServerHello.random value using the user private key; this random value contains the server timestamp, the browser will add or deduct a few random seconds to it, those random seconds should be short enough to prevent replay attack, and at the same time should be large enough to protect against the known plain text attack. When the user tries to login later, he will provide only the user_name and the user_token, the token will be validated by tying to reconstructing the server time stamp, and if succeed the premaster will be generated by the server and encrypted using the user_public_key, so no one can have access to the session key unless he has the user private key, so even if the user_public_key got captured it will not help the attacker to monitor the traffic. On Wed, Feb 13, 2013 at 7:47 AM, wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/tls > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send TLS mailing list submissions to > tls@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/tls > or, via email, send a message with subject or body 'help' to > tls-request@ietf.org > > You can reach the person managing the list at > tls-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of TLS digest..." > > > Today's Topics: > > 1. Re: Certificate Authorities are not required anymore > (OMAR HASSAN (RIT Student)) > 2. Re: Certificate Authorities are not required anymore > (Russ Housley) > 3. Re: Certificate Authorities are not required anymore > (Peter Sylvester) > 4. Re: Certificate Authorities are not required anymore > (Peter Gutmann) > 5. Re: Certificate Authorities are not required anymore > (OMAR HASSAN (RIT Student)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 12 Feb 2013 12:42:11 -0800 > From: "OMAR HASSAN (RIT Student)" > To: Russ Housley > Cc: tls@ietf.org > Subject: Re: [TLS] Certificate Authorities are not required anymore > Message-ID: > < > CALxQUYH1BPe7t1eU8Z4kJafXBzZ5ixYA7DsYiN9pvhSo6Gtj1A@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Russ, > > Thank you for being interesting in the draft. > > When I start thinking in that approach, I was highly motivated by the > desire to achieve my golden goal; to make the security of my connection to > my internet bank is the ultimate responsibility of me and my internet bank > not anyone else. In the original implementation of the TLS my connection is > as secure as all Certificate Authorities that are trusted by my browser. If > any of those CAs betrayed this trust relationship either intentionally or > by being attacked or even by any insider employee, my connection to my > internet bank will be at risk, so my connection security depends on > hundreds or may be thousands factors that are outside the control of me and > my internet bank as the communication parties. This is the philosophy > behind my idea. > > Many workarounds that have been discussed to reduce the risk of this issue, > but they couldn't achieve my golden goal for being independent on any third > party. Of those attempts are: Certification Authority Authorization (CAA) , > and DNS-based Authentication of Named Entities (DANE). These approaches are > DNS based and can prevent any untrustworthy signer from compromising > anyone's keys except those in their own sub domains, but unfortunately > domains security are based on the security of the DNSSEC; which means these > approaches are vulnerable to the DNS keys integrity corruption if the > registrar for that domain compromised, so registrars still have the power > theoretically to abuse their position because they're responsible for your > communication to the root servers. > > So for dane, instead of being dependent on the security of Certificate > Authorities, you will be dependent on the security of the domain > registrars. > > I hope I was able to clear my point, and feel free to ask if you need more > explanation of any of the above. > > > > On Tue, Feb 12, 2013 at 10:01 PM, Russ Housley > wrote: > > > Doesn't the use of DANE to authenticate the public key of the server make > > this a much stronger solution? > > > > Russ > > > > > > On Feb 12, 2013, at 11:04 AM, OMAR HASSAN (RIT Student) wrote: > > > > Hi All, > > > > I have submitted a new internet draft that aims to build a secured tunnel > > between the client and the server without the need to involve Certificate > > Authorities or any other third party in this process. it is based on the > > assumption that in most cases there is a registered profile for the user > on > > the server; a profile that includes among a lot of things the username > and > > the password that the user uses to authenticate to the server, the > proposed > > protocol will make use of the username and the password to create a key > > pair for the user on the fly at the client side (inside the browser), and > > it will use this key pair as the starting point for creating the secured > > tunnel instead of taking the server certificate as the starting point. > > Additionally the proposed protocol has self-protection against phishing > > attacks. > > I will be appreciated if you had a look at the document and told me your > > thoughts about the idea. You can find the document under the following > link: > > > > http://tools.ietf.org/html/draft-omar-tls-udkp-00 > > > > > > Thank You > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/tls/attachments/20130212/bf929a08/attachment.htm > > > > ------------------------------ > > Message: 2 > Date: Tue, 12 Feb 2013 23:48:56 -0500 > From: Russ Housley > To: "OMAR HASSAN (RIT Student)" > Cc: tls@ietf.org > Subject: Re: [TLS] Certificate Authorities are not required anymore > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Omar: > > > So for dane, instead of being dependent on the security of Certificate > Authorities, you will be dependent on the security of the domain registrars. > > You cannot avoid that dependency. The DNS provides the IP address for the > server. The admin at the bank needs to make sure the right IP address is > in the DNS, and it is not a big additional burden to include the public key > of that server at the same time. This adds no further trust relationships > than are needed to get the IP address in the first place. > > Russ > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/tls/attachments/20130212/14b869ac/attachment.htm > > > > ------------------------------ > > Message: 3 > Date: Wed, 13 Feb 2013 07:56:39 +0100 > From: Peter Sylvester > To: tls@ietf.org > Subject: Re: [TLS] Certificate Authorities are not required anymore > Message-ID: <511B3927.5070106@edelweb.fr> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On 02/13/2013 05:48 AM, Russ Housley wrote: > > Omar: > > > >> So for dane, instead of being dependent on the security of Certificate > Authorities, you will be > >> dependent on the security of the domain registrars. > > > > You cannot avoid that dependency. The DNS provides the IP address for > the server. The admin at > > the bank needs to make sure the right IP address is in the DNS, and it > is not a big additional > > burden to include the public key of that server at the same time. This > adds no further trust > > relationships than are needed to get the IP address in the first place. > > > > rfc 5054 also does (real) mutual authentication > without need of certificates local (client) trust base. > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/tls/attachments/20130213/53645b31/attachment.htm > > > > ------------------------------ > > Message: 4 > Date: Wed, 13 Feb 2013 12:36:17 +0000 > From: Peter Gutmann > To: "tls@ietf.org" > Subject: Re: [TLS] Certificate Authorities are not required anymore > Message-ID: > < > 9A043F3CF02CD34C8E74AC1594475C7333407720@uxcn10-2.UoA.auckland.ac.nz> > Content-Type: text/plain; charset="us-ascii" > > "OMAR HASSAN (RIT Student)" writes: > > >it is based on the assumption that in most cases there is a registered > >profile for the user on the server; a profile that includes among a lot of > >things the username and the password that the user uses to authenticate to > >the server, the proposed protocol will make use of the username and the > >password to create a key pair for the user on the fly at the client side > >(inside the browser), and it will use this key pair as the starting point > for > >creating the secured tunnel instead of taking the server certificate as > the > >starting point. Additionally the proposed protocol has self-protection > >against phishing attacks. > > How does this improve on TLS-SRP and TLS-PSK, which already do the same > thing? > > Peter. > > > ------------------------------ > > Message: 5 > Date: Wed, 13 Feb 2013 07:47:14 -0800 > From: "OMAR HASSAN (RIT Student)" > To: Russ Housley > Cc: tls@ietf.org > Subject: Re: [TLS] Certificate Authorities are not required anymore > Message-ID: > xKqJ-3A@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Russ : > > You cannot avoid that dependency. > > > Actually that what I am trying to prove with my draft; that we can > completely avoid forcing e-business applications to have trust > relationships with domain registrars, certificate authorities, or any other > third party. > > The root cause that fails the current TLS implementation to achieve the > expected security protection even after using dane, is that the client > encrypts the premaster secret using the server certificate it receives from > someone who claims to be the server; this claim is supported by the > attestation of a third party; the third party could be CA, or Domain > Registrar, and the e-business is as secure as this relationship to the > third party is trusted. > > the new approach is based on benefiting from the existing account for the > user on the server (internet bank) by reversing the TLS process, the server > will receive a message from the client signed by the user private key, and > he doesn't have to validate the signed message from any third party as it > has the related public key as a part of the user account, and then the > server will use that public key to encrypt the premaster and send it to the > client who will read it using its private key. > > For the sake of demonstrating the functionality and proofing the concept > behind UDKP protocol, I have made a simple implementation for the proposed > protocol. In this implementation I have modified the TLS implementation to > reflect the new changes in the handshake messages. I have not written any > application from scratch for this proof of concept; instead, I have > modified > > > > On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley > wrote: > > > Omar: > > > > So for dane, instead of being dependent on the security of Certificate > > Authorities, you will be dependent on the security of the domain > > registrars. > > > > > > You cannot avoid that dependency. The DNS provides the IP address for > the > > server. The admin at the bank needs to make sure the right IP address is > > in the DNS, and it is not a big additional burden to include the public > key > > of that server at the same time. This adds no further trust > relationships > > than are needed to get the IP address in the first place. > > > > Russ > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/tls/attachments/20130213/fd239bff/attachment.htm > > > > ------------------------------ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > End of TLS Digest, Vol 103, Issue 17 > ************************************ > --14dae9340b6516cbac04d5a54238 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding the user of the=A0SRP; it has the following issu= es that make it not widely used in websites:

1) The serv= er needs to store the username, v (which is based on the user chosen passwo= rd), and s(salt)
SRP=A0didn't=A0mention how these values will be saved in the first= time, most probably when SRP is deployed with websites, websites =A0will h= ave to depend on the Certificate Authority to secure this communication for= the first user registration, or the registration will be out of the intern= et band.

2) If =A0v is compromised, an attacker can spoof as Ser= ver and fool the user to log in, and attacker could have full transparently= access over the traffic.

3) the handshake part of= SRP needs heavy computation at the server side each time the user log in, = which cannot be afforded by all websites.

In the new approach; the public/private key pair will b= e generated inside the browser plugin using heavy computations (but this co= mputation complexity will be distributed at the client machines during the = handshake), the public, key could be transferred in clear during registrati= on for the first time, without much dangerous on revealing the user private= key, or user password, as it's generated using heavy computation based= on the user name and user password, and the user password will never leave= the browser.

so the registration message will be:

struct{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UDKP_private-= key-encrypted Random user_token;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = UserName user_name;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UserPubliKey user_public_key;
=A0= =A0 =A0 =A0 } UserAuthentication;

where the user_= token will be constructed by encrypting the ServerHello.random value using = the user private key; this random value contains the server timestamp, the = browser will add or deduct a few random seconds to it, those random seconds= should be short enough to prevent replay attack, and at the same time shou= ld be large enough to protect against the known plain text attack.

When the user tries to login later, he will provide onl= y the user_name and the user_token, the token will be validated by tying to= reconstructing the=A0server=A0time stamp, and if succeed the premaster wil= l be generated by the server and encrypted using the user_public_key, so no= one can have access to the session key=A0unless=A0he has the user private = key, so even if the user_public_key got=A0captured=A0it will not help the a= ttacker to monitor the traffic.

On Wed, Feb 13, 2013 at 7:47 AM, <tls-= request@ietf.org> wrote:
If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription. =A0To do so, go to

htt= ps://www.ietf.org/mailman/listinfo/tls

Click the 'Unsubscribe or edit options' button, log in, and set &qu= ot;Get
MIME or Plain Text Digests?" to MIME. =A0You can set this option
globally for all the list digests you receive at this point.



Send TLS mailing list submissions to
=A0 =A0 =A0 =A0 tls@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 tls-request@ietf.or= g

You can reach the person managing the list at
=A0 =A0 =A0 =A0 tls-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."


Today's Topics:

=A0 =A01. Re: =A0Certificate Authorities are not required anymore
=A0 =A0 =A0 (OMAR HASSAN (RIT Student))
=A0 =A02. Re: =A0Certificate Authorities are not required anymore
=A0 =A0 =A0 (Russ Housley)
=A0 =A03. Re: =A0Certificate Authorities are not required anymore
=A0 =A0 =A0 (Peter Sylvester)
=A0 =A04. Re: =A0Certificate Authorities are not required anymore
=A0 =A0 =A0 (Peter Gutmann)
=A0 =A05. Re: =A0Certificate Authorities are not required anymore
=A0 =A0 =A0 (OMAR HASSAN (RIT Student))


----------------------------------------------------------------------

Message: 1
Date: Tue, 12 Feb 2013 12:42:11 -0800
From: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
To: Russ Housley <housley@vigils= ec.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Certificate Authorities are not required anymore
Message-ID:
=A0 =A0 =A0 =A0 <CALxQUYH1BPe7t1eU8Z4kJafXBzZ5ixYA7DsYiN9pvhS= o6Gtj1A@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Hi Russ,

Thank you for being interesting in the draft.

When I start thinking in that approach, I was highly motivated by the
desire to achieve my golden goal; to make the security of my connection to<= br> my internet bank is the ultimate responsibility of me and my internet bank<= br> not anyone else. In the original implementation of the TLS my connection is=
as secure as all Certificate Authorities that are trusted by my browser. If=
any of those CAs betrayed this trust relationship either intentionally or by being attacked or even by any insider employee, my connection to my
internet bank will be at risk, so my connection security depends on
hundreds or may be thousands factors that are outside the control of me and=
my internet bank as the communication parties. This is the philosophy
behind my idea.

Many workarounds that have been discussed to reduce the risk of this issue,=
but they couldn't achieve my golden goal for being independent on any t= hird
party. Of those attempts are: Certification Authority Authorization (CAA) ,=
and DNS-based Authentication of Named Entities (DANE). These approaches are=
DNS based and can prevent any untrustworthy signer from compromising
anyone's keys except those in their own sub domains, but unfortunately<= br> domains security are based on the security of the DNSSEC; which means these=
approaches are vulnerable to the DNS keys integrity corruption if the
registrar for that domain compromised, so registrars still have the power theoretically to abuse their position because they're responsible for y= our
communication to the root servers.

So for dane, instead of being dependent on the security of Certificate
Authorities, you will be dependent on the security of the domain
registrars.

I hope I was able to clear my point, and feel free to ask if you need more<= br> explanation of any of the above.



On Tue, Feb 12, 2013 at 10:01 PM, Russ Housley <housley@vigilsec.com> wrote:

> Doesn't the use of DANE to authenticate the public key of the serv= er make
> this a much stronger solution?
>
> Russ
>
>
> On Feb 12, 2013, at 11:04 AM, OMAR HASSAN (RIT Student) wrote:
>
> Hi All,
>
> I have submitted a new internet draft that aims to build a secured tun= nel
> between the client and the server without the need to involve Certific= ate
> Authorities or any other third party in this process. it is based on t= he
> assumption that in most cases there is a registered profile for the us= er on
> the server; a profile that includes among a lot of things the username= and
> the password that the user uses to authenticate to the server, the pro= posed
> protocol will make use of the username and the password to create a ke= y
> pair for the user on the fly at the client side (inside the browser), = and
> it will use this key pair as the starting point for creating the secur= ed
> tunnel instead of taking the server certificate as the =A0 starting po= int.
> Additionally the proposed protocol has self-protection against phishin= g
> attacks.
> I will be appreciated if you had a look at the document and told me yo= ur
> thoughts about the idea. You can find the document under the following= link:
>
> http://tools.ietf.org/html/draft-omar-tls-udkp-00
>
>
> Thank You
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-= archive/web/tls/attachments/20130212/bf929a08/attachment.htm>

------------------------------

Message: 2
Date: Tue, 12 Feb 2013 23:48:56 -0500
From: Russ Housley <housley@vigi= lsec.com>
To: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
Cc: tls@ietf.org
Subject: Re: [TLS] Certificate Authorities are not required anymore
Message-ID: <D6F208DB-A539-4C70-AC99-F26E286A92A9@vigilsec.com>
Content-Type: text/plain; charset=3D"us-ascii"

Omar:

> So for dane, instead of being dependent on the security of Certificate= Authorities, you will be dependent on the security of the domain registrar= s.

You cannot avoid that dependency. =A0The DNS provides the IP address for th= e server. =A0The admin at the bank needs to make sure the right IP address = is in the DNS, and it is not a big additional burden to include the public = key of that server at the same time. =A0This adds no further trust relation= ships than are needed to get the IP address in the first place.

Russ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-= archive/web/tls/attachments/20130212/14b869ac/attachment.htm>

------------------------------

Message: 3
Date: Wed, 13 Feb 2013 07:56:39 +0100
From: Peter Sylvester <pet= er.sylvester@edelweb.fr>
To: tls@ietf.org
Subject: Re: [TLS] Certificate Authorities are not required anymore
Message-ID: <511B3927.507= 0106@edelweb.fr>
Content-Type: text/plain; charset=3D"iso-8859-1"; Format=3D"= flowed"

On 02/13/2013 05:48 AM, Russ Housley wrote:
> Omar:
>
>> So for dane, instead of being dependent on the security of Certifi= cate Authorities, you will be
>> dependent on the security of the domain registrars.
>
> You cannot avoid that dependency. =A0The DNS provides the IP address f= or the server. =A0The admin at
> the bank needs to make sure the right IP address is in the DNS, and it= is not a big additional
> burden to include the public key of that server at the same time. =A0T= his adds no further trust
> relationships than are needed to get the IP address in the first place= .
>

rfc 5054 also does (real) mutual authentication
without need of certificates local (client) trust base.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-= archive/web/tls/attachments/20130213/53645b31/attachment.htm>

------------------------------

Message: 4
Date: Wed, 13 Feb 2013 12:36:17 +0000
From: Peter Gutmann <pgut00= 1@cs.auckland.ac.nz>
To: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Certificate Authorities are not required anymore
Message-ID:
=A0 =A0 =A0 =A0 <9A043F3CF02CD34C8E74AC1594475C7333407720@u= xcn10-2.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=3D"us-ascii"

"OMAR HASSAN (RIT Student)" <omh1835@rit.edu> writes:

>it is based on the assumption that in most cases there is a registered<= br> >profile for the user on the server; a profile that includes among a lot= of
>things the username and the password that the user uses to authenticate= to
>the server, the proposed protocol will make use of the username and the=
>password to create a key pair for the user on the fly at the client sid= e
>(inside the browser), and it will use this key pair as the starting poi= nt for
>creating the secured tunnel instead of taking the server certificate as= the
>starting point. Additionally the proposed protocol has self-protection<= br> >against phishing attacks.

How does this improve on TLS-SRP and TLS-PSK, which already do the same thi= ng?

Peter.


------------------------------

Message: 5
Date: Wed, 13 Feb 2013 07:47:14 -0800
From: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
To: Russ Housley <housley@vigils= ec.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Certificate Authorities are not required anymore
Message-ID:
=A0 =A0 =A0 =A0 <CALxQUYEqYy1C2++fh=3D_H3qLvPVkKexBjwHoUNZZqbn=3DxKqJ-3A@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Russ :

You cannot avoid that dependency.


Actually that what I am trying to prove with my draft; that we can
completely avoid forcing e-business applications to have trust
relationships with domain registrars, certificate authorities, or any other=
third party.

The root cause that fails the current TLS implementation to achieve the
expected security protection even after using dane, is that the client
encrypts the premaster secret using the server certificate it receives from=
someone who claims to be the server; this claim is supported by the
attestation of a third party; the third party could be CA, or Domain
Registrar, and the e-business is as secure as this relationship to the
third party is trusted.

the new approach is based on benefiting from the existing account for the user on the server (internet bank) by reversing the TLS process, the server=
will receive a message from the client signed by the user private key, and<= br> he doesn't have to validate the signed message from any third party as = it
has the related public key as a part of the user account, and then the
server will use that public key to encrypt the premaster and send it to the=
client who will read it using its private key.

For the sake of demonstrating the functionality and proofing the concept behind UDKP protocol, I have made a simple implementation for the proposed<= br> protocol. In this implementation I have modified the TLS implementation to<= br> reflect the new changes in the handshake messages. I have not written any application from scratch for this proof of concept; instead, I have
modified



On Wed, Feb 13, 2013 at 7:48 AM, Russ Housley <housley@vigilsec.com> wrote:

> Omar:
>
> So for dane, instead of being dependent on the security of Certificate=
> Authorities, you will be dependent on the security of the domain
> registrars.
>
>
> You cannot avoid that dependency. =A0The DNS provides the IP address f= or the
> server. =A0The admin at the bank needs to make sure the right IP addre= ss is
> in the DNS, and it is not a big additional burden to include the publi= c key
> of that server at the same time. =A0This adds no further trust relatio= nships
> than are needed to get the IP address in the first place.
>
> Russ
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-= archive/web/tls/attachments/20130213/fd239bff/attachment.htm>

------------------------------

_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


End of TLS Digest, Vol 103, Issue 17
************************************

--14dae9340b6516cbac04d5a54238-- From omh1835@g.rit.edu Wed Feb 13 17:44:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1721F8684 for ; Wed, 13 Feb 2013 17:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.958 X-Spam-Level: X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.018, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUUA+JHgoSLP for ; Wed, 13 Feb 2013 17:44:43 -0800 (PST) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF7A21F8682 for ; Wed, 13 Feb 2013 17:44:42 -0800 (PST) Received: from mail-ia0-f197.google.com (mail-ia0-f197.google.com [209.85.210.197]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MI6008HUSUHGF@smtp-server.rit.edu> for tls@ietf.org; Wed, 13 Feb 2013 20:44:42 -0500 (EST) Received: by mail-ia0-f197.google.com with SMTP id y25so6203770iay.8 for ; Wed, 13 Feb 2013 17:44:41 -0800 (PST) Received: by 10.42.245.2 with HTTP; Wed, 13 Feb 2013 17:44:40 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr15670726igc.12.1360806281134; Wed, 13 Feb 2013 17:44:41 -0800 (PST) X-Received: by 10.50.207.67 with SMTP id lu3mr15670712igc.12.1360806280963; Wed, 13 Feb 2013 17:44:40 -0800 (PST) Date: Wed, 13 Feb 2013 17:44:40 -0800 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu To: "tls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=14dae9340b65fc261f04d5a56649 X-RIT-Received-From: 209.85.210.197 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:sender:in-reply-to:references :date:x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=IwVg4Tut+Oa+0lg7VE8DL/QZ550bY7qBQDCAvutqV/g=; b=i8Oy+89sUsXqL5N3Li01xMKsijMUKi9ITXubt0dsZgNuZpMfOedl3fB+I13ahVqU+E 6uZP2UOI1ryrk4fmhx30McaRFO/XJN88OkGE9raNPR/flLC8wOEmOQhzVg5Ja1eQ2y0I 2mCMU5hHrkONAQ8XwbyyliSI1r5bKcBIRbc+tC+yi/riKsn4nttiqaSY1rP49+B3wf0T vY2hy/q3IIBiLvoTngvuqFK7AZGuGYxJ8u0dYY+PxABTpXbkO86DeHb2XuNPIq6qMcH/ Rvc17w63JemDT4WIbgajsrHtUH3PYWgn40vJAY7+LU+lnI0d5izu4JurcpRhKoXLbion j5cg== X-Google-Sender-Auth: 0z9cCsJfYqU0LyW1VW26nQPj92o X-Gm-Message-State: ALoCoQlPyNNed0es5wcEfqLV3hqr073rcKu0PIXaCQYL1txhM7BcFJFEvKDiaepZkslGFGiKffVnID+JF7DoEPBzoYz37zoXncsiAFc68E0Q7EwRZPTN7VXKxZjn5oY4TW7IID0h+VV4 References: Subject: Re: [TLS] Certificate Authorities are not required anymore X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 14 Feb 2013 01:44:45 -0000 --14dae9340b65fc261f04d5a56649 Content-Type: text/plain; charset=ISO-8859-1 Regarding the user of the SRP; it has the following issues that make it not widely used in websites: 1) The server needs to store the username, v (which is based on the user chosen password), and s(salt) SRP didn't mention how these values will be saved in the first time, most probably when SRP is deployed with websites, websites will have to depend on the Certificate Authority to secure this communication for the first user registration, or the registration will be out of the internet band. 2) If v is compromised, an attacker can spoof as Server and fool the user to log in, and attacker could have full transparently access over the traffic. 3) the handshake part of SRP needs heavy computation at the server side each time the user log in, which cannot be afforded by all websites. In the new approach; the public/private key pair will be generated inside the browser plugin using heavy computations (but this computation complexity will be distributed at the client machines during the handshake), the public, key could be transferred in clear during registration for the first time, without much dangerous on revealing the user private key, or user password, as it's generated using heavy computation based on the user name and user password, and the user password will never leave the browser. so the registration message will be: struct{ UDKP_private-key-encrypted Random user_token; UserName user_name; UserPubliKey user_public_key; } UserAuthentication; where the user_token will be constructed by encrypting the ServerHello.random value using the user private key; this random value contains the server timestamp, the browser will add or deduct a few random seconds to it, those random seconds should be short enough to prevent replay attack, and at the same time should be large enough to protect against the known plain text attack. When the user tries to login later, he will provide only the user_name and the user_token, the token will be validated by tying to reconstructing the server time stamp, and if succeed the premaster will be generated by the server and encrypted using the user_public_key, so no one can have access to the session key unless he has the user private key, so even if the user_public_key got captured it will not help the attacker to monitor the traffic. On Wed, Feb 13, 2013 at 8:57 AM, Ben Laurie wrote: > On 12 February 2013 20:48, Russ Housley wrote: > > Omar: > > > > So for dane, instead of being dependent on the security of Certificate > > Authorities, you will be dependent on the security of the domain > registrars. > > > > > > You cannot avoid that dependency. The DNS provides the IP address for > the > > server. > > And if it is wrong, the server won't have the correct private key. > Isn't that the whole (alleged) point of CAs? > > > The admin at the bank needs to make sure the right IP address is in > > the DNS, and it is not a big additional burden to include the public key > of > > that server at the same time. This adds no further trust relationships > than > > are needed to get the IP address in the first place. > > > > Russ > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --14dae9340b65fc261f04d5a56649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Regarding the user = of the=A0SRP; it has the following issues that make it not widely used in w= ebsites:

1) The server needs to stor= e the username, v (which is based on the user chosen password), and s(salt)=
SRP=A0didn't=A0mention how these = values will be saved in the first time, most probably when SRP is deployed = with websites, websites =A0will have to depend on the Certificate Authority= to secure this communication for the first user registration, or the regis= tration will be out of the internet band.

2) If =A0v is compromised, an attacker can spoof as Server and fool the use= r to log in, and attacker could have full transparently access over the tra= ffic.

3) the handshake part of SR= P needs heavy computation at the server side each time the user log in, whi= ch cannot be afforded by all websites.

In the new approach; the public/private key pair will be generated inside t= he browser plugin using heavy computations (but this computation complexity= will be distributed at the client machines during the handshake), the publ= ic, key could be transferred in clear during registration for the first tim= e, without much dangerous on revealing the user private key, or user passwo= rd, as it's generated using heavy computation based on the user name an= d user password, and the user password will never leave the browser.

so the registration message will be:

struct{
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UDKP_private-key-enc= rypted Random user_token;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UserNam= e user_name;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 UserPubliKey user_pu= blic_key;
=A0 =A0 =A0 =A0 } UserAuthentication;

where the user_token will be constructed by encrypting = the ServerHello.random value using the user private key; this random value = contains the server timestamp, the browser will add or deduct a few random = seconds to it, those random seconds should be short enough to prevent repla= y attack, and at the same time should be large enough to protect against th= e known plain text attack.

When the user tries to login later, he will provide onl= y the user_name and the user_token, the token will be validated by tying to= reconstructing the=A0server=A0time stamp, and if succeed the premaster wil= l be generated by the server and encrypted using the user_public_key, so no= one can have access to the session key=A0unless=A0he has the user private = key, so even if the user_public_key got=A0captured=A0it will not help the a= ttacker to monitor the traffic.

On Wed, Feb 13, 2013 at 8:57 AM, Ben L= aurie <benl@google.com> wrote:
On 12 February 2013 20:48, Russ Housley <housley@vigilsec.com> wrote:
> Omar:
>
> So for dane, instead of being dependent on the security of Certificate=
> Authorities, you will be dependent on the security of the domain regis= trars.
>
>
> You cannot avoid that dependency. =A0The DNS provides the IP address f= or the
> server.

And if it is wrong, the server won't have the correct private key= .
Isn't that the whole (alleged) point of CAs?

> =A0The admin at the bank needs to make sure the right IP address is in=
> the DNS, and it is not a big additional burden to include the public k= ey of
> that server at the same time. =A0This adds no further trust relationsh= ips than
> are needed to get the IP address in the first place.
>
> Russ
>
>
> ________________________= _______________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--14dae9340b65fc261f04d5a56649-- From internet-drafts@ietf.org Thu Feb 14 22:46:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA51521F85AF; Thu, 14 Feb 2013 22:46:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVko1zE9xVvM; Thu, 14 Feb 2013 22:46:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C674221F85B1; Thu, 14 Feb 2013 22:46:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130215064641.20825.22045.idtracker@ietfa.amsl.com> Date: Thu, 14 Feb 2013 22:46:41 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 06:46:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Out-of-Band Public Key Validation for Transport Layer Se= curity (TLS) Author(s) : Paul Wouters Hannes Tschofenig John Gilmore Samuel Weiler Tero Kivinen Filename : draft-ietf-tls-oob-pubkey-07.txt Pages : 17 Date : 2013-02-14 Abstract: This document specifies a new certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. Currently, TLS authentication can only occur via X.509-based Public Key Infrastructure (PKI) or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative public key validation methods. One such alternative public key valiation method is offered by the DNS-Based Authentication of Named Entities (DANE) together with DNS Security. Another alternative is to utilize pre-configured keys, as is the case with sensors and other embedded devices. The usage of raw public keys, instead of X.509-based certificates, leads to a smaller code footprint. This document introduces the support for raw public keys in TLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jsalowey@cisco.com Fri Feb 15 11:09:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E744F21F8883 for ; Fri, 15 Feb 2013 11:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vU-kw6PBUaNT for ; Fri, 15 Feb 2013 11:09:04 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D418321F887D for ; Fri, 15 Feb 2013 11:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6437; q=dns/txt; s=iport; t=1360955344; x=1362164944; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=JfCPpBAlyAUqcPCs1hrmviID8k54d3HMAnq6rSCcTDA=; b=DG9vjHBiTdVMFg+LMHlzsKJAUUeXiGLqj1MXzCbvp+IR/pfyPSQ5IhLn 0BWCmc2AX3m+g9dYNDZayJap4+cVvc512uJ/hiXUP7qo/5Geh0gPDZySe i9OZZNW4f3LDYNGShVYBfUCmrVuSjCfD6Lm7pOWhvRY30b65FUhkHONO9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABmHHlGtJXG+/2dsb2JhbAA6Cr9yfRZzgiEBBDoxBxkBKhRCJwQbAYgJDJwooQuNXQaBF4MXYQOmfYMHgWsHFwYY X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; d="scan'208";a="174675495" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 15 Feb 2013 19:09:03 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1FJ93kO028088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Feb 2013 19:09:03 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 13:09:03 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Proto write-up for draft-ietf-tls-multiple-cert-status-extension-04 Thread-Index: AQHOC6/qa3MYyptWIUC9Sc2+sDX32Q== Date: Fri, 15 Feb 2013 19:09:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <766E5DD207B70C42A545900E6EEC8338@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Proto write-up for draft-ietf-tls-multiple-cert-status-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 19:09:05 -0000 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet S= tandard, Informational, Experimental, or Historic)? Why is this the proper = type of RFC? Is this type of RFC indicated in the title page header? The type of document is proposed standard. It provides a mechanism useful = for the internet and represents working group consensus. The document indi= cates "Standards Track"=20 (2) The IESG approval announcement includes a Document Announcement Write-U= p. Please provide such a Document Announcement Write-Up. Recent examples ca= n be found in the "Action" announcements for approved documents. The approv= al announcement contains the following sections: Technical Summary: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. Working Group Summary: In general working group consensus was smooth. There were no major stickin= g points=20 Document Quality: There are a number of implementers who plan to implement this protocol exte= nsion.=20 Personnel: Shepherd - Joe Salowey; AD - Sean turner (3) Briefly describe the review of this document that was performed by the = Document Shepherd. If this version of the document is not ready for publica= tion, please explain why the document is being forwarded to the IESG. The document shepherd has read the document and run the I-D nits tool. =20 (4) Does the document Shepherd have any concerns about the depth or breadth= of the reviews that have been performed? No.=20 (5) Do portions of the document need review from a particular or from broad= er perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML= , or internationalization? If so, describe the review that took place. THe document has be reviewed by members of the TLS working group that have = expertise in TLS and OCSP. =20 (6) Describe any specific concerns or issues that the Document Shepherd has= with this document that the Responsible Area Director and/or the IESG shou= ld be aware of? For example, perhaps he or she is uncomfortable with certai= n parts of the document, or has concerns whether there really is a need for= it. In any event, if the WG has discussed those issues and has indicated t= hat it still wishes to advance the document, detail those concerns here. No concerns (7) Has each author confirmed that any and all appropriate IPR disclosures = required for full conformance with the provisions of BCP 78 and BCP 79 have= already been filed. If not, explain why? Yes the author has confirmed this,=20 (8) Has an IPR disclosure been filed that references this document? If so, = summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR declaration has been filed=20 (9) How solid is the WG consensus behind this document? Does it represent t= he strong concurrence of a few individuals, with others being silent, or do= es the WG as a whole understand and agree with it? I would say that there is strong concurrence of a few individuals with a ge= neral support for the document (10) Has anyone threatened an appeal or otherwise indicated extreme discont= ent? If so, please summarise the areas of conflict in separate email messag= es to the Responsible Area Director. (It should be in a separate email beca= use this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document.= (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).= Boilerplate checks are not enough; this check needs to be thorough. No nits (12) Describe how the document meets any required formal review criteria, s= uch as the MIB Doctor, media type, and URI type reviews. The document has a security considerations section (13) Have all references within this document been identified as either nor= mative or informative? Yes (14) Are there normative references to documents that are not ready for adv= ancement or are otherwise in an unclear state? If such normative references= exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If = so, list these downward references to support the Area Director in the Last= Call procedure. No (16) Will publication of this document change the status of any existing RF= Cs? Are those RFCs listed on the title page header, listed in the abstract,= and discussed in the introduction? If the RFCs are not listed in the Abstr= act and Introduction, explain why, and point to the part of the document wh= ere the relationship of this document to the other RFCs is discussed. If th= is information is not in the document, explain why the WG considers it unne= cessary. This document does not change the status of existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations sec= tion, especially with regard to its consistency with the body of the docume= nt. Confirm that all protocol extensions that the document makes are associ= ated with the appropriate reservations in IANA registries. Confirm that any= referenced IANA registries have been clearly identified. Confirm that newl= y created IANA registries include a detailed specification of the initial c= ontents for the registry, that allocations procedures for future registrati= ons are defined, and a reasonable name for the new registry has been sugges= ted (see RFC 5226). The IANA Considerations are complete (18) List any new IANA registries that require Expert Review for future all= ocations. Provide any public guidance that the IESG would find useful in se= lecting the IANA Experts for these new registries. New IANA registry is by IETF consensus=20 (19) Describe reviews and automated checks performed by the Document Shephe= rd to validate sections of the document written in a formal language, such = as XML code, BNF rules, MIB definitions, etc. This document does not contain such sections.=20 From internet-drafts@ietf.org Fri Feb 15 12:50:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25F21E8041; Fri, 15 Feb 2013 12:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At30x7L0Upt8; Fri, 15 Feb 2013 12:50:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00961F0D07; Fri, 15 Feb 2013 12:50:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130215205032.29219.8131.idtracker@ietfa.amsl.com> Date: Fri, 15 Feb 2013 12:50:32 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-pwd-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 20:50:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : Secure Password Ciphersuites for Transport Layer Securit= y (TLS) Author(s) : Dan Harkins Dave Halasz Filename : draft-ietf-tls-pwd-00.txt Pages : 24 Date : 2013-01-21 Abstract: This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-pwd-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wtc@google.com Fri Feb 15 16:10:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 319A721F842E for ; Fri, 15 Feb 2013 16:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH6EfEjzcVAu for ; Fri, 15 Feb 2013 16:10:05 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id B57C221F8413 for ; Fri, 15 Feb 2013 16:10:05 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id bn7so5472783ieb.25 for ; Fri, 15 Feb 2013 16:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9mUssFPhuatZ2OP+LYowq2x8+QkU0OlXYgVSgQTHGMM=; b=EP2SH3An8ger2EyOse/d2UWlR6QTjgBrGpDxTCjJgIsGnp4zdW08oyfGMnouo+qNHV h1DszKfYXg3YN+o/o5jN4IpenOhyT4LbdYHdn2/RfltkUYlusY4e6Nj5VCj0KqXLYlaV ZHyltXJ7kmghuAKeAej/jCj2W2x2xDf4j6d3A+qxnOdhf0DiUIT97umPEw6L9iRlAxKq i7Ro03R5KHAsy+pXSj7QMnNrL/nmE7Hq7+mvNmyhVe5dqkN5YccphiiuZpxuR6mdYlz6 +fifs0+F9yU+sqZQvwvGTA0tx9MtpDa0qgpHc+P9M3ONwzzZhHip7Ky9HwZPLWQFoDzv jsiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=9mUssFPhuatZ2OP+LYowq2x8+QkU0OlXYgVSgQTHGMM=; b=PZMpRlFax2tVHLFMIoGACm6SuAe6+l37G4AXZoMlevVMS8f8TD8DJ0685a3Fk7SZ/S 6FWdfm2SLppxhUTnaL4UN2HntrJAPBKXXba563U53qvDnHOa3GkJZ+tGd68jRORvTfJz vz106p8/VcZoIvJ+KkLhUnYCyepjtvdDGxDt1KhY46UR5tDieboDz8RBHqu9eksxNMkb SiLraGNj2O2Lyr51IcW4npjG/nVfxnH5z2RsR0CJQj1R/buJXYSBn4pTZs1N0cJbRtyl v5zblzhAWMKIxWT+VIhkqJPIosKpVTevdAlRq1rf8P8Z3e34APUVN2lKfnT/hw/aCL3y 2y3Q== MIME-Version: 1.0 X-Received: by 10.42.48.147 with SMTP id s19mr2737616icf.18.1360973404291; Fri, 15 Feb 2013 16:10:04 -0800 (PST) Received: by 10.231.92.65 with HTTP; Fri, 15 Feb 2013 16:10:04 -0800 (PST) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73334013EB@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73334013EB@uxcn10-2.UoA.auckland.ac.nz> Date: Fri, 15 Feb 2013 16:10:04 -0800 Message-ID: From: Wan-Teh Chang To: Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnMoRHxwca2y9bw1a3z7S3FPRWkeGV+KWvLmcVpbcvnP6KTkd8j93CfClRTrEhp+nFs+fBzmKKSFxtbm4dJSeDz+5EF2fT4KXiMvFDWZB3PlTH0OA1Od3dQJU50mviKbrksfy3whizbN0NKZMVKFlKeuDKjnEF2uZKhWt5tBjoJLLoORpaKxzlBTqqeIVzMTDmPX2ug Cc: "tls@ietf.org" Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 16 Feb 2013 00:10:06 -0000 On Mon, Feb 11, 2013 at 3:13 PM, Peter Gutmann wrote: > > In what way would HMAC-MD5 be "too weak"? I agree that HMAC-SHA1/ > SHA256 are a better proposition, but using HMAC-MD5 should be up to > the implementer in any case. I've deprecated it for some years now, the > minimum I'll do is HMAC-SHA1. It's not as if there's a shortage of suites > to choose from, and I've never found anything that does only -MD5 and > not -SHA1. There are some websites that enable only one cipher suite: TLS_RSA_WITH_RC4_128_MD5. You can find some examples in this Chromium bug report: https://code.google.com/p/chromium/issues/detail?id=118330 Wan-Teh From i.grok@comcast.net Fri Feb 15 19:13:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3505411E80A3 for ; Fri, 15 Feb 2013 19:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyJ-QODXd3OU for ; Fri, 15 Feb 2013 19:13:17 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 600D221F8444 for ; Fri, 15 Feb 2013 19:13:17 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id 0r2q1l0021ZXKqc54rDGnV; Sat, 16 Feb 2013 03:13:16 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta21.westchester.pa.mail.comcast.net with comcast id 0rDE1l00b2Ekl483hrDGA1; Sat, 16 Feb 2013 03:13:16 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id r1G3DDIA021164 for ; Fri, 15 Feb 2013 22:13:13 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id r1G3DCuB021163 for tls@ietf.org; Fri, 15 Feb 2013 22:13:12 -0500 Date: Fri, 15 Feb 2013 22:13:12 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20130216031312.GA21026@odin.ulthar.us> Mail-Followup-To: tls@ietf.org References: <20130211152934.ED58A1A542@ld9781.wdf.sap.corp> <20130211153327.6EE941A546@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20130211153327.6EE941A546@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360984396; bh=+lpOVlWv7tbv5C9M9XZ84Q1qVRH2TKv6VhcdI4lguwE=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=ZqoFLQCavTY7stftyJ5PSMZVarn2V9xxGqs2Stu3x+c1QeQzcU6ILVoOLzdLpVtI0 Si/nmOdREVcIsbW/6nHFsTy/VuwxkJcMw7fybNgx89pJMYvdo6mq0Zyu9Ja1IQryrs PTm/45UKU6v7LsYhEgBKkHKSD++6qU0lV7iv7V7qfQ0zio3XfL8lIqGyuTTcrhgAqP VLK+aR/ib1ZG0leHWCEgTBDS5RAYjbIEwirstSRPc2Ad9EnY+w93FuatagnXnwE7pd YbMR0czMQ9lD1Ts6VJvL9yyGNRaes9opsFEtMmM7maxrNT0Ag6+WDAF0nAU1iLWVS5 IqutJGkYpuDbA== Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 16 Feb 2013 03:13:18 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 11, 2013 at 04:33:27PM +0100, Martin Rex wrote: > Martin Rex wrote: > > > >When the encryption scheme that is used is bijective, then it > > > >will not matter (to the confidentiality of the encryption) > > > >whether AtE or EtA is used, as long as authentication covers the > > > >exact same information in both cases, i.e. *ALL* of it, padding > > > >included. > > >=20 > > > However you do need to to MAC the IV. > >=20 > > Correct.=20 >=20 > Re-thinking it, I believe it would be OK to _not_ cover the CBC-IV in > the AtE, while you *MUST* cover the IV in the EtA case. Look at the CBC decrypt operation again. If I can modify the IV, I can modify the first block of your plaintext. So much for authentication... --=20 Scott Schmit --gBBFr7Ir9EOA20Yy Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTYwMzEzMTJaMCMG CSqGSIb3DQEJBDEWBBR7G3mreL4PZkgeOdMcmkrETdhXwzB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQB0wlGx6OPPY1AH+RishPTsDnoD0mjap7oae5Gz3D8NybR33GPwEl0G vKJlXu1E9SXVMnmeC/O+tMYyZGPAZECIhWgAb17Y4h1sbIENIsBu7Zc1pdiUQZnyQYtgK8rR YGijjCxyArpNY3pQNzFDK09MzyURE68Tvard3kUm5zHfSGh119NAevooR/kATPQJRKcrB0C5 YUC303Tez+4leO78TWWpJt5+0miP00hCNwm9RJxndUpbJLPDtPKOgdmpB5kkvXFGMjaFvjYk 4w+A2JOIyU1i1xVBEB4f9duoT9Ax3dwxavFl53ecWkUdP+Xz7mBQpry9QKsjGpK49PBGgDB/ --gBBFr7Ir9EOA20Yy-- From mrex@sap.com Fri Feb 15 20:54:00 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC1E21F8573 for ; Fri, 15 Feb 2013 20:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.233 X-Spam-Level: X-Spam-Status: No, score=-10.233 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6oTzZYszUvn for ; Fri, 15 Feb 2013 20:53:59 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 578C621F8570 for ; Fri, 15 Feb 2013 20:53:58 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1G4ruqW008596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 16 Feb 2013 05:53:56 +0100 (MET) In-Reply-To: <20130216031312.GA21026@odin.ulthar.us> To: Scott Schmit Date: Sat, 16 Feb 2013 05:53:56 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130216045356.16F8A1A580@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 04:54:00 -0000 Scott Schmit wrote: > On Mon, Feb 11, 2013 at 04:33:27PM +0100, Martin Rex wrote: > > Martin Rex wrote: > > > > >When the encryption scheme that is used is bijective, then it > > > > >will not matter (to the confidentiality of the encryption) > > > > >whether AtE or EtA is used, as long as authentication covers the > > > > >exact same information in both cases, i.e. *ALL* of it, padding > > > > >included. > > > > > > > > However you do need to to MAC the IV. > > > > > > Correct. > > > > Re-thinking it, I believe it would be OK to _not_ cover the CBC-IV in > > the AtE, while you *MUST* cover the IV in the EtA case. > > Look at the CBC decrypt operation again. If I can modify the IV, I can > modify the first block of your plaintext. So much for authentication... I'm sorry, but I fail to see what your comment refers to. The CBC-IV is either part of the ciphertext or part of the keying material, but never part of the plaintext. For Authenticate-then-Encrypt (AtE), it is unnecesary to cover the IV by the Authentication (it is also not currently done in TLS), and independent of whether the CBC-IV is part of the keying material as in SSLv3/TLSv1.0 or part of the ciphertext as in TLSv1.1+. For Encrypt-then-Authenticate, you MUST cover the CBC-IV by the authentication when it is part of the ciphertext (TLSv1.1+), and you MAY cover the CBC-IV (or not) when it is part of the keying material (SSLv3/TLSv1.0) -Martin From i.grok@comcast.net Fri Feb 15 21:09:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2501F0C4E for ; Fri, 15 Feb 2013 21:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd+9E6TPMI6Q for ; Fri, 15 Feb 2013 21:09:16 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4EE1F0C36 for ; Fri, 15 Feb 2013 21:09:16 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id 0sfB1l0061GhbT853t96NK; Sat, 16 Feb 2013 05:09:06 +0000 Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta07.westchester.pa.mail.comcast.net with comcast id 0t951l00S2Ekl483Tt96YL; Sat, 16 Feb 2013 05:09:06 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.5/8.14.5) with ESMTP id r1G595BQ022243 for ; Sat, 16 Feb 2013 00:09:05 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.14.5/8.14.5/Submit) id r1G595DQ022242 for tls@ietf.org; Sat, 16 Feb 2013 00:09:05 -0500 Date: Sat, 16 Feb 2013 00:09:05 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20130216050905.GB21026@odin.ulthar.us> Mail-Followup-To: tls@ietf.org References: <20130216031312.GA21026@odin.ulthar.us> <20130216045356.16F8A1A580@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline In-Reply-To: <20130216045356.16F8A1A580@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1360991346; bh=E3nTNmMCqDcRxMu1Uz74Q71eCR/xiB08/YuLhqMVe/s=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=CggmjcODq1mLz/Ftopwa5wEfGecGklk7cy27llYTDGCrOs07mGzu0xUqj0zgv3PBU CN270yDRTH/F2Vb1iwjrKYUojzXnZo44Ln3mSVYwN7ml/RUfsP/04vCclcKV7WES28 1ziJ4eCnP+EZxaMhEmrLyMYf2rbvwZCSdZhPZ4HsYDF4meCd5pghXLgsVB1EQUGqfV 5zGJ0h3MLrtCHyxeuqMZrph1psKnCVxbIXxb1XbSiCtg9bPjZcWgfWlc4Y3fMbMn5I q/b9RbgyjyjQ3Ibhqs+Rtr8DDUOxix67Unok4U7NrS51JWLyQRmoAE5/zNpXzC2Waz LG1oAva+Ijlqw== Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 16 Feb 2013 05:09:17 -0000 --WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 16, 2013 at 05:53:56AM +0100, Martin Rex wrote: > Scott Schmit wrote: > > On Mon, Feb 11, 2013 at 04:33:27PM +0100, Martin Rex wrote: > > > Re-thinking it, I believe it would be OK to _not_ cover the CBC-IV in > > > the AtE, while you *MUST* cover the IV in the EtA case. > >=20 > > Look at the CBC decrypt operation again. If I can modify the IV, I can > > modify the first block of your plaintext. So much for authentication... >=20 > I'm sorry, but I fail to see what your comment refers to. >=20 > The CBC-IV is either part of the ciphertext or part of the keying materia= l, > but never part of the plaintext. >=20 > For Authenticate-then-Encrypt (AtE), it is unnecesary to cover the IV > by the Authentication (it is also not currently done in TLS), and > independent of whether the CBC-IV is part of the keying material > as in SSLv3/TLSv1.0 or part of the ciphertext as in TLSv1.1+. >=20 > For Encrypt-then-Authenticate, you MUST cover the CBC-IV by the > authentication when it is part of the ciphertext (TLSv1.1+), and > you MAY cover the CBC-IV (or not) when it is part of the keying > material (SSLv3/TLSv1.0) Ah, right. I misread. Sorry for the noise. --=20 Scott Schmit --WhfpMioaduB5tiZL Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIQBAYJKoZIhvcNAQcCoIIP9TCCD/ECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DTUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBvkwggXhoAMCAQICAwR4CjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEyMDcwNDEz NTc1MVoXDTEzMDcwNTA1MjcyNlowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCxn+QJTgdUJ1RAOi6JbFsDfl21ZX/OPx/ttuXWQP1vWwBZybHU+4/+bRXH 5ONhjbc5ikZvz/E406iQLy2xMT5PI/hx4uIZQQYpkjxd4rCbbvLNACz5L+cFaGj4WfGwAXDv bw4nx8Mh3WjbR5yjBCWYqadiv7HWAWmhaJmuaTp/e+mO2EEOOdoNQ8b2mxMyN43TlElx6Zos t7g/eQUcLWgTB5apPhowCCGnFU6uHK053QsPmsmZ67gg8acpb5ic0+P+X1j+IgD3jcsDzjrF TPlrvU4ZuBYQJISqngbc2ua/uutx75Xs4iFXWNRlnYfZMFJy96USzrhIBRqcORrjbyGXAgMB AAGjggOtMIIDqTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwHQYDVR0OBBYEFAxkdHPHW3mhf+gXJjezdazgoDRuMB8GA1UdIwQYMBaA FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC AiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVzIGFyZSBsaW1pdGVkISBT ZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0aGUgU3RhcnRDb20gQ0Eg cG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9h aWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBACJi0f4m 0bSVq+pq4AHeC2Rj4S8rciW+Uce6LC69UlyVMijKv/pZNFM08vqRXEI9WpKQhKXacJ+rK9az DBmnxq1scqKhn7991V6Yt2t0tEY8vUX7q330GybUB/rQLNrh66GFXaEWU/S692pGzvUXeV+w zz48snMpoMHQdxkHHW5sQkpo99SF/vOA5/sqvFmJ+ai1iDRjtKcChjkmAtFmCKv/dNrXnvew 5+QnLlnE/TsW4Sdv3bcLdlthD4eavS3BdgXfX7dfj0ykel53J2Us3CikNbyuCsJpwMH+gX1j LcXZOYIDLzZXCFEOFajhgsAZ5JQrW0fFRxjGIp8Rs+rxdFwxggKXMIICkwIBATCBlDCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEeAowCQYFKw4DAhoFAKCB2DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzAyMTYwNTA5MDVaMCMG CSqGSIb3DQEJBDEWBBSb7jE6pN4xG34/3rbuSb9RMBtM4jB5BgkqhkiG9w0BCQ8xbDBqMAsG CWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkq hkiG9w0BAQEFAASCAQAkQbm2P6WaN6K3xlb9kSYl1MHhoSYbv3urwJrijUBRef3piXiEAVp1 0xY0j1eJkGNCbZ6+6lXZoW/GbYiRwWohaCgEgcD3IAUxKTItUSaCQwgK+urEDW7ii+RgERP6 7boOSNWV1RLzfBzrvttVBeXTMHItdhOdKgAuiIxqf3qjqP13nTho5ee896KqpZ4leC482B5p MYjoG7pf7j2r2LSCOn3H7qLZi9DOACGFPH4oC4m9Hoo8dK4KvK8idxpj+17tmEWO1xmxS1JN /+Y8bv1ZhdfzcM/YcXNkJUce8aY1Nv223KBxGOOItIaxcF6jKtPrguzeKG/Pa0jb+x6/jeeg --WhfpMioaduB5tiZL-- From pgut001@cs.auckland.ac.nz Sat Feb 16 03:46:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1372321F898A for ; Sat, 16 Feb 2013 03:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1aaPjvwPDD+k for ; Sat, 16 Feb 2013 03:46:43 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.244]) by ietfa.amsl.com (Postfix) with ESMTP id B3AB121F86AD for ; Sat, 16 Feb 2013 03:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1361015203; x=1392551203; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=RDdWHXQdP3qR6R9nqZVXu/S9QAey/hZs5wnqEG29OQI=; b=j8sDhNhQPX72ZEXCERVUGLZ+JAGvdMcZPOh+AAczCA2CVXsoeZgTetZS fyFV5ZQ6ScitcaVjXbwZRVtUxjQIrc/gf3/L8eovy5o1V8ewb/IfM3jE+ lmgQgI+8avl+DrZla73UIz2p2PErbgeKfPMyhXuQ8gyDMDmihj1AX1Wcz E=; X-IronPort-AV: E=Sophos;i="4.84,678,1355050800"; d="scan'208";a="170747127" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Feb 2013 00:46:40 +1300 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sun, 17 Feb 2013 00:46:39 +1300 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.108]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Sun, 17 Feb 2013 00:46:39 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS1.3 Thread-Index: Ac4MO0gR2nWvv6hzRdusDSKOAABC8A== Date: Sat, 16 Feb 2013 11:46:39 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C733340BF41@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-GB, en-NZ, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 16 Feb 2013 11:46:44 -0000 Wan-Teh Chang writes:=0A= >On Mon, Feb 11, 2013 at 3:13 PM, Peter Gutmann = wrote:=0A= >> In what way would HMAC-MD5 be "too weak"? I agree that HMAC-SHA1/=0A= >> SHA256 are a better proposition, but using HMAC-MD5 should be up to=0A= >> the implementer in any case. I've deprecated it for some years now, the= =0A= >> minimum I'll do is HMAC-SHA1. It's not as if there's a shortage of suit= es=0A= >> to choose from, and I've never found anything that does only -MD5 and=0A= >> not -SHA1.=0A= >=0A= >There are some websites that enable only one cipher suite:=0A= >TLS_RSA_WITH_RC4_128_MD5. You can find some examples in this Chromium bug= =0A= >report: https://code.google.com/p/chromium/issues/detail?id=3D118330=0A= =0A= Hmm, interesting. The discussion however points out that this issue is fro= m a=0A= misconfigured server, so I don't think it really generalises.=0A= =0A= Peter.=0A= From Brian.Raymor@microsoft.com Sun Feb 17 14:52:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4521F85A0 for ; Sun, 17 Feb 2013 14:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SBGPMrmx+FH for ; Sun, 17 Feb 2013 14:52:49 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.31]) by ietfa.amsl.com (Postfix) with ESMTP id D1DDE21F8574 for ; Sun, 17 Feb 2013 14:52:48 -0800 (PST) Received: from BY2FFO11FD018.protection.gbl (10.1.15.200) by BY2FFO11HUB015.protection.gbl (10.1.14.88) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 17 Feb 2013 22:52:38 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD018.mail.protection.outlook.com (10.1.14.106) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 17 Feb 2013 22:52:38 +0000 Received: from CO9EHSOBE015.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 17 Feb 2013 22:52:33 +0000 Received: from mail43-co9-R.bigfish.com (10.236.132.250) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.23; Sun, 17 Feb 2013 22:52:32 +0000 Received: from mail43-co9 (localhost [127.0.0.1]) by mail43-co9-R.bigfish.com (Postfix) with ESMTP id D740BA40160 for ; Sun, 17 Feb 2013 22:52:32 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -11 X-BigFish: PS-11(zz98dI9371Ia65R14ffIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz17326ah8275bhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh9a9j1155h) Received-SPF: softfail (mail43-co9: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Brian.Raymor@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2PR03MB605; H:BL2PR03MB605.namprd03.prod.outlook.com; LANG:en; Received: from mail43-co9 (localhost.localdomain [127.0.0.1]) by mail43-co9 (MessageSwitch) id 1361141550607671_20595; Sun, 17 Feb 2013 22:52:30 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.246]) by mail43-co9.bigfish.com (Postfix) with ESMTP id 887CE30004A for ; Sun, 17 Feb 2013 22:52:30 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 17 Feb 2013 22:52:30 +0000 Received: from BL2PR03MB605.namprd03.prod.outlook.com (10.255.109.39) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.275.5; Sun, 17 Feb 2013 22:52:24 +0000 Received: from BL2PR03MB605.namprd03.prod.outlook.com (10.255.109.39) by BL2PR03MB605.namprd03.prod.outlook.com (10.255.109.39) with Microsoft SMTP Server (TLS) id 15.0.620.10; Sun, 17 Feb 2013 22:52:23 +0000 Received: from BL2PR03MB605.namprd03.prod.outlook.com ([169.254.12.56]) by BL2PR03MB605.namprd03.prod.outlook.com ([169.254.12.56]) with mapi id 15.00.0620.005; Sun, 17 Feb 2013 22:52:23 +0000 From: "Brian Raymor (MS OPEN TECH)" To: "tls@ietf.org" Thread-Topic: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted Thread-Index: Ac4NXRc9L3q3bRXhSMmI6ZVp5WL6WQ== Date: Sun, 17 Feb 2013 22:52:22 +0000 Message-ID: <5204633e4339437fbd5e6fc1e4b264ec@BL2PR03MB605.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.17.61.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB605.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(53754002)(26614001)(24454001)(65816001)(31966008)(74502001)(76482001)(47446002)(23726001)(74662001)(44976002)(15202345001)(46406002)(6806001)(16676001)(33646001)(79102001)(46102001)(5343635001)(66066001)(63696002)(56776001)(80022001)(56816002)(20776003)(47776003)(59766001)(54356001)(77982001)(53806001)(47976001)(4396001)(47736001)(54316002)(50466001)(51856001)(50986001)(49866001)(59253001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB015; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07607ED19A Subject: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 22:52:50 -0000 Our HTML5 Labs prototype is the first implementation that is based on the a= pplayerprotoneg-01 internet draft. It is an evolution of earlier prototypes= that couples a modified command-line C# client with a basic HTTP/2.0 serve= r. We plan to further develop it in the coming weeks and look forward to yo= ur feedback both on the TLS WG mailing list and through HTML5 Labs.=20 http://html5labs.interoperabilitybridges.com/prototypes/alpn/alpn/info Brian Raymor Microsoft Open Technologies, Inc.=20 A subsidiary of Microsoft Corporation On Feb 6, 2013, at 5:09 AM, Stephan Friedl (sfriedl) = wrote: Hello All, =20 A revised version of 'Transport Layer Security (TLS) Application Layer Pro= tocol Negotiation Extension' (draft-friedl-tls- applayerprotoneg-01) has be= en posted. This version includes a number of significant improvements to t= he original draft including: =20 1. Use of a single extension for both the ClientHello and Serve= rHello messages 2. Definition of ProtocolIdentifiers as opaque, non-empty byte = strings and the list of protocols is serialized as a concatenation of 8-b= it, length prefixed byte strings 3. Clarification of the suggested order of client-side Protocol= Identifiers 4. Clarification that the server-side extension_data MUST conta= in exactly one ProtocolIdentifier 5. Should the server support none of the protocols advertised b= y the client, then the server SHALL respond with a 'fatal handshake failu= re alert'. 6. Addition of Andrei Popov of Microsoft as a co-author =20 These changes were largely proposed by Andrei and have greatly improved th= e draft. =20 I would greatly appreciate any comments and feedback on the draft. =20 Thanks and Best Wishes, =20 Stephan From hannes.tschofenig@gmx.net Tue Feb 19 09:30:59 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66D521F8E5B for ; Tue, 19 Feb 2013 09:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrUcGcSXFR09 for ; Tue, 19 Feb 2013 09:30:49 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A930A21F8E4D for ; Tue, 19 Feb 2013 09:30:48 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MXkWv-1ULL9M2nJf-00WkIK for ; Tue, 19 Feb 2013 18:30:47 +0100 Received: (qmail invoked by alias); 19 Feb 2013 17:30:47 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.219.140] by mail.gmx.net (mp030) with SMTP; 19 Feb 2013 18:30:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+pjv0skoap/tLOycZU7BMr6dS4SN3VTbgzqrig6i X5Q8yNn13XPvPl From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Feb 2013 19:30:45 +0200 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [TLS] draft-ietf-tls-oob-pubkey-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:31:00 -0000 Hi all,=20 as you have seen I have submitted an updated version of the "Out-of-Band = Public Key Validation for Transport Layer Security (TLS)" document. The latest draft can be found at:=20 http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07 Diff to the previous version:=20 http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-07.txt Here is a summary of the changes: * Clarifications regarding the SubjectPublicKeyInfo structure, as = described in = http://www.ietf.org/mail-archive/web/tls/current/msg09129.html * Re-use of the existing TLS cert_type registry, as mentioned in this = discussion thread: = http://www.ietf.org/mail-archive/web/tls/current/msg09130.html * Changes regarding the encoding of the exchange, as described by Nikos = in http://www.ietf.org/mail-archive/web/tls/current/msg09093.html * Barry Leiba provided guidance on the IANA consideration section.=20 In case I missed something please let me know before the final cut-off = date.=20 Ciao Hannes From jsalowey@cisco.com Tue Feb 19 15:09:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CE721F894E for ; Tue, 19 Feb 2013 15:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF7seaZ5-bS5 for ; Tue, 19 Feb 2013 15:09:58 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7718921F882A for ; Tue, 19 Feb 2013 15:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1550; q=dns/txt; s=iport; t=1361315397; x=1362524997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=y43f8lSaaeFDPxj5ekyGVUiksC92QxEejbwHjK5zAOs=; b=QWqkJRxd6+qNo/WxiYjZAP2fGftylRgIXSG+A8h3uv0PnFL0mj/wQbPE SItfGPmNITbCk5QqsxTw8yw9cmtX0+mXZFIAwI8+4AXjDS6CrNKeI7joI QYLf0ra76xuTO5tRsHJrmeNwS+TMu9Cop3e+fQ85dGhCc2aVE1kjLkNN9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPwEJFGtJV2Y/2dsb2JhbABFwESBDRZzgh8BAQEDAQEBATc0CwULAgEIIhQQJwslAgQOBQgBh3cDCQYMsC6QJ4w3gRaBDgIxAgWCX2EDl0iPO4MHgWsHFwYY X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="178926406" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 19 Feb 2013 23:09:57 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1JN9v6L006365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Feb 2013 23:09:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 17:09:56 -0600 From: "Joseph Salowey (jsalowey)" To: Hannes Tschofenig Thread-Topic: [TLS] draft-ietf-tls-oob-pubkey-07 Thread-Index: AQHODsb6jMKDDyTgMEGxANt1Jzf/nJiCM30A Date: Tue, 19 Feb 2013 23:09:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <9DFEB2C8503C8D4EAFAEBDF18C196FA8@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] draft-ietf-tls-oob-pubkey-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:09:58 -0000 Thanks Hannes, I believe this resolves all the open issues with the draft raised in last c= all. Since its been a few revisions I'll run a final review of the draft= until 3/6/2013 before submitting to the IESG.=20 Cheers, Joe On Feb 19, 2013, at 9:30 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > as you have seen I have submitted an updated version of the "Out-of-Band = Public Key Validation for Transport Layer Security (TLS)" document. >=20 > The latest draft can be found at:=20 > http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-07 >=20 > Diff to the previous version:=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-oob-pubkey-07.txt >=20 > Here is a summary of the changes: >=20 > * Clarifications regarding the SubjectPublicKeyInfo structure, as describ= ed in http://www.ietf.org/mail-archive/web/tls/current/msg09129.html > * Re-use of the existing TLS cert_type registry, as mentioned in this dis= cussion thread: http://www.ietf.org/mail-archive/web/tls/current/msg09130.h= tml > * Changes regarding the encoding of the exchange, as described by Nikos i= n http://www.ietf.org/mail-archive/web/tls/current/msg09093.html > * Barry Leiba provided guidance on the IANA consideration section.=20 >=20 > In case I missed something please let me know before the final cut-off da= te.=20 >=20 > Ciao > Hannes >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Tue Feb 19 15:10:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA90821F8A3F for ; Tue, 19 Feb 2013 15:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i61Y9QoBQCso for ; Tue, 19 Feb 2013 15:10:18 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9A26621F8A3D for ; Tue, 19 Feb 2013 15:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=261; q=dns/txt; s=iport; t=1361315418; x=1362525018; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=bI2Fdi+hYr2gt5J24jjv+MM9DSRCM38lR9TNoU0PvCY=; b=IQ7W7ODD16738YWT8EHN+KBzTfu4OJlpm5iqylWEVf4btkXBlj1FFFpI Mu6ELN5HBmrc/RvSaD/d/OqFSN8UynhLRV64S5OSVec7b/qDKdbj6CbMf XTQ60NA0wFeof0zxZagixqneZt3AJoNf76vEAYzjemSaqsuX1lxlXWudh 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC0GJFGtJXG8/2dsb2JhbABFwESBDRZzgiEBBDpRASoUQicEG4gKnyaRE5Anjl2DF2EDpwODB4In X-IronPort-AV: E=Sophos;i="4.84,698,1355097600"; d="scan'208";a="178708475" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 19 Feb 2013 23:10:14 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1JNAEFp016199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Feb 2013 23:10:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 19 Feb 2013 17:10:13 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Final Review for draft-ietf-tls-oob-pubkey-07 Thread-Index: AQHODvZF4rbcMuxOW0+dsTojZi1dWQ== Date: Tue, 19 Feb 2013 23:10:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <093FD3325182C14F9E689DABFAF641F5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Final Review for draft-ietf-tls-oob-pubkey-07 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 23:10:19 -0000 A new revision of draft-ietf-tls-oob-pubkey-07 has been submitted that addr= esses all issues raised in Working Group Last Call. This is a final review= before submitting to IESG. Please send any comments you have to the TLS l= ist by March 6, 2013. =20 From jsalowey@cisco.com Wed Feb 20 14:44:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760B21E8037 for ; Wed, 20 Feb 2013 14:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIJ-1VSomFon for ; Wed, 20 Feb 2013 14:44:15 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A7DD321E8030 for ; Wed, 20 Feb 2013 14:44:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1361400255; x=1362609855; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uUS42326qZKonM2yWUC2X3WcqX1dEMSwY35cKJvIA9k=; b=jvYX28upe/Iu4UgAg8DcCVxfHtRHvvNY60q1Nw04/H9Nb0LW0sqmvdSC wwzj6ZuAv7qM0h+/tq4sOqP6JaBI406Qk6lrUiDYx4jLrVbH+A/g/XRtH xLMpB5G+eVzFxH7RWX2ZARSVaaQo5nMbOkZ2qrqU90QBXsbaMn7wscnHm s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFpRJVGtJXG+/2dsb2JhbABFwGOBAxZzgiEBBDpRASoLCUInBBuICp9FoRGOXUKCVWEDkm2UGoMHgic X-IronPort-AV: E=Sophos;i="4.84,705,1355097600"; d="scan'208";a="179409273" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 20 Feb 2013 22:44:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1KMiFW5022042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 20 Feb 2013 22:44:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 16:44:15 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Cached-info draft open issues Thread-Index: AQHOD7vOEQmEkKvPOU2LJJMPtLylnw== Date: Wed, 20 Feb 2013 22:44:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <6390AE9BFC1CB94AAD2B737ACAFE93A1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Cached-info draft open issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 22:44:16 -0000 According to my notes we have the following open issue with the draft-ietf-= tls-cached-info-13. 1) Whether to include the confirmation of cached objects in the response f= rom the server and what to include in the server hello. We had some discuss= ion earlier on the list. While it didn't seem that we had strong consensu= s I think this is roughly where things are at: + The inclusion or elimination of the hashed values in some messages could = cause ambiguities. Martin Rex raised the issue that the certificate_author= ities field may be empty or contain small values that could be confused wit= h a hash. =20 + The server can indicate which cached objects it accepts in the server hel= lo. =20 + The server can then send an empty field in place of the objects it would = normally send + The spec would have to define how the empty field was defined for each ty= pe. =20 + In order to handle the caching of intermediate certificates a cached obje= ct type would be defined for it and the spec would define how the server ce= rtificate message is formatted to account for the cached certificates. =20 I'm looking for comments on this approaches and contributions of text for t= he document. Thanks, Joe From hannes.tschofenig@gmx.net Thu Feb 21 03:16:01 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D761221F8E6F for ; Thu, 21 Feb 2013 03:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.988 X-Spam-Level: X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AM3ytVhrWNr for ; Thu, 21 Feb 2013 03:16:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF4A21F8E6D for ; Thu, 21 Feb 2013 03:16:00 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M7FY8-1V2GDL0Ady-00x4oh for ; Thu, 21 Feb 2013 12:15:57 +0100 Received: (qmail 26382 invoked by uid 0); 21 Feb 2013 11:15:56 -0000 Received: from 194.251.119.197 by www039.gmx.net with HTTP; Thu, 21 Feb 2013 12:15:55 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Thu, 21 Feb 2013 12:15:55 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20130221111555.19950@gmx.net> MIME-Version: 1.0 References: To: "Joseph Salowey (jsalowey)" , tls@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18LQGkIBhcLYHPnomcHUDS2oj0cS5QHUm2LbAf8QS Uvtm+kQTz0Xnxdi2RsTT5ouODiZUDyieDjkg== Content-Transfer-Encoding: 8bit X-GMX-UID: vGRUca9meSEqTJIAqXUhB3p+IGRvb4BQ Subject: Re: [TLS] Cached-info draft open issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 11:16:01 -0000 Hi Joe, thanks for your mail. Here is a proposal for a simplification: client_hello, cached_info=(certificate) -> // [1] <- server_hello, cached_info= // [2] (certificate) server_key_exchange, server_hello_done client_key_exchange, change_cipher_spec, finished -> <- change_cipher_spec, finished Application Data <-------> Application Data [1] This would indicate that the client supports the TLS cached info extension and that he has a certificate for the server cached. Note that I simplified the exchange a bit and just say that the certificate payload altogether has been cached rather than individual parts of it. The hash of the certificate would still be carried in the client hello cached_info extension to give the server an idea what had been cached. [2] The server indicates that it also supports the certificate payload omission. It would then omit the certificate payload from the response message. (Alternatively, we could return an empty payload.) When the client receives the server hello it uses the cached certificate payload. Ciao Hannes > -------- Original-Nachricht -------- > Datum: Wed, 20 Feb 2013 22:44:14 +0000 > Von: "Joseph Salowey (jsalowey)" > An: "" > Betreff: [TLS] Cached-info draft open issues >  According to my notes we have the following open issue with the draft-ietf-tls-cached-info-13. 1) Whether to include the confirmation of cached objects in the response from the server and what to include in the server hello. We had some discussion earlier on the list. While it didn't seem that we had strong consensus I think this is roughly where things are at: + The inclusion or elimination of the hashed values in some messages could cause ambiguities. Martin Rex raised the issue that the certificate_authorities field may be empty or contain small values that could be confused with a hash. + The server can indicate which cached objects it accepts in the server hello. + The server can then send an empty field in place of the objects it would normally send + The spec would have to define how the empty field was defined for each type. + In order to handle the caching of intermediate certificates a cached object type would be defined for it and the spec would define how the server certificate message is formatted to account for the cached certificates. I'm looking for comments on this approaches and contributions of text for the document. Thanks, Joe From jsalowey@cisco.com Thu Feb 21 15:48:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42F521E803D for ; Thu, 21 Feb 2013 15:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th4rELV6+X5A for ; Thu, 21 Feb 2013 15:48:14 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C9B8C21E8039 for ; Thu, 21 Feb 2013 15:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3649; q=dns/txt; s=iport; t=1361490494; x=1362700094; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yDeYuoS+dbPf6aYi9BZAjafCqeJhweUaOi/3TYfJxvM=; b=A/rxlEpXoAtlPx/iZCfkzbYFkc0GjvIeOWSewP2lfHxLK52qME+e1Cw1 ch+0QzqeqU+S2IJY3DmjKUzD1x0uVh20qGSVfUKEYZk/A34tQHC36Q7bI hQF4nYlI4pUOoS8xIo0MClYwE7zqjLfw7bBwKVR3HnSmKTGIK4E4Yn3i+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALqxJlGtJXG+/2dsb2JhbABFwRKBBhZzgh8BAQEDAScTLRIFCwIBCCILCRAyJQIEDgUIh3gDCQa/Low3gRaBDgIGKwcKglVhA5J2lB6DB4FyNQ X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179882124" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2013 23:48:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1LNmESj009969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 23:48:14 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 17:48:14 -0600 From: "Joseph Salowey (jsalowey)" To: Hannes Tschofenig Thread-Topic: [TLS] Cached-info draft open issues Thread-Index: AQHOD7vOEQmEkKvPOU2LJJMPtLyln5iEjr+AgADSMYA= Date: Thu, 21 Feb 2013 23:48:13 +0000 Message-ID: References: <20130221111555.19950@gmx.net> In-Reply-To: <20130221111555.19950@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <0ACBE7735C6110478DACBB34BB7B743E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Cached-info draft open issues X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:48:15 -0000 On Feb 21, 2013, at 3:15 AM, Hannes Tschofenig = wrote: > Hi Joe,=20 >=20 > thanks for your mail. Here is a proposal for a simplification:=20 >=20 > client_hello, > cached_info=3D(certificate) -> // [1] > <- server_hello, > cached_info=3D // [2] > (certificate) > server_key_exchange, > server_hello_done >=20 > client_key_exchange, > change_cipher_spec, > finished -> >=20 > <- change_cipher_spec, > finished >=20 > Application Data <-------> Application Data >=20 >=20 > [1] This would indicate that the client supports the TLS cached info exte= nsion and that he has a certificate for the server cached.=20 >=20 > Note that I simplified the exchange a bit and just say that the certifica= te payload altogether has been cached rather than individual parts of it. >=20 > The hash of the certificate would still be carried in the client hello ca= ched_info extension to give the server an idea what had been cached.=20 >=20 > [2] The server indicates that it also supports the certificate payload om= ission. It would then omit the certificate payload from the response messag= e. (Alternatively, we could return an empty payload.) >=20 > When the client receives the server hello it uses the cached certificate = payload.=20 >=20 [Joe] I think we want to support two cases 1) the whole certificate message= is cached. 2) just the intermediate certificate(s) in the chain are cache= d. I think your description works well for the first case. I believe it w= ould support the second if it could return a certificate message with just = the end-entity cert and any intermediate certs that were not cached. We co= uld use the same cached info type for both these cases. I would be OK with= that. I'd also be OK with using two different cached info types for the = two different cases. =20 > Ciao > Hannes >=20 >> -------- Original-Nachricht -------- >> Datum: Wed, 20 Feb 2013 22:44:14 +0000 >> Von: "Joseph Salowey (jsalowey)" >> An: "" >> Betreff: [TLS] Cached-info draft open issues >> =20 > According to my notes we have the following open issue with the draft-iet= f-tls-cached-info-13. >=20 > 1) Whether to include the confirmation of cached objects in the response= from the server and what to include in the server hello. We had some discu= ssion earlier on the list. While it didn't seem that we had strong consen= sus I think this is roughly where things are at: >=20 > + The inclusion or elimination of the hashed values in some messages coul= d cause ambiguities. Martin Rex raised the issue that the certificate_auth= orities field may be empty or contain small values that could be confused w= ith a hash. =20 > + The server can indicate which cached objects it accepts in the server h= ello. =20 > + The server can then send an empty field in place of the objects it woul= d normally send > + The spec would have to define how the empty field was defined for each = type. =20 > + In order to handle the caching of intermediate certificates a cached ob= ject type would be defined for it and the spec would define how the server = certificate message is formatted to account for the cached certificates. =20 >=20 > I'm looking for comments on this approaches and contributions of text for= the document. >=20 > Thanks, >=20 > Joe From pkix@inbox.lv Fri Feb 22 03:25:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25EF321F8C5D for ; Fri, 22 Feb 2013 03:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_20=-0.74, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yRfoStYo5Ndp for ; Fri, 22 Feb 2013 03:25:03 -0800 (PST) Received: from shark3.inbox.lv (shark3.inbox.lv [89.111.3.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD8621F87E7 for ; Fri, 22 Feb 2013 03:25:03 -0800 (PST) Received: by shark3.inbox.lv (Postfix, from userid 1000) id E9EAA110B8; Fri, 22 Feb 2013 13:25:00 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark3-plain-b64d2.inbox.lv (Postfix) with ESMTP id 89DA711048 for ; Fri, 22 Feb 2013 13:25:00 +0200 (EET) Received: from localhost ([10.0.1.16]) by localhost (shark3.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id I58lGsxLpt1N for ; Fri, 22 Feb 2013 13:25:00 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Fri, 22 Feb 2013 13:25:00 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w6.inbox.lv, l=en, compose=HTML X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17 Message-ID: <1361532300.5127558c6d0bf@mail.inbox.lv> Date: Fri, 22 Feb 2013 13:25:00 +0200 From: "Andris Berzins" To: tls@ietf.org User-Agent: Inbox.lv Webmail Subject: [TLS] TLS session resumption lifetime X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 22 Feb 2013 11:25:04 -0000 Hello,

 
=  
Can anyone comment whether TLS session lifetime is enforced by = browsers?

Thank you! From turners@ieca.com Fri Feb 22 07:15:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BE621F8E47 for ; Fri, 22 Feb 2013 07:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.725 X-Spam-Level: X-Spam-Status: No, score=-101.725 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbva4SgjWo+E for ; Fri, 22 Feb 2013 07:15:16 -0800 (PST) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.205.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1E521F8E2C for ; Fri, 22 Feb 2013 07:15:16 -0800 (PST) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 351BD9520364; Fri, 22 Feb 2013 09:15:14 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 56349951FF0B for ; Fri, 22 Feb 2013 09:15:14 -0600 (CST) Received: from [108.45.16.214] (port=60168 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1U8uLB-0005Zf-U9 for tls@ietf.org; Fri, 22 Feb 2013 09:15:14 -0600 Message-ID: <51278B81.9070809@ieca.com> Date: Fri, 22 Feb 2013 10:15:13 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:60168 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] AD review of draft-ietf-tls-multiple-cert-status-extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 15:15:16 -0000 Two questions, one comment, and one thing to note: Q1: Is text needed that restricts the number of requests that can go with case ocsp to 1? e.g.,: The list of CertificateStatusRequestItem entries MUST be in order of preference. When used with case ocsp, only one request item is allowed. When used with case ocsp_multi, more than one request is allowed. Q2: Should there be an error if case ocsp is used with multiple requests or when case ocsp_multi is used with only one request? C1: CCITT was long ago renamed ITU. How about we change: r/[CCITT.X680.2002]/[X680.2002] r/[CCITT.X690.2002]/[X690.2002] and use the same references from RFC 5246: [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). N1: OCSP is also about to be in last call so the references will likely be updated to point to it at some point. spt From sfriedl@cisco.com Fri Feb 22 08:43:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CEC21F8E92 for ; Fri, 22 Feb 2013 08:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD9uSvPKpDB5 for ; Fri, 22 Feb 2013 08:43:05 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6C21F8E53 for ; Fri, 22 Feb 2013 08:43:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4810; q=dns/txt; s=iport; t=1361551385; x=1362760985; h=from:to:subject:date:message-id:mime-version; bh=sXi8AZVdtFMzVHXl2DSEYOGBRTQLW5QuOKKwpT8crNs=; b=eV6czHe5nCvSNiHEua6wrrbNR15vDVhKhBIRpYMZ2E5EaFin5RwUN95m C3KUXf/V2Y3G/AxDeyfHTs4Tw6YLqYKuUFJo5r+GY+SXytUKoXo9YAKEP n3w7792k5boAgCBQYOY+Bhk9Qw/7q7KdFT+b+A9wRGDBfsXnADbTJzGPU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADufJ1GtJXG9/2dsb2JhbABEgkO+YIEKFnOCIQEELV4BKlYmAQQbiAqeQaENjl2DF2EDpx2DB4In X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208,217";a="179915097" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 22 Feb 2013 16:43:05 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1MGh5Jo013690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Feb 2013 16:43:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 10:43:05 -0600 From: "Stephan Friedl (sfriedl)" To: "tls@ietf.org" Thread-Topic: Revision draft-friedl-tls-applayerprotoneg-02 Posted Thread-Index: Ac4RG67UeAcrhMywR3iT9QNgy/S49w== Date: Fri, 22 Feb 2013 16:43:04 +0000 Message-ID: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.37.98] Content-Type: multipart/alternative; boundary="_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67xmbalnx02ciscoc_" MIME-Version: 1.0 Subject: [TLS] Revision draft-friedl-tls-applayerprotoneg-02 Posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:43:07 -0000 --_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A revision of draft-friedl-tls-applayerprotoneg has been posted. The follo= wing changes have been introduced into the draft in response to feedback fr= om the working group: 1. Section 3.1 "Application Layer Protocol Negotiation Extension" def= ines ProtocolNameList and ProtocolName as variable-length arrays, as typica= lly done in TLS. This increases payload size by 2 bytes, but allows the use= of the normal TLS parsers. 2. Section 3.2 "Protocol Selection" defines a new fatal alert no_appl= ication_protocol, to be used with ALPN extension only, instead of using a g= eneric handshake_failure alert. This is done to help distinguish applicatio= n protocol negotiation issues from other handshake failures. We would greatly appreciate any comments and feedback on the draft. Best Wishes, Stephan Friedl, Andrei Popov --_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A revision of draft-friedl-tls-applayerprotoneg has = been posted.  The following changes have been introduced into the draf= t in response to feedback from the working group:

 

1.       Section 3.1 “Application Layer Protocol Negotiation Extension&= #8221; defines ProtocolNameList and ProtocolName as variable-length arrays,= as typically done in TLS. This increases payload size by 2 bytes, but allo= ws the use of the normal TLS parsers.

2.       Section 3.2 “Protocol Selection” defines a new fatal ale= rt no_application_protocol, to be used with ALPN extension only, instead of= using a generic handshake_failure alert. This is done to help distinguish = application protocol negotiation issues from other handshake failures.

 

We would greatly appreciate any comments and feedbac= k on the draft.

 

Best Wishes,

 

Stephan Friedl, Andrei Popov

 

--_000_2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67xmbalnx02ciscoc_-- From jsalowey@cisco.com Fri Feb 22 11:00:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5267A21F8AB6 for ; Fri, 22 Feb 2013 11:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNPMvnUEg1cV for ; Fri, 22 Feb 2013 11:00:52 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BF14921F8689 for ; Fri, 22 Feb 2013 11:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=150; q=dns/txt; s=iport; t=1361559652; x=1362769252; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=LjBpVG2AwD1rxaGFACzLVgz3GUPIVlkWIbdzF34JPto=; b=FEiA7rDVAtS8n0nTkHxMK5lil9+Slc42VcyN+l21LaO8A31PKuF20qZa KfHMC13C1j3F3qkKxGZpMBKO7xQpbd4gdi30kW2gDE6V91Cm4J+6SufoP MROUKDjNzhp2joMsMU8Mx7w8difuXLYQTcYrAwo9l9t/5q9Pq0VpQIe/y E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKK/J1GtJV2c/2dsb2JhbABEvkyCUQmBDBZzgiEBBDpRASoUQicEG4gKnjCgbY5dgxdhA6cdgweCJw X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208";a="179964627" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 22 Feb 2013 19:00:52 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1MJ0qrs020308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Feb 2013 19:00:52 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 13:00:51 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: TLS agenda items for IETF 86 Thread-Index: AQHOES7uzfLMKsTIqU25Y9+HDXMF5A== Date: Fri, 22 Feb 2013 19:00:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.249.140] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] TLS agenda items for IETF 86 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 22 Feb 2013 19:00:53 -0000 The TLS meeting is scheduled for Friday March 15, 11:20 - 13:30 Please let the chairs know if you have Items for the agenda.=20 Thanks, Joe From mrex@sap.com Fri Feb 22 13:26:34 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207BD21F8E06 for ; Fri, 22 Feb 2013 13:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.234 X-Spam-Level: X-Spam-Status: No, score=-10.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVYjGvuWqFFm for ; Fri, 22 Feb 2013 13:26:31 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1487621F8EFB for ; Fri, 22 Feb 2013 13:26:22 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1MLQKP5006463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Feb 2013 22:26:21 +0100 (MET) In-Reply-To: <1361532300.5127558c6d0bf@mail.inbox.lv> To: Andris Berzins Date: Fri, 22 Feb 2013 22:26:20 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130222212620.DACD71A5BC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS session resumption lifetime X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 21:26:34 -0000 Andris Berzins wrote: > > Hello,

 
 
Can anyone comment whether TLS session lifetime is enforced by browsers?

Thank you! What exactly do you mean with "TLS session lifetime is enforced by browsers"? There is only a _suggestion_ to not cache TLS session for more than 24 hours in TLSv1.0 (rfc2246). Often, servers may expire TLS sessions from the server side cache much earlier (our server uses a session cache lifetime of only 24 minutes by default). http://tools.ietf.org/html/rfc2246#section-7.4.1.2 7.4.1.2. Client Hello [...] The client hello message includes a variable length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier may be from an earlier connection, this connection, or another currently active connection. The second option is useful if the client only wishes to update the random structures and derived values of a connection, while the third option makes it possible to establish several independent secure connections without repeating the full handshake protocol. These independent connections may occur sequentially or simultaneously; a SessionID becomes valid when the handshake negotiating it completes with the exchange of Finished messages and persists until removed due to aging or because a fatal error was encountered on a connection associated with the session. http://tools.ietf.org/html/rfc2246#appendix-F.1.4 F.1.4. Resuming Sessions [...] Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. The time of use of a TLS session on an established connection is independent from the TLS session cache lifetime (the latter typically affects only the possibility to resume a prior session on a new connection). At least some browsers delete the TLS sessions from their TLS session cache when a new connection, where TLS session resumption was proposed, is aborted by the browser itself early during the handshake, e.g. du to a user navigating to a new page before the current one has completed loading. Active content on a page might also cause new TLS connections to be killed during its infancy. -Martin From pkix@inbox.lv Fri Feb 22 16:46:23 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A1621E808E for ; Fri, 22 Feb 2013 16:46:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hRWR6sfWX0i for ; Fri, 22 Feb 2013 16:46:23 -0800 (PST) Received: from shark1.inbox.lv (shark1.inbox.lv [89.111.3.81]) by ietfa.amsl.com (Postfix) with ESMTP id B547621E8043 for ; Fri, 22 Feb 2013 16:46:21 -0800 (PST) Received: by shark1.inbox.lv (Postfix, from userid 1000) id DC50C7225; Sat, 23 Feb 2013 02:46:19 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by shark1-plain-b64d2.inbox.lv (Postfix) with ESMTP id 8DB9A71EB; Sat, 23 Feb 2013 02:46:19 +0200 (EET) Received: from localhost ([10.0.1.21]) by localhost (shark1.inbox.lv [10.0.1.80]) (spamfilter, port 27) with ESMTP id eMJAfVaz7DVe; Sat, 23 Feb 2013 02:46:18 +0200 (EET) Received: from 193.40.12.10 ( [193.40.12.10]) by mail.inbox.lv with HTTP; Sat, 23 Feb 2013 02:46:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Compose: web=mail.inbox.lv, node=w11.inbox.lv, l=en, compose=Plaintext X-REMOTE-ADDR: 193.40.12.10 X-HTTP-USER-AGENT: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Ubuntu Chromium/24.0.1312.56 Chrome/24.0.1312.56 Safari/537.17 Message-ID: <1361580378.5128115a9014b@mail.inbox.lv> Date: Sat, 23 Feb 2013 02:46:18 +0200 From: "Andris Berzins" To: mrex@sap.com References: <1361532300.5127558c6d0bf@mail.inbox.lv> <20130222212620.DACD71A5BC@ld9781.wdf.sap.corp> In-Reply-To: <20130222212620.DACD71A5BC@ld9781.wdf.sap.corp> User-Agent: Inbox.lv Webmail Cc: tls@ietf.org Subject: Re: [TLS] TLS session resumption lifetime X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 23 Feb 2013 00:46:24 -0000 Thank you Martin! So there is suggestion for client to enforce upper lifeti= me of 24 hours. I know that Firefox clears TLS session cache when "Active logins" checkbox = from "Clear all history" menu is=20 checked. Maybe someone from browser vendors can comment whether session cache expira= tion is enforced. Quoting "Martin Rex" : > Andris Berzins wrote: >>=20 >> Hello,

=C2=A0
=C2=A0
Can >> anyone comment whether TLS session lifetime is enforced by browsers?
=20 >>
Thank you! >=20 > What exactly do you mean with "TLS session lifetime is enforced by browse= rs" >? >=20 > There is only a _suggestion_ to not cache TLS session for more than > 24 hours in TLSv1.0 (rfc2246). Often, servers may expire TLS sessions > from the server side cache much earlier (our server uses a session cache > lifetime of only 24 minutes by default). >=20 >=20 > http://tools.ietf.org/html/rfc2246#section-7.4.1.2 >=20 > 7.4.1.2. Client Hello > [...] >=20 > The client hello message includes a variable length session > identifier. If not empty, the value identifies a session between the > same client and server whose security parameters the client wishes to > reuse. The session identifier may be from an earlier connection, this > connection, or another currently active connection. The second option > is useful if the client only wishes to update the random structures > and derived values of a connection, while the third option makes it > possible to establish several independent secure connections without > repeating the full handshake protocol. These independent connections > may occur sequentially or simultaneously; a SessionID becomes valid > when the handshake negotiating it completes with the exchange of > Finished messages and persists until removed due to aging or because > a fatal error was encountered on a connection associated with the > session. >=20 > http://tools.ietf.org/html/rfc2246#appendix-F.1.4 >=20 > F.1.4. Resuming Sessions > [...] >=20 > Sessions cannot be resumed unless both the client and server agree. > If either party suspects that the session may have been compromised, > or that certificates may have expired or been revoked, it should > force a full handshake. An upper limit of 24 hours is suggested for > session ID lifetimes, since an attacker who obtains a master_secret > may be able to impersonate the compromised party until the > corresponding session ID is retired. >=20 >=20 > The time of use of a TLS session on an established connection is independ= ent > from the TLS session cache lifetime (the latter typically affects only > the possibility to resume a prior session on a new connection). >=20 >=20 > At least some browsers delete the TLS sessions from their TLS session cac= he > when a new connection, where TLS session resumption was proposed, is > aborted by the browser itself early during the handshake, e.g. du to a > user navigating to a new page before the current one has completed loadin= g. > Active content on a page might also cause new TLS connections to be > killed during its infancy. >=20 >=20 > -Martin From hannes.tschofenig@gmx.net Sat Feb 23 10:12:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0D521F8697 for ; Sat, 23 Feb 2013 10:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsILTOlVMKUW for ; Sat, 23 Feb 2013 10:12:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5799C21F867D for ; Sat, 23 Feb 2013 10:12:55 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MJYft-1U7OiT0c1r-0031lk for ; Sat, 23 Feb 2013 19:12:54 +0100 Received: (qmail invoked by alias); 23 Feb 2013 18:12:53 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO [192.168.100.200]) [88.115.219.140] by mail.gmx.net (mp034) with SMTP; 23 Feb 2013 19:12:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX194ZMhxiAZ46DYu1YWPrTP0wLqnSPKmI3HqGjLaK8 73t7Mlh+aMhwnT Message-ID: <512906A1.5060903@gmx.net> Date: Sat, 23 Feb 2013 20:12:49 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Schwarz, Albrecht (Albrecht)" References: <5F7BCCF5541B7444830A2288ABBEBC9623DF010287@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> In-Reply-To: <5F7BCCF5541B7444830A2288ABBEBC9623DF010287@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "TLS@ietf.org" Subject: Re: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 18:12:56 -0000 Hi Albrecht, sorry that I missed your review comments. The term "TLS profile" could be a bit misleading. In your context (based on the documents listed below) profile means (if I understood it correctly) a description of how to use TLS to secure a selected protocol (Megaco in your case). Since TLS is a fairly widely used protocol there are many such descriptions available for TLS. For example, the Diameter base specification says how to use TLS to secure Diameter peer-to-peer exchanges. When someone tries to use TLS (or DTLS) to secure protocols on a smart object or constraint node network then the initial reaction is that TLS is too heavy to do that. Based on several implementations we do, however, know that that's not true. The answer is of course more complex since TLS has many features and even more extensions and the security requirements (as well as non-security related requirements) may dictate which of these extensions are reasonable to use. That's what draft-tschofenig-lwig-tls-minimal tries to explain. Of course, there is still work to provide better guidance (as you noticed). Ideally, I would like to provide a rough estimate of main memory, code size, bandwidth requirements, and energy consumption for commonly used features for these types of devices. In draft-tschofenig-lwig-tls-minimal we do not want to introduce new functionality that is in conflict with TLS/DTLS specifications. Regarding the mentioned TLS documents in your mail below I think you went a bit too far in terms of describing TLS usage for such a simple protocol like Megaco. I had intentionally mentioned Diameter since it provides similar functionality and IMHO TLS with client and server certificates + a reference to RFC 6125 would have been enough already. Ciao Hannes On 11/08/2012 11:47 AM, Schwarz, Albrecht (Albrecht) wrote: > Dear All, > like to raise a general comment to the group, driven by the “TLS > minimal” draft: > Do agree to the message of this doc, guess that the subject as such is > out of question in the TLS community. > Actually I’ve expected more concrete specification guidelines from the > conclusion section. > Notions such as “TLS can be customized …”, “… required TLS > functionality” or “It can be tailored to fit the needs of a specific > deployment environment.” point out that TLS related parameters and > procedures could and should be specified in detail for a particular > communication (and security) environment. > The answer could be the explicit introduction of a profile concept, - > which is very well known already for some protocols. > Profiles could be more high level (like the “RTP profiles” (e.g. RFC > 3551 as a “minimum” …) or fairly detailed (such as the 3GPP “SIP Gm > profile” or H.248 profiles). > And there are already concepts for “TLS profiles” around, see e.g. > - „3GPP TLS Protocol Profile“ (Annex E/33.310) > - „OMA TLS Profile“ (OMA-TS-TLS-V1_...) or > - „Operating system xyz TLS Profile“ (‘xyz’ as a placeholder for some > well known OSs) > However, all these TLS profile concepts are not really identical, > sharing some common capabilities, but also adding some specifics. > The rational behind is the fact that an explicit TLS profile concept is > not (yet?) introduced in the IETF TLS core RFCs in my understanding. > We faced the same situation in ITU-T SG16 in work items for > H.248-controlled TLS services. > Thus, we made a definition proposal as a working assumption. > Interested parties may have a look in: > a) *H.248.TLS "H.248 packages for control of transport security"* > _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-23.zip_ > *3.2.6 TLS-profile*: A selection of options from a set of TLS related > parameters and procedures. > and a concrete example may be found in: > *8.7 Example for the TLS profile concept* > b) *H.248.TLSPROF* "Guidelines on the use of H.248 capabilities for > transport security in TLS networks in H.248 Profiles" > _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-2__4__.zip_ > > Would be interested whether the TLS WG experts > a) thought already about the definition of a profile for TLS (and DTLS)? > [Which would be a terminology definition and could be additionally a > template for protocol profiling] > b) got any comments on our proposed TLS terms in above ITU-T work items? > Thanks, > Albrecht > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From paul.hoffman@vpnc.org Sat Feb 23 11:13:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF7121F8F34 for ; Sat, 23 Feb 2013 11:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.382 X-Spam-Level: X-Spam-Status: No, score=-104.382 tagged_above=-999 required=5 tests=[AWL=1.664, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2TeOs4IyR0r for ; Sat, 23 Feb 2013 11:13:38 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9956421F8EA8 for ; Sat, 23 Feb 2013 11:13:38 -0800 (PST) Received: from [10.20.30.90] (50-1-98-12.dsl.dynamic.sonic.net [50.1.98.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r1NJCGss093606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 23 Feb 2013 12:12:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <512906A1.5060903@gmx.net> Date: Sat, 23 Feb 2013 11:12:17 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F7BCCF5541B7444830A2288ABBEBC9623DF010287@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <512906A1.5060903@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1499) Cc: "TLS@ietf.org" Subject: Re: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 19:13:39 -0000 You may have missed Albrecht's main point: "Actually I=92ve expected = more concrete specification guidelines from the conclusion section". I = would have put it another way. Your document can be completely rewritten in a much shorter form. "TLS has many optional features" "Some of these optional features are more appropriate for different use = cases" "Here is a proposal for a minimal implementation appropriate for = constrained environments where the client and server have had = out-of-band communication before the TLS/DTLS session" Then list the implementation (OOB or preshared keys; no revocation; no = reauthentication; maybe a different MTI crypto suite set; standardized = extensions that are not expected to be supported) If you want to keep your long theoretical discussion, it can be an = appendix. --Paul Hoffman= From albrecht.schwarz@alcatel-lucent.com Mon Feb 25 00:14:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C2821F91EB; Mon, 25 Feb 2013 00:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAHAfJu8nKrq; Mon, 25 Feb 2013 00:14:26 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id ACEC121F923C; Mon, 25 Feb 2013 00:14:22 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r1P8CP1N028498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 25 Feb 2013 09:14:20 +0100 Received: from FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com ([135.120.45.52]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 25 Feb 2013 09:14:13 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Hannes Tschofenig Date: Mon, 25 Feb 2013 09:14:12 +0100 Thread-Topic: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal Thread-Index: Ac4R8Wip+rPWHA0PR9umXEmxNComLABPJqgg Message-ID: <5F7BCCF5541B7444830A2288ABBEBC9625FBE0154B@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> References: <5F7BCCF5541B7444830A2288ABBEBC9623DF010287@FRMRSSXCHMBSD2.dc-m.alcatel-lucent.com> <512906A1.5060903@gmx.net> In-Reply-To: <512906A1.5060903@gmx.net> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "megaco@ietf.org" , "TLS@ietf.org" Subject: Re: [TLS] draft-tschofenig-lwig-tls-minimal = TLS profile proposal X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 08:14:27 -0000 [Cc'd Megaco =3D H.248] Hi Hannes, with regards to: > " such a simple protocol like Megaco " Hm, looks like that you missed a main point: there are two aspects a) Transport security for Diameter/Megaco/... protocol itself =3D RFC 3588 (clause 13.2. TLS Usage) for Diameter =3D H.248.67 for H.248 b) Transport security for Diamter/Megaco/... control IP transport connectio= ns ("called IP bearer connections in context of H.248") =3D ??? for Diameter =3D H.248.TLS (& H.248.TCP) for H.248 Any "TLS profile" concept would be valuable for both (a) and (b), but being= aware that present "TLS protocol profiling" for (a) is fairly minimal (per= haps still too high level). However, more challenging is "TLS protocol profiling" for (b), - for specif= ic applications (not web/http, but IMS/SIP controlled). Regards, Albrecht PS - MMUSIC related: E.g., the negotiation of TLS client/server roles is presently not yet suppo= rted by SDP offer/answer. RFC 4145 does only define the semantics for TCP c= lient/server roles, and RFC 4572 just provides the "fingerprint" capability= . PSS "simple protocol like Megaco": Not sure whether you are up to date :-) =3D> http://www.itu.int/rec/T-REC-H/e=20 See list of H.248.x-series of Recommendations ... -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Samstag, 23. Februar 2013 19:13 To: Schwarz, Albrecht (Albrecht) Cc: TLS@ietf.org; hannes.tschofenig@gmx.net Subject: Re: [TLS] draft-tschofenig-lwig-tls-minimal =3D TLS profile propos= al Hi Albrecht, sorry that I missed your review comments. The term "TLS profile" could be a bit misleading. In your context (based on= the documents listed below) profile means (if I understood it correctly) a description of how to use TLS to secure a selected protocol (M= egaco in your case). Since TLS is a fairly widely used protocol there are m= any such descriptions available for TLS. For example, the Diameter base spe= cification says how to use TLS to secure Diameter peer-to-peer exchanges. When someone tries to use TLS (or DTLS) to secure protocols on a smart obje= ct or constraint node network then the initial reaction is that TLS is too = heavy to do that. Based on several implementations we do, however, know tha= t that's not true. The answer is of course more complex since TLS has many = features and even more extensions and the security requirements (as well as= non-security related requirements) may dictate which of these extensions a= re reasonable to use. That's what draft-tschofenig-lwig-tls-minimal tries to explain. Of course, = there is still work to provide better guidance (as you noticed). Ideally, I would like to provide a rough estimate of main memory, code size= , bandwidth requirements, and energy consumption for commonly used features= for these types of devices. In draft-tschofenig-lwig-tls-minimal we do not want to introduce new functi= onality that is in conflict with TLS/DTLS specifications. Regarding the mentioned TLS documents in your mail below I think you went a= bit too far in terms of describing TLS usage for such a simple protocol li= ke Megaco. I had intentionally mentioned Diameter since it provides similar= functionality and IMHO TLS with client and server certificates + a referen= ce to RFC 6125 would have been enough already. Ciao Hannes On 11/08/2012 11:47 AM, Schwarz, Albrecht (Albrecht) wrote: > Dear All, > like to raise a general comment to the group, driven by the "TLS=20 > minimal" draft: > Do agree to the message of this doc, guess that the subject as such is=20 > out of question in the TLS community. > Actually I've expected more concrete specification guidelines from the=20 > conclusion section. > Notions such as "TLS can be customized ...", "... required TLS=20 > functionality" or "It can be tailored to fit the needs of a specific=20 > deployment environment." point out that TLS related parameters and=20 > procedures could and should be specified in detail for a particular=20 > communication (and security) environment. > The answer could be the explicit introduction of a profile concept, -=20 > which is very well known already for some protocols. > Profiles could be more high level (like the "RTP profiles" (e.g. RFC > 3551 as a "minimum" ...) or fairly detailed (such as the 3GPP "SIP Gm=20 > profile" or H.248 profiles). > And there are already concepts for "TLS profiles" around, see e.g. > - "3GPP TLS Protocol Profile" (Annex E/33.310) > - "OMA TLS Profile" (OMA-TS-TLS-V1_...) or > - "Operating system xyz TLS Profile" ('xyz' as a placeholder for some=20 > well known OSs) However, all these TLS profile concepts are not really=20 > identical, sharing some common capabilities, but also adding some=20 > specifics. > The rational behind is the fact that an explicit TLS profile concept=20 > is not (yet?) introduced in the IETF TLS core RFCs in my understanding. > We faced the same situation in ITU-T SG16 in work items for=20 > H.248-controlled TLS services. > Thus, we made a definition proposal as a working assumption. > Interested parties may have a look in: > a) *H.248.TLS "H.248 packages for control of transport security"*=20 > _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-23.zip_ > *3.2.6 TLS-profile*: A selection of options from a set of TLS related > parameters and procedures. > and a concrete example may be found in: > *8.7 Example for the TLS profile concept* > b) *H.248.TLSPROF* "Guidelines on the use of H.248 capabilities for=20 > transport security in TLS networks in H.248 Profiles" > _http://wftp3.itu.int/av-arch/avc-site/2009-2012/1209_Bri/TD-2__4__.zi > p_=20 > > Would be interested whether the TLS WG experts > a) thought already about the definition of a profile for TLS (and DTLS)? > [Which would be a terminology definition and could be additionally a=20 > template for protocol profiling] > b) got any comments on our proposed TLS terms in above ITU-T work items? > Thanks, > Albrecht > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From n.mavrogiannopoulos@gmail.com Tue Feb 26 03:25:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7A621F882C for ; Tue, 26 Feb 2013 03:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYJ+7Hus9iqe for ; Tue, 26 Feb 2013 03:25:04 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1049421F8828 for ; Tue, 26 Feb 2013 03:25:03 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id nd7so1551773qeb.38 for ; Tue, 26 Feb 2013 03:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=ft2y3ufeLsOBXlPy2JDq2Q+Ksrbd6yvYCtbiEDM9dKw=; b=kfltZvThU9opUSfcHIszFNK8+pVsIOYqby8yZX3jIFROdXVah9lzIYCt/VL353xJW3 8FCXw5+95LyiNWnHlZLPApy3Le183tjQIK9tthr0Okfgf42mLbD4ab8thBEwmRJKmQWL +xxpbWEffB/AZhfVG4PaaVWAyUoPKVvwlx6uVTton3+D1eHiPROpFCp7CptLoaRXqxZV wyMDxko6rQAoJH/YUy4fgTaPVoKd4GZwiJhCx2JB/jq/adE9L5E7oQT3wWZVdZ+1B71b 0fdEuGmY2LgPZksJgHi+Gs6gKugBsf+EKFM/fINvaEx55azDM590pjnkadBSLCB5qfE0 d3OA== MIME-Version: 1.0 X-Received: by 10.49.133.68 with SMTP id pa4mr19445708qeb.50.1361877903529; Tue, 26 Feb 2013 03:25:03 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.119.138 with HTTP; Tue, 26 Feb 2013 03:25:03 -0800 (PST) Date: Tue, 26 Feb 2013 12:25:03 +0100 X-Google-Sender-Auth: 1-Y4wM_jXSxSHNG-QE5VUHtQVMw Message-ID: From: Nikos Mavrogiannopoulos To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [TLS] associating a DTLS session with something else X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 11:25:04 -0000 Hello, I am looking on ways to associate a DTLS session with another TLS session, so that a superserver will forward the DTLS session to the handler of the TLS. As it is now there is not much one can do for that. * Some ciphersuites allow specifying a username as a hello extension (e.g. SRP) which can be used to specify any identifier as the username. However it is restricted to SRP and I don't want to use it. * The PSK ciphersuites (which I'd like to use) allow specifying a username on the clientKeyExchange message, but that's during the handshake process and the superserver isn't supposed to perform the handshake. * Other similar solutions overload the SessionID field of the clientHello and place the identifier there, but I find overloading inelegant (even though it is a very simple solution). Has anyone encountered this problem before? Are there any other approaches to the issue? As it is now I'm more inclined into re-using the SessionID overloading due to its simplicity. regards, Nikos From Brian.Raymor@microsoft.com Wed Feb 27 21:30:42 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452F921F87E5 for ; Wed, 27 Feb 2013 21:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuqZeVuYVji7 for ; Wed, 27 Feb 2013 21:30:41 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD0921F8771 for ; Wed, 27 Feb 2013 21:30:41 -0800 (PST) Received: from BY2FFO11FD014.protection.gbl (10.1.15.203) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 28 Feb 2013 05:30:39 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Thu, 28 Feb 2013 05:30:39 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 28 Feb 2013 05:30:20 +0000 Received: from mail84-co1-R.bigfish.com (10.243.78.242) by CO1EHSOBE022.bigfish.com (10.243.66.85) with Microsoft SMTP Server id 14.1.225.23; Thu, 28 Feb 2013 05:30:19 +0000 Received: from mail84-co1 (localhost [127.0.0.1]) by mail84-co1-R.bigfish.com (Postfix) with ESMTP id CED8B300164 for ; Thu, 28 Feb 2013 05:30:19 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -29 X-BigFish: PS-29(zz9371Ia65Rzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL1adaf8h17326ah8275dhd0f34h8275bhz31h2a8h668h839h947hd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h9a9j1155h) Received-SPF: softfail (mail84-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=Brian.Raymor@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BL2PR03MB606; H:BL2PR03MB605.namprd03.prod.outlook.com; LANG:en; Received: from mail84-co1 (localhost.localdomain [127.0.0.1]) by mail84-co1 (MessageSwitch) id 1362029417318526_18664; Thu, 28 Feb 2013 05:30:17 +0000 (UTC) Received: from CO1EHSMHS026.bigfish.com (unknown [10.243.78.253]) by mail84-co1.bigfish.com (Postfix) with ESMTP id 4216C840049; Thu, 28 Feb 2013 05:30:17 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS026.bigfish.com (10.243.66.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 28 Feb 2013 05:30:17 +0000 Received: from BL2PR03MB606.namprd03.prod.outlook.com (10.255.109.40) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.275.5; Thu, 28 Feb 2013 05:30:15 +0000 Received: from BL2PR03MB605.namprd03.prod.outlook.com (10.255.109.39) by BL2PR03MB606.namprd03.prod.outlook.com (10.255.109.40) with Microsoft SMTP Server (TLS) id 15.0.620.20; Thu, 28 Feb 2013 05:30:14 +0000 Received: from BL2PR03MB605.namprd03.prod.outlook.com ([169.254.5.170]) by BL2PR03MB605.namprd03.prod.outlook.com ([169.254.5.200]) with mapi id 15.00.0620.020; Thu, 28 Feb 2013 05:30:14 +0000 From: "Brian Raymor (MS OPEN TECH)" To: "Stephan Friedl (sfriedl" , "tls@ietf.org" Thread-Topic: Revision draft-friedl-tls-applayerprotoneg-02 Posted Thread-Index: Ac4RG67UeAcrhMywR3iT9QNgy/S49wENyYyg Date: Thu, 28 Feb 2013 05:30:14 +0000 Message-ID: <164a774e38c84743a086361f3b4eb4ca@BL2PR03MB605.namprd03.prod.outlook.com> References: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67@xmb-aln-x02.cisco.com> In-Reply-To: <2AA4F2B7B0341A4CA4DAB10D4EDA0D7C12B7EC67@xmb-aln-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.17.61.195] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BL2PR03MB606.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CISCO.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(26614001)(46102001)(47736001)(49866001)(74502001)(8558605002)(76482001)(80022001)(59766001)(4396001)(66066001)(15202345001)(65816001)(53806001)(77982001)(17599925004)(50466001)(20776003)(33646001)(56816002)(44976002)(56776001)(54316002)(79102001)(63696002)(54356001)(31966008)(51856001)(5343635001)(23756002)(5343655001)(16676001)(47446002)(50986001)(74662001)(47976001)(47776003)(6806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0771670921 Subject: Re: [TLS] Revision draft-friedl-tls-applayerprotoneg-02 Posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:30:42 -0000 Our HTML5 Labs HTTP/2.0 prototype has been updated to reflect the changes i= n the applayerprotoneg-02 internet draft. This prototype now leverages Open= SSL and Apache on the backend.=20 http://html5labs.interopbridges.com/prototypes/alpn/alpn/info The associated server patch is available as open source - http://html5labs.= interopbridges.com/media/167447/alpn_patches.zip Feedback on the code and the internet draft would be appreciated. Brian Raymor Microsoft Open Technologies, Inc.=20 A subsidiary of Microsoft Corporation > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Ste= phan Friedl (sfriedl) > Sent: Friday, February 22, 2013 8:43 AM > To: tls@ietf.org > Subject: [TLS] Revision draft-friedl-tls-applayerprotoneg-02 Posted > A revision of draft-friedl-tls-applayerprotoneg has been posted.=A0 The f= ollowing changes have been introduced into the draft in response to feedbac= k from the working group: =A0 > 1.=A0=A0=A0=A0=A0=A0 Section 3.1 "Application Layer Protocol Negotiation = Extension" defines ProtocolNameList and ProtocolName as variable-length arr= ays, as typically done in TLS. This increases payload size by 2 bytes, but = allows the use of the normal TLS parsers. > 2.=A0=A0=A0=A0=A0=A0 Section 3.2 "Protocol Selection" defines a new fatal= alert no_application_protocol, to be used with ALPN extension only, instea= d of using a generic handshake_failure alert. This is done to help distingu= ish application protocol negotiation issues from other handshake failures. =A0 > We would greatly appreciate any comments and feedback on the draft. =A0 > Best Wishes, =A0 > Stephan Friedl, Andrei Popov