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.