Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13

From: <[email-masked]>
Date: Thu, 28 Dec 2006 23:56:02 -0800

We were discussing ephemeral DH (etc), vs temporary RSA.

As always, NIST make things crystal clear:

http://csrc.nist.gov/CryptoToolkit/kms/SP800-56A_May2006.pdf

Its best to read this in concert with IETF's CMS for KEA/skipjack, so
one can see its application to more than undergrad DH examples. Then
one can apply it to SSLv3 (and extensions).

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

---

From: <[email-masked]>
Date: Fri, 29 Dec 2006 00:46:27 -0800

see appendix B. Its rationale is relevant to SSL's finished processes,
and the TLS Evidence work item (concerning the confirmed roles being
affirmed, pertinent to the "agreement").

I suspect TLS really ought to define more roles for use in 
the final KDF, including "T-bridge" and "https proxy".

---

From: <[email-masked]>
Date: Fri, 29 Dec 2006 13:50:19 -0800

Given RSA "ephemeral" is being discussed on the WG's mailing list and
was discussed in Eric's authoritative SSL/TLS book, presumably
referring to SSL3/TLS "temporary" keys, we should attempt
to put the topic into the formal proceedings.

If I read between the lines, perhaps we see the underlying issues
of "hardware-assured key exchange" being introduced in NSA's proposed means
for "application-enhanced" PRF mechanisms; and, perhaps also in the GSS-API
proposals. Whilst this is but conjecture on my part, it's not unreasonable.

Given these issues, let's revisit:

  http://www3.ietf.org/proceedings/04mar/I-D/draft-ietf-smime-cms-rsa-kem-01.txt

(as FIPS 800-56B drafts are not available to the likes of me.)

Lets contrast schemes, top begin. SSL3 invested in ephemeral (DH) and
temporary (RSA) keying as means of enforcing cryptostrength-containment 
policies
(i.e. export rules); others use them for assurance reasons, giving plausible
rationales. We saw the latter clearly articulated in 800-56A, and given 
embodiment
by IESG in the CMS with KEA/skipjack RFC. We can see read it furthermore, 
albeit
minimally, in SSLv3 fortezza_dms's type declarations.

Now, it was a colleague of Russ Housley who taught me about the linkage 
between
PKC and integrity-protected (1) TEKs/KEKs, (2) wrapped keys/IVs (with or 
without
LEAFs), and the design of assured FIPS-complying cryptomodules. It was a
former member of CSE in Canada who then taught me how these principles
are extended to trusted path arming processes, in a level 3 FIPS device. If
I now summarize what I was taught, when done right, security handshakes are 
but a
way of provisioning a trusted cryptomodule - a way of remoting the admin 
port, over
which previouslyone might have deployed key manually, using a key fill 
device. When
done right, we can then create families of trusted devices distinguished
by manufacturing-time certs and group parameters; with HSM-certs that 
accompany
key exchange certificates (both static and ephemeral) to distinguish crypto
from such an HSM family from software CSPs. Linked now to FIPS-mode HMACs we 
see
how key derivation can characterize even roles within a security protocol 
flow,
extending the TNI's connection-oriented access control concept to address 
RBAC.

When we look at what NIST and NSA folks have openly taught us, with KEA for
DH's key agreement regimes, as reflected in SSLv3 and CMS, I'm open minded
whether RSA ciphersuites should adopt similar assurance benefits, re key 
wrapping,
MacTags, etc. Viewing RSA transient and additional nonces no longer as 
export-regulation
enforcement tools but as assurance-producing mechanisms, perhaps
we do need to adapt to RSA ciphersuites (a) key wrapping (b) static
and ephemeral keys c) nonces (d) manufacturing and HSM certs.

Peter.

---

From: <[email-masked]>
Date: Fri, 29 Dec 2006 18:23:24 -0800

> (as FIPS 800-56B drafts are not available to the likes of me.)

I've been attempting to deconstruct what I understand NIST's position on
next generation RSA ciphersuites to be (from what I assume 800-56B to say):-

Based on the way 800-56A discusses the role of RSA (or other) key transport.

One uses DH in the users' national identity cards to agree a random
secret,  which has the important property of "bi-lateral key confirmation"
implicit to the math of the DH/KEA etc. This agreement process may include
certain DH ephemerals in addition to statics, and a UKM nonce. This process
satisfies the writer-to-reader rules.

One may use RSA as an IK to transport to several parties the "secret" value 
to
the authorized HSMs associated with one or more user (e.g. one's TPM-based 
SSL CSP,
or a broadcast community of HSMs). The crypto device uses a 
parameterized-KDF to
transform the value into a KEK, which unwraps the keying materials (and mac 
secrets)
used in the SSL HSMs. Presumably, the KDF enforces TPM assurance controls, 
preventing
key derivation when the secret is not assured to be from authorized id cards 
(validated
using "tri-lateral key confirmation" using some unstated method (e.g. HSM 
certs)).

"Key confirmation" would have to be trilateral, if there is key confirmation
by a "third party" - the community of authorized crypto devices.

The final KDF (per connection) in SSL finished protocol takes into account 
the roles
of the 2 or more SSL  parties, currently hashes of the terms "client" and 
"server"

------------

For fun one can extrapolate, doctrinally:-

One can define a role for TLS Evidence, which exist to audit such 
handshakes, using
a dig sig of the handshake hashes (and store the handshake plaintexts).
Presumably, the router/ISP can enforce policy to (a) interdict certain flows 
(b) record
certain auditable handshake plaintexts.