Subject: RE: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00

From: Peter Williams <[email-masked]>
Date: Sat, 16 Dec 2006 16:49:24 -0800

COncerning Filename : draft-rescorla-tls-opaque-prf-input-00.txt   "As noted in Section 3 it is anticipated that applications may want to   have access to the opaque PRF input values and that they may contain   data that is meaningful at a higher layer.  Because the values are   covered by the TLS Finished message, they are integrity-protected by   TLS.  However, the application must independently provide any   confidentiality necessary for those values."
We are used, post SSL2, to layer 5 entities inspecting SSL3/TLS1.x messages - particularly for sessionid. We are used to sticky and persistent SSL sessions, over one or more reliable byte streams.  In the TCP over IPv4 world, we are well used to load balancers managing/influencing session resumption, on sticky sessions. We are used to sticky sessions being tied to (p)vlans, and SSL sessionids being similarly tied to networked-cryptomodule sessions via PKCS#11 session mapping. We are used to ssl offloading, in front of load balancers. We are used to TTLS's  additional protections for the SSL handshake, and its impact on end-end transport in the general internet.
 
However, those deployment options have nothing to do with TLS - the standard. They are merely a set of operational deployment practice - focusing on the Netscape-https world, the mobile world, and radius logon/authorization to ISP access points. My (SSLv2-mode) TLS endpoints however, operate within an entirely different operational world.
 
Acting wholly within a FIPS 140-2 level 3 crypto boundary, my protocol engine and the application data consumer/producer do their thing -  obviously accessing the crypto primitives and SMIB of keys. The design implements the N-TCB concept of trusted network design, where the "distributed application" operates across the set of TCB and FIPS 140-2 boundaries, just as the SSL protocol engine, the (bluetooth wep-secured) stack and cryptomodules classically do. Obviously, under the trust criteria, my applications are necessarily very small (and happen to be small java applications). The TLS engine does NOT have session resumption (in SSLv2 mode), enforces Red Book connection-oriented paradigm (necessarily) at the T-layer endpoint, and ciphersuite negotiations are controlled by the cipher capabilities of the cryptomodule component of the NTCB instance. It is not your classical load balancer! ... helping websites do cost-effective hashed password login to hotmail.com!
 
Now, to the point!
What the architecture change in the I-D seems to propose is that applications in unix host type environments may require API/socket-level access to more than the sessionid. Its unclear whether "applications" are client protocols of, or conventional parties that generate application-data on, the record layer. Its unclear what would happen in a TTLS case, where the handshakes are themselves requiring privacy for client-id, session-id control etc, and TTLS is wholly implemented within the FIPS module boundary.
 
But, as I indicated earlier, "application" access to certain VALUES within the SSL state machine and its data flows is not that unusual. But, control over and/or access to PRFs data-components are. If we take the example of the Microsoft CSP for SSL, such SSL-crypto providers are specific to its schannel stack (being well distinguished from CAPI providers for security analysis and export control purposes), and the PRF is assumed to be a security mechanism that resides within the FIPS 140-1 crypto boundary - much like a hash or signature primitive is. Unlike normal CAPI/JCA CSPs, the schannel CSP support the PRFs required for SSL (and ws-secureconversation). How sensitive material enters and leaves the crypto module when the module is applying this PRF primitive, is therefore a function of the FIPS security policy, the key/data wrapping disclosures , the state of the unit under its trusted path rules, etc.
 
I find it the I-D a bit confusing as "so much context is missing"  for rationalizing the scheme (which is itself perfectly well specified ).  I do note that the spec is targeting an HTTP extension, worries alot about the extension negotiation rules, and of course entails that the extension's user-data might be passing over OOB channels beyond the control of load balancers and their traditional engineering work in trying to tie keepalives, ssl sessions, and cryptobox sessions together.
 
If I apply it to my own deployment context, I'm not sure how I could pass the additional PRF input/output values across the crypto module boundary - when the integration is with a _non client-protocol_ "application", while ALSO retaining the integrity assurance required by in the spec.
 
Perhaps we also need to look at some FIPS 140-2 security policies, looking at the WS-encryption/WS-SX/SAML2 profiles, too. The same issues surely must be being raised there, for the same US govt apps.
 
But, this is all a fascinating evolution of SSL!
Peter.

> Date: Fri, 15 Dec 2006 11:26:19 +0200> From: [email-masked]> To: [email-masked]> Subject: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00> > FYI:> > New Internet-Draft is available from the on-line Internet-Drafts > directories.> > Title : Opaque PRF Inputs for TLS> Author(s) : E. Rescorla, M. Salter> Filename : draft-rescorla-tls-opaque-prf-input-00.txt> Pages : 8> Date : 2006-12-14> > This document describes a mechanism for using opaque PRF inputs with> Transport Layer Security (TLS) and Datagram TLS (DTLS).> > A URL for this Internet-Draft is:> http://www.ietf.org/internet-drafts/draft-rescorla-tls-opaque-prf-input-> 00.txt> > [...]> > A New Internet-Draft is available from the on-line Internet-Drafts > directories.> > Title : SuiteB CipherSuites for TLS> Author(s) : M. Salter, E. Rescorla> Filename : draft-rescorla-tls-suiteb-00.txt> Pages : 11> Date : 2006-12-14> > RFC 4492 describes elliptic curve cipher suites for Transport Layer> Security (TLS). However, all those cipher suites use SHA-1 as their> MAC algorithm, which makes them unsuitable for some applications.> This document describes eight new CipherSuites for TLS/DTLS which> specify stronger digest algorithms and therefore are suitable for use> in applications which require compliance with the United States> Government's guidelines for "NSA Suite B Cryptography" dated July,> 2005.> > A URL for this Internet-Draft is:> http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-00.txt> > [...]> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Use Messenger to talk to your IM friends, even those on Yahoo!
http://ideas.live.com/programpage.aspx?versionId=7adb59de-a857-45ba-81cc-685ee3e858fe

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 18 Dec 2006 16:22:09 +0100 (MET)

Peter Williams wrote:
> 
> We are used, post SSL2, to layer 5 entities inspecting SSL3/TLS1.x
> messages - particularly for sessionid.

I don't understand the purpose of looking at the SSL session ID on
(transparent) middle boxes, other than for statistics.

An application or a Browser-based application frontend may be using
several independent SSL sessions within a single application session,
and since there is both a lifetime limit on SSL sessions and a resource
limit on the server-side SSL session cache, it is undefined
at which point during an application session SSL sessions expire.

When the backend application is stateless, it is not necessary
to look at the SSL session ID for load balancing.

When there is backend state involved, looking at the SSL session ID
will result in a flakey load balancing architecture.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Dec 2006 07:48:46 -0800

Peter,

*please* figure out some way to put line breaks in your messages.
It makes them very hard to read.

Peter Williams <[email-masked]> wrote:
> What the architecture change in the I-D seems to propose is that
> applications in unix host type environments may require
> API/socket-level access to more than the sessionid.

That's always been true. Recall that TLS doesn't specify how
one checks certificates. That's done at higher layers (E.g.,
RFC 2818). So, the next layer protocol generally needs a 
fair amount of access to properties of the TLS session. 
It's also generally common to provide access to the cipher
suite.

> I do note that the spec is targeting an HTTP extension, worries alot
> about the extension negotiation rules, and of course entails that the
> extension's user-data might be passing over OOB channels beyond the
> control of load balancers and their traditional engineering work in
> trying to tie keepalives, ssl sessions, and cryptobox sessions
> together.

Why do you say "HTTP extension"? This is a pure TLS extension.

-Ekr

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Fri, 22 Dec 2006 10:03:41 -0500

Hi,
speaking of the "the next layer protocol generally needs a
 fair amount of access to properties of the TLS session"
How to get access to the client and server session caches?
How to do it on the various SSL/TLS implementations on the win 32 or 64
platforms:
Where do they implement the dll or COM object or ... that holds the client
and server side session caches?
Thanks in advance,
Regards,
Omirjan Batyrbaev,
----- Original Message ----- 
From: "Eric Rescorla" <[email-masked]>
To: "Peter Williams" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, December 18, 2006 10:48 AM
Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00
anddraft-rescorla-tls-suiteb-00