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

[Stephen Farrell <[e-mail]>]

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

On 04/11/15 11:02, Simon Josefsson wrote:
> 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
>