Re: [TLS] Data volume limits

[Hubert Kario <[e-mail]>]

On Monday 04 January 2016 13:02:57 Florian Weimer wrote:
> On 01/04/2016 12:59 PM, Hubert Kario wrote:
> > On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> >> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> >>> if the rekey doesn't allow the application to change
> >>> authentication
> >>> tokens (as it now stands), then rekey is much more secure than
> >>> renegotiation was in TLS <= 1.2
> >> 
> >> You still have the added complexity that during rekey, you need to
> >> temporarily switch from mere sending or receiving to at least
> >> half-duplex interaction.
> > 
> > this situation already happens in initial handshake so the
> > implementation needs to support that
> 
> But after and the handshake and without real re-key, sending and
> receiving operations exactly match what the application requests.  If
> you need to switch directions against the application's wishes, you
> end up with an API like OpenJDK's SSLEngine (or a callback variant
> which is equivalent in complexity).

for renegotiation, yes

but for rekey it doesn't need any input from application so there is no 
need for any callbacks
 
> Dealing with this during the initial handshake is fine.  But
> supporting direction-switching after that is *really* difficult.

yes, this is a bit more problematic, especially for one-sided transfers. 
For example, when one side is just sending a multi-gigabyte transfer as 
a reply to a single command - there may be megabytes transferred before 
the other side reads our request for rekey and then our "CCS" message

I thought you just meant the need to keep two cipher contexts in memory 
at the same time (current and currently negotiated).
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic