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

[David-Sarah Hopwood <david-sarah at jacaranda.org>]

Michael D'Errico wrote:
>> 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.
[...]
> 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.

Yes, you're right. I was confused.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

Attachment: signature.asc
Description: OpenPGP digital signature