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

From: Wan-Teh Chang <[email-masked]>
Date: Wed, 17 Jan 2007 14:47:49 -0800

Here are my review comments on the Internet-Draft "Opaque PRF
Inputs for TLS", draft-rescorla-tls-opaque-prf-input-00.txt.

1. The "Introduction" section says that in a number of US Government
applications, it is desirable to have some material with four properties.

Could you cite the source of these four requirements?  Is it NIST
Special Publication 800-56A?  Is this Internet-Draft related to the
"OtherInfo" input to the NIST KDF?

Is the material required to be unique or unpredictable?

2. Can you give an example of the opaque PRF input?  Without concrete
examples, it is hard to assess the usefulness of this Internet-Draft.

3. The title of Section 3 "The OpaquePRFInput Extension" probably
should read "The opaque_prf_input Extension."

The first sentence in Section 3 probably should read:

   The opaque PRF input is carried in a new TLS extension called
   "opaque_prf_input", whose "extension_data" field contains an
   OpaquePRFInput value.

Then, you could remove the last sentence of the first paragraph in
Section 3.1.

4. In Section 3.1, the third paragraph explains that the client and
server agree on the opaque PRF input based on its length alone.  The
OpaquePRFInput structure does not have any type information.  It
seems that the client and server must infer the type of the opaque
value by using the length.  Since the receiving party may need to
decode the opaque value, it seems crucial to know the type of the
opaque value, and so it seems that the length alone may not provide
adequate type information.

I'm just trying to understand the rationale behind the requirement
that the lengths of the client and server's opaque PRF inputs be
equal.

5. In Section 3.1, the fourth paragraph, the last sentence is:

   In this case, the server should generate a fatal "handshake_failure"
   alert.

Should the "should" be changed to "SHOULD"?

In this case, since the server requires the opaque_prf_input extension,
should we say "MUST" instead of "SHOULD"?

6. In Section 3.1, the fifth (last) paragraph, the last sentence is:

   If a client requires the opaque PRF input feature but the server
   does not negotiate it, the client SHOULD generate a fatal
   "handshake_failure" alert.

Similar question to the above: since the client requires it, should we
say "MUST" instead of "SHOULD"?

7. In Section 3.2, the second paragraph, we have:

   mixing in the opaque PRF inputs during the MS->keying material
   conversion would simply involve mixing in the same material twice.

I suggest changing "involve mixing" to "mix".

8. In Section 4.1, the last sentence of the first paragraph is hard
to understand because of the double negative:

   there is currently no proof that a larger input space would not make
   attacks easier.

I don't have a better way to say it though.

9. In the References, the last reference (Draft TLS 1.2) is not being
used.

Wan-Teh Chang

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

---

From: <[email-masked]>
Date: Wed, 17 Jan 2007 20:40:27 -0800

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.

---

From: <[email-masked]>
Date: Wed, 17 Jan 2007 20:50:54 -0800

Extending the length of the contributed Nonce information in 
the PRF is nicely disclosed, in section 3.2.

What is interesting now is the session resumption 
disclosure. This may explain why Eric is so adamant that he 
can FORCE a new handshake, so he can refresh the extensions 
values for a new TLS Connection?

But, as disclosed, its more confusing than before. Now the 
opaque PRF can only be used in pre-master-secret to master 
secret generation. In the other document and earlier in the 
paper, it seemed opaque PRF was being given a rationale for 
use in final KDF;'s generation of keying material.

Between protocol analysis, hacking some extensions to extend 
the nonce, PRF parameterization, the way it handles session 
resumption and kind of reverses its rationale... this doesn't 
look a polished and finished piece of work. is "feels" like 
work in progress, attempting to apply external policy to 
standards making.

Again, I cannot find any reason not to do this, or be open 
about it!

---------

3.2.  PRF Modifications

   When the opaque PRF input feature is in use, the opaque 
PRF input
   values MUST be mixed into the PRF along with the client 
and server
   random values during the PMS->MS conversion.  Thus, the 
PRF becomes:

          master_secret = PRF(pre_master_secret, "master 
secret",
                              ClientHello.random +
                              ClientHello.opaque_prf_input_value 
+
                              ServerHello.random +
                              ServerHello.opaque_prf_input_value)[0..47];

   Because new extensions may not be introduced in resumed 
handshakes,
   mixing in the opaque PRF inputs during the MS->keying 
