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

Bodo Moeller <> Tue, 11 July 2006 16:14 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1G0KsO-0001V1-ES; Tue, 11 Jul 2006 12:14:20 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1G0KsN-0001Uu-Ef for; Tue, 11 Jul 2006 12:14:19 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1G0KsM-0004Dj-2B for; Tue, 11 Jul 2006 12:14:19 -0400
Received: from [] (helo=tau.invalid) by (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G0KsJ1XAJ-0003D7; Tue, 11 Jul 2006 18:14:16 +0200
Received: by tau.invalid (Postfix, from userid 1000) id 2432719456; Tue, 11 Jul 2006 18:14:13 +0200 (CEST)
Date: Tue, 11 Jul 2006 18:14:13 +0200
From: Bodo Moeller <>
To: "Linn, John" <>
Subject: Re: [TLS] Comments on draft-linn-otp-tls-00
Message-ID: <>
References: <> <CBF06F06E674C948AD89E671645B785F0103ED3D@rsana-ex-hq2.NA.RSA.NET>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CBF06F06E674C948AD89E671645B785F0103ED3D@rsana-ex-hq2.NA.RSA.NET>
User-Agent: Mutt/1.5.9i
X-Provags-ID: login:2100a517a32aea841b51dac1f7c5a318
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: =?iso-8859-1?Q?Nystr=F6m=2C?= Magnus <>,
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Wed, Jul 05, 2006 at 09:51:34AM -0400, Linn, John wrote:

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

Consider client authentication using just plain old X.509
certificates.  When the server does not accept the client's
certificate chain, there generally are two possible ways to handle

1. Send a fatal alert.

2. Continue with the TLS connection, but don't consider the client
   authenticated.  Depending on the application that is running over
   TLS, the error can be described on a higher level (i.e., as part of
   a higher-level protocol error message, or simply as text in a way
   that suits the application).

Shouldn't this work for one-time passwords as well to convey detailed
error information?

For the case that an alert is sent, you might consider overloading
some existing alerts.  Some new alerts may be warranted, such as
"unsupported_otp_algorithm"; but how about, for example, using
"certificate_expired" where your draft has "otp_key_expired"?
(Then in the case that a client uses *both* a certificate and a
one-time password, the alert loses some information since the client
may not be able to tell if it refers to the certificate or the
password.  But then, "certificate_expired" doesn't give all the
details anyway -- it could refer to any certificate in the client's
certification chain.  For a more complete error report with details
and explanations, you often can use option #2 with application-level
error reporting.)

TLS mailing list