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

[<Pasi.Eronen@xxxxxxxxx>]

Magnus Nyström wrote:
> 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?

It would solve the "coexistence with ordinary TLS-PSK" concern, but the
motivation of this layering still puzzles me... it would make sense
if defining a new ciphersuite was extremely hard and unpleasant thing 
that should be done only if no other option is possible... but to
me, it looks like a new ciphersuite would be both easier, simpler,
and architecturally "nicer" way to do OTP with TLS. 

And it's actually easier get numbers for ciphersuites than 
TLS extensions :-)

Best regards,
Pasi

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