Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix

From: Peter Williams <[email-masked]>
Date: Thu, 23 Nov 2006 19:46:09 -0800

Jan:
 
1. Introduction
 
I'm glad we can have a general conversation. Lets remember though that this is ietf, not the ssl-talk community. IETF has formal information distribution and decision processes, which are much less inclusive than ssl-talk processes were. We may well be told to shut up; IETF has to address a much broader set of political issues and players, than we ever had to do. 10 years into TLS, its not my intention to restart the process! At the same time, to become a Internet Standard, the document has to show its being clearly understood by the average technical reader. 
 
On this score, I do worry when I see the some of the topics being discussed. TLS is apparently diverging from SSL precepts to the point where the internet standard time test is no longer valid, and we may need to restart the clock.
 
So, to start the review, lets magine, as we did, that we are a microsoft-equivalent winsock programming team for SSL, not knowing quite who will be using our sockets, or for what purpose. Assume that those users on the initiating end are as diverse as content-specific plugins to browsers, or HTML-based javascript apps and java applets, on a competing "web" platform to windows. While the winsock provider for SSL3 is installed by default, we dont know as a design team which other providers will be pre- or post-hooked; assume we provide custom socket configuration support to orchestrate how, say, SSL3's two layers cooperate. Perhaps, by default, the record layer only encapsulates the "SSL Handshake" protocol, requiring socket configuration to do otherwise. Assume that this is our architectural plan, and assumed primary usage model.
 
We also have a target delivery date for IE3, Jan 1995. Assume noone knows what to do with client certs, and only RSA ciphersuites matter, with RSA's reversible properties and software key management and crypto libraries; assume from the outset that OPTIONAL server-side caches retain session keys, for use in session resumption and law enforcement processes relevant to banking regulation (the main design target of SSL2) . Assume banks are writing large CGI applications, and want SSL removed at the in router/network land, and do NOT want network identification and authentication techniques to be used (e.g. client certs, or IP addresses) within the mainframe application domain that CGI is binding web applications to. Assume that actual delivery of SSL as an actual winsock provider becomes politically/competitively impractical, even tho the concept is retained architecturally. (* MSFT did actually deliver a winsock provider, before NSA politics killed it).
 
2. Evidence and Analysis
 
If we consider the authoritative SSL3 citation, we can refer to its opening statements on architecture (that may not align with the "received architecture" in TLS, for all I know):-
 
"The primary goal of the SSL Protocol is to provide privacy and   reliability between two communicating applications.  The protocol   is composed of two layers.  At the lowest level, layered on top of   some reliable transport protocol (e.g., TCP[TCP]), is the SSL   Record Protocol.  The SSL Record Protocol is used for encapsulation   of various higher level protocols.  One such encapsulated protocol,   the SSL Handshake Protocol, allows the server and client to   authenticate each other and to negotiate an encryption algorithm   and cryptographic keys before the application protocol transmits or   receives its first byte of data."

Then we parse the design goals stated in this architecture:
 
1. the "SSL Handshake Protocol" is "one such encapsulated protocol" borne by the record protocol. Furthermore, various higher level protocol are architecturally entitled to be encapsulated in the record protocol. I trust this address my general point about multiplexing. Change the term multiplexing to "multi-capsulating", if one must be an american pedant when using English.
2. the lowest record protocol layer is "layered on top of some reliable transport protocol (e.g., TCP[TCP])". TCP is  clearly cited as an example, only. TCP was not assumed in the security model design goals, though of course reality often intruded on the team! A record layer layered on the protocol known as the "SSL3 Protocol" was certainly intended (i.e. SSL tunneling). Do not assume HTTP 1.1 keep-alive existed, and the internet is being flooded by shortlife TCP instances that are upsetting US ISPs and the US FIX-architecture backbone concept for an IP internetwork design.
 
3. the primary goal of SSL Protocol was to provide privacy and reliability, app to app. As my parsing in (2) above indicates, the reliability properties of one protocol stack (record layer over TCP) might be different to another (record layer over the SSL Protocol, over TP4). As history may recall, at the time getting reliable transport sessions between class d addressed applications was a challenge, as the internet had no bandwidth reservation techniques, at the time.
 
