Re: [Cfrg] Fwd: [saag] possible BCP on public review being needed for standards-track crypto

[Stephen Farrell <[e-mail]>]

Folks, please use [e-mail] for discussion of this
topic, not cfrg.

S

On 23/03/16 19:30, Phillip Hallam-Baker wrote:
> On Wed, Mar 23, 2016 at 2:38 PM, Yoav Nir <[e-mail]> wrote:
>>
>>> On 23 Mar 2016, at 7:23 PM, Phillip Hallam-Baker <[e-mail]> wrote:
>>>
>>> On Wed, Mar 23, 2016 at 10:06 AM, Stephen Farrell
>>> <[e-mail]> wrote:
>>>>
>>>> FYI. Please send comments to [e-mail].
>>>>
>>>> If you just want to say "+1" that's as useful here I guess,
>>>> but if you think this is a bad idea, please explain why on
>>>> the saag list, and of course any detailed comments should
>>>> go to the saag list.
>>>>
>>>
>>> I think it a good idea to insist that any crypto that the IETF is
>>> apparently endorsing have been subject to public review.
>>>
>>> I also believe that it should be possible to use arbitrary crypto with
>>> IETF protocols.
>>>
>>> Using IANA assigned code points means it is not possible to satisfy
>>> both at once.
>>
>> I don’t think that it is impossible.  Suppose you have a registry for encryption algorithms such as the IKEv2 one ([1]), where identifiers are 16-bit. Currently it is partitioned so that 0-1023 are for assignment by the IETF (we’re up to 28), while 1024-65536 is for private use.  It should be fairly easy to alter the partition so that 0-1023 is for the IETF with expert review (like it is today), 1024-2047 specification required (no implication about quality), 2048-4095 FCFS (no implication that you can even implement it), and the rest left for private use (like today).  That way the higher ranges are only used to avoid two private experiments colliding.
>>
>> The downside is what is happening right now with ChaCha20 and TLS. Someone starts using a value either by squatting or by the easy procedure. After that, if the IETF decides to “bless” it, a new identifier would hurt interop with a deployed base. So you end up with a recommended algorithm in the range we reserved for crypto that amateurs invent.
>>
> 
> That is why I suggest OIDs. Anyone can cut one. I have an arc. You can
> have one too.
> 
> If I am writing a general purpose library, I almost certainly need to
> cut an OID to support CMS, PKIX and the like. So supporting use of the
> IETF code point or the OID, isn't actually much of an overhead if
> anything.
> 
> Right now I have crypto libraries wrapping crypto libraries three deep
> because folk can't write decent, consistent APIs and because I need to
> support four different IETF naming and numbering schemes.
>