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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 05 November 2015 01:55 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62831B369E for <secdir@ietfa.amsl.com>; Wed, 4 Nov 2015 17:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSBvbu_YQbL2 for <secdir@ietfa.amsl.com>; Wed, 4 Nov 2015 17:55:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D2E1B3687 for <secdir@ietf.org>; Wed, 4 Nov 2015 17:54:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 39733BDF9; Thu, 5 Nov 2015 01:54:57 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ_6FWlQhgbe; Thu, 5 Nov 2015 01:54:55 +0000 (GMT)
Received: from [133.93.24.87] (unknown [133.93.24.87]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 15B1DBDCF; Thu, 5 Nov 2015 01:54:53 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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 <simon@josefsson.org>, Yoav Nir <ynir.ietf@gmail.com>
References: <56383A36.3020200@cs.tcd.ie> <20151103095611.33a536b9@latte.josefsson.org> <5113E79E-D8DA-4B19-A730-2EDC58FCE41A@gmail.com> <1446634943.26563.23.camel@josefsson.org>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <563AB6E4.4040705@cs.tcd.ie>
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: <1446634943.26563.23.camel@josefsson.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/TvShmszyduQlhCNpQ4yW2IANUX8>
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] a few new algs and a bunch of deprecation
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 01:55:07 -0000

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 <simon@josefsson.org> 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
>