On Fri, 5 Jun 2020, Scott Fluhrer (sfluhrer) wrote:
The draft “Mixing Preshared Keys in IKEv2 for Post-quantum Security” was winding through the AUTH48 process, when at the last minute, I received an email from a researcher who thought they found a problem with low entropy PPKs (the preshared keys that the draft uses). While it turned out that what the found really wasn’t a problem, such low entropy PPKs are a problem in general.
We had this discussion in the WG.
An attacker who impersonates the server is able to validate guesses to the PPK. Because of this, low entropy PPK values MUST NOT be used.
My problem with the text is that the setion is about how the users are using the software/protocol. So a MUST NOT reads kind of weird, because users don't read RFCs. Implementors are the ones who can follow a MUST NOT, but the text makes no requirement of implementors. I've been here before with PSKs. I had added some code in our implementation to do some simple strength check on entropy and reject weak PSKs. But there was a discussion on how far one should go and of course examples of easy stupid tricks to defeat simplistic entropy checks. In the end, it got removed again. I would be happy for the draft to recommend something like a minimum length of 32 bytes. I can implement that. We know some people will use 32 A's or 0's, but where would you draw the line. Alternatively, the text could suggest some kind of exponential backoff scheme based on wrong PPK values that would dramatically slow down the efforts of an attacker. Again, that would be something we can implement. I am fine with the first sentence being included. The second one could read something like "Because of this, low entropy PPK values MAY be rejected and implementations MAY warn about their use". This then leaves it up to implementors as to whether they will add some entropy checking code or not. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
