Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt

Vladimir Dubrovin <dubrovin@corp.mail.ru> Sat, 08 April 2017 14:30 UTC

Return-Path: <dubrovin@corp.mail.ru>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136E4127843 for <dmarc@ietfa.amsl.com>; Sat, 8 Apr 2017 07:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level:
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=corp.mail.ru
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 xQocnlWAfw_b for <dmarc@ietfa.amsl.com>; Sat, 8 Apr 2017 07:30:15 -0700 (PDT)
Received: from smtp46.i.mail.ru (smtp46.i.mail.ru [94.100.177.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E501279E5 for <dmarc@ietf.org>; Sat, 8 Apr 2017 07:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=A5EcwUYK8l7dxbtnDeEuSsWURMG4fQqurkw4OfTKq18=; b=GoMGtN5TAtpHBbgSKxIek8GQUwfNLiIEqjp/rxxdtolUUNYWHG2mcKD07fnwAz6HI3gFcDGjWkclTgQcYcqZQR5QKcmvUxVhE7MklaJW6LWWU8HJSOx8DRDKwSm3shYAR2GrlNnLjS8Ibx7vAcK8ZIb+ELBN2jq//TgvzM91qoE=;
Received: from gate.3proxy.ru ([95.79.31.239]:51668 helo=[127.0.0.1]) by smtp46.i.mail.ru with esmtpa (envelope-from <dubrovin@corp.mail.ru>) id 1cwrNU-0004Gt-2R; Sat, 08 Apr 2017 17:30:12 +0300
To: John R Levine <johnl@taugh.com>, "dmarc@ietf.org" <dmarc@ietf.org>
References: <d91de205-05b4-0b59-b3a3-568fc0f57375@corp.mail.ru> <20170406235815.47843.qmail@ary.lan> <1491556016.525223113@f391.i.mail.ru> <alpine.OSX.2.20.1704071004500.55219@ary.qy>
From: Vladimir Dubrovin <dubrovin@corp.mail.ru>
Message-ID: <6bf0cc38-581a-9cd6-404b-a9acf527c453@corp.mail.ru>
Date: Sat, 08 Apr 2017 17:30:06 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.OSX.2.20.1704071004500.55219@ary.qy>
Content-Type: multipart/alternative; boundary="------------EB484DB6C085515F43C65B3C"
Authentication-Results: smtp46.i.mail.ru; auth=pass smtp.auth=dubrovin@corp.mail.ru smtp.mailfrom=dubrovin@corp.mail.ru
X-7FA49CB5: 0D63561A33F958A58A3592046C3E9618D1E09DC3CE3199056972239B64B5A6939F18ECD7E95F35E929AFE063DF4C541C0B0D1444BC99ECAD5554226FBFDD09D3A98AD9646F7AAD836AC2B24064223BE0
X-Mailru-Sender: C5364AD02485212FBEAE30F3FA322883122D5B6481DADB5E1B630F20623ED90A7B57453E6972826ACDCEB298E575E7B2C77752E0C033A69EDAAA56350C7513E7ACB45E4F000D93863453F38A29522196
X-Mras: OK
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/DsbrJcuvOMWst1OEmvW-VR2llJ8>
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-srose-dkim-ecc-00.txt
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Apr 2017 14:30:18 -0000

If you believe sha256/rsa1024 are forever, there is no actual need for
draft-srose-dkim-ecc-00.txt.  The problem is, this need may arrive at
some time, and this time is hardly predictable. There is also possible
there may be the need to roll back ECC and mark it as insecure at some
point of time. So one would expect from the standard:

1. To be compatible with existing implementation to allow to implement
the standard ASAP if required and yet to allow the use of the strongest
up-to-date algorithms
2. To be self updating, to avoid the need to produce the new DKIM
standard each time encryption standards are changing. It may be achieved
by e.g. referencing to IANA TLS SignatureAlgorithm/HashAlgorithm registry.

08.04.2017 15:45, John R Levine пишет:
>> Without marking the published key as obsolete, downgrade attack is
>> possible, because attacker can still use a weaker key to spoof
>> signature.
>
> If you know how to spoof a sha256/rsa1024 signature, I know a lot of
> people who would like to talk to you.
>
> Other than that, please review RFC 6376.  Each signing algorithm has a
> separate key -- if you don't trust an algorithm, don't publish a key
> for it.
>
> R's,
> John
>
>>
>>>> 1. produce 2 different DKIM-Signatures with 2 different selectors:
>>>> slector1  with SHA-1 + RSA and selector2 one with  SHA-512 + ECDSA
>>>
>>> Of course.
>>>
>>>> 2. add an additional field to either selector1 DKIM DNS record
>>>> (need to
>>>> consult RFC if it's allowed) or to DKIM-Signature with selector1 (it's
>>>> allowed but probably is not enough to protect against downgrade) to
>>>> indicate the selector is legacy-only, e.g. o=sha512/eccp256 to
>>>> indicate
>>>> this selector should be ignored if verifier supports sha-512 and
>>>> eccp256.
>>>
>>> No.  If the verifier is smart enough to understand new algorithms, it
>>> is smart enough to figure out which signature to prefer.  Also keep in
>>> mind that the legacy crypto is sha256/rsa1024 which is plenty strong
>>> for the forseeable future.


-- 
Vladimir Dubrovin
@Mail.Ru