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

Wan-Teh Chang <wtchang@redhat.com> Wed, 17 January 2007 22:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JZa-0002hI-F6; Wed, 17 Jan 2007 17:48:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7JZX-0002eB-U1 for tls@ietf.org; Wed, 17 Jan 2007 17:47:59 -0500
Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7JZU-0000gE-De for tls@ietf.org; Wed, 17 Jan 2007 17:47:59 -0500
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0HMlsfC011183; Wed, 17 Jan 2007 17:47:54 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l0HMlrjj008947; Wed, 17 Jan 2007 17:47:53 -0500
Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id l0HMlohS009299; Wed, 17 Jan 2007 17:47:52 -0500
Message-ID: <45AEA795.2080308@redhat.com>
Date: Wed, 17 Jan 2007 14:47:49 -0800
From: Wan-Teh Chang <wtchang@redhat.com>
User-Agent: Thunderbird 2.0b2pre (Windows/20070117)
MIME-Version: 1.0
To: tls mailing list <tls@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc:
Subject: [TLS] Review comments on draft-rescorla-tls-opaque-prf-input-00.txt
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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