On 12/1/15 4:02 AM, Fabrice Gautier wrote: > 1) What would be the implications of this for DTLS? (Knowing that one > difference between TLS and DTLS is the record header)
Good question. Fortunately my proposal should be fairly easy to adapt to DTLS, with one small trick. The main issue is that DTLS packets need to contain explicitly transmitted sequence numbers rather than implicit sequence numbers, because packets can be received out of the order and the receiver needs to know which sequence number (and hence which nonce) to use to try to decrypt and integrity-check. But if we encrypt the full DTLS header including sequence number, how does the receiver decrypt it without knowing the correct nonce to use to decrypt it? An apparent chicken-and-egg problem. Fortunately the solution is fairly simple: the receiver simply pre-computes and keeps in a small hash table the encrypted sequence numbers of all packets with sequence numbers between H-W and H+W, where H is the highest sequence number correctly received so far (the horizon) and W is the anti-replay window size as specified in 4.1.2.5 of RFC 4347, which typically should be 32 or 64 according to the RFC. The receiver can precompute all these encryptions because in my proposal TLS headers are encrypted with a stream cipher (or the AEAD operating as a stream cipher), so it's just a matter of producing the correct cipherstream bytes and XORing them with the uint48 sequence number. Whenever the receiver gets a datagram, it looks up the encrypted sequence number in the hash table, drops it on the floor if it's not present, and if it's present the receiver gets the decrypted sequence number from the hash table and uses that in the AEAD decryption and integrity-check. In the low-probability event of a hash-table collision (i.e., two uint48 sequence numbers encrypting to the same 48-bit ciphertext in a single 129-datagram window), the receiver can trial-decrypt with both (or all) sequence numbers in that colliding hash table entry. Or the receiver can keep it even simpler and just drop all but one colliding entry, introducing a pretty low probability of introducing occasional "false packet drops." The hash table is pretty trivial to maintain efficiently as well: e.g., whenever the horizon H moves forward by delta D, remove the first D entries from the current window and precompute another D encrypted sequence numbers (where D will most often be 1). In the simple design that doesn't bother dealing with hash table collisions (e.g., that allows each hash table entry to contain only one value), perhaps don't even bother clearing/removing old entries; just gradually overwrite them with new ones as H moves forward. > 2) In some implementations the record framing/parsing and > encryption/decryption are down at different layers. Would this proposal make > this type of implementation impossible? Not that I'm aware of, but I might need more information about the specific layering approaches you're thinking of and how "strongly enforced" that layering might be. But in the version of my proposal that operates the "normal" AEAD as a stream cipher for header encryption/decryption purposes, it doesn't seem like any change would be needed to the standard AEAD encryption/decryption interface. It should even be fine if the AEAD was implemented as a separate hardware module that takes the standard AEAD interface inputs and produces the standard AEAD outputs; as long as it supports the standard AEAD API it should be perfectly usable in the design I proposed. The one potential issue I can think of if a particular, restricted API forces the caller to commit at key-setup time to either "AEAD encryption mode" or "AEAD decryption mode", and makes it difficult or impossible to switch back and forth. In that case in my proposal as it stands the receiver TLS implementation might need to set up and maintain two hardware contexts, one for AEAD decryption (for the payloads), the other for AEAD encryption (for stream cipher header decryption), both using the symmetric key. This still doesn't seem all that problematic to me, though, and I don't even know of any particular APIs offhand that present this particular issue. Cheers Bryan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