material
   conversion would simply involve mixing in the same 
material twice.
   Therefore, the opaque PRF inputs are only used when the 
PMS is
   converted into the MS.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jan 2007 21:12:24 -0800

<[email-masked]> writes:
> What is interesting now is the session resumption disclosure. This may
> explain why Eric is so adamant that he can FORCE a new handshake, so
> he can refresh the extensions values for a new TLS Connection?

Peter, it's generally polite not to attribute ulterior motives to
others. 

> But, as disclosed, its more confusing than before. Now the opaque PRF
> can only be used in pre-master-secret to master secret generation. In
> the other document and earlier in the paper, it seemed opaque PRF was
> being given a rationale for use in final KDF;'s generation of keying
> material.

First, I should state that I only have fairly limited insight into
the motivation for this extension. I was asked to help design
something with a particular set of parameters in the way that
would be most tasteful for TLS and that's what I did. I agree
it would be nice to have a more explicit rationale for these
parameters and I'm working on getting one.
         
That said, not re-mixing the new entropy into the KDF for 
session key generation wasn't an intentional design feature.
It's merely a limitation of the way that session resumption
and extensions interact.

-Ekr

---

From: <[email-masked]>
Date: Wed, 17 Jan 2007 22:09:52 -0800

----- Original Message -----
From: "Eric Rescorla" <[email-masked]>
To: <[email-masked]>
Cc: "Wan-Teh Chang" <[email-masked]>; "tls mailing list" 
<[email-masked]>
Sent: Wednesday, January 17, 2007 9:12 PM
Subject: Re: [TLS] Review comments on 
draft-rescorla-tls-opaque-prf-input-00.txt

>> disclosure. This may

My apologies.

But, I thought it quite an excellent (assumed 
:-) )rationale, and I am seriously considering its validity; 
designing protocols is always a tradeoff process. it's a lot 
better rationale than worrying about deformed error messages 
in some products.

Before I think about mandatory full handshakes on the 
session resumption case, I think we should first see if we 
can merge two existing traditions, to do what they need:-

(a) let the proposed nonce extension sort out the derivation 
for the master_secret, part of a sequencing for a normal 
full handshake; and

(b) let an enhanced ChangeCipherSuite message (value "2"?) 
(use-negotiated as a semantic of the nonce extension) 
indicate new opaque nonce values for use in the final KDF, 
in a session resumption case.

Put the two together?

There is really nothing sacred about ChangeCipherSuite. OK 
today, it goes on and on about secure state transition, and 
exists to prove knowledge of the master_secret. But it can 
also bear two new nonce enhancements to be used "during" 
said state transition.

In my experiments a long time ago, I had them bearing role 
names strings, to (for purposes similar to TLS Evidence) 
bind the legal roles of the cliamants to the keying material 
being "agreed", and the secure state being "now in effect". 
Imagine the roles names being "client" and "attorney" 
(versus "client" and "server") Or "buyer and seller", or 
"licensed realty agent and licensed mortgage broker". 
Whatever...business protocol is being agreed shall control 
the transaction.

what I did was define 3 states: pending - active - and 
"superactive". I took the key block resulting from 
conforming processing upon entering active, hashed it, used 
it an entropy for a further KDF based on my parameterized 
ChangeCipherSuite. A bit like fortezza_dms, I then just 
overwrote the existing keyblock with new values. (Being used 
in ChangeCipherSuite, it had/has a nice side effect that the 
nonces/roles are confidential (assuming the ciphersuite is 
not null-confidentiality).

How about proposing something along those lines?

I'm now trying to help you, with some brainstorming.

> parameters and I'm working on getting one.

I can already guess. And, I don't thing there is anything 
strange at all in the basic requiremnets being expressed.

Im not sure why your co-author wanted  "It is structured and 
decodable [by the receiving party]." tho.
> It's merely a limitation of the way that session 

So think beyond extensions; I never used them till recently. 
Consider now defining a supporting changeCipherSpec message 
and allow each message to define its secure state definition 
that  go beyond pending and active. This will might remove 
the angst from the current design - which comes across as 
being FORCED into a a set of practice that work...but really 
don't "fit". I think it can "fit fine" tho, if we just think 
a bit more liberally.

Best wishes and good luck.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 17 Jan 2007 22:33:48 -0800

<[email-masked]> writes:
> 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.

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

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