On 2/2/19 9:09 PM, Gary E. Miller via devel wrote: >> In the context of >> attacks on C2S/S2C, if the client willingly shares C2S/S2C in >> plaintext with someone else (other than the server), the client has >> already compromised C2S/S2C by its own actions. There is nothing in >> the protocol which does this. > > Yup. The protocol allows this class of attack.
Sure, a client could take the keys (C2S/S2C) it has in plaintext and give them (C2S/S2C) away, and then its keys (C2S/S2C) are compromised. It is impossible for any protocol to prevent the client from separately choosing to give away its keys. If Firefox opens a socket to nsa.gov and gives them your TLS session keys, that's not a flaw in TLS! Likewise, a client giving away its own keys out of band is not a flaw in NTS. >> The limit is on how many messages should be encrypted by a single key. > > Yup. Except there is NO limit. The "limit" is how many messages per key is considered safe for a specified algorithm by crypto experts. That is the "limit" we are trying to stay under by verifying our assumptions and/or setting time-based or count-based key rollover configuration options. For AES-GCM, we were told that limit is 2^32. For AES-SIV (-CMAC), we were told that is 2^48. You can verify that 2^48 in RFC 5297, page 15. >> For C2S/S2C, the limit is applicable to a normally functioning client >> (and server). > > I'm not talking about normal. I'm talking about enemy action. > >> Even with the worst case assumptions of AES-GCM and minpoll 4, that >> limit is 2,176 years. C2S/S2C are re-keyed at least on client >> restart. I believe 2,176 years is "very conservative[]" relative to >> client ntpd restarts. Do you disagree? > > If I agree to your assumptions, then I agree to your conclusion. > > Except, I do not agree with your assumptions. Nothing enforces > minpoll 4. Nothing prevents cookie sharing. Cookies are a client's C2S/S2C (and some other data) encrypted to key K. Because they are encrypted, they are only readable by the server which has key K. So sharing them in encrypted form (cookie form) does not by itself give away C2S/S2C or K. The client does have the important part of the cookie, the keys inside the cookie (C2S/S2C). If it gives away its own keys, well, I covered that above. You said, "I'm not talking about normal. I'm talking about enemy action." So the client is trying to attack something. It's not attacking itself to get its own C2S/S2C, because it has its own C2S/S2C in plaintext already. The security of _another_ client's C2S/S2C, if the attacker can eavesdrop on its client-server NTP communications to get the cookie (which is the encrypted form of C2S/S2C), is protected by those cookies being encrypted to key K. There are two ways to attack the other client's C2S/S2C: 1) Attacking C2S/S2C here refers to disclosure of the other client's C2S/S2C by way of the other, normal, victim client encrypting too many NTP communications (to the server) to C2S, or the server encrypting too many NTP communications (to that client) to S2C. The number of communications that the other, normal, victim client sends to the server and the server sends to the other, normal, victim client is bounded by normal behavior. We're not going to be anywhere near even the AES-GCM limit. So Daniel's/Hal's/my point is that we do not need expiration for C2S/S2C, because it will naturally stop being used due to client ntpd restarts many orders of magnitude sooner than is a risk for the underlying encryption. So the "enemy action" scenario is the second one: 2) Attacking K here refers to disclosure of K by way of the server encrypting too many cookies to K. So the malicious client is trying, possibly with coordinating machines, to attack K because once it has K, it can decrypt other client's cookies to get those other client's C2S/S2C. Once it has those other client's C2S/S2C, it can do bad things. The easiest example is that it can then impersonate the server and give the client bad time, which the client believes is correct. >> However, as above, maybe we want some crypto >> diversity, just in case a future problem is found with AES-SIV. > > Or, because the Proposed RFC insists on it. For the cookie encryption, it does not require any particular algorithm nor a choice of algorithms. The cookie format, which is what is encrypted to key K with some algorithm, is entirely implementation defined. If you disagree, please cite the appropriate section. >> So >> maybe we do allow AES-GCM too, and thus need to consider that case, >> so we're at 2^32 messages. > > Or less, a lot less. Remember BEAST? How much safety factor is built into that 2^32 recommendation? If it already has "enough" safety factor, then no, it's not "a lot less". If the safety factor is not already "enough", then yes, we need to reduce it. What constitutes "enough" is obviously debatable, but we agree that we should be conservative in that. In the attacking C2S/S2C scenario, the current worst case (ntpcipher of AES-GCM + a client doing maxpoll 4) is 2,137 years between ntpd client restarts, which has plenty of safety factor for me. My servers get reboots every month or two for some security patch or another. If I went a whole year, then I might be considered reckless on that basis alone. And yearly reboots is a 2^11 safety factor compared to 2,137 years (AES-GCM + maxpoll 4) or a 2^27 safety factor on AES-SIV + maxpoll 4, or a 2^33 safety factor on the default case of AES-SIV + maxpoll 10. And that assumes the initial 2^32 for AES-GCM and 2^48 for AES-SIV have zero safety factor already. In the attacking K scenario, the worst case (cookiecipher of AES-GCM + NIST levels of server traffic) _is_ a problem. Note that the ciphers are different. The C2S/S2C attack scenario is about the negotiated AEAD cipher, of which the server is only required to support AES-SIV, but it may wish to support others for crypto diversity. The K scenario is about the cipher used for cookies, which is entirely up to the server and thus can be changed more easily (because it does not involve coordination with an installed base of clients). Note that the message counts are different. The C2S/S2C attack scenario is about how many legitimate messages are generated for a single C2S/S2C, which is maxpoll 4. This attack is against an unknown C2S/S2C (because if it's known, it's not an attack), so it is for another client's C2S/S2C. You can publicly share your cookies and your C2S/S2C keys and it won't make a different in attacking someone else's C2S/S2C. The K attack scenario is about how cookies are generated by the server per K, including when it is under attack by multiple coordinating clients requesting cookies. >> If we assume the recommended rotation of daily, > > Wrong again. It is not a rotation, it is a ratchet! As I stated, I'm assuming we, the implementation, choose random generation of K instead of choosing to do ratcheting. I said we'd address ratcheting separately. >> So I conclude that using AES-GCM to protect K is a real problem at >> NIST scale, even if they don't share K across servers, with a daily >> rotation schedule (assuming a world where everyone implemented NTS). > > Well, good. Now extrapolate to other ciphers. I did give both: "If we assume the recommended rotation of daily, keeping one old K, 2^32/2/24/60/60 = 24,855 requests/sec per K with AES-GCM. In comparison, 1628906115 request/sec per K with AES-SIV." This is a difference of 2^16, because AES-SIV's 2^48 - AES-GCM's 2^32 = 2^16. >> Rotating more frequently is one possible solution. However, they >> almost certainly need to keep a client's cookie valid for at least >> 1024 seconds (17 hours), as that is a common polling window. So K >> needs to be valid at least that long (i.e. rotate K every 9 hours >> keeping one old K). Trying to support a maxpoll of 17 (36.4 hours) is >> really pushing the boundaries of an AES-GCM protected K at NIST load, >> even if K is per server, unless they deploy more servers (to get more >> Ks) than they used in 2016. > > Or, just expire the C2S/S2S a bit more frequently. Again, this is about protecting K from disclosure due to encrypting too many plaintexts with the same K. Changing what those plaintexts are (rotating C2S/S2C) does not affect in any way how many plaintexts are encrypted to a given K, and thus rotating C2S/S2C doesn't help at all in the attacks against K. > Until AES-SIV is broken. Alternative solution, as James proposed, like > all other good crypto programs I know: just expire the C2s/S2C after some > reasonable time. I believe the weakest AEAD algorithm being considered is AES-GCM. With maxpoll 4, the client need only re-key every 2,137 years. The point is that "some reasonable time" for expiration is 2,137 or 9 million years depending on algorithm, the lower of which is still much longer than the client ntpd is ever going to run. >> If each K is randomly generated (let's address ratcheting separately), > > Once again, flawed assumption. Please reread section 6. NOT randomly > generated. I'm saying we, the implementation, can make the decision to only randomly generate K. >> do you agree that the window for attack is however long K is valid, >> which by the recommendation is two days? > > Yeah, if assume what we are not going to do, then it works. Okay, good, so we agree things are okay if we decide to randomly generate K instead of ratchet it. > My preference. Except it opens up a new can of worms. How does the > NTPD server tell the NTS-KE what the new K is? If the NTS-KE and NTP daemons are the same process, that's obviously easy: a global variable. If the daemons are separate processes, either shared memory, a local socket, or a local file. If the daemons are on separate hosts... a network socket, protected by TLS, with an implementation-defined protocol. I'm not actually sure it is necessary to support these being on separate hosts, but if it is, that's how you do it. Either ntpked or ntpd can be responsible for generating K. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
