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

Thanks, Eric, for the review and comments.  Our thoughts embedded, with [JL] prefixes. 

-----Original Message-----
From: Eric Rescorla [mailto:ekr@networkresonance.com] 
Sent: Sunday, July 02, 2006 12:39 PM
To: tls@ietf.org
Subject: [TLS] Comments on draft-linn-otp-tls-00

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. 

[JL] Any confusion here was unintended.  A number of methods are commonly known and described as one-time passwords; the draft is intended to be able to support a range of choices.  RFC-2289's title, e.g., is "A One-Time Password System"; it's a particular method, rather than defining the entire class. To resolve the name conflict against RFC-2289, we could coin a new phrase for this draft, perhaps Single-Use Passwords (SUPs), but this would lack familiarity for readers.

   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.

[JL] Good observation.  The approach as described in the draft indeed requires that both client and server be capable of generating a common OTP/SUP value independently.  We'll make this explicit in a subsequent revision.

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.

[JL] As RFC-4279 states, "This document does not mandate the use of any particular type of identity...".  We've tried to remain consistent with the encoding conventions that RFC-4279 prescribes, but it appeared that the content of psk_identity was not fully constrained.  Potentially, it could be possible to maintain the existing interpretation of psk_identity (basically, what the current draft prefixes with "UI="), and to accompany it with OTP-specific qualifiers only if signaled through use of an extension.  Would additional qualifiers within psk_identity seem acceptable in such a context?

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.

[JL] This would be appropriate within the context of a new TLS key exchange method definition.  The current draft sought to represent this data within RFC-4279's overall character string encoding conventions for psk_identity.

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

[JL] Good point.  We'll investigate this in the context of a new extension, as suggested above. 

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

[JL] Agreed. 

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

[JL] Is there existing guidance and precedent to qualify definition of alerts that are specific to particular methods or ciphersuites?  I respect the need to conserve the alert space, and compression relative to the current proposal would be possible, but would like to identify a means to provide sufficiently descriptive indicators as to disambiguate failure cases. 

-Ekr

[JL] --jl

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls