[openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Karthikeyan Bhargavan via RT]

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150930/a7ce5e42/attachment-0001.sig>