Re: [TLS] Issue 16: Alert clarifications

[Bodo Moeller <bmoeller at acm.org>]

On Tue, Jun 12, 2007 at 04:53:41PM +0200, Martin Rex wrote:

>> Again, this is not what I *want* the specification to say or how I would
>> like implementations to behave -- I just want the specification to say
>> *more explicitly* that a party that receives a warning (other than
>> close_notify) and decides to terminate the connection needs to send a
>> fatal alert.

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


>> Maybe that's already what RFC 2246 secretly wanted us to do, but if
>> so, it is not revealing much about this.  For example, you have to be
>> creative about determining the appropriate error alert for this fatal
>> alert:      [...]
>>                           so handshake_failure possibly is the best
>> choice, but this use doesn't quite match its description in the RFC
>> (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.)

Bodo


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