RE: [TLS] Record layer corner cases
Peter Williams <home_pw@msn.com> Sun, 26 November 2006 03:44 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoAvx-0000iE-Gy; Sat, 25 Nov 2006 22:44:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoAvv-0000do-HV for tls@ietf.org; Sat, 25 Nov 2006 22:43:59 -0500
Received: from bay0-omc3-s32.bay0.hotmail.com ([65.54.246.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoAvt-0002z4-Uy for tls@ietf.org; Sat, 25 Nov 2006 22:43:59 -0500
Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc3-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 19:43:57 -0800
X-Originating-IP: [71.140.81.171]
X-Originating-Email: [home_pw@msn.com]
Message-ID: <BAY103-W47AEAAB12C71F47E6B68A92E70@phx.gbl>
From: Peter Williams <home_pw@msn.com>
To: pasi.eronen@nokia.com, mike-list@pobox.com, tls@ietf.org
Subject: RE: [TLS] Record layer corner cases
Date: Sat, 25 Nov 2006 19:43:57 -0800
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Nov 2006 03:43:57.0400 (UTC) FILETIME=[1A218580:01C7110D]
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac
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="===============0769853735=="
Errors-To: tls-bounces@lists.ietf.org
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@nokia.com> To: mike-list@pobox.com; tls@ietf.org> CC: > > mike-list@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@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Express yourself with gadgets on Windows Live Spaces http://discoverspaces.live.com?source=hmtag1&loc=us
_______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- RE: [TLS] Record layer corner cases Peter Williams
- [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Bodo Moeller
- Re: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Rob Dugal
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Mike
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Mike
- Re: [TLS] Record layer corner cases Martin Rex
- Re: [TLS] Record layer corner cases Peter Gutmann
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Peter Williams
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Mike
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Martin Rex
- Re: [TLS] Record layer corner cases Mike
- RE: [TLS] Record layer corner cases Peter Gutmann
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Kyle Hamilton
- Re: [TLS] Record layer corner cases Steven M. Bellovin
- Re: [TLS] Record layer corner cases Bodo Moeller
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Kemp, David P.
- Re: [TLS] Record layer corner cases Kyle Hamilton
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Mike
- RE: [TLS] Record layer corner cases Kemp, David P.
- RE: [TLS] Record layer corner cases Kemp, David P.
- RE: [TLS] Record layer corner cases Peter Williams
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Peter Gutmann
- Re: [TLS] Record layer corner cases Martin Rex
- RE: [TLS] Record layer corner cases Peter Gutmann
- RE: [TLS] Record layer corner cases Kemp, David P.
- RE: [TLS] Record layer corner cases Pasi.Eronen
- Re: [TLS] Record layer corner cases Bodo Moeller
- Re: [TLS] Record layer corner cases Mike
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Diffie-Hellman parameters are unsigned … Pasi.Eronen
- Re: [TLS] Record layer corner cases Bodo Moeller
- RE: [TLS] Record layer corner cases Peter Williams