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

[Ludovic BOCQUET <[e-mail]>]

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":

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

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 <[e-mail]>
Sent: Wednesday, November 4, 2020 8:47 PM
To: Ludovic BOCQUET <[e-mail]>; Alexey Melnikov <[e-mail]>; Robbie Harwood <[e-mail]>; Jim Fenton <[e-mail]>; KITTEN Working Group <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00

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