Subject: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt

From: "Aschauer, Hans" <[email-masked]>
Date: Fri, 11 Dec 2020 16:13:11 +0000

> Hendrik and Jonathan,
>
> Have you had a chance to review the new draft, and do you believe your
> concerns have been adequately addressed?
>
> -Tim

Hello,

After discussing the topics internally with Hendrik, there are some concerns left:

1. Iteration count:

 NEW:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      least 10,000 [NISTSP800-63B].  There is a trade off between
      protection of the password from attacks and the time spent by the
      server processing the iterations.

Please note that the cited NIST publication does *not* say that iteration count must be at least 10,000. Actually, it states:

    Therefore, the iteration count SHOULD be as large as
    Verification server performance will allow, typically at least 10,000 iterations.

The difference is subtle, but important. 10,000 merely is an estimate on what typical servers will be able to process. However, the important part is "SHOULD be as large as [...] performance will allow". This is due to the fact that even much higher iteration counts will not prevent an attacker from breaking a low-entropy password in an offline attack. NIST also knows this, and for this reason they continue:

    In addition, verifiers SHOULD perform an additional iteration of a key
    derivation function using a salt value that is secret and known only to
    the verifier.

However, the secret salt is not an option in the use case discussed here (it can only be used for storing password verifiers, not for password based key generation).

So IMHO it is not ok to cite the NIST SP in order to recommend 10,000 iterations as an acceptable minimum.

[[[
Let me just explain why this iteration count of 10,000 should be considered insecure.

Assume that the password has an entropy of 35 bits (*), and you use an iteration count of 10,000. Further assume that the attacker has an ASIC based hash machine, similar to one used for Bitcoin mining, with a hash rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially available for USD 3000).

The time it takes to break the password is then

    t_pwd = 2^35 * 10,000 hashes / 14e12 hashes per second = 25 seconds

I would assume that this is a realistic threat, even for online attacks.

On the other hand, a typical server CPU can calculate about 10-100 M hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a password verification time of one second, this allows for an iteration count of 10,000,000 to 100,000,000. This is the number you should choose according to the NIST recommendation. Note that this choice will make online attacks difficult.

(*) The entropy of a typical password (chosen by a human) is difficult to assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5 bits as _mean_ entropy, but also newer research [2] which shows that 50% of real-world passwords can be broken with less than 150,000,000 trials, indicating a much lower _median_ entropy (27 bits).

[1] Florencio, Dinei; Herley, Cormac (May 8, 2007). http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the International World Wide Web Conference Committee

[2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
]]]

2. One-time passwords

NEW:
     The password used
      to compute this MAC SHOULD NOT be used for any other purpose.

Please note that while a password should in general be used for only a single purpose, due to the weakness of the password based MAC, in the use case under consideration it should really be used only *once*. This is the only way to thwart offline attacks.

I would suggest to use the formulation: "The password used to compute this MAC SHOULD be used only once."

3. Security Considerations:

I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups", International Conference on Advances in Business Management and Information Technology Istanbul, Turkey (2019).

Best regards,
Hans

Mit freundlichen Grüßen
Dr. Hans Aschauer

Siemens AG
Corporate Technology
Research in Digitalization and Automation
Security for Embedded Systems
CT RDA CST SES-DE
Otto-Hahn-Ring 6
81739 München, Deutschland
Tel.: +49 89 636-633706
Fax: +49 89 636-48000
mailto:[email-masked]

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 14 Dec 2020 08:26:38 +0100

Good notes on the affect of iterations.

Would it not make more sense to instead of focusing on iterations per
se, specify a minimum entropy required for the password? Does that not
have greater effect on security than the iteration count.

We do performance measurements for CMP and the iteration count have huge
performance impact. In real world projects we nowadays sometimes have
requirements for 100 tps certificate issuance (sometimes even more). And
what's more important latency requirements, for example <100ms per
transaction for 95% of requests. Mandating too high iteration count will
disqualify CMP with HMAC secret protection from such projects.

Not allowing too fast hashing absolutely makes sense, with a balance
that it must still be usable for real world usage.
Having a specified minimum entropy for secrets can also make sense, as
we see from other specifications.

Regards,
Tomas

On 2020-12-11 17:13, Aschauer, Hans wrote:
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Dec 2020 11:25:13 -0500

Tomas:

Tomas:

The Security Consideration already talk about entropy in the password.  What more needs to be said?

I think you are advocating:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      minimum of X.  The iterationCount SHOULD be at least 10,000
      [NISTSP800-63B].  There is a trade off between protection of the
      password from attacks and the time spent by the server processing
      the iterations.

I think that X=100 is too low.  What number are you proposing?

Russ

> On Dec 14, 2020, at 2:26 AM, Tomas Gustavsson <[email-masked]> wrote:
> 
> 
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 14 Dec 2020 17:38:56 +0100

> The Security Consideration already talk about entropy in the password.  What more needs to be said?

Right, I can see that in the draft. Are there any recommendations from
good sources as to what level of entropy to use? If we recommend number
of iterations, we should recommend minimum entropy as well, as that is
perhaps even more relevant?

> I think that X=100 is too low.  What number are you proposing?

The good thing is that the client can choose number of iterations, so
the client can make dynamic trade-offs. So it's actually not super
critical what exact number is specified, but it can be mentioned.
In one performance test we have we use the random number of 567
iterations. This is fast. I don't believe 1000 would be much of an
issue. 10K, probably yes for high performance issuance.

Do we want to say that conformant clients MUST use a minimum of X
(1000?). Is that the same as saying conformant servers MUST reject
iterationCount < 1000, with bad_request?

---

From: Lijun Liao <[email-masked]>
Date: Mon, 14 Dec 2020 22:20:24 +0100

IterationCount 1000 is definitely too small to prevent from the well-known
password guess attacks. But with 10000 the server has an extreme
computation burden. In this sense, I do not think password based encryption
is the correct mechanism for systems with high throughput. Instead, for
such systems, one should use the symmetric key based encryption mechanism.

- Lijun

On Mon, Dec 14, 2020 at 5:39 PM Tomas Gustavsson <
[email-masked]> wrote:

> >>> Please note that the cited NIST publication does *not* say that
> iteration count must be at least 10,000. Actually, it states:
> >>>
> >>> The difference is subtle, but important. 10,000 merely is an estimate
> on what typical servers will be able to process. However, the important
> part is "SHOULD be as large as [...] performance will allow". This is due
> to the fact that even much higher iteration counts will not prevent an
> attacker from breaking a low-entropy password in an offline attack. NIST
> also knows this, and for this reason they continue:
> >>>
> >>> However, the secret salt is not an option in the use case discussed
> here (it can only be used for storing password verifiers, not for password
> based key generation).
> >>>
> >>> Assume that the password has an entropy of 35 bits (*), and you use an
> iteration count of 10,000. Further assume that the attacker has an ASIC
> based hash machine, similar to one used for Bitcoin mining, with a hash
> rate of 14 Thash/second, i.e. 14e12 hashes per second (commercially
> available for USD 3000).
> >>>
> >>> On the other hand, a typical server CPU can calculate about 10-100 M
> hashes per second, i.e. 1e7 to 1e8 hashes per second. Allowing for a
> password verification time of one second, this allows for an iteration
> count of 10,000,000 to 100,000,000. This is the number you should choose
> according to the NIST recommendation. Note that this choice will make
> online attacks difficult.
> >>>
> >>> (*) The entropy of a typical password (chosen by a human) is difficult
> to assess. There is a paper from 2007 by Florencio et al [1] which
> calculates 40.5 bits as _mean_ entropy, but also newer research [2] which
> shows that 50% of real-world passwords can be broken with less than
> 150,000,000 trials, indicating a much lower _median_ entropy (27 bits).
> >>>
> >>> [1] Florencio, Dinei; Herley, Cormac (May 8, 2007).
> http://research.microsoft.com/pubs/74164/www2007.pdf, Proceeds of the
> International World Wide Web Conference Committee
> >>>
> >>> [2] Dell’Amico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010).
> Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 -
> 9. 10.1109/INFCOM.2010.5461951.
> >>> ]]]
> >>>
> >>>
> >>>
> >>> 2. One-time passwords
> >>>
> >>> NEW:
> >>>     The password used
> >>> Please note that while a password should in general be used for only a
> single purpose, due to the weakness of the password based MAC, in the use
> case under consideration it should really be used only *once*. This is the
> only way to thwart offline attacks.
> >>>
> >>> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka &
> Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit:
> Using Data from 119 Bitcoin Mining Hardware Setups", International
> Conference on Advances in Business Management and Information Technology
> Istanbul, Turkey (2019).
> >>>
> >>>
> >>> Best regards,
> >>> Hans
> >>>
> >>>
> >>>
> >>> Mit freundlichen Grüßen
> >>> Dr. Hans Aschauer
> >>>
> >>> Siemens AG
> >>> Corporate Technology
> >>> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim
> Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus
> Helmrich, Cedrik Neike, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und
> München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300,
> München, HRB 6684; WEEE-Reg.-Nr. DE 23691322
> >>>
> >>>

-- 
Lijun Liao

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Dec 2020 16:51:59 -0500

> perhaps even more relevant?

We could say that the password SHOULD have at least Z bits of entropy, but only the party that generates the password can know whether it does, and history has shown that the password generator may have less entropy than they think.

> iterationCount < 1000, with bad_request?

The mandatory-to-implement discussion is not the place, in my opinion, for a statement like servers MUST reject iterationCount < 1000.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Dec 2020 17:55:32 -0500

Hans:

> [2] DellAmico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.
> ]]]

As we have seen from other messages on this list, some people think 10,000 is too high.

Recall that the reason for starting this document at all was to move away from HMAC-SHA1, DES-MAC, and Triple-DES-MAC that are specified in RFC 4211.  We are replacing them with HMAC-SHA256 and AES-128-GMAC.  The argument offered here does not apply to both of these algorithms.  Yet, it is desirable that we offer MUST and SHOULD advice that is relevant to both.

Does something like this make sense to you?

I think that X=100 is too low.  What number is a reasonable minimum value?

> I would suggest to use the formulation: "The password used to compute this MAC SHOULD be used only once."

How would you suggest handling communications interruptions?

> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups",…

I will take a look at this paper.

Russ

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 15 Dec 2020 08:10:29 +0100

> The mandatory-to-implement discussion is not the place, in my opinion, for a statement like servers MUST reject iterationCount < 1000.

I can see the difference between RFC4211 and RFC4210 for this now. I got
confused because the same definition of id-PasswordBasedMac is on both
RFC4210 and RFC4211. Creating a risk of conflict/unclarity between the
two RFCs if not updated in sync.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 15 Dec 2020 09:35:01 +0000

Tomas

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von Tomas Gustavsson
> 
> > The mandatory-to-implement discussion is not the place, in my opinion, for
> a statement like servers MUST reject iterationCount < 1000.
> 
> RFC4210 and RFC4211. Creating a risk of conflict/unclarity between the two
> RFCs if not updated in sync.

Good point. 
I will add an update of section 5.1.3.1 pf RFC4210 to CMP Updates and refer to the updated section in CRMF.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Thu, 17 Dec 2020 18:48:41 -0500

> [2] DellAmico, Matteo & Michiardi, Pietro & Roudier, Yves. (2010). Password Strength: An Empirical Analysis. Proceedings of INFOCOM 2010. 1 - 9. 10.1109/INFCOM.2010.5461951.

I suggest:

      iterationCount identifies the number of times the hash is applied
      during the key computation process.  The iterationCount MUST be a
      minimum of 100; however, the iterationCount SHOULD be as large as
      server performance will allow, typically at least 10,000
      [NISTSP800-63B].  There is a trade off between protection of the
      password from attacks and the time spent by the server processing
      the iterations.

> I would suggest to use the formulation: "The password used to compute this MAC SHOULD be used only once."

As I said in my previous response, I think that a second use maght be needed when connections fail.

> I would cite a different paper: Pathirana, Amila & Halgamuge, Malka & Syed, Ali: "Energy Efficient Bitcoin Mining to Maximize the Mining Profit: Using Data from 119 Bitcoin Mining Hardware Setups",…

I have now taken a look at this paper, and it is a good fit.  I will cite this paper.

Russ

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 18 Dec 2020 07:55:14 +0100

Perhaps a stupid question. Is Password-Based Proof-of-possession
something used in practice? I at east have not seen it's use within PKI
(for certificate enrollment).

Cheers,
Tomas

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 18 Dec 2020 07:00:15 +0000

Hi Tomas

I haven't seen password based POP.
I am just aware of password based MAC (not POP) for CMP message protection, e.g., as specified in UNISIG Subset-137.

Hendrik

