RE: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate
"Blumenthal, Uri" <uri.blumenthal@intel.com> Sun, 19 November 2006 16:34 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpcV-0000Rd-QL; Sun, 19 Nov 2006 11:34:15 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpcU-0000RI-0C for tls@ietf.org; Sun, 19 Nov 2006 11:34:14 -0500
Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlpcP-0004ED-Ax for tls@ietf.org; Sun, 19 Nov 2006 11:34:13 -0500
Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga09.intel.com with ESMTP; 19 Nov 2006 08:34:06 -0800
Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 19 Nov 2006 08:33:01 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,439,1157353200"; d="scan'208,217"; a="148275955:sNHT34094984"
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 08:33:01 -0800
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate
Date: Sun, 19 Nov 2006 11:32:51 -0500
Message-ID: <279DDDAFA85EC74C9300A0598E704056F91A47@hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate
Thread-Index: AccLgX56GjKY4DrETrOpAZYOgokJggAde57Q
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: Peter Williams <home_pw@msn.com>, tls@ietf.org
X-OriginalArrivalTime: 19 Nov 2006 16:33:01.0457 (UTC) FILETIME=[613D9810:01C70BF8]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1156465574=="
Errors-To: tls-bounces@lists.ietf.org
Peter, Whether you like it or not, but (a) there are applications that are OK with authentication/integrity only, and more importantly (b) some legistations and domains forbid encrypted channels, period. To address this reality, authentication-only TLS protocol suites are introduced. Their applicability is clear and limited - exactly as explicitly specified in the document. Political balance and issues should be brought to US Congress and corresponding foreign bodies. P.S. Perhaps it is worth to ensure that GUI unambiguously differentiates between encrypted and authenticated-only channel. If so, I bet you that Firefox will be there before MS IE. :-) ________________________________ From: Peter Williams [mailto:home_pw@msn.com] Sent: Saturday, November 18, 2006 9:13 PM To: tls@ietf.org Subject: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate I'm EXTREMELY worried socially about an IAB-endorsement of the null encryption ciphersuite for TLS. Whilst I recognize its value, on the stated merits, I think we need a political balance addressing issues beyond IETF's scope. Too many consumers are potentially going to be duped by the millions of well-meant but potentially incorrect e-commerce website representations which today affirm that "SSL protects your credit-card data (via encryption etc)". With the use of endorsed null encryption ciphersuites in TLS/SSL, that is obviously not true (in any way grandma would understand). The average consumer is trained to assume "SSL" (or TLS) protects your from obvious criminal activities, concerning pilfering credit card numbers. IAB activities that destroy the brand name of SSL is something which is not worth the value of endorsing the null-encryption ciphersuite, in my own view. Perhaps the right balance for IAB/IESG is to to require that the https RFC be simultaneously modified so that it makes it NON-CONFORMING for SSL/TLS in the https context to ever use the null encryption ciphersuites. Other URL protocols can be registered with IANA that don't confuse consumers (e.g. httpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/), which can even behave exactly as https v.10 otherwise does, but allowing for a conforming use of the null-encryption cipher suite. Peter ________________________________ From: home_pw@msn.com To: tls@ietf.org Subject: RE: [TLS] IETF67 TLS Summary Date: Sat, 18 Nov 2006 09:53:44 -0800 CC: ________________________________ Express yourself with gadgets on Windows Live Spaces Try it! <http://discoverspaces.live.com?source=hmtag1&loc=us>
_______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] comment on null encryption ciphersuite; htt… Peter Williams
- Re: [TLS] comment on null encryption ciphersuite;… EKR
- RE: [TLS] comment on null encryption ciphersuite;… Blumenthal, Uri
- RE: [TLS] comment on null encryption ciphersuite;… Peter Williams
- Re: [TLS] comment on null encryption ciphersuite;… EKR
- [TLS] RE: comment on null encryption ciphersuite;… Peter Williams
- Re: [TLS] comment on null encryption ciphersuite;… Steven M. Bellovin