Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00

From: Alexey Melnikov <[email-masked]>
Date: Tue, 3 Nov 2020 14:27:31 +0000

Hi Sam,

I tend to agree with Ludovic on ordering. More on this below:

On 30/10/2020 00:40, Sam Whited wrote:

> Hi Ludovic,
>
> On Thu, Oct 29, 2020, at 18:48, Ludovic BOCQUET wrote:
>>   * "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS
>>     variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-
>>     256 variants [RFC7677] SHOULD be preferred over SHA-1 variants
>>     [RFC5802])"
> I disagree with the RFC on this regard, but if further evidence can be
> provided I'm all ears. There are no known pre-image attacks against SHA-
> 1, and the weaknesses I'm aware of at least won't matter for SCRAM since
> SHA-1 is only used in the HMAC so to me it seems preferable to encourage
I think trust in SHA-1 is diminishing, so it will be phased out even if 
HMAC-SHA-1 is still considered to be Ok. I think at this point we 
shouldn't encourage use of SHA-1 with SCRAM, unless this is required for 
backward compatibility reasons.
> channel binding first, and the specific hash second.

That I agree with. So maybe the following ordering:

SCRAM-SHA-256-PLUS
SCRAM-SHA-1-PLUS
SCRAM-SHA-256
SCRAM-SHA-1
?

> That being said,
> channel binding isn't actually very useful right now since there's no
> way to negotiate it and the existing methods are insecure without the
> TLS master secret fix, so maybe it doesn't matter either way.
Fixing channel binding for TLS 1.3 is something that we need to do 
anyway. But this is a separate discussion.
> I am certainly not an expert and will bow to expert opinion if consensus
> is against me, so I'd love more feedback on this.
>
>> In the same time, I think that we must to add two new official SCRAM
>> drafts of the same author of SCRAM:
>>
>> Currently SCRAM-SHA-512-PLUS and SCRAM-SHA-512 are missing:
>> -https://tools.ietf.org/html/draft-melnikov-scram-sha-512
>>
>> Currently SCRAM-SHA3-512-PLUS and SCRAM-SHA3-512 are missing:
>> -https://tools.ietf.org/html/draft-melnikov-scram-sha3-512
> I'm keeping an eye on those and am very excited to see them coming
> along! I'd prefer that they go through expert review first though
> before adding them to this document (although I do think it's
> appropriate to do so since they're both just I-Ds right now, so I don't
> feel strongly about this). I wouldn't want this document to go to RFC
> and still be referencing those I-Ds, but I don't know what the IETF
> position on this is; either way it seems worth waiting and keeping an
> eye on them for now.

Fair point.

Best Regards,

Alexey

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 04 Nov 2020 08:06:16 -0500

Responses inline. TL;DR I agree.

> That I agree with. So maybe the following ordering:

That seems fine to me, I'll update in the next version.

> anyway. But this is a separate discussion.

See also https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/, I'd love your feedback there too.

—Sam

---

From: Ludovic BOCQUET <[email-masked]>
Date: Wed, 4 Nov 2020 18:03:06 +0000

Hello all,

