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

[Eric Rescorla <[e-mail]>]

<[e-mail]> writes:
> 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.

Hmm... Well, they were both funded by the same people but they
really are separate. This draft is just what it says, 
a new set of cipher suites profiled to match SuiteB.
Note that SuiteB is *algorithms* and is applicable to non-TLS
applications such as S/MIME. The SuiteB algorithms have
already been published, so the purpose of this document is
just to produce cipher suites that match that profile.
Note that it also defines some cipher suites that would
be good to have.

In the rest of this comment I'm going to read where you say "SuiteB"
as draft-rescorla-tls-suiteb...



> - 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?

Yes, it's because SuiteB requires SHA-256 or SHA-384.


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

Yes. In general SuiteB is designed to have a set of algorithms
of more or less equivalent strength. SHA-1's strength doesn't
match the rest of the algorithms.


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

I think you've gone off track here. The rational for GCM isn't
that it works with DTLS. There is an interest in GCM in both
TLS and DTLS for a bunch of performance reasons.


> -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),

Sorry, I think you're off track here again. The reason for using
the sequence number as the GCM per-record IV is to make each
record independent without having an explicit IV. Note, btw,
that in post-San Diego discussion the WG seemed to prefer to
have an explicit IV, so I think this sequence number hack is
probably going to go away.


> 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, there's nothing mysterious here... GCM doesn't use HMAC
and TLS 1.2 requires hashes to use in the KDF, so we have to 
specify them.


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

It's really for an orthogonal purpose. The SuiteB draft is
useful even in the absence of that draft.


> - 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)

Well, TLS already supports ECC and SuiteB just requires a
specific set of curves, so this section is intended to 
specify which ones were.


> 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)

What puzzles you about the design choices in draft-rescorla-tls-suiteb?


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

Well, you shouldn't call the DH ZZ a key. It's not. It's a secret.
Arguably it's not keying material either...

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

As noted previously, use of the SuiteB cipher suites is orthogonal
to use of opaque prf.


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

I don't see where it implies that and there's no more connection
between GCM and the opaque PRF draft than there is between
CBC and the opaque PRF draft. 


> 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?

The Opaque PRF is only for generating the master_secret. It is 
not re-used to generate the keys for the individual algorithms.
However, because those keys are generated from the master_secret,
entropy from it of course gets fed into the final keys.

-Ekr


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