> Gesendet: Freitag, 18. Dezember 2020 07:55
> An: [email-masked]
> Betreff: Re: [lamps] I-D Action: draft-ietf-lamps-crmf-update-algs-00.txt
> 
> 
> something used in practice? I at east have not seen it's use within PKI (for
> certificate enrollment).
> 
> Cheers,
> Tomas
> 
> >> Please note that the cited NIST publication does *not* say that iteration
> count must be at least 10,000. Actually, it states:
> >>
> >> The difference is subtle, but important. 10,000 merely is an estimate on
> what typical servers will be able to process. However, the important part is
> "SHOULD be as large as [...] performance will allow". This is due to the fact
> that even much higher iteration counts will not prevent an attacker from
> breaking a low-entropy password in an offline attack. NIST also knows this,
> and for this reason they continue:
> >>
> >> However, the secret salt is not an option in the use case discussed here (it
> can only be used for storing password verifiers, not for password based key
> generation).
> >>
> iteration count of 10,000. Further assume that the attacker has an ASIC based
> hash machine, similar to one used for Bitcoin mining, with a hash rate of 14
> Thash/second, i.e. 14e12 hashes per second (commercially available for USD
> 3000).
> >>
> password verification time of one second, this allows for an iteration count of
> 10,000,000 to 100,000,000. This is the number you should choose according to
> the NIST recommendation. Note that this choice will make online attacks
> difficult.
> >>
> >> (*) The entropy of a typical password (chosen by a human) is difficult to
> assess. There is a paper from 2007 by Florencio et al [1] which calculates 40.5
> bits as _mean_ entropy, but also newer research [2] which shows that 50%
> of real-world passwords can be broken with less than 150,000,000 trials,
> indicating a much lower _median_ entropy (27 bits).
> >>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frese
> >>
> arch.microsoft.com%2Fpubs%2F74164%2Fwww2007.pdf&amp;data=04%7C0
> 1%7Che
> >>
> ndrik.brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%
> 7C38
> >>
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
> nknown
> >>
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLC
> >>
> JXVCI6Mn0%3D%7C1000&amp;sdata=bairHiBk5lbBrNgav8N89Wz2H3VcnuJvI
> %2BfU0
> >> aI2k1E%3D&amp;reserved=0, Proceeds of the International World Wide
> >> Web Conference Committee
> >>
> case under consideration it should really be used only *once*. This is the only
> way to thwart offline attacks.
> >>
> Conference on Advances in Business Management and Information
> Technology Istanbul, Turkey (2019).
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .
> >
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.b
> rock
> >
> haus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38ae3bc
> d95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7
> >
> C1000&amp;sdata=9eADDQ8voM8GgKPwZrUngK4mQrrk04uA5luLsf%2FrDI4
> %3D&amp;r
> > eserved=0
> >
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.
> brockhaus%40siemens.com%7Cae7f9c46e5424d5e615e08d8a321eb64%7C38
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637438713379882182%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=9eADDQ8voM8GgKPwZr
> UngK4mQrrk04uA5luLsf%2FrDI4%3D&amp;reserved=0

---

From: David von Oheimb <[email-masked]>
Date: Fri, 18 Dec 2020 09:29:56 +0100

It depends on: proof-of-possession (POP) for what?
For private (asymmetric) keys, a password-based POP makes no sense.
Yet any successful use of a password is a POP for that password.

    David

On 18.12.20 08:00, Brockhaus, Hendrik wrote:
>> something used in practice? I at least have not seen it's use within PKI (for
>> certificate enrollment).
>>
>> Cheers,
>> Tomas
>>

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 18 Dec 2020 09:44:48 +0100

I was just thinking as the HMAC is described in RFC4211 section 4.4,
which is POP.

For CMP there can also be other mitigations, such as the "password"
being a one-time code, in which case an attack on the HMAC pwd in the
message is irrelevant.

Regards,
Tomas

---

From: David von Oheimb <[email-masked]>
Date: Fri, 18 Dec 2020 10:03:33 +0100

Yes,  RFC 4211 section 4.4 describes POP for a password by successful
use of an HMAC
(while section 4.1. is about POP for signature keys, which is the most
common use case).

In the context of certificate management the "password-based POP" is not
needed by itself
because having and proving the possession of a password is not a primary
goal in that context,
but it can be used for PBM-based proof of origin (message protection)
when a client does not have a suitable cert yet.

Regards,

    David