After my comments that I have done some months ago about the bad SCRAM order, my relaunch in this public list and after the reply of Alexey Melnikov (Author of several RFCs: https://datatracker.ietf.org/person/alexey%20melnikov), thanks to Sam for finally listening to me.

Do not forget to add in the next version of "draft-ietf-kitten-password-storage" Internet-Draft:

  *   SCRAM-SHA3-512-PLUS
  *   SCRAM-SHA-512-PLUS
  *   SCRAM-SHA3-512
  *   SCRAM-SHA-512

To have:

  *   SCRAM-SHA3-512-PLUS
  *   SCRAM-SHA-512-PLUS
  *   SCRAM-SHA-256-PLUS
  *   SCRAM-SHA-1-PLUS
  *   SCRAM-SHA3-512
  *   SCRAM-SHA-512
  *   SCRAM-SHA-256
  *   SCRAM-SHA-1

Note: The final "draft-ietf-kitten-password-storage" must be validated like a RFC after the next two I-Ds, it is really important.

Linked to:

  *   https://tools.ietf.org/html/draft-melnikov-scram-sha3-512
  *   https://tools.ietf.org/html/draft-melnikov-scram-sha-512

It is not linked to IETF, but in the same time, do not forget to update the XEP-0438 with my comments too:

  *   https://xmpp.org/extensions/xep-0438.html

Thanks in advance.

Regards,

BOCQUET Ludovic

________________________________
From: Sam Whited <[email-masked]>
Sent: Wednesday, November 4, 2020 1:06 PM
To: Alexey Melnikov <[email-masked]>; Ludovic BOCQUET <[email-masked]>; Robbie Harwood <[email-masked]>; Jim Fenton <[email-masked]>; KITTEN Working Group <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00

—Sam

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 04 Nov 2020 14:06:49 -0500

On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote:
> thanks to Sam for finally listening to me.

My apologies if I misunderstood, I thought you were advocating for:

* SCRAM-SHA-256-PLUS
* SCRAM-SHA-256
* SCRAM-SHA-1-PLUS
* SCRAM-SHA-1

Which is not what we're going with for now. I did like the idea of
separating the -PLUS mechanisms out into two levels though to indicate
that even if SHA-1 is just as secure right now, it is likely in the
process of being deprecated as Alexey suggested.

>  * SCRAM-SHA3-512-PLUS …

As discussed, I do not currently plan on doing this. Let's wait and see
how those I-Ds develop first.

—Sam

---

From: "Sam Whited" <[email-masked]>
Date: Wed, 04 Nov 2020 15:47:53 -0500

Following up on this after our conversation out-of-band since I
apparently misunderstood this sentence:

On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote:
> Note: The final "draft-ietf-kitten-password-storage" must be validated
> like a RFC after the next two I-Ds, it is really important.

I appreciate your confidence and desire to see this published as an RFC,
but I don't think we can set such an aggressive timeline on it.

I'll be the first to complain about working with the IETFs obtuse
process (someone was kind enough to sit me down and walk me through the
whole thing on video chat and I still have no idea how any of it works
or what my role as an author is, the tools are impossible to use, the
format is impossible to write, etc.), but picking an arbitrary number of
drafts before advancing a document with a lot of subtle bits that need
expert review doesn't seem like a good idea to me.

Sorry, I'd love to see it advance too, but I'm not sure it's ready
quite yet. We have plenty of time to see what happens with the other
SCRAM I-D first. If one document or the other looks like it's ready to
advance, we can reevaluate this position before doing so. Don't worry,
if the new SCRAM mechanisms look like they're going to work out, we'll
get them in there!

Although I haven't heard many other opinions; if waiting on linking the
other SCRAM I-Ds seems too conservative I'd love to be told I'm wrong by
more seasoned IETF folks.

Thanks,
Sam

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 5 Nov 2020 11:49:43 +0000

Hi Sam,

> if the new SCRAM mechanisms look like they're going to work out, we'll

I am Ok with you not including SCRAM-SHA-512, etc until these documents 
are approved for publication or at least adopted by the Kitten WG.

As far as the IETF process is concerned, if you include a normative 
reference to it in your draft now, your document couldn't be published 
as an RFC until after all normative references are published as RFCs.

---

From: Ludovic BOCQUET <[email-masked]>
Date: Sun, 22 Nov 2020 12:04:48 +0000

Hello all,

After my previous comments, maybe it is not clear to all in this list, sorry.

Sam and others, I have requested you to have in this "draft-ietf-kitten-password-storage" I-D:

  *   SCRAM-SHA3-512-PLUS
  *   SCRAM-SHA-512-PLUS
  *   SCRAM-SHA-256-PLUS
  *   SCRAM-SHA-1-PLUS
  *   SCRAM-SHA3-512
  *   SCRAM-SHA-512
  *   SCRAM-SHA-256
  *   SCRAM-SHA-1

And added in "References":

Currently we can see only and with a bad order:

  *   EXTERNAL
  *   SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
  *   SCRAM-SHA-1, SCRAM-SHA-256
  *   PLAIN
  *   DIGEST-MD5, CRAM-MD5

The bad order of SCRAM is always here in "-01": "1" before "256" and on one line.

And Alexey Melnikov has confirmed here:

  *   https://mailarchive.ietf.org/arch/msg/kitten/8GglIHO_8kgZtk83D-8XOsZxuxE/

But Alexey Melnikov has said about SCRAM-SHA-512(-PLUS) and SCRAM-SHA3-512(-PLUS):
"I am Ok with you not including SCRAM-SHA-512, etc until these documents are approved for publication or at least adopted by the Kitten WG.
As far as the IETF process is concerned, if you include a normative reference to it in your draft now, your document couldn't be published as an RFC until after all normative references are published as RFCs."

  *   https://mailarchive.ietf.org/arch/msg/kitten/fqeNdi5-n8_x3zw4NIy7Yi8ayLo/

Please read my comments after.

It is to be ready and I have specified to wait that the 2 I-Ds become 2 RFCs and after "draft-ietf-kitten-password-storage" I-D can be updated with RFC links and after this I-D can become an RFC.
I would not to see a next I-D to update again.

I have never said finalize today or tomorrow.
And other parts can be improved.

And I think, that it is possible to add a reference to "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D into "draft-ietf-kitten-password-storage" I-D too.

  *   https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-for-tls13

In order, steps:
1 - "draft-ietf-kitten-password-storage" I-D can have "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D link
2 - "draft-ietf-kitten-password-storage" I-D can have "draft-melnikov-scram-sha-512" I-D link
3 - "draft-ietf-kitten-password-storage" I-D can have "draft-melnikov-scram-sha3-512" I-D link
4 - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D become an RFC
5 - "draft-melnikov-scram-sha-512" I-D become an RFC
6 - "draft-melnikov-scram-sha3-512" I-D become an RFC
7 - "draft-ietf-kitten-password-storage" I-D is updated with new links and your I-D can become an RFC

The goal is to do not create a new RFC some days after with forgotten parts.

Note:
- "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D updates or obsoletes RFC5929 (but it is not specified in header)
- "draft-ietf-kitten-password-storage" I-D updates RFC8600 (but it is not specified in header)

If we look previous RFCs (there are a lot), we can see in some examples:
- In RFC5801: https://tools.ietf.org/html/rfc5801, a link to RFC5802 (released at the same time: RFC5801/RFC5802/RFC5803)
- In RFC5802: https://tools.ietf.org/html/rfc5802, a link to RFC5803 (released at the same time: RFC5801/RFC5802/RFC5803)
- In RFC6120: https://tools.ietf.org/html/rfc6120, a link to RFC6121 and RFC6122 (released at the same time: RFC6120/RFC6121/RFC6122)
- In RFC8446: https://tools.ietf.org/html/rfc8446, a link to  draft-ietf-tls-tls13-vectors-06
- In RFC7590: https://tools.ietf.org/html/rfc7590, a link to draft-ietf-dane-srv-14 + draft-ietf-xmpp-posh-04 + draft-ietf-xmpp-dna-10

1 - We can see it is possible to release several RFCs at the same time, it is a great organization and a great synchronization.
2 - We can see that it is possible to have draft in a new RFC.

We can see that Alexey Melnikov has added my request, there is a draft-ietf-kitten-tls-channel-bindings-for-tls13 reference in:

  *   https://tools.ietf.org/html/draft-melnikov-scram-sha-512-01
  *   https://tools.ietf.org/html/draft-melnikov-scram-sha3-512-01

Do not forget that:
1 - CRAM-MD5 to Historic:
- https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 // 20 November 2008
- https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-00 // June 29, 2017

2 - RFC6331: Moving DIGEST-MD5 to Historic:
- https://tools.ietf.org/html/rfc6331 // July 2011

Maybe it is time to take them off completely from the list even if they are after PLAIN.

Thanks for reading me.

Regards,

BOCQUET Ludovic

________________________________
From: Sam Whited <[email-masked]>
Sent: Wednesday, November 4, 2020 8:47 PM
To: Ludovic BOCQUET <[email-masked]>; Alexey Melnikov <[email-masked]>; Robbie Harwood <[email-masked]>; Jim Fenton <[email-masked]>; KITTEN Working Group <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00

Thanks,
Sam

---

From: "Sam Whited" <[email-masked]>
Date: Sun, 22 Nov 2020 20:36:10 +0000

> After my previous comments, maybe it is not clear to all in this

I apologize for the confusion, but I am still not sure what you are
advocating for in this email. It appeared that you want the order that
Alexey suggested, which I already said I would update in the next draft.

It also appears that you're asking again for me to add references to the
various new SCRAM mechanisms, but as I have already told you I plan on
waiting a bit. There is no harm in waiting for more feedback on them
before referencing them in this I-D.

> Please read my comments after.

I am not sure what comments you are referring to.

> I have never said finalize today or tomorrow. And other parts can be
> improved.

I apologize, I thought when you said "The final 'draft-ietf-kitten-password-
storage' must be validated like a RFC after the next two I-Ds, it is
really important" you meant that we should move password-storage to RFC
after two more drafts and this is what I was pushing back on. I am sorry
if I misunderstood.

> - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D updates or
>   obsoletes RFC5929 (but it is not specified in header)

I'm not sure if this is true or not. Maybe it just updates them since
they are still valid for TLS 1.2? I could go either way. I will make a
note that this needs updating in a future revision. Thanks.

> - "draft-ietf-kitten-password-storage" I-D updates RFC8600 (but it is

I don't think this one is true unless we're going to count this as
updating every single protocol that uses SCRAM.

> Do not forget that: 1 - CRAM-MD5 to Historic:

I don't think we need to reference every obsolete hashing mechanism, I
just mentioned that old MD5 mechanisms aren't a good idea in the example
of how to order mechanisms.

> Maybe it is time to take them off completely from the list even if

They are off the list, the only place they are mentioned is in an
example of how to order mechanisms. If this is causing confusion maybe
they shouldn't be mentioned there either though. I'll consider it for
the next draft.

Thank you for your feedback. I'm sorry if I missed anything, it was a
very long email and included feedback on multiple I-Ds. In future it
might be best to provide feedback for different I-Ds in different
threads. Hopefully I responded to all the important bits.

—Sam

---

From: Ludovic BOCQUET <[email-masked]>
Date: Mon, 23 Nov 2020 06:54:29 +0000

Sent: Sunday, November 22, 2020 8:36 PM

-> Thanks for -02 draft :)
- https://tools.ietf.org/html/draft-ietf-kitten-password-storage-02

-> I hope that you will not forget to add before the final draft :)

