[TLS] Comments on draft-linn-otp-tls-00

Eric Rescorla <ekr@networkresonance.com> Sun, 02 July 2006 16:39 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx4ye-0008Ph-Kr; Sun, 02 Jul 2006 12:39:20 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx4yc-0008JT-SR for tls@ietf.org; Sun, 02 Jul 2006 12:39:18 -0400
Received: from laser.networkresonance.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx4yb-000134-II for tls@ietf.org; Sun, 02 Jul 2006 12:39:18 -0400
Received: from networkresonance.com (raman.networkresonance.com []) by laser.networkresonance.com (Postfix) with ESMTP id DE385222425 for <tls@ietf.org>; Sun, 2 Jul 2006 09:47:26 -0700 (PDT)
To: tls@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19)
Date: Sun, 02 Jul 2006 09:39:17 -0700
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20060702164726.DE385222425@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Subject: [TLS] Comments on draft-linn-otp-tls-00
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

I've given this document a quick read. Comments follow.

1. Calling this an OTP mechanism is kind of confusing because
   the IETF already has a standard for OTP (RFC 2289) based
   on S/Key. Because the RFC 2289 scheme relies on the server
   storing the output of a digest and the client providing
   the preimage, it cannot be used with the mechanism in
   this draft. At minimum, you need to have a section 
   explaining that only systems in which both client and
   server can generate the same password sequence can be
   used here and preferably a name change would be appropriate.

2. I'm very uncomfortable with retroactively changing the 
   meaning of psk_identity--without any external signalling
   as far as I can tell. That doesn't seem like a good plan
   at all.

3. The new PSK identity encoding should be expressed using
   standard TLS structures, not an ASCII encoding. This 
   comment applies both to how to pack the structures and how
   to represent the time, which should be a 32-bit integer
   in accordance with TLS standard practice.

4. In S 3.3.2, what happens if I want to offer multiple 
   otp_algorithms? Impossible.

5. In S 3.3.3, making iteration_count a uint16 seems unwise.
   Better to future proof and make it a uint32.

6. I'm very uncomfortable with creating all these alerts. Note
   that the TLS alert space is only 8 bits wide. Note also
   that per RFC 4346 Alerts can only be created by Standards


TLS mailing list