Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt

[Michael D'Errico <mike-list at pobox.com>]

> Another issue is that a server that supports the extension can refuse
> the renegotiation. The current draft is not clear about what the client
> and server behaviour should be in that case.
>
> Suggestion:
>
> If a ClientHello that is requesting to resume a previous session
> contains a Renegotiation_Info extension, and the server supports the
> extension but wishes to refuse the renegotiation, it SHOULD reply
> with a zero-length Renegotiation_Info.

The server already has to reply with an empty Renegotiation_Info
extension.  That is what happens on an initial handshake even when
resuming a previous session, and also for a session_ticket resume.

The draft has only a single sentence discussing session resumption:

   The above rules apply even when TLS resumption is used.

Maybe it needs to elaborate more.

> If a client that is requesting to resume a session receives a
> zero-length Renegotiation_Info without a no_renegotiation alert, it
> MUST abort the handshake. If it receives both a zero-length
> Renegotiation_Info and a no_renegotiation alert, then the fact that
> the Renegotiation_Info contents do not match the previous session's
> verify_data values should not be considered a reason for the client
> to abort.

No, session resumption is no different w.r.t. the Renegotiation_Info
extension than a full handshake.  The info is always empty on the
first handshake for a connection, even when resuming a previous session.

As a result, you do not need to store the verify_data from the finished
messages in your session cache.

> Note that one legitimate reason for refusing a renegotiation is that
> the old session has expired, in which case the server is likely to have
> forgotten the client and server verify_data values for that session.
> Nevertheless it SHOULD reply with a Renegotiation_Info to indicate
> that it supports the extension.

The server never needs to remember the verify_data from a previous
session unless it is the currently active session.  When storing a
session in your session cache, the verify_data can be discarded since
it is not needed in the future.  If that session gets resumed later,
the Renegotiation_Info will be empty.

Mike


> For the same reason, when the server refuses a renegotiation it may
> not have the ability to check that the contents of the client's
> Renegotiation_Info were correct. Therefore, there should be no
> requirement for the server to check the contents in that case.