-> I have explained why it is better to have a perfect "Best practices for password hashing and storage" RFC instead of 2 RFCs (this future and a next one to update "Best practices for password hashing and storage" with a "Best practices for password hashing and storage v2").

-> If you need to have only RFC reference links instead draft or prepare to release at the same time (see examples that I have done), but it is possible to have an RFC with draft reference links (see examples that I have done).

-> Thanks :)
TLS 1.3 obsoletes TLS 1.2 and it is not for this that TLS 1.2 is already not used, there is a transition period...
- https://tools.ietf.org/html/rfc8446
Obsoletes: 5077, 5246, 6961
Updates: 5705, 6066

-> It is SCRAM-SHA-512(-PLUS) and SCRAM-SHA3-512(-PLUS) which must inform the update of other previous SCRAM.

But the order in the RFC8600 is not good:
- https://tools.ietf.org/html/rfc8600
- "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802])".
Results: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1.

I have informed you when you have done: https://tools.ietf.org/html/draft-whited-kitten-password-storage-00.

Recall: The order was bad since the first draft:
- https://tools.ietf.org/html/draft-whited-kitten-password-storage-00
"- SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
- SCRAM-SHA-1, SCRAM-SHA-256"
Results: SCRAM-SHA-1-PLUS > SCRAM-SHA-256-PLUS > SCRAM-SHA-1 > SCRAM-SHA-256.

Now, we have updated the good order in "draft-ietf-kitten-password-storage":
- https://tools.ietf.org/html/draft-ietf-kitten-password-storage-02
"- SCRAM-SHA-256-PLUS
- SCRAM-SHA-1-PLUS
- SCRAM-SHA-256
- SCRAM-SHA-1"
Results: SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1.

This current draft updates the RFC8600.

Do not forget that there is the XEP-0438 too:
- https://xmpp.org/extensions/xep-0438.html

-> See below

-> Thanks! :)
If removed or not, better to have references to inform people that it is needed to downgrade (like you have done, before PLAIN) or remove the implementation to have a more secure system.
I really think that references to RFC6331 and old CRAM-MD5 drafts (not RFCs badly) are needed.

—Sam

Thanks for the answers, the changes made and those still to be made.

Regards,

BOCQUET Ludovic