4. What is not stated (as https was deliberately never specified, except by Eric's "authorized" rendition of web reality from his (then implementor's) viewpoint) was how this protocol architecture addressed hypermedia applications. It true that it is not stated that "reliable transport" should be assume to include multicast transport, supporting (multicast hypermedia) applications. Take it from me, however, that this was intended, when addressing protocol goals such as were being considered (at the time) for HTML-enhanced nntp  , and pre-ldap multicast white pages directories and their supporting directory replication/authentication protocols (for efficient PKI cert distribution!).
In terms of its read./write secure session state management design, lets note, the critical text:
"   An SSL session may include multiple secure connections; in   addition, parties may have multiple simultaneous sessions."
 
3. Conclusions on Internet Standard status
In terms of whether SSL3/TLS is prime time for Internet Standard status , its often worth testing what folks read into the document, when they implement long after the original design issues have long since left the community consciousness.
 
With TLS 1.0 endorsing  null confidentiality ciphersuites, I assume the primary goal statement ("provide privacy and reliabily...to apps") in TLS got changed from that in SSL3. Goal:Privacy assumed a robust confidentiality service, and goal:reliablity assumed OPTIONAL robust session management/resumption techniques that were intended to be sensitive to the IP network over which the https/SSL connections were flowing while understanding the socio-political risks that come with sever-side session caches and hidden session restarts using lower strength ciphersuites.
 
its not clear to me, from recent reading, that this community understand that session caches are OPTIONAL, and a function of the network topology of the IP backbone. In tying SSL interworking quality to TCP behavior in particular (probably US) IP nets, I worry! hypermedia apps and https understanding aside, I worry about whether folks really get the secure session state architecture within SSL! Its really not clear that folks get that SSL Record layer contains its own fragmentation and reassembly possibilities, which addressed the competing goals of compression contexts and security contexts, for multiple, multiplexed secure sessions operating in two directions, simultaneously. While someone thought quite carefully about the interaction of SAML1.1 protocol's session establisment process and its interaction with the SSL architecture for secure sessions, its not clear TLS1.2 is properly addressing the radical changes brought about by SAML2.0 - on multi-site session destruction, for example. 
 
In summary, as an Internet Standard, its not clear that TLS is ready for such standing. Its  evidently really not a widely understood secure session management architecture , and its architecture or writeup was not sufficient apparently for it to keep uptodate with the inevitable changes that always go on around standard protocols.
 
But, when I rationalize, this is not all that surprising. The specific intent of the writeup was to benefit implementors and RSA's cryptographic analysts; support standardization was not an explicit writing goal.

> From: [email-masked]> To: [email-masked]> CC: [email-masked]> Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix> Date: Fri, 24 Nov 2006 12:31:00 +1100> > I'm responding very generally ...> > Peter Williams wrote:> > > What happens with TCP packets depends on many variables. These are> > > irrelevant to TLS and are hidden by a TCP implementation.> > > > > > TLS has a record layer to provide a record abstraction on > > top of TCP.> > > > > > > Distinguish TCP packets from TCP connection state changes, > > however. These were all security-relevant signals, for SSL > > designers, as indicated by the socket.> > > > And, dont read too much into the term "record", and don't > > associate it with TCP/IP's internal signalling or "framing" > > behaviour for a given network media. The record construct > > refers to the framing of the SSL2 handshake messages, and > > then the framing due to handling the resulting security > > context(s), suited to Type II cipher environments.> > > > SSL3 always intended that one could multiplex different > > handshakes and different security contexts within the > > reliable byte stream(s) (perhaps and only perhaps implemented > > using TCP/IP), befitting resolving an HTML page with multiple > > image and voice tags to be rendered in parallel, along with > > other HTML pages in the frameset being similarly rendered > > from other website sources via http or other URL protocols.> > Are you saying that SSL3 was intended to allow multiplexing over a single> reliable byte stream? If so, do you have a reference?> > > TLS1.1+ seems to be rapidly deviating from the intended > > multiplexing architecture, by always extending the common > > handshake (wot crypto wimps!). It should have been specifying > > and standardizing additional handshakes, for use beyond > > https, using a common pool of std ciphersuites, when > > resolving non HTML media such as different XML document classes. > > Why?> > TLS provides a reliable byte stream with specific security services applied.> Providing "media specific" services or multiplexing in a protocol like TLS> is clearly a mistake. TCP/IP does a fine job of multiplexing. Why do it> again?> > An application implementing a higher layer protocol can choose to allow> specific TLS features and to deny others to meet a specific need, but that> is where it should end. TLS has no knowledge of https.> > > Perhaps its not too late to put TLS back into its original > > security model. One could be ensuring that when the > > WS-Security secureConversation protocol (for example) is > > performing the actions of resolving a particular class of XML > > media then suitably multiplexed handshake(s) are occuring > > within the record layer - (a) supporting the http-bindinhs > > and (b) the secureconversation protocol itself, in parallel > > as necessary. In such a handshake, entropy may of course be > > being obtained from a server, rather than from random source, > > as in traditiona netscape https for example, where the server > > retains information records to address crypto regulations > > (e.g. the proposed signed evidence work items). If one is > > using the TLS1.1 SAML extension for identification, this > > third handshake may be specifically using SAML's delegated > > entropy modes when applying XML-encryption-based > > ciphersuites. Who knows! But this is what the architecture > > was intended to support!> > > > I for one make the assumption that, upon resuming a (or being > > induced by an ISP to resume an interupted) SSL2 or SSl3 > > session, one may be being required to re-renegotiate > > ciphersuites when picking up the new TCP channel (that > > requires SSL->TLS handling, and then use of govt-escrowed > > (i.e. compromised) PSK ciphersuite perhaps) - at the right > > moment to (i) perform the legal interception of the > > particular multiplexed session identified, and (ii) enable > > the ISP to show that its intervetion at the SSL session > > layer, probably via TCP interference, fits the particular > > class of interception order.> > I am guessing that you are concerned about the crypto in a resumed TLS> session being downgraded, but I'm not sure. If this is what concerns you,> then write (or configure) your application to not use ciphersuites you don't> want.> > > Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP > > signals is fraught with security sideeffects, that IETF's > > senior security architects may be intending or not intending > > when standardizing TLS.> > Sorry, I think I've missed your real point entirely.> > TLS's purpose is to provide a reliable byte stream service with strong> confidentiality, integrity, and/or authentication. To do this, TLS uses a> reliable byte stream service without strong security guarantees, such as> TCP.> > > Regards,> > Jan Mikkelsen.> 
_________________________________________________________________
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: EKR <[email-masked]>
Date: Thu, 23 Nov 2006 20:20:05 -0800

I really don't understand what point you're making, but a number
of the specific claims you make below strike me as dubious.

Peter Williams <[email-masked]> writes:
> So, to start the review, lets magine, as we did, that we are a
> microsoft-equivalent winsock programming team for SSL, not knowing
> quite who will be using our sockets, or for what purpose. Assume
> that those users on the initiating end are as diverse as
> content-specific plugins to browsers, or HTML-based javascript apps
> and java applets, on a competing "web" platform to windows. While
> the winsock provider for SSL3 is installed by default, we dont know
> as a design team which other providers will be pre- or post-hooked;
> assume we provide custom socket configuration support to orchestrate
> how, say, SSL3's two layers cooperate. Perhaps, by default, the
> record layer only encapsulates the "SSL Handshake" protocol,
> requiring socket configuration to do otherwise. Assume that this is
> our architectural plan, and assumed primary usage model.
>  
> We also have a target delivery date for IE3, Jan 1995.

This is already a weird assertion, since Netscape designed SSL
and they really didn't have any interest in anything working
with IE.

> 1. the "SSL Handshake Protocol" is "one such encapsulated protocol"
> borne by the record protocol. Furthermore, various higher level
> protocol are architecturally entitled to be encapsulated in the
> record protocol. I trust this address my general point about
> multiplexing. Change the term multiplexing to "multi-capsulating",
> if one must be an american pedant when using English.

I certainly agree that SSLv3 offered this feature, but it's not
at all clear to me that anyone had any clear idea what to do
with it, but rather that it was a placeholder. Recall that
despite the fact that only 4 protocols were defined, the minimum
enum size in SSL is 1 byte, so there were 252 unused values
anyway.

> 4. What is not stated (as https was deliberately never specified,
> except by Eric's "authorized" rendition of web reality from his
> (then implementor's) viewpoint)

Do you have a source for "deliberately"? I never got any such
sense from any of the Netscape personnel. Rather, it just seemed
that it was so obvious what to do that nobody ever got around
to documenting it.

> 3. Conclusions on Internet Standard status In terms of whether
> SSL3/TLS is prime time for Internet Standard status , its often
> worth testing what folks read into the document, when they implement
> long after the original design issues have long since left the
> community consciousness.
>  
> With TLS 1.0 endorsing null confidentiality ciphersuites, I assume
> the primary goal statement ("provide privacy and reliabily...to
> apps") in TLS got changed from that in SSL3. Goal:Privacy assumed a
> robust confidentiality service,

Huh?

NULL cipher suites weren't something the IETF invented. They
were in SSL version 3.

http://wp.netscape.com/eng/ssl3/4-APPN.HTM#D-4

> its not clear to me, from recent reading, that this community
> understand that session caches are OPTIONAL, and a function of the
> network topology of the IP backbone.

Huh? The need (or lack of need) for session caches has nothing
whatsoever to do with the topology of IP networks and everything to do
with the connection characteristics of the applications that are
running over top of TLS, most importantly HTTP.

-Ekr

---

From: "Jan Mikkelsen" <[email-masked]>
Date: Fri, 24 Nov 2006 16:13:29 +1100

Peter,

I'm not going to address all of your message, but I have picked some below.

>From my reading of your messages I think that you have two main points:

1. You want to add "multiplexing" to TLS for the transfer of more complex
data.  

2. You have a problem with null cipher suites.

On the first point, I don't see any requirement that isn't met by the
current protocol.  Please be specific (and concise) about the problem you
want to solve.

On the second point, null ciphersuites were in the SSL3 document you cite.
There are three aspects to security in SSL:  confidentiality, integrity and
authentication.  Not all are required in all situations.  I said this a few
messages ago, and it is also stated in the introduction to the SSL3
document.

Anyway, I've addressed some things from your message, but I suggest that you
try a one or two paragraph statement of the problem you want to solve.

Peter Williams writes:
> [ ... Context, Microsoft, the 90s ... ]

I see protocols and implementations as distinct things.  Issues in
implementing software in complex multivendors environments does not mean
that the protocol is broken.

> 2. Evidence and Analysis
>  
> If we consider the authoritative SSL3 citation, we can refer 
> to its opening statements on architecture (that may not align 
> with the "received architecture" in TLS, for all I know):-
>  
> "The primary goal of the SSL Protocol is to provide privacy and
>    reliability between two communicating applications.  The protocol
>    is composed of two layers.  At the lowest level, layered on top of
>    some reliable transport protocol (e.g., TCP[TCP]), is the SSL
>    Record Protocol.  The SSL Record Protocol is used for encapsulation
>    of various higher level protocols.  One such encapsulated protocol,
>    the SSL Handshake Protocol, allows the server and client to
>    authenticate each other and to negotiate an encryption algorithm
>    and cryptographic keys before the application protocol transmits or
>    receives its first byte of data."
>  
>  
> 1. the "SSL Handshake Protocol" is "one such encapsulated 
> protocol" borne by the record protocol. Furthermore, various 
> higher level protocol are architecturally entitled to be 
> encapsulated in the record protocol. I trust this address my 
> general point about multiplexing. Change the term 
> multiplexing to "multi-capsulating", if one must be an 
> american pedant when using English.

I don't see multiplexing "architecturally entitled" from this.  I see an
application data protocol, with the messages "treated as transparent data to
the record layer" (5.7).

> 2. the lowest record protocol layer is "layered on top of 
> some reliable transport protocol (e.g., TCP[TCP])". TCP is  
> clearly cited as an example, only. TCP was not assumed in the 
> security model design goals, though of course reality often 
> intruded on the team! A record layer layered on the protocol 
> known as the "SSL3 Protocol" was certainly intended (i.e. SSL 
> tunneling). Do not assume HTTP 1.1 keep-alive existed, and 
> the internet is being flooded by shortlife TCP instances that 
> are upsetting US ISPs and the US FIX-architecture backbone 
> concept for an IP internetwork design.
>  
> 3. the primary goal of SSL Protocol was to provide privacy 
> and reliability, app to app. As my parsing in (2) above 
> indicates, the reliability properties of one protocol stack 
> (record layer over TCP) might be different to another (record 
> layer over the SSL Protocol, over TP4). As history may 
> recall, at the time getting reliable transport sessions 
> between class d addressed applications was a challenge, as 
> the internet had no bandwidth reservation techniques, at the time.

Gee, OSI flashbacks!

I don't see any different between SSL over TP4 and SSL over TCP.  I don't
see how bandwidth reservation is relevant.

> 4. What is not stated (as https was deliberately never 
> specified, except by Eric's "authorized" rendition of web 
> reality from his (then implementor's) viewpoint) was how this 
> protocol architecture addressed hypermedia applications. It 
> true that it is not stated that "reliable transport" should 
> be assume to include multicast transport, supporting 
> (multicast hypermedia) applications. Take it from me, 
> however, that this was intended, when addressing protocol 
> goals such as were being considered (at the time) for 
> HTML-enhanced nntp  , and pre-ldap multicast white pages 
> directories and their supporting directory 
> replication/authentication protocols (for efficient PKI cert 
> distribution!).

I'm having trouble getting the point here.  Why are addressing structures at
that level relevant here?
 
> "   An SSL session may include multiple secure connections; in
>    addition, parties may have multiple simultaneous sessions."

Sure.  I read that as meaning that an SSL session may involve multiple
underlying connections (eg. TCP, TP4, whatever) and those underlying
connections may be used simulataneously or successively.  In otherwords the
lifetime of the SSL session does not follow the lifetime of the underlying
transport session.

I do not see this as a statement of architectural intention to add
"multiplexing."

> In terms of whether SSL3/TLS is prime time for Internet 
> Standard status , its often worth testing what folks read 
> into the document, when they implement long after the 
> original design issues have long since left the community 
> consciousness.
>  
> With TLS 1.0 endorsing  null confidentiality ciphersuites, I 
> assume the primary goal statement ("provide privacy and 
> reliabily...to apps") in TLS got changed from that in SSL3. 
> Goal:Privacy assumed a robust confidentiality service, and 
> goal:reliablity assumed OPTIONAL robust session 
> management/resumption techniques that were intended to be 
> sensitive to the IP network over which the https/SSL 
> connections were flowing while understanding the 
> socio-political risks that come with sever-side session 
> caches and hidden session restarts using lower strength ciphersuites.
>  
> understand that session caches are OPTIONAL, and a function 
> of the network topology of the IP backbone. In tying SSL 
> interworking quality to TCP behavior in particular (probably 
> US) IP nets, I worry! hypermedia apps and https understanding 
> aside, I worry about whether folks really get the secure 
> session state architecture within SSL! Its really not clear 
> that folks get that SSL Record layer contains its own 
> fragmentation and reassembly possibilities, which addressed 
> the competing goals of compression contexts and security 
> contexts, for multiple, multiplexed secure sessions operating 
> in two directions, simultaneously. While someone thought 
> quite carefully about the interaction of SAML1.1 protocol's 
> session establisment process and its interaction with the SSL 
> architecture for secure sessions, its not clear TLS1.2 is 
> properly addressing the radical changes brought about by 
> SAML2.0 - on multi-site session destruction, for example. 

How is this relevant?
  
> In summary, as an Internet Standard, its not clear that TLS 
> is ready for such standing. Its  evidently really not a 
> widely understood secure session management architecture , 
> and its architecture or writeup was not sufficient apparently 
> for it to keep uptodate with the inevitable changes that 
> always go on around standard protocols.

I don't see this as evident at all.  Can you be more precise?
  
> But, when I rationalize, this is not all that surprising. The 
> specific intent of the writeup was to benefit implementors 
> and RSA's cryptographic analysts; support standardization was 
> not an explicit writing goal.

Benefiting implementors is generally a good thing, in my experience,
standards for the sake of standards generate lots of paper, but aren't
terribly useful to implementers.  And standards without implementers
generally aren't very useful over time.  Witness the current popularity of
TP4.

Regards,

Jan.
 
> 
>   _____  
> 
> 
> > From: [email-masked]
> > To: [email-masked]
> > CC: [email-masked]
> > Subject: RE: [TLS] Serious crypto problem fixed by envelope 
> HMACmethodinstead of currently used prefix
> > Date: Fri, 24 Nov 2006 12:31:00 +1100
> > 
> > I'm responding very generally ...
> > 
> > Peter Williams wrote:
> > > > What happens with TCP packets depends on many 
> variables. These are
> > > > irrelevant to TLS and are hidden by a TCP implementation.
> > > > 
> > > > TLS has a record layer to provide a record abstraction on 
> > > top of TCP.
> > > > 
> > > 
> > > Distinguish TCP packets from TCP connection state changes, 
> > > however. These were all security-relevant signals, for SSL 
> > > designers, as indicated by the socket.
> > > 
> > > And, dont read too much into the term "record", and don't 
> > > associate it with TCP/IP's internal signalling or "framing" 
> > > behaviour for a given network media. The record construct 
> > > refers to the framing of the SSL2 handshake messages, and 
> > > then the framing due to handling the resulting security 
> > > context(s), suited to Type II cipher environments.
> > > 
> > > SSL3 always intended that one could multiplex different 
> > > handshakes and different security contexts within the 
> > > reliable byte stream(s) (perhaps and only perhaps implemented 
> > > using TCP/IP), befitting resolving an HTML page with multiple 
> > > image and voice tags to be rendered in parallel, along with 
> > > other HTML pages in the frameset being similarly rendered 
> > > from other website sources via http or other URL protocols.
> > 
> > Are you saying that SSL3 was intended to allow multiplexing 
> over a single
> > reliable byte stream? If so, do you have a reference?
> > 
> > > TLS1.1+ seems to be rapidly deviating from the intended 
> > > multiplexing architecture, by always extending the common 
> > > handshake (wot crypto wimps!). It should have been specifying 
> > > and standardizing additional handshakes, for use beyond 
> > > https, using a common pool of std ciphersuites, when 
> > > resolving non HTML media such as different XML document classes. 
> > 
> > Why?
> > 
> > TLS provides a reliable byte stream with specific security 
> services applied.
> > Providing "media specific" services or multiplexing in a 
> protocol like TLS
> > is clearly a mistake. TCP/IP does a fine job of 
> multiplexing. Why do it
> > again?
> > 
> > An application implementing a higher layer protocol can 
> choose to allow
> > specific TLS features and to deny others to meet a specific 
> need, but that
> > is where it should end. TLS has no knowledge of https.
> > 
> > > Perhaps its not too late to put TLS back into its original 
> > > security model. One could be ensuring that when the 
> > > WS-Security secureConversation protocol (for example) is 
> > > performing the actions of resolving a particular class of XML 
> > > media then suitably multiplexed handshake(s) are occuring 
> > > within the record layer - (a) supporting the http-bindinhs 
> > > and (b) the secureconversation protocol itself, in parallel 
> > > as necessary. In such a handshake, entropy may of course be 
> > > being obtained from a server, rather than from random source, 
> > > as in traditiona netscape https for example, where the server 
> > > retains information records to address crypto regulations 
> > > (e.g. the proposed signed evidence work items). If one is 
> > > using the TLS1.1 SAML extension for identification, this 
> > > third handshake may be specifically using SAML's delegated 
> > > entropy modes when applying XML-encryption-based 
> > > ciphersuites. Who knows! But this is what the architecture 
> > > was intended to support!
> > > 
> > > I for one make the assumption that, upon resuming a (or being 
> > > induced by an ISP to resume an interupted) SSL2 or SSl3 
> > > session, one may be being required to re-renegotiate 
> > > ciphersuites when picking up the new TCP channel (that 
> > > requires SSL->TLS handling, and then use of govt-escrowed 
> > > (i.e. compromised) PSK ciphersuite perhaps) - at the right 
> > > moment to (i) perform the legal interception of the 
> > > particular multiplexed session identified, and (ii) enable 
> > > the ISP to show that its intervetion at the SSL session 
> > > layer, probably via TCP interference, fits the particular 
> > > class of interception order.
> > 
> > I am guessing that you are concerned about the crypto in a 
> resumed TLS
> > session being downgraded, but I'm not sure. If this is what 
> concerns you,
> > then write (or configure) your application to not use 
> ciphersuites you don't
> > want.
> > 
> > > Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP 
> > > signals is fraught with security sideeffects, that IETF's 
> > > senior security architects may be intending or not intending 
> > > when standardizing TLS.
> > 
> > Sorry, I think I've missed your real point entirely.
> > 
> > TLS's purpose is to provide a reliable byte stream service 
> with strong
> > confidentiality, integrity, and/or authentication. To do 
> this, TLS uses a
> > reliable byte stream service without strong security 
> guarantees, such as
> > TCP.
> > 
> > 
> > Regards,
> > 
> > Jan Mikkelsen.
> > 
> 
> 
> 
>   _____  
> 
> Check the weather nationwide with MSN Search Try it now! 
> <http://search.msn.com/results.aspx?q=weather&FORM=WLMTAG> 
>

---

From: Mike <[email-masked]>
Date: Thu, 23 Nov 2006 21:42:04 -0800

Peter Williams wrote:
> At the same time, to become a Internet Standard, the document 
> has to show its being clearly understood by the average technical reader.

I am new to TLS; I first decided to try to implement it two months ago.
Looking at my CVS logs, my first line of code was written on September
18, 2006.  I've found all the specs to be straightforward, and my code
interoperates with SSLv3, TLS 1.0, and TLS 1.1.  I've implemented the
spec in the TLS 1.2 draft, but so far nobody has connected to my test
server (www.mikestoolbox.net:4433) with that version.  It's possible
that it doesn't work, but nobody has told me.

Note that I had already implemented X.509 certificates and (ironically)
use the OpenSSL libcrypto for all encryption and public-key operations.
Also of note is that the C++ classes I wrote to handle SSL/TLS never
make any socket calls; they merely do a lot of string processing.

> its not clear to me, from recent reading, that this community understand 
> that session caches are OPTIONAL, and a function of the network topology 
> of the IP backbone. In tying SSL interworking quality to TCP behavior in 
> particular (probably US) IP nets, I worry! hypermedia apps and https 
> understanding aside, I worry about whether folks really get the secure 
> session state architecture within SSL! Its really not clear that folks 
> get that SSL Record layer contains its own fragmentation and reassembly 
> possibilities, which addressed the competing goals of compression 
> contexts and security contexts, for multiple, multiplexed secure 
> sessions operating in two directions, simultaneously. While someone 
> thought quite carefully about the interaction of SAML1.1 protocol's 
> architecture for secure sessions, its not clear TLS1.2 is properly 
> addressing the radical changes brought about by SAML2.0 - on multi-site 
> session destruction, for example.

I don't know what SAML is, so I can't comment on that, but will note
that it took me just a couple hours to add session caching to my TLS
server code.  All you need is a map with the session id as the key.

> But, when I rationalize, this is not all that surprising. The specific 
> intent of the writeup was to benefit implementors and RSA's 
> cryptographic analysts; support standardization was not an explicit 
> writing goal.

I'll admit that it took me a few tries to get through the first spec
(TLS 1.0), because of the description of the presentation language.
It's actually quite simple, once you get used to it, but I had to
put it down a few times due to information overload before getting
to the meat of the spec.  Once I saw it being used in real examples,
it became natural.

Mike