Re: [TLS] Issue 16: Alert clarifications
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Issue 16: Alert clarifications



On Sun, Jun 10, 2007 at 07:52:31PM -0700, Nelson B Bolyard wrote:

>> How about the following?
>> 
>>    If an alert with a level of warning is sent and received, generally
>>    the connection can continue normally.  If the receiving party
>>    decides not to proceed with the connection (e.g., after having
>>    received a no_renegotiation alert that it is not willing to
>>    accept), it MUST send a fatal alert to terminate the connection.

> I don't object to that, except that it changes TLS so that SOME fatal
> errors MUST be accompanied with a Fatal Alert (as opposed to being
> torn down silently), but others are not required to do so.  This begs
> the question: why should some fatal errors require a fatal alert,
> but not others?
> 
> In a previous message in this thread, I asked/proposed:
> 
>> Why not require that a fatal alert be sent any time that the connection
>> is going to be torn down due to a protocol error of any kind?

Yes, this makes sense -- anytime a party has to abort the connection
because of some protocol error, it should send a fatal alert if
possible.

Bodo


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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.