Re: [TLS] Issue 16: Alert clarifications

[Bodo Moeller <bmoeller at acm.org>]

On Mon, Jun 11, 2007 at 10:41:17PM +0200, Martin Rex wrote:
> Bodo Moeller wrote:

>>> I don't undestand what should be new to this.

>> I used to think so too.  However, RFC 2246 and RFC 4346 both explicity
>> say that
>> 
>>                  if an alert with a level of warning is received, the
>>    receiving party MAY decide at its discretion whether to treat this as
>>    a fatal error or not.
>
> I don't see how this changes anything.  A Server that receives a
> no_certificate alert instead of a requested client SSL cert may
> treat this as a fatal error as well.  But that's a determination
> made by the server, and such a determination is *NOT* covered
> by the peer's alert message (the peer should be waiting for
> continuation of the communication/handshake).

I'm not sure what your point is here: We had suggestions to add some
"SHOULD NOT tear down the connection for warning alerts" rule to the
specification, or even "MUST NOT tear down"; you said you didn't
understand what should be new to this; and in response I pointed to
the above language that isn't consistent with "SHOULD NOT tear down"
or "MUST NOT tear down": that's why "SHOULD NOT tear down" or "MUST
NOT tear down" would be new.


>> Sometimes this actually *does* make a bit of sense, e.g. when
>> receiving a certificate-related alert when you know you have to be
>> authenticated for whatever you intend to do with the TLS connection;
>> or if you want to insist on renegotiation.  It would make much more
>> sense, though, if the party that intends to close the connection in
>> response to a warning alert is required to send a fatal alert first.

> This is how I understood the idea behind the seperate warning
> and fatal alerts.

>> Then the warning alert itself does not close the connection, and we
>> have an explicit fatal alert that indicates to the other party that
>> the connection will be closed.

> There is one particular warning alert that terminates the currently active
> SSL session (and usually, but not necessarily the connection):
> the SSL close notify alert.

True.  The above language ("if an alert with a level of warning is
received ...") is from the "Error Alerts" subsection of the "Alert
Protocol" subsection, which covers any alerts besides the close_notify
alert, so that's actually what the proposal is meant for.


>> This is what my proposal would achieve:
>> 
>>    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.
>> 
>> Nelson has suggested spelling out that fatal alerts should be required
>> for all fatal errors, which makes sense too.  That is, anytime a
>> party closes the connection because of whatever error, it should send
>> a fatal alert unless it has already sent or received one, or unless
>> it is impossible to send anything.


> The description of Error (alerts) in SSLv3 (Nov.96) says this:
> 
>   5.4.2 Error alerts
> 
>      Error handling in the SSL Handshake protocol is very simple.  When
>      an error is detected, the detecting party sends a message to the
>      other party.  Upon transmission or receipt of an fatal alert
>      message, both parties immediately close the connection.  Servers
>      and clients are required to forget any session-identifiers, keys,
>      and secrets associated with a failed connection.  The following
>      error alerts are defined:
> 
> A no_certificate alert sent by an SSL/TLS client is not an error,
> it is a protocol option requested by the server and rejected by the
> client.  If the server considers this an error "the detecting party
> sends a message to the other party."  If that message is a fatal
> alert, the communication ends.  If the peer simply closes the
> communication channel without sending the required (alert) message
> it is defective.

Here you are mixing levels: the no_certicate alert *is* defined in
the "Error Alerts" section, so technically this *is* an "error" --
at least in the sense of "error" that the sentence that you quote
is assuming.



Actually it seems that our ideas on how the protocol should behave
with regards to alerts agree mostly (or even completely).  The main
problem apparently is that there are many things that the
specification doesn't spell out clearly -- they are left to common
sense, and occasionally there are different ways to interpret the few
details that the specification does spell out that yet, when applying
common sense, can lead to the same result.

Bodo


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