[kitten] Murray Kucherawy's Discuss on draft-ietf-kitten-krb-spake-preauth-11: (with DISCUSS and COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-kitten-krb-spake-preauth-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[For the IESG to discuss]

I'd like to discuss some of the procedural stuff that's been raised by others
before going to either ABSTAIN or NO OBJECTION.  Basically I have the same
concerns as Eric: The shepherd writeup is 4+ years old and doesn't use an
approved template; the directorate reviews are stale; IETF Last Call was 3+
years ago.  Maybe this is all fine, but I'd like to be sure we talk about it
first.

In Section 12, we're telling the Designated Experts that an I-D counts as a
specification, even if it is never published as an RFC.  But an I-D can expire.
 Are we OK with having an IANA registry with an entry that claims as its
authoritative specification an expired I-D?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 12.2.2 appears to have four registrations all run together.  Could we
separate them somehow, either with line breaks or with subsections?

Section 4.1: Why is this only a SHOULD?  Is it OK if I do something different?

Section 4.3: Same question.

===

Additional comments from incoming ART AD, Orie Steele:

9.  Hint for Authentication Sets

Why MAY and not SHOULD?

Phrasing around MUST NOT and must only could be clearer, and is possibly the
reason for the MAYs?

10.2 Unauthenticated Plaintext

> Second factor
   types MUST account for this when specifying the semantics of the data
   field.

It's not clear (to me) how to comply with this MUST, an example of citation
might help.

In 10.4

Several SHOULD's that maybe ought to be MUSTs?

It would be nice to see clearer recommendations on achieving forward secrecy,
and on rotating the cookie.