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

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Mar 2016 14:06:15 +0000

FYI. Please send comments to [email-masked].

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.

Thanks,
S.

-------- Forwarded Message --------
Subject: [saag] possible BCP on public review being needed for
standards-track crypto
Date: Wed, 23 Mar 2016 13:45:10 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked] <[email-masked]>

Hiya,

Rich Salz has put together an initial stab at a draft of a BCP [1]
that says "for IETF standards track, crypto algorithms need to
have had public analysis." (Thanks Rich!)

I think this'd be a good thing to progress but as you'll see the
-00 submitted just at the cutoff needs a good bit of work. (Still
great to have a starting point though, so thanks again Rich:-)

So, please read and comment on [email-masked]. As well as getting
detailed comments, I'd also be interested in whether or not
folks think the basic premise is something it'd be good to have
as a BCP, so thumbs-up/down messages are also useful at this
point. (If "thumbs-down" please say why, if "thumbs-up" then
later detailed wrangling over text will be fine.)

We'll have a short 5-min slot for this in the saag session in B-A
just to bring it to folks' attention.  If there are issues that
we don't resolve on the list (e.g. I'd expect that getting a good
enough description of "public review" might be tricky) we can have
a more extended discussion about this at saag in Berlin.

Cheers,
S.

[1] https://tools.ietf.org/html/draft-rsalz-drbg-speck-wap-wep

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Mar 2016 13:23:25 -0400

> the saag list, and of course any detailed comments should

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.

My preferred solution is that IANA code points be reserved for IETF
reviewed and recommended crypto. Noting of course that the IETF review
might be of the AES or SHA-2 competition process and not rehashing the
competition itself.

I would like there to be precisely one way to install other crypto
using OIDs as algorithm identifiers. Why OIDs? Because we don't need
to touch them at all. No endorsement is expressed or implied.

Making this happen in protocols like JOSE and XML Dig Sig would mean
using the OID string as the identifier. In other protocols it might be
necessary to prefix the crypto stream with the OID value.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 Mar 2016 17:26:52 +0000

For those playing along at home, my draft is maintained here: https://github.com/richsalz/draft-rsalz-dbrg-speck-wap-wep and it's had some changes since the cut-off deadline.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Yoav Nir <[email-masked]>
Date: Wed, 23 Mar 2016 20:38:44 +0200

> On 23 Mar 2016, at 7:23 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

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.

Yoav

[1] http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 23 Mar 2016 15:30:08 -0400

> 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 id…

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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Mar 2016 20:17:57 +0000

Folks, please use [email-masked] for discussion of this
topic, not cfrg.

S