[saag] Re: New Version Notification for draft-rsalz-crypto-registries-00.txt

[Simon Josefsson <[e-mail]>]

"Salz, Rich" <rsalz=[e-mail]> writes:

>>What problem are you trying to solve with this document?
>>Could we start with a problem statement?
>
> It was discussed during SAAG.  See the tail end of the chat at https://zulip.ietf.org/#narrow/stream/337-saag

That link leads to a login prompt that requires me to run remotely
controlled JavaScript code in my browser.  Is the chat publicly
archived?  Wouldn't it be nice if things had to be "permanent and
readily available" to be used as reference material? :)

>> To me, it seems like an attempt to generalize a policy that risk
> i> ncreasing the downward angle of the slipper slope towards rejecting all
>>crypto that isn't controlled by NIST.
>
> This greatly concerns me.  Can you tell why you think it encourages
> that?  Because I am strongly opposed to that.

Good.  I don't claim the document encourage rejecting non-NIST crypto,
but I think the document may be a useful tool for people who want to
delay deployment of strong non-sanctioned crypto.  The document suggests
"Specification Required" for all registries.  This is a limitation
compared to broad set of different policies allowed by RFC 8126.
Limiting the registration policies is one method to make it harder for
people to interoperate protocols with non-blessed crypto.  In my
perception, this aspect was used to delay publication of 25519 and
currently ssh-ntruprime.  While good arguments may exist for
"Specification Required" in some protocols, I don't follow why this is
necessarily the right thing for all protocols.  The
First-Come-First-Serve policy for SASL mechanisms have worked fine, and
allow experimentation with non-blessed crypto if people care to do so.

/Simon



>
>> I don't think I-D's are appropriate to use as reference material in the
>>Specification Required context. The current IETF I-D boilerplate says:
>
> Yes, that's a matter of controversy, see above comment on consensus.
>
>>> DE Instructions
>>> Unless the WG chairs indicate otherwise via email, the Designated
>>> Experts should decline code point registrations for documents which
>>> have already been adopted or are being proposed for adoption by IETF
>>> working groups or IRTF research groups.
>
>> I suggest changing 'or are being proposed for adoption into 'or are
>> being proposed by the document authors for adoption into' to avoid
>> external people fillibustering the registration process of a document by
>> proposing it for adoption by some random WG's. Proposing other's work
>> as WG documents is a pattern that have been followed for several
>>protocols that people dislike and seamingly wish to delay.
>
> Very good suggestion. Recorded at https://github.com/richsalz/draft-rsalz-crypto-registries/issues/1
>
>
> _______________________________________________
> saag mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]