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

Peter Williams <home_pw@msn.com> Fri, 24 November 2006 03:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnS10-0001ok-IA; Thu, 23 Nov 2006 22:46:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnS0z-0001ob-JI for tls@lists.ietf.org; Thu, 23 Nov 2006 22:46:13 -0500
Received: from bay0-omc3-s23.bay0.hotmail.com ([65.54.246.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnS0w-0007u5-DM for tls@lists.ietf.org; Thu, 23 Nov 2006 22:46:13 -0500
Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc3-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 19:46:09 -0800
X-Originating-IP: [71.140.81.171]
X-Originating-Email: [home_pw@msn.com]
Message-ID: <BAY103-W1437F30DB1B5ECABE060892E10@phx.gbl>
From: Peter Williams <home_pw@msn.com>
To: Jan Mikkelsen <janm@transactionware.com>
Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix
Date: Thu, 23 Nov 2006 19:46:09 -0800
MIME-Version: 1.0
X-OriginalArrivalTime: 24 Nov 2006 03:46:09.0861 (UTC) FILETIME=[1441F750:01C70F7B]
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 6a817af60e4281a101681ecb646dffff
Cc: tls@lists.ietf.org
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="===============1484841462=="
Errors-To: tls-bounces@lists.ietf.org

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: janm@transactionware.com> To: home_pw@msn.com> CC: tls@lists.ietf.org> 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
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls