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

[Simon Josefsson <[e-mail]>]

Hi.  I have read the document and wrote down some comments, that I try
to distill into this e-mail.  Take this post for what its worth, an hour
or so worth of looking at the document and composing the feedback.  I
may have misunderstood something, and in that case, I would appreciate
clarifications.

In general, I believe the document is in good technical shape, and that
implementations of it should be possible.

The abstract should spell out PRF, I suggest to replace:

   This document describes a mechanism for using opaque PRF inputs with
   Transport Layer Security (TLS) and Datagram TLS (DTLS).

with

   This document describes a mechanism for using opaque pseudo-random
   function (PRF) inputs with Transport Layer Security (TLS) and
   Datagram TLS (DTLS).

The introduction, section 1, could be improved by also mentioning the
PRF term.  I suggest to change:

   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.

into:

   The client and server each contribute a Random value which is then
   mixed, using a pseudo-random function (PRF), with secret keying
   material to produce the final per-association keying material.

The title of section 3.2 ('PRF Modifications') is miss-leading because
the PRF is not modified by this document.  What is modified by the
document is the algorithm described in section 8.1 of RFC 4346.  I
suggest to change the title of section 3.2 to 'Modifications to Master
Secret Computation'.

The observation in the previous paragraph may suggest that a better
title for the entire document would be 'Opaque Inputs to Master Secret
Computation for TLS'.  The document only discuss new PRF inputs to one
particular use of the PRF.  The document do not discuss new PRF inputs
to all PRF computations, which could be inferred from the current title
'Opaque PRF Inputs for TLS'.  I got a flawed impression of the goals
with the document after reading the title and not having read much of
the details in the document.

Section 3.2 uses terms 'PMS' and 'MS' without explanation, and there is
no references to the appropriate place in RFC 4346 that is modified.  I
suggest to replace the current paragraph:

   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:

with the following:

   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 pre-master secret to master secret
   conversion (section 8.1 of RFC 4346).  Thus, the step becomes:

The final paragraph in section 3.2 reads:

   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.

The statement is not specific to resumed session, as far as I can tell.
Further, there is already a section 4.3 that explain the interactions
with resumed handshake (a forward reference would have helped me).  I
believe it would be clearer to drop the reference to resumed handshakes
here, and focus on the assertion itself, because it is helpful in
understanding the design choice.  I suggest to drop the first line, and
to add some references and word explanations, making the paragraph read:

   Mixing in the opaque PRF inputs during master secret to keying
   material conversion (see section 6.3 of RFC 4346) would simply
   involve mixing in the same material twice.  Therefore, the opaque PRF
   inputs are only used when the premaster secret is converted into the
   master secret.  See also section 4.3.

For symmetry between (all in section 3.1):

   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.

and:

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

I suggest the last 'should' be in upper case.

In section 4.1, I suggest to add something like this:

   This extension enables client and servers to send significant amount
   of data "out-of-band" to each other, which can be abused to leak
   information.

Finally, I wonder whether the size limit of the opaque prf inputs is
appropriate.  It is currently limited to 64KB.  This is larger than what
would be justified by entropy to better seed the PRF, where (if I
understand the cryptography properly) you'd typically use 128 or 256
bytes.  However, 64KB may be too limited if, as is suggested by the
document, the data will be in some pre-agreed format that the client and
server can parse and do something intelligible with.  This also begs the
question whether there should be an optional type-indicator present, to
indicate the format of the opaque data?

/Simon

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