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

[Wan-Teh Chang <wtchang at redhat.com>]

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