Yoav Nir wrote: > >> On 3 Nov 2016, at 20:20, Martin Rex <[email protected]> wrote: >> >>> With visible content type, you can tell these two flows apart. >> >> (a) so what? for those interested, one can tell such flows appart >> pretty reliably by traffic analysis. So there is exactly ZERO >> protection against bad guys, while breaking the good guys. > > There is if you pad the records to the size of application records.
There is no such padding by default. And the TLS handshake is half-duplex, and for any interested third party, who performs the handshake with the server himself for comparison, the PDUs are still pretty much predictable heuristically (by their ordering), even when they're padded. So besides being completely pointless, can you describe any realistic problem that is worth breaking middleware at the endpoints so badly? > > > (b) but TLSv1.2 remains unchanged, and this flow does not seem to > > exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3. > > Re-negoatiation doesn?t, but post-handshake client authentication does: > https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 > <https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2> > > > -- so why would we need a backwards-incompatible change in a > > protocol that protects something that no longer exists, > > but which severely breaks existing middleware, making it > > impossible to drop-in replace a TLSv1.2 implementation with > > a TLSv1.3 implementation that has this backwards-incompatibility. > > Can you elaborate on that middleware? As previously mentioned, it is middleware that facilitates using a TLS-protected communication channel for application callers. It offers several different kinds of reading strategies to the caller, which the caller is free to choose from. One reading mode is "streaming", where as many app-data TLS records are read (non-blocking) and decrypted, as fit into the application-supplied buffer. This facilitates communication with servers that fragment app data into pathologically small pieces (e.g. Google). Non-Appdata records (such as a final Close-Notify or a renegotiation request) are left in the network buffers, and will only be fully read&processed after all AppData preceding it have been properly returned to the application. In a similar fashion, the reverse proxy part (often in the DMZ), can check whether a browser prematurely aborts a communication and closes the network connection, by checking for readable events on the network socket and peeking whether it is a hard connection closure (TCP RESET, such as MSIE), or a CloseNotify Alert (Firefox,Chrome), without reading&decoding any application data. For large-scale Servers, non-blocking network operations are much more efficient than blocking network operations, the general wait point of the application is a select/poll call which waits on sockets, and it is up to the application to decide whether to "select for read" when it is ready to receive application data on a communication channel. With appdata records clearly distinguishable at the outer TLS record layer, the event-based architecture of the application did not need any changes when switching from cleartext communication to TLS-encrypted communication, all app-data socket-readable events remained visible with SSLv3->TLSv1.2, because TLS appdata records can be clearly distinguished from Handshake, CCS and Alert. -Martin _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
