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

[<home_pw@xxxxxxx>]

> (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. 


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