Subject: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 5 Jun 2020 19:40:44 +0000

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.

To address this, I suggested to the RFC editors that we modify the first paragraph of the security considerations from:

Original text:
   Quantum computers are able to perform Grover's algorithm [GROVER];
   that effectively halves the size of a symmetric key.  Because of
   this, the user SHOULD ensure that the post-quantum preshared key used
   has at least 256 bits of entropy, in order to provide 128 bits of
   post-quantum security.  That provides security equivalent to Level 5
   as defined in the NIST PQ Project Call For Proposals [NISTPQCFP].

Modified text:
   Quantum computers are able to perform Grover's algorithm [GROVER];
   that effectively halves the size of a symmetric key.  Because of
   this, the user SHOULD ensure that the post-quantum preshared key used
   has at least 256 bits of entropy, in order to provide 128 bits of
   post-quantum security.  That provides security equivalent to Level 5
   as defined in the NIST PQ Project Call For Proposals [NISTPQCFP].
   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.

Additional text high-lighted.

Because of the lateness of this change, Ben Kaduk (the area director) asked me to check with the list to make sure everyone is OK with this addition.

Comments?

---

From: Paul Wouters <[email-masked]>
Date: Fri, 5 Jun 2020 16:44:40 -0400 (EDT)

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.

>    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

---

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 7 Jun 2020 13:24:19 +0300

Hi Paul,

> > 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.
> 

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.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Sun, 7 Jun 2020 10:48:37 -0400

> On Jun 7, 2020, at 06:24, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Paul,
> 

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.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 8 Jun 2020 12:47:00 +0300

> 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.
> 

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.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 8 Jun 2020 15:06:24 +0000

