[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] permitted client behaviour when rejecting renegotiation
From:       Nikos Mavrogiannopoulos <nmav () gnutls ! org>
Date:       2010-01-21 7:52:30
Message-ID: 4B5807BE.6010206 () gnutls ! org
[Download RAW message or body]

Martin Rex wrote:

> I should clarify this:  Prohibiting app data exchange _during_ a
> renegotiation handshake is something that I advocated for myself
> (and would likely implement myself if I would implement TLS), see

Ah ok I got the point. Applications that use gnutls can in the time
frame between renegotiation request and handshake start to check and
read pending application data. However this is not done implicitly by
the handshake procedure, that will error if it encounters application data.

> http://www.ietf.org/mail-archive/web/tls/current/msg04091.html
> 
> But given the full-duplex nature of the TLS exchanges before
> and after renegotiation, I would cut the "renegotiation handshake"
> differently, and _not_ consider a HelloRequest message to be part
> of that handshake.  Because of the full-duplex nature, the handshake
> is not guaranteed to be started synchronously on both directions
> of the communication.  The TLS handshake itself is half-duplex
> by nature (which might be the reason why the SSL spec defined the
> interleaving of renegotiation handshake and application data
> in the first place).

Indeed, but there is always the issue of how many record packets to
accept before starting the handshake. Is the client allowed to start the
handshake 2 minutes later or after 2mb of transferred data? Currently I
left this to the application developer.

regards,
Nikos

[prev in list] [next in list] [prev in thread] [next in thread]