Re: [TLS] Issue 16: Alert clarifications

[Bodo Moeller <bmoeller at acm.org>]

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.


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