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

[Simon Josefsson <[e-mail]>]

tis 2015-11-03 klockan 21:48 +0900 skrev Yoav Nir:
> > On 3 Nov 2015, at 5:56 PM, Simon Josefsson <[e-mail]> wrote:
> > 
> > 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.
> 
> 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.

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.

> 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.

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