A simpler interpretation would be that application data should never be sent or received with sequence number = 0; only finished messages may have this sequence number. For connections with NPN enabled, we may need a slightly more complex rule.
In TLS we can also assume that encrypted fragments will not be accepted out of sequence. Perhaps DTLS violates this sequentiality? In which case, the interpretation of the CCS - Finished - AppData ordering becomes more difficult to enforce for DTLS. -K. > I'd interpret it as not talking about the client's ability to send data > but rather about latency observed by application layer. In other words > about such situation: > > <snip> > ClientKeyExchange > [ChangeCipherSpec] > Finished > Application Data[1] --------> > [ChangeCipherSpec] > <-------- Finished > Application Data[2] <-------> Application Data > > and how the data [1] will be received by other side's application later > than if it wasn't sent during a handshake > -- > Regards, > Hubert Kario > Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com <http://www.cz.redhat.com/> > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic > <signature.asc>_______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > <https://mta.openssl.org/mailman/listinfo/openssl-dev>
signature.asc
Description: PGP signature
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
