RE: [TLS] Record layer corner cases

[Peter Williams <home_pw at msn.com>]

Out of interest Peter and Martin, how well do your software and hardward modules handle the following change from SSL v2 to SSL v3, including fallback handling as specified by SSL3, and then the TLS fallback mechanisms?
 
"SSL Version 3 supports the transmission and reception of "out of band data". Out of band data is normally defined at the TCP/IP protocol level, but because of SSL's privacy enhancements and support for block ciphers, this becomes difficult to support. 

To send out-of-band data, the sender sends an escape record whose body contains a single byte of data indicating the escape type code: 

char escape-tee-code 

The escape-type-code value should be SSL.sub.-- ET.sub.-- OOB.sub.-- DATA. The record following the escape record will be interpreted as "out-of-band" data and will only be made available to the receiver through an unspecified mechanism that is different than the receivers normal data reception method. The transmitted data record and the escape record are transmitted normally (i.e. encryption, MAC computations, and block cipher padding remain in effect). "

Its worth exploring this area, in Windows 2000 onward, I found.

---

From: home_pw at msn.com
To: pgut001 at cs.auckland.ac.nz; martin.rex at sap.com
CC: tls at ietf.org
Subject: RE: [TLS] Record layer corner cases
Date: Thu, 23 Nov 2006 20:57:42 -0800





> For root certs, the practice is to have them never expire [0]. You'll never
> see this written down anywhere (you're supposed to roll over certs every few
> years), but I think in practice everyone in the industry knows that root cert
> replacement is so unworkable that you just give your certs an infinite
> lifetime. When it comes to security vs.availability, availability always wins
> out.
>
> Peter.

 
The business/investement model dictated this. VeriSign existed to make money for its venture investors; nothing would stand in that way, and certainly not personal privacy interests (For example, implement mandatory key escrow! or be put out of business by USG!! VeriSign management quickly kowtow'ed, as did most but not all of the IETF luminaries, to be fair to the VeriSign team). So whilst capitalism broke through the barriers to engender adoption, capitalism also upheld certain other social issues concerning privacy limits via deception, etc. So, fair is fair...
 
But, we are still learning, about crypto and society. Peter was very wrong recently! Even though TLS1.0 had null cipher suites for years, the credit-card world did not *actually* crumble. At the same time, its true that only in the recent IE7 has the global infrastructure for grandmas finally made TLS1.1 the default (and with MSFT IETF-unverified techniques for testing which TLS extensions are actually supported on servers!). So, perhaps we will yet see what further evidence of TLS design vs practice has to offer, now it enters mainstream testing.
 
Peter W.

---

Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today! Try it now!

---

Check the weather nationwide with MSN Search Try it now!
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls