Re: [TLS] Issue 16: Alert clarifications

[Martin Rex <Martin.Rex at sap.com>]

Bodo Moeller wrote:
> 
> On Tue, Jun 12, 2007 at 04:53:41PM +0200, Martin Rex wrote:
> 
> > I would also appreciate if the spec was more explicit about this,
> > and in particular I do *NOT* want this to be considered a change
> > to the existing spec that is new and valid only for TLSv1.2.
> 
> Not a change just for TLS 1.2, but a clarification for something that
> previously was under-specified.

OK!

 
> 
> >> (according to the spec, it is about unacceptable "security
> >> parameters", and that's a pretty specific term in the TLS
> >> specification: see 6.1 and A.6).
> >
> > The spec calls for a fatal handshake_failure alert in most situations.
> 
> One problem is that the spec doesn't really say that you can use
> handshake_failure in such situations.  The spec can just as easily be
> interpreted as saying that you can't.  (Common sense can come in
> helpfully and say that you should use handshake_failure *despite of*
> what the current spec says.)

According to the SSL spec, a handshake failure alert is the appropriate
(server) response to a client sending a "no_certificate" warning alert
upon a Certificate Request message.


For every protocol you will need a catch-all error message that has
to be used whenever there is not specific error message available
to describe the situation (In GSS-API it is the MISC_FAILURE major_status)
In SSL, for errors during the handshake this is the handshake_failure alert.

What TLS currently doesn't provide is a means to communicate implementation
specific information about an error, which may be specific to particular
cipher-suites, specific to particular PKI operations (and not covered
by the existing certificate-related alerts), or eventually, specific
to alternative authentication protocols that people are trying to
add to TLS.  Maybe the alert protocol should be enhanced to provide
a container for such auxiliary error information before fancy new
authentication schemes are added to the TLS protocol engine.


-Martin

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