> > Hi Paul, > > > > 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. > > If you read it that way, then I strongly recommend we put implementeren > advise there. The last thing we want > is implemented deciding differently on the minimum entropy enforced. Because > if I say 32 bytes length and > you say 16, interop with me breaks until I lower to 16, and a few years down > the line we all set the minimum > length at 1 for interoperability. > > If it’s advise to the user, we can hand wave. If it is requirement for the > implementer, we need very specific > directions.
I'd rather to avoid using concrete numbers here - they depend on a situation and tend to change over time. I think that our message to implementers is: don't use this extension with secrets that are easily guessable (PINs, passwords, SMS-codes etc.), because malicious server can guess them. It doesn't mean that we limit the minimal size of the key to some pre-hardcoded value (although we have already advised a couple of sentences above that 256 bit keys SHOULD be used). It only means that implementers must not use this extension if their implementations generate PPKs by, say, deriving them from passwords. Anyway, can you come up with a text that that you'll be fine with and that will address this concern? Regards, Valery. > Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
