[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TLS] RE: comment on null encryption ciphersuite; https RFC amendment ...to compensate
I retract my objection, referenced below, on the basis that its evident that TLS, generically, supports cipher suites with null confidentiality component, with no limits on what kind of data are passed over such channels. Unless i'm shown wrong (yet again), IETF has not counseled against using any of its endorsed ciphersuites, when transferring credit card data, securely. It is entirely legitimate to knowingly transfer sensitive data over TLS_RSA_WITH_NULL_MD5, for example.
Given the nature of the specification of the core TLS RFC, Intel folks' I-D on PSK modality (with null confidentiality ciphers) looks rather professional, warning against using the cited mechanism for transferring sensitive data.
There is no reason for Intel folk to articulate a rationale for their proposal that customers/governments are (now) demanding the authentication-only feature, or null-confidentiality cipher feature. They are merely profiling existing internet policy endorsing such practices, set by the process in 1999.
From: home_pw@xxxxxxx
To: tls@xxxxxxxx
Subject: comment on null encryption ciphersuite; https RFC amendment ...to compensate
Date: Sat, 18 Nov 2006 18:12:38 -0800
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@xxxxxxx
To: tls@xxxxxxxx
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!
All-in-one security and maintenance for your PC. Get a free 90-day trial! Learn more!
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls