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: Mon, 18 Dec 2006 14:43:51 -0800

1. First: a minor rewrite. I have no idea why I typed HTTP, incorrectly. I certainly 
thought "TLS."
"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 TLS 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."
There are now two issues in the controversy: (a) should apps have this kind of control 
(b) is there a public rationale for opening up application control of a PRF crypto-primitive 
(and thus the master keying)
 2a. Its true that SSLv2 assumed/assumes applications will do cert stuff, & assumes
the server chooses whether to do the (optional) server authentication. In _modern_ SSLv2, one
can apply elements of its design intent in ways one cannot do with SSL3/TLS1. Recall: one 
need not  assume X.509 , and neither does one need furthermore to assume
the world of assured PKIs, in SSLv2.
 
So, for example, we can use modern XML DerivedSessionTokens from modern WS-SX specs in SSLv2 
certificate messages, if we want. We define our own "cert type", and let SSLv2 record layer
master key generation be a function of an WS-SX exchange in a "parallel SSLv2 session".
 
For example,  In the wifi world of PEAP-TLS, the vlan in the client stack created by the first 
ssl session on a first binding to an access point's "provisioning" ssid can now provision/constrain and 
key for the vlan#2 to now address the second binding to the second ssid -- the subscriber having now 
"paid for" the service at the hotspot, which is now suitably provisioned.
 
Thus, a DerivedSessionKeysToken exchange from the first binding can become the key management 
and control regime for the second, enforced by the vlan implementation in the client wireless 
stack that delegates *complete* control of this new nic to the ISP. 
 
This is the KIND of application control that was intended, in SSLv2!
 
2b. SSLv3 design was of course radically different to SSLv2, addressing proxing and multi-tier 
load balancing  in ways that SSLv2 did not (and could not, by design). The SSLv3 engineering and 
architecture addressed high-volume SSL in the data center architectures of the 1995 period, when 
crypto-accelerators and trusted CSP's were not common! 
 
In SSLv3, we went beyond SSLv2's ideas of app control, via socket parms, limited up to then to
the issues of deciding a. auth policy, b. cert trust, and 
c. key management/distribution's cert formats. The design allowed **various** SSLv3 
participants to now control session resumption, standardizing on the control principles of hierarchical 
PKI futhermore. Arguably, the latter was the wrong decision. However, all this 
got SSL into mainstream __data center__ engineering. Today, its easy to buy offloaders, load 
balancers for SSL...that properly linkup with firewalls and vlan configs, for predicable performance
and virtual SSL hosting.
 
3. In the I-D, we seem to going **yet further**, with TLS 1.2-era proposal. Now, the application can 
influence elements within the trusted CSP and how the crypto primitives in the firmware of the 
FIPS device boundary will react, to certain data signals. THis is a bit like putting S/MIME's security 
labels into the Cryptobox, and letting those signals control the PRF crypto primitive.
 
Without disclosure of a _non_ govt application of this practice, its REALLY hard for IETF to endorse the 
direction.
 
We HAVE to find a (fully disclosed) motivation for this in IETF, that is not military/govt. Otherwise, 
NSA really needs to just get NIST to issue a FIPS, like they did for the escrowed algorithms in
the Clinton era. Then public FIPS commenting processes can be used to qualify the specified 
practice, for any non govt. uses. 
 
So. in conclusion: Im not opposed, except on the grounds of "less than adequate disclosure". 
 
Peter.

> To: [email-masked]> CC: [email-masked]; [email-masked]> Subject: Re: [TLS] New I-Ds: draft-rescorla-tls-opaque-prf-input-00 and draft-rescorla-tls-suiteb-00 > Date: Mon, 18 Dec 2006 07:48:46 -0800> From: [email-masked]> > 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
_________________________________________________________________
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: <[email-masked]>
Date: Wed, 20 Dec 2006 17:05:58 +0200

I sort of agree with what Peter already said about the
opaque-prf-input draft. It is clearly the "lower layer" of some
mechanism for doing something useful. It's not useful if we don't 
know what the "upper layer", "some mechanism" or "something useful" 
are, and without knowing those, it's very difficult to comment the 
draft or support its advancement.

So, more details would be very welcome! 

Best regards,
Pasi