Subject: RE: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate

From: "Blumenthal, Uri" <[email-masked]>
Date: Sun, 19 Nov 2006 11:32:51 -0500

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:[email-masked]] 
	Sent: Saturday, November 18, 2006 9:13 PM
	To: [email-masked]
	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: [email-masked]
		To: [email-masked]
		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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 19 Nov 2006 20:44:29 -0500

> corresponding foreign bodies.

Uri: ever since the Danvers IETF -- April, 1995 -- the IETF has had a
policy of designing cryptographic mechanisms taking into account only
technical criteria, not political issues.  (Also see RFC 1984.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb