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

Stephen Farrell <> Thu, 05 November 2015 01:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E62831B369E for <>; Wed, 4 Nov 2015 17:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NSBvbu_YQbL2 for <>; Wed, 4 Nov 2015 17:55:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87D2E1B3687 for <>; Wed, 4 Nov 2015 17:54:58 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39733BDF9; Thu, 5 Nov 2015 01:54:57 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LJ_6FWlQhgbe; Thu, 5 Nov 2015 01:54:55 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 15B1DBDCF; Thu, 5 Nov 2015 01:54:53 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1446688495; bh=crot30ZDFO/7tRyhOee2M5baPor7Opi1ugr9etAnv/A=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=tlnm771mHHWEy9a+X+EpaaB1/g08Pvdci5urJxs/h0To+QRud5Q7Dd3303pfPk8Sr vfx9jv70CD9P8wK/o1jrk5tt0tpIhGFMZnoT6JAAvVlZsaaXKutb2mNO0oZgiXtF1U UkwxbtHql5JPWMHLbXS6QHc65NDEcBXod4Iqqyx8=
To: Simon Josefsson <>, Yoav Nir <>
References: <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 5 Nov 2015 01:54:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <>
Cc: "" <>
Subject: Re: [secdir] a few new algs and a bunch of deprecation
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2015 01:55:07 -0000

Can we move the discussion to saag?

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