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

[<home_pw@xxxxxxx>]

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.


----- Original Message -----
From: <home_pw@xxxxxxx>
To: <tls@xxxxxxxx>
Sent: Thursday, December 28, 2006 11:56 PM
Subject: Re: [TLS] Re: WGLC: draft-ietf-tls-srp-13

> 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
> TLS@xxxxxxxxxxxxxx
> https://www1.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls