[TLS] Follow-up to comments on draft-linn-otp-tls-00

[Magnus Nyström <magnus@xxxxxxxxxxxxxxx>]

All,

I would like to follow-up on some of the comments that John and I have 
received in the past and also received during the TLS session at the 66th 
IETF in Montreal. Firstly, I'd like to thank all the reviewers; we really 
appreciate you taking the time.

Whether to layer on TLS-PSK or not
----------------------------------
Several reviewers have suggested that it would be architecturally
better if new ciphersuites would be defined rather than attempting to
profile/extend TLS-PSK. There seems to be a few reasons why the
current approach has not been seen as optimal:

a) The term "key exchange" in TLS relates to the whole handshake as
opposed to the actual cryptographic key exchange (Pasi Eronen). Since
we're modifying the handshake (new extensions, new alerts, ...) it
should follow that this is a new key exchange and hence should define
a new ciphersuite (or -suites).

b) Interpretation of certain data (e.g. the psk_identity field) will
vary depending on whether "ordinary" TLS-PSK is performed or not; this
is undesirable as servers will need to be prepared to interpret (and
act upon) this field based on information in the Hello exchanges (Eric
Rescorla).

I don't quite understand a) above. I don't see that RFC4346 says that the
key exchange defines the whole handshake. But even if this is the case,
what about some of the extensions defined in RFC 4366, e.g. the
truncated_hmac one? It seems to me that that extension also modifies the
behavior of the parties, without introducing new ciphersuites?

On b) above, I agree that this is undesirable. One way forward that I
can see - besides defining new ciphersuites - would be to introduce
(and require use of, when doing a handshake based on OTPs) a new
extension, along the lines of (obviously the syntax needs to be
corrected):

      OTPHandshakeParams otp_handshake_params<0..2^16-1>;>
      struct {
          OTPAlgorithm otp_algorithm;
          ChallengeData challenge_data<0..>;
          HardeningData hardening_data<0..>;
          KeyIdentifier key_identifier<0..>;
          UserIdentifier user_identifier<0..>;
      } OTPHandshakeParams;

This approach would allow not only signaling of the intent of basing
the exchange on OTPs, but also to negotiate the actual OTP algorithm
as well as related parameters. I note that the above should also take
away the need to change the meaning of the psk_identity field,
something we anyway have been recommended not to do.

What I'd like to ask is if this mandatory "signaling" of OTP use would
be enough to resolve the concerns raised about the layering on top of
the TLS-PSK ciphersuites?

The strength of OTPs as a basis for TLS session keys
----------------------------------------------------
There was a discussion about this in Montreal and I just want to
clarify:

A typical OTP is 6 - 8 decimal digits long, although alphanumerical OTPs 
are also in use. In addition, some OTP systems employ centralized PINs, 
meaning that the user provides a PIN in conjunction with the OTP. 
Typically this would therefore give in the order of 33 - 40 bits of 
entropy.  Through hardening, one can increase the resistance. For example, 
hardening by iterative hashes, as suggested in the current draft, could 
complicate an attack as follows: With 100,000 iterations, the work load of 
the attacker will be about 17 bits more, in effect adding about 17 bits of 
strength (admittedly at a cost for the legit parties). For the example 
above, this would mean 50 - 57 bits of "entropy". Clearly this is less 
than even the 80-bit level offered through use of RSA 1024-bit keys, and I 
agree we could make this fact explicit (e.g. through some detailed 
examples) in the document and also add a recommendation to use the D-H-PSK 
(with normal caveats about MITM) or RSA-PSK variants in these situations. 
But I would not want to disallow the "direct" variant, for example since 
some connected OTP tokens may be able to emit considerably longer OTPs 
when in connected mode, and therefore would not need D-H (or the use of a 
PKI with RSA). (Longer OTPs in connected mode do not need to degrade the 
user experience since the user in these cases only enters the PIN, the OTP 
is programmatically retrieved. Long OTPs also eliminate or at least reduce 
the need for "hardening").

-- Magnus


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