Re: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt

[<[e-mail]>]

Lets reference RFC4347, and 
http://www.ietf.org/internet-drafts/draft-rescorla-tls-suiteb-00.txt, 
and see where some analysis takes us. It cannot be that 
hard, if Peter can make some sense of it - to build a 
reasoning context.

 (1) we should probably link suiteb-00.txt with 
opaque-prf-input.

- SuiteB starts with the core claim that "However, all those 
cipher suites use SHA-1 as their MAC algorithm, which makes 
them unsuitable for some applications." Something about 
SHA-1 means someone can't use them. Perhaps, its because 
they have to use SHA-256? E.G. 
http://www.cast-inc.com/cores/sha-256/index.shtml

- SuiteB goes on to assert that guess: "A key ingredient of 
SuiteB not found in RFC4492--or the definition of TLS itself 
prior to 1.2--is the use of SHA256 or SHA384 for key 
derivation." And, not only is it disclosing not an issue of 
MACs (re SHA-1), now it's the KDF. So, there is a 
ciphersuite issue with MAC *and* KDFs, I'm guessing

- SuiteB goes on to define not only some ciphersuites, 
around the Suite B Algorithms, but also focuses on 
AEAD-related notions specific to DTLS, probably  - which 
needs such things, being connectionless. It cites and 
profiles the Galois mode CCM method, defining a nonce form. 
We should recall that NIST only addressed AES-CCM for 
802.11, not wider. It was VERY specifically worded , I 
recall. I think this is implying that the Galois mode is 
required, for SuiteB compliance.

-Suite B focuses itself a lot on DTLS, links up with its 
seq_number constructs (that presumably have to worry like 
TCP seq-nos have to similarly worry), cites RFC3686, and 
notes that "Because GCM does not use HMAC as a MAC function, 
the hash function for the TLS PRF must be explicitly 
specified."

- Well, I'm going to guess that 
draft-rescorla-tls-opaque-prf-input-00.txt is the follow up 
to the specification need.

- SuiteB finishes off with material about EC curves, and how 
curve selection is being addressed as a function of 
protocol. (This is quite interesting of itself, note; I have 
to think about that for a connectioness setting)
Ok. I don't see any great mystery or conspiracy going on 
here (apart from the conspiracy of silence in mailing list 
discussion by the authors to 3 sets of comments, now, all 
asserting the same thing, essentially: "Explain & 
Participate! We cannot be a rubber stamp!" Have the RFC 
Editor just issue these documents as is, and avoid TLS WG - 
if it is just too sensitive for USG to be seen arguing over 
policy stuff, in public standards forums. The RFC Editor has 
that power, and its not a bad reason to exploit it)


Now to (2) lets look at opaque-prf-input.

-	First we focus on the nonce discussion. So, aha. 28 + 4 = 
32. That clears up one mystery for me! Only 28 of the 32 
bytes come from a suitable PRNG process fit for nonces; the 
other 4 are not random, as another part of the TLS spec 
implied. They are current time. Hmm. Random does not require 
any particular random properties; Random is just a type name

-	We can quote now "The client and server each contribute a 
Random value which is then mixed with secret keying material 
to produce the final per-association keying material." One 
should note the use of the term "keying material", 
associated with the term  secret. He didn't say key. He also 
refers to "keying material" as being the output of the final 
KDF, having done the classical mix type operation.

-	Let's contrast now, with fortezza_dms from SSLv3 days. 
There, they didn't generate keying material for the mac 
process; it generated mac_secrets (i.e. note the change in 
doctrinal naming; the former "mac_secret" is now probably 
goin to be referred to as "keying material", but only in a 
SuiteB context). This would normally tell you that the mac 
process has to go through the HSM now, no more soft-mac'ing. 
For a wired/wireless NIC or layer 3 router doing DTLS, this 
is not that unusual, where the hard logic of the FPGA 
cryptocore can handle the overhead of generating the GCM key 
schedule (using Galois mode math) and doing 
multiply-expensive SHA-384 mac operations, at high data 
packet/frame flow rates.

-	In terms of language usage, it then focuses not on SuitB 
rationale, but on the actual applications, when asserting:
   In a number of United States Government applications, it 
is desirable to have some material with the following 
properties:

   1.  It is contributed both by client and server.
   2.  It is arbitrary-length.
   3.  It is mixed into the eventual keying material.
   4.  It is structured and decodable by the receiving 
party.

-	It then whine a bit about the current definition of 
Random, which is "too small" and doesn't have the properties 
above. Then, it defines the core claim: opaque PRF will 
address this, basically by having an enhanced Random sent as 
extensions.

-	Ok. So mystery over. They cannot fix the Random type 
definition, so they are passing a better one as an 
extension. And, its values SHALL have the defined 
properties, and get used in the final KDF for the SuiteB 
ciphersuites disclosed in the other document.

-	There is some confusion in my mind tho. The documents are 
not really consistent. They also imply that the opaque PRF 
is also used in the GCM, used to setup the key schedule for 
the AEAD stream cipher. Some writing clarity is required 
here. The big picture needs laying out, if TLS WG is to add 
any IETF value, not available be having the RFC Editor issue 
it. So, my outstanding issues are: Is the opaque PFR only 
for the KDF for generating connection state, or is it also 
for the generating the key schedule?

ok. we need to drop the spookiness, and just interact. There 
is nothing wrong with any of this material in IETF, so long 
as average joes can read and understand it.


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