Subject: [secdir] a few new algs and a bunch of deprecation

From: Stephen Farrell <[email-masked]>
Date: Tue, 3 Nov 2015 04:38:14 +0000

Hiya,

At the secdir lunch we spoke about needing a bit of organisation
around adding new curves and about deprecating some old algs (e.g.
sha1). There's a scattered set of stuff that'll need doing some
of which is in progress (e.g. drafts allocating OIDs for new
curves), others of which may not yet be. One possibility would be
to try do this as a WG with a charter that tightly defines which
new things can be added but allows for deprecating anything
that should be deprecated. (The putative WG here would not I
think tackle items where we have a current WG active, e.g. TLS
can handle defining codepoints for TLS.)

As a separate but related thing, Alexey said he'd create a cfrg
wiki page where folks could add the names of drafts that are
defining things related to new curves. That might feed into the
positive parts of chartering.

FWIW, if this is something people supported and found useful,
Kathleen and I are happy to help it happen. Next step would likely
be to send a mail like this to saag then if nothing bad happens, to
start a mailing list for this and see if there's enough energy
to get stuff going. (If there is, I doubt a BoF would be needed.)

Thoughts?

S.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 3 Nov 2015 09:56:11 +0100

I'm following Curve25519/Ed25519 use in IETF protocols and is
interested in helping that effort.  It seems the intersection between
this putative WG and existing WGs needs to be carefully explained
though, it isn't clear to me how it could be done.  Isn't deprecating
crypto parts of a protocol up to each protocol community to think
about?  We've seen with TLS, OpenPGP, Secure Shell and PKIX that
adding Curve25519/Ed25519 is highly protocol specific and requires
domain knowledge.

/Simon

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Nov 2015 21:48:22 +0900

> On 3 Nov 2015, at 5:56 PM, Simon Josefsson <[email-masked]> wrote:
> 

My take on this is the exact opposite. We’ve added ChaCha20/Poly1305 to SSH and TLS and IPsec. Same algorithm in all three (yes, I know SSH uses the old construction). 

We’re adding Curve25519/Ed25519 to SSH and TLS and IKE and PGP and PKIX. Same algorithm for all of them.

Is it safe to use SHA-1 in signatures? Regardless of what you think the answer is, it is the same in TLS and PGP and IKE and SSH and PKIX.

I think the best thing with such algorithms is to have guidance documents from either CFRG or Security AD-sponsored, and then have the separate protocol documents be little more than code point allocations.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Nov 2015 04:22:32 +0000

As nobody said this was crazy, I'll shoot a mail to saag
and we can discuss it there. The issue of how this would
relate to existing WGs is clearly a fine one to chat about.

Cheers,
S.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Nov 2015 12:02:23 +0100

> We’re adding Curve25519/Ed25519 to SSH and TLS and IKE and PGP and PKIX. Same algorithm for all of them.

Curve25519/Ed25519 will be published through CFRG so the algorithm
description is covered there -- but the integration into each protocol
proved to contain protocol-specific differences and considerations.  I'm
concerned that a separate WG will get such details wrong, or will have
confusing overlap with any established WG.  For ChaCha20/Poly1305 I
agree, but it it is a simple add-in for any protocol that supports AEAD
constructs.

> I think the best thing with such algorithms is to have guidance documents from either CFRG or Security AD-sponsored, and then have the separate protocol documents be little more than code point all…

I agree.  What do you see a putative WG doing then?  Code point
allocation discussion typically happens in each protocol WG, if there is
any.  For Secure Shell and PKIX where there aren't active WGs, I suppose
Security AD-sponsored would work.

Saying that you MUST NOT rely on SHA1 to provide collision resistance is
an obvious document to publish (isn't there one already?), but I'm not
sure it needs a WG around it.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Nov 2015 01:54:44 +0000

Can we move the discussion to saag?
Thanks,
S.