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

From: Peter Williams <[email-masked]>
Date: Thu, 23 Nov 2006 07:14:55 -0800

> From: [email-masked]
> No.> >...
> 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.
 
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. 
 
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.
 
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.

> Jan Mikkelsen> 
Peter.> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
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: "Jan Mikkelsen" <[email-masked]>
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.