RE: [TLS] Record layer corner cases

[Peter Williams <home_pw at msn.com>]

Using TCP "urgent mode", say, for security signaling/controls is a marked deviation from the constructs and design precepts of the SSL Handshake, but not the SSL Protocol, note. I'm being very pedantic with terminology, for a reason: as we discussed earlier, the SSL Protocol is an encapsulation of {SSL Handshake, or other ALPHA handshake(s)) by the Record Protocol. 
 
Allowing the (standard) SSL Handshake to use TCP urgent mode would detract from allowing the SSL3 to be recognized as a fully fledged Internet Standard, known as TLS, a standing it clearly deserves - given its demonstrated range of applicability, its hardware and software implementation knowhow, and the way SSL session handling succesfully cooeprates with stateful inspection firewalls.  In the same vein, recognizing that said potential Internet Standard has proper "future proofing" features (allowing ALPHA handshake designs down the line to evolve the standard) supports SSL3's designation as a fully mature, Internet Standard, known as TLS. That SSL3 is not tied to today's dominant transport (TCP over IPv4 over the US IP backbone architecture) is also good for that standing!
 
Without interfering with the recognition SSL3 in its TLS1.1 form should have as an Internet Standard , we could reasonably keep this WG open if there were a new, distinct standards track initiative to specify one or more "ALPHA Handshakes" - that (a) parallel the SSL Handshake, and (b) have some knowledge of and interaction with post-hooked socket providers (TCP, X, or some of the class d addressed reliable channels we experimented with, long ago, using multicast key management, core-based access and connection controls, and session directory support). A long long time ago, we found it necessary to indeed allow the handshake to *interactively* control how the reliable transport channel behaved, for those transports which merge byte transfer with the very key management concept and access/connection controls being used in the handshake's design.
 
If this is too abstract for folks, there were at one point I-Ds from NSA designers/engineers on using multicast key management for IKE-enhancements addressing multi-drop security association management, that one can peruse for background. Some of these ideas are appropriate for multi-drop session management, particularly when ALPHA-design handshakes would be cooperating with the SAML2 protocols at the https.v2  layer, in the setup/teardown of multi-drop client authentication sessions.

---

> Subject: RE: [TLS] Record layer corner cases
> Date: Thu, 23 Nov 2006 11:37:38 +0200
> From: Pasi.Eronen at nokia.com
> To: mike-list at pobox.com; tls at ietf.org
> CC: 
> 
> mike-list at pobox.com wrote:
> > 
> > I think this would be taking it too far (consider sending
> > ServerHelloDone in its own packet). Plus if you implement
> > TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3
> > which don't have the restriction.
> 
> A separate record doesn't mean its own IP packet (or TCP segment);
> it's just 5 bytes of record header overhead (in case of
> NULL_WITH_NULL). But yes, maybe it would still be taking it too far...
> 
> (But TLS 1.2 spec doesn't require you to implement any older spec; and
> even the older specs in reality seem to have the restriction that you
> can't fragment handshake messages if you want good interoperability.)
> 
> Best regards,
> Pasi
> 
> _______________________________________________
> TLS mailing list
> TLS at lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

---

Express yourself with gadgets on Windows Live Spaces Try it!
_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls