Re: [TLS] Issue 16: Alert clarifications

[Nelson B Bolyard <nelson at bolyard.com>]

Bodo Moeller wrote:
> On Thu, Jun 07, 2007 at 08:33:11PM -0700, Nelson B Bolyard wrote:
>> Eric Rescorla wrote:
>>> <Pasi.Eronen at nokia.com> wrote:
>>>> Eric Rescorla wrote:
> 
>>>>> - Add a warning that some implementations tear down the connection
>>>>>   for any alert so warning alerts are dangerous. New implementations
>>>>>   SHOULD not tear down the connection for warning alerts.
> 
>>>> Why not simply "MUST NOT tear down"? (this requirement would apply 
>>>> only when TLS 1.2 is negotiated, so what some implementations did
>>>> with 1.0 or 1.1 doesn't matter)
> 
>>> Works for me.
> 
>> Umm. Some warning alerts exist to give the recipient a choice to tear
>> down or not.  E.g. no_renegotiation.  RFC 2246 says:
>>
>>    no_renegotiation
>>        Sent by the client in response to a hello request or by the
>>        server in response to a client hello after initial handshaking.
>>        Either of these would normally lead to renegotiation; when that
>>        is not appropriate, the recipient should respond with this alert;
>>        at that point, the original requester can decide whether to
>>        proceed with the connection. One case where this would be
>>        appropriate would be where a server has spawned a process to
>>        satisfy a request; the process might receive security parameters
>>        (key length, authentication, etc.) at startup and it might be
>>        difficult to communicate changes to these parameters after that
>>        point. This message is always a warning.
> 
> Good point.  This means that neither "SHOULD NOT" nor "MUST NOT" works
> for everything.  However, I think a party should not silently tear
> down the connection after receiving a no_renegotiation alert that it
> does not like -- instead, it should send a fatal alert first.
> 
> 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?

I still think that deserves an answer.

-- 
Nelson B

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