I will start by re-iterating my initial position that I would prefer that the DTLS and TLS analysis is going to be the same in terms of masking the header information. So I decided to do some thought experiments about what happens if the length were to be encrypted and how many different situations does this not appear to help the situation.
DTLS - Given that most DTLS situations are going to want to keep the block of data sent small, there is no to little incentive to send multiple DTLS blocks in a single UDP packet. This means that the length of the encrypted data is going to be easily found based on the length of the UDP packet. One can probably make some significantly accurate guesses about what the header fields are going to be for a DTLS packet, but I would assume that even if the key could be determined it would not compromise the keys used in protecting the D/TLS content itself. TLS w/ lock step protocol - Think about using TLS with a lock step protocol such as exists for POP where you always have a situation where the client sends a request and the server sends a response. Even with the length field encrypted a traffic analysis is going to be able to determine the length of all of many of the messages based on the amount of data that is flowing from each of the end-points. Thus with POP I can make a good guess about the length your password just by looking at the traffic being sent in terms of raw byte counts even without the length being directly available. TLS w/ time breaks between operations - Think about doing browsing on a web site. I read a page, which takes time, and then I click a link. Looking just at the traffic flow I can make a really good guess about the length of the link that you just sent to the server based on the number of bytes that are sent from the client to the server before the server starts chattering. Any protocol where there are going to be times where there is silence followed by a request and then responses is going to all for a relatively easy guess about the length of the request based just on the number of bytes in the stream. These are all situations where if one say - My attack model is that exposing the length of the encrypted data allows the attacker to obtain significant information about what I am sending - then the simple expedient of encrypting the header information is clearly insufficient to deal with the attack proposed. Additional steps need to be taken as well. For example sending all of the randomly updating adware back on the same TLS channel to prevent time breaks from occurring. (What a horrid idea of using adware as a method of preventing attacks.) I believe that this is the type of analysis that Peter is looking for in terms of what is the attack you are trying to prevent, what does the proposed remedy actually do what you think it does. The situations above would all appear to be better dealt with padding of the plain text in some manner rather than encrypting the length field. Jim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
