Hi Peter, On 11/28/15 12:15 PM, Peter Gutmann wrote: > Bryan A Ford <brynosau...@gmail.com> writes: > SSL/TLS have used unencrypted lengths for twenty years without there being any > (known) attack or weakness based on this.
Leaving all headers in the clear (and in particular record lengths) is a huge side-channel, and historical experience is that attackers are getting better and better at exploiting side-channels in surprising ways. The CRIME attack, for example, applied to a close relative of TLS (namely SPDY), and exploited the attacker's ability to learn precise information about (compressed in this case) record lengths. I'm not saying that hiding TLS/SPDY record lengths in particular would necessarily address the CRIME attack (there were many factors involved and a combination of weaknesses), but it is certainly an attack in which the attacker's ability to see fine-grained length information was a factor. The general lesson is simply that lengths do represent sometimes-exploitable side-channels. > OTOH SSH has used encrypted lengths > for nearly the same period, and there have been several attacks/weaknesses > based on that. Security-wise, it has the opposite effect of the one intended, > it makes the protocol weaker, not stronger. You're conflating the goal (hiding TLS headers) with one particular old, broken approach to achieving that goal (namely SSH's). I am not proposing to hide TLS headers in the same way SSH did, and just because one historical approach to hiding headers was broken doesn't mean that the goal itself is a bad idea, or that all possible ways to achieve that goal are broken, or that my proposal in particular is broken. Feel free to attack my proposal but then please attack *my* proposal, not the old broken SSH approach. I already addressed one specific weakness the SSH approach had and explained why that's not an issue in my proposal. You allude to "several attacks/weaknesses" SSH had: if there were several, can you summarize or point me to information about the others? And can you say whether and in what way any of those past weaknesses in SSH might conceivably apply to my proposed approach? I claim you won't be able to (but would be happy to be shown wrong), because there appears to be a rather trivial "security proof" that my proposed hiding approach can't possibly create any new security weaknesses that weren't already in TLS 1.3 as currently specified. I already outlined that reasoning in my proposal but will expand on it a bit more below. > My real issue with it though is that, as you've pointed out, it makes it > impossible to create an efficient streaming implementation. With TLS you read > the length at the start, stream the rest into the target memory location, and > decrypt in place. With SSH you have to read a single block, decrypt it, make > sure you're not providing an oracle for the attacker, copy what's left around, > read more encrypted data onto the end, decrypt the remainder, ugh. How exactly does my proposal make it "impossible to create an efficient streaming implementation"? Again, it sounds like you're attacking SSH's broken approach while ignoring my proposal itself. With my proposal you can still perform exactly the same optimization just as before: 1. Read the 5-byte TLS header at the start, and decrypt it by XORing with the output of the stream cipher as my proposal specifies, so you now have the length. 2. Stream the rest into the target memory location, and AEAD-decrypt in place. I don't see how my proposal in any way makes life more difficult for such streaming optimizations, because my proposal keeps encryption/decryption of TLS headers separate from encryption/decryption of the body. What *might* make this optimization a bit more difficult is the MAC that the AEAD wants to attach to each ciphertext, but if that's a problem it's caused by TLS's use of AEAD and has nothing to do with my proposal. (That problem can in principle be worked around if the AEAD cipher implementation has a simple "scatter/gather" capability so it can put the MAC elsewhere, but that's a completely separate and orthogonal topic.) Now, returning to your concern about TLS header hiding creating security weaknesses: my claim is that all that my proposal introduces is a change of encoding of the 5-byte TLS header, which cannot possibly introduce any new security weaknesses because it is not affecting in any way the actual information content transmitted or received in the protocol or the way it is processed outside of that header encoding change. Consider this example: Suppose we decided we wanted the 2-byte length field in the TLS header to be transmitted in little-endian rather than big-endian. A useless change, yes, but could it create a new security vulnerability that TLS 1.3 doesn't already have as specified? Obviously not; this would yield a perfectly (and provably) equivalent protocol. Similarly, what if we decided for whatever reason it would be nice to XOR the 5-byte length field with the constant five-byte sequence [0x55,0x55,0x55,0x55,0x55]? Could that create a new security vulnerability? Again, obviously not. What if we decided that the TLS headers of odd-numbered records should be XORed with [0x55,0x55,0x55,0x55,0x55], and the even-numbered records should be XORed with [0xaa,0xaa,0xaa,0xaa,0xaa]. Could that create a new security vulnerability? No, it's still just an encoding change - just one that happens to depend dynamically on record number. What if we decided that the TLS headers should be XORed with an MD5 hash of the record number? Again, useless from a security perspective, but not harmful either: it's still just changing the TLS header encoding without changing anything else about how the protocol works - and in particular doesn't change anything about how the record is AEAD-protected or how the protocol behaves if an attacker flips any bits. What if we decided that the TLS headers should be XORed with an HMAC-SHA256 of the record number, keyed with a shared secret used only for TLS header hiding? This is now (finally) potentially useful from a security perspective, and is basically isomorphic to my proposal - but even if the attacker could break HMAC-SHA256 tomorrow or could learn the shared secret used for TLS header protection, we would just be back to the same security level as TLS's current cleartext-header design achieves; we would still not be introducing any new security weaknesses that TLS 1.3 doesn't already have. Again, if you believe my reasoning is in any way flawed here, please point out how you think my proposal (*not* the old SSH approach) could conceivably introduce any new security weaknesses that TLS 1.3 doesn't already have. Thanks Bryan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