Tero had this comment (which didn't make it onto this mailing list):

Btw, there is similar text in RFC7296 (base IKEv2) saying following:

   When using pre-shared keys, a critical consideration is how to assure

   the randomness of these secrets.  The strongest practice is to ensure

   that any pre-shared key contain as much randomness as the strongest

   key being negotiated.  Deriving a shared secret from a password,

   name, or other low-entropy source is not secure.  These sources are

   subject to dictionary and social-engineering attacks, among others.

so one option would also point to IKEv2 RFC and say that same restrictions for not using low-entropy key that apply for pre-shared keys there applies also PPK.

That comment strikes me as having a good point; the pre-shared keys in IKE are subject to exactly the same dictionary attack that a PPK would have, and so the same advice would apply to both.  On the other hand, asking the reader to dig through a 142 page document for the relevant advice, or even scan through 3 pages of the security considerations would appear to be less friendly than we could be; in addition, advice for PPKs also need to consider Quantum Computers (which were not a consideration with IKE pre-shared keys).

How about this text (which integrates suggestions both from the security considerations of both RFC7296 and the PPK text, while trying to not sound like Frankentext [1].

   A critical consideration is how to assure the randomness of this
   post-quantum preshared key.  Quantum computers are able to perform
   Grover's algorithm [GROVER]; that effectively halves the size of a
   symmetric key.  In addition, an adversary, even with a conventional
   computer, can perform a dictionary search over plausible post-quantum
   preshared key values.  The strongest practice is to ensure that
   any post-quantum preshared key contains at least 256 bits of entropy,
   this will provide 128 bits of post-quantum security, while providing
   security against conventional dictionary attacks.  That provides
   security equivalent to Level 5 as defined in the NIST PQ Project Call
   For Proposals [NISTPQCFP].  Deriving a postquantum preshared key from
   a password, name, or other low-entropy source is not secure because
   of these known attacks.

The highlighted sections is text that is new to the draft; this would replace the first paragraph of the Security Considerations section.

And, I would agree with Valery; I also would prefer to avoid putting numbers that sound concrete; especially on something that is hard to measure (and "amount of entropy" is notoriously hard to measure - you can measure length, but that doesn't actually mean "guessability", which is what we're trying to get at).

[1]: For those readers who might not be familiar with English Literation or pop culture, there is a classic English novel "Frankenstein", when a scientist (Dr Frankenstein) patches together parts from several corpses, and brings it to life (of course, it didn't go well); in later references to this original novel, the stitching of the several parts is obvious.  The allusion "Frankentext" suggests parts of several works being clumsily stitched together.  It is typically good advice to avoid cultural references when talking on an international mailing list; I just couldn't help myself this time...

From: Scott Fluhrer (sfluhrer)
Sent: Friday, June 05, 2020 3:41 PM
To: [email-masked]
Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2

Original text:

Modified text:

Comments?

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 8 Jun 2020 18:59:47 +0300

Hi Scott,

I like this variant.

Regards,

Valery.

From: IPsec [mailto:[email-masked]] On Behalf Of Scott Fluhrer
(sfluhrer)
Sent: Monday, June 08, 2020 6:06 PM
To: [email-masked]
Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2

so one option would also point to IKEv2 RFC and say that same restrictions
for not using low-entropy key that apply for pre-shared keys there applies
also PPK. 

That comment strikes me as having a good point; the pre-shared keys in IKE
are subject to exactly the same dictionary attack that a PPK would have, and
so the same advice would apply to both.  On the other hand, asking the
reader to dig through a 142 page document for the relevant advice, or even
scan through 3 pages of the security considerations would appear to be less
friendly than we could be; in addition, advice for PPKs also need to
consider Quantum Computers (which were not a consideration with IKE
pre-shared keys).

How about this text (which integrates suggestions both from the security
considerations of both RFC7296 and the PPK text, while trying to not sound
like Frankentext [1].

   of these known attacks.

The highlighted sections is text that is new to the draft; this would
replace the first paragraph of the Security Considerations section.

And, I would agree with Valery; I also would prefer to avoid putting numbers
that sound concrete; especially on something that is hard to measure (and
"amount of entropy" is notoriously hard to measure - you can measure length,
but that doesn't actually mean "guessability", which is what we're trying to
get at).

[1]: For those readers who might not be familiar with English Literation or
pop culture, there is a classic English novel "Frankenstein", when a
scientist (Dr Frankenstein) patches together parts from several corpses, and
brings it to life (of course, it didn't go well); in later references to
this original novel, the stitching of the several parts is obvious.  The
allusion "Frankentext" suggests parts of several works being clumsily
stitched together.  It is typically good advice to avoid cultural references
when talking on an international mailing list; I just couldn't help myself
this time.

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.

To address this, I suggested to the RFC editors that we modify the first
paragraph of the security considerations from:

Original text:

Modified text:

Because of the lateness of this change, Ben Kaduk (the area director) asked
me to check with the list to make sure everyone is OK with this addition.

Comments?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Jun 2020 12:37:54 -0400 (EDT)

On Mon, 8 Jun 2020, Scott Fluhrer (sfluhrer) wrote:

> How about this text (which integrates suggestions both from the security considerations of both RFC7296 and the PPK text, while
> trying to not sound like Frankentext [1].

That is okay with me.

> And, I would agree with Valery; I also would prefer to avoid putting numbers that sound concrete; especially on something that is
> hard to measure (and “amount of entropy” is notoriously hard to measure – you can measure length, but that doesn’t actually mean
> “guessability”, which is what we’re trying to get at).

I agree with not putting in numbers. I am worried about rejecting
anything as an implementation though because whichever implementation
has the strongest checks will be the least compatible. So in the end,
the text you suggested to add will have to be completely ignored by
implementers :/

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 11 Jun 2020 20:05:24 +0000

Does anyone else have comments about this text (either for or against)?  Paul, Tero, you had previously chimed in; do either of you something to say?

From: IPsec <[email-masked]> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Monday, June 08, 2020 11:06 AM
To: [email-masked]
Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2

From: Scott Fluhrer (sfluhrer)
Sent: Friday, June 05, 2020 3:41 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Last minute change to draft-ietf-ipsecme-qr-ikev2

Original text:

Modified text:

Comments?

---

From: Paul Wouters <[email-masked]>
Date: Thu, 11 Jun 2020 16:34:54 -0400 (EDT)

> Does anyone else have comments about this text (either for or against)?  Paul, Tero, you had previously chimed in; do either of you something to say?

I'm fine with the change proposed.

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 15 Jun 2020 12:48:22 +0000

Last call; does anyone have any objections if I send these changes to the RFC editors as a final modification?

From: Scott Fluhrer (sfluhrer) <sfluhrer=[email-masked]>
Sent: Thursday, June 11, 2020 4:05 PM
To: Scott Fluhrer (sfluhrer) <[email-masked]>; [email-masked]
Subject: RE: Last minute change to draft-ietf-ipsecme-qr-ikev2

From: IPsec <[email-masked]<mailto:[email-masked]>> On Behalf Of Scott Fluhrer (sfluhrer)
Sent: Monday, June 08, 2020 11:06 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] Last minute change to draft-ietf-ipsecme-qr-ikev2

Original text:

Modified text:

Comments?