Hi Paul, > 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 read this text as a caveat for implementers to not use keys which cannot provide enough entropy in any case (e.g. passwords). With this reading it's a text for implementers, not for users. Regards, Valery. > 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
