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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
