Subject: RE: [TLS] Record layer corner cases

From: Peter Williams <[email-masked]>
Date: Mon, 27 Nov 2006 09:46:51 -0800

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: [email-masked]: [email-masked]; [email-masked]: [email-masked]: RE: [TLS] Record layer corner casesDate: 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!
http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Mon, 27 Nov 2006 10:13:47 -0800

> "SSL Version 3 supports the transmission and reception of "out of band 
> data".

I don't think so.  But it would be easy to define a new record
type for that.

Mike

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 28 Nov 2006 15:00:31 +1300

Peter Williams <[email-masked]> writes:

>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.

I don't handle it at all, if my code sees OOB data in the middle of a TLS
stream it flags it as a network-level error (my security model is default-
deny).  I've never seen OOB data used and can't imagine why it'd ever be used
except as a potential attack vector targetting corner cases in TLS
implementations.

Peter.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 27 Nov 2006 19:10:42 -0700

> except as a potential attack vector targetting corner cases in TLS

Evidently you've never used SIGURG, nor seen urgent data sent (that
which causes TCP PSH headers to be generated in BSD-type stacks).  I'd
like to see the discussions from when TCP was designed as to what it
was designed to be used for -- it would seem to be for metadata
involving the connection.  (This is akin to the TLS record protocol
being used to request a rehandshake, since the TLS implementation
consumes those records.)

I would think that such a concept could be useful in modification of
the trust parameters associated with the data stream (specifically,
notification of revocation or expiration of trust parameters would be
a good reason for it).

-Kyle H

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 27 Nov 2006 21:34:44 -0500

On Mon, 27 Nov 2006 19:10:42 -0700
"Kyle Hamilton" <[email-masked]> wrote:

> > I don't handle it at all, if my code sees OOB data in the middle of
> > a TLS stream it flags it as a network-level error (my security
> > model is default- deny).  I've never seen OOB data used and can't
> > imagine why it'd ever be used except as a potential attack vector
> > targetting corner cases in TLS implementations.
> 
First, that's not what cause the push bit to be set.  PSH is set when
there's nothing pending to be written.  More precisely, it's set to
zero when a packet is sent and the stack knows that there's nothing
else about to be sent.  Here's the comment and code in NetBSD's
tcp_output.c:

                /*
                 * If we're sending everything we've got, set PUSH.
                 * (This will keep happy those implementations which
only 
                 * give data to the user when a buffer fills or
                 * a PUSH comes in.)
                 */ 
                if (off + len == so->so_snd.sb_cc)
                        flags |= TH_PUSH;

Second, and more important, it was intended to be sent when the user had
hit BREAK on their ASR-35 Teletypes or ATTN on their IBM 2741s -- see
RFC 764.  It was part of the "flush all buffers until the urgent
pointer" mechanism; TCP Urgent is ill-suited to anything else, since
(as is noted in the RFC) multiple urgent pointers pending at the same
time are coalesced.

The only other place I can recall seeing it used was for window size
change notifications in rlogin.  Rlogin did not make suitable provision
(more accurately, did not make any useful provision) for any sort of
connection metadata; the implementors of later versions fell back on
TCP Urgent when it became important to do *something*.

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

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 28 Nov 2006 13:21:25 +0100

> except as a potential attack vector targetting corner cases in TLS

The above quote is from the SSL patent, which does mention
"SSL Version 3" -- but it's not really about what we know as SSL 3.0,
it only describes the SSL 2 protocol design.  The patent says that
"currently there are several versions of the novel SSL", and there the
"novel SSL" is what we know as SSL 2 and variants thereof.  What
eventually was fielded as SSL 3.0 is, of course, a very different
protocol.

The SSL 2 protocol design provides for a "security escape" flag in
record headers ("reserved for future versions of the protocol"),
which would be used to tag out-of-band data.  That and now TCP-leve
out-of-band data is what the above patent text is talking about.
(As noted there, handling TCP out-of-band data would be difficult
within SSL.)

Bodo

---

From: Martin Rex <[email-masked]>
Date: Tue, 28 Nov 2006 15:55:51 +0100 (MET)

Peter Williams wrote:
> modules handle the following change from SSL v2 to SSL v3, including
> fallback handling as specified by SSL3, and then the TLS fallback
> mechanisms?
>
> 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.

That might be an issue for a generic SSL/TLS toolkit and/or a vendor
implementor thereof.  My employer sells applications and includes
an OEM sslv3 implementation which is used almost exclusively for HTTPS.

I'm not aware that HTTPS specifies a usage of TCP OOB data--and the
document that comes closest to a spec for HTTPS (rfc2818) does not
seem to contain the words "urgent", "out of band" and "OOB".

It might be useful to check whether OOB data has any negative unexpected
side-effects (aka vulnerabilities) besides causing the communication
channel to be closed.

-Martin