From nobody Thu Jun 1 21:24:52 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D27F124D85 for ; Thu, 1 Jun 2017 21:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 TJ48bfyQbivz for ; Thu, 1 Jun 2017 21:24:49 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF3B1270AC for ; Thu, 1 Jun 2017 21:24:49 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 99433C401F4 for ; Thu, 1 Jun 2017 23:24:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496377487; bh=Mtr8rpcfb35YN/1JvOD+GPEkqSuFVqDNoGEYeMNxnZE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YKKiQPa5BvFzixf23Er7gkg+bQ5V6LnOSgLgZHIfINV6hzGF7rSrhPiRbVeai634d ta4RGgH2f5tP/jmpCQpzNseS8mRxXSd8I9N4mwztRfVo1izxOKHR9zhjJ4+3zo75yv JUSuwbD+YvkIcP8iYmjupS0OE+F5rmdM3xJZTO4k= From: Scott Kitterman To: dcrup@ietf.org Date: Fri, 02 Jun 2017 00:24:47 -0400 Message-ID: <3745683.4zdJlR4cAU@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <149619233095.19793.14947085917778354002@ietfa.amsl.com> References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 04:24:51 -0000 On Tuesday, May 30, 2017 05:58:51 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DKIM Crypto Update of the > IETF. > > Title : Cryptographic Algorithm and Key Usage to DKIM > Author : Scott Kitterman > Filename : draft-ietf-dcrup-dkim-usage-00.txt > Pages : 5 > Date : 2017-05-30 > > Abstract: > The cryptographic algorithm and key size requirements included when > DKIM was designed in the last decade are functionally obsolete and in > need of immediate revision. This document updates DKIM requirements > to those minimaly suitable for operation with currently specified > algorithms. This document updates RFC 6376. This is a pretty simple draft. It does two things: 1. Changes signers SHOULD sha-256 and verifiers MUST support both sha-1 and sha-256 to signers/verifiers MUST sha-256 and MUST not sha-1. It does nothing about adding anything new as there will be other documents for that. 2. Changes signers MUST at least 1024 bits for long live keys (long lived is never defined) and verifiers MUST support 512 bits to 2048 bits to signers SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers MUST support 1024 to 4096 bits. I think the ABNF for the a=tag in 3.5 and the h= tag in 3.6.1 should be updated to remove sha1. I missed that in the first draft. Based on the discussion before I submitted the draft, I don't think any of this is very controversial. We've already discussed the trade-offs on key length. I don't recall that we explicitly discussed MUST NOT sha1. Given the WG will later add other new algorithms and it's been required to support sha256 from the beginning, I think that's the right answer, but it might merit some further discussion. Scott K From nobody Thu Jun 1 21:29:25 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FC8124D85 for ; Thu, 1 Jun 2017 21:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=kitterman.com 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 I5RmG7KSzSGX for ; Thu, 1 Jun 2017 21:29:23 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3699127876 for ; Thu, 1 Jun 2017 21:29:22 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 55B9DC401F4 for ; Thu, 1 Jun 2017 23:29:21 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496377761; bh=hlO6XlhNBf1jIo9dECyKDZSpKHqjwVfUR5WdEFAnkM0=; h=From:To:Subject:Date:From; b=0qBr2UQ08C0MHt7u14tb2GG/rMDpufDQhsEzbk17zKA+H2IBVQ9hF96yv1Ofl4XoG 6slOLMCriTPbXWrE4PWoAWXvaRmIW1F/E/PTDOHBMpDTRVdJzepqX85YLSdV4I9l1e i4WUTR1bCIMhP5/AMjUhl23uxT79KBqRvGt9SitI= From: Scott Kitterman To: dcrup@ietf.org Date: Fri, 02 Jun 2017 00:29:21 -0400 Message-ID: <83146166.aPhNjP9IUJ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [Dcrup] References X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 04:29:24 -0000 Would it be appropriate to add http://www.kb.cert.org/vuls/id/268267 to the references to help explain why this update is needed? Scott K From nobody Thu Jun 1 21:49:11 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B55A127419 for ; Thu, 1 Jun 2017 21:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 YkZJzjjl9I6j for ; Thu, 1 Jun 2017 21:49:07 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15946127011 for ; Thu, 1 Jun 2017 21:49:07 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id w1so34990346vkd.2 for ; Thu, 01 Jun 2017 21:49:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6jdDh8YtZsvagLDtOxzpdJC1fa8LNUo+TRkexEgAwcA=; b=eey+89o99di28IpGPXYEpPbaY37T9FLRkjbzLiKC8HHp4qviiqb5NQDI8mDpnGawaC O5YLvtsU+q0OGPyK3w9L0TIx+BKc6fOo5BbWLGs2KYylBU6qR3n+XNctVj4vb6iH7eDM 0QofsHgNyn/T/g7692D0yFPl/ts34P0eib8Kk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6jdDh8YtZsvagLDtOxzpdJC1fa8LNUo+TRkexEgAwcA=; b=VQxmfYLRT19oma3bL9tb4yVQfJP/Zhg6OYGGBdlr/OW7vlolklSS4mnDNlf4PRnRwM A4/OIO7rYqDxh3HuTOnmH/wrLbCVWQf23ndFT9nBZXAoIvuzUB2pho5ceR5t35cvmO/P DDwaY6cgsvWnvB779RY4YHfG/VnPNxqgj6hyJz40DPiG2hURri53bsv8DkzqHQD6PYh3 HI2mEDqonnG8iw5mX3vbkYPKjRg2pZVUlXIp+9u6UdZnDInd0NmeuIFj+4Z0hLHqM+rO +sAJjM6Ln+BWCoYOOTUFzlPjsZcN6EW7vCTBSHXBmIlpisdBgV7K1AFQC28WAINaJ5w4 P5ug== X-Gm-Message-State: AODbwcAqaatfOITG03VLaoQsORGmbn7qWq/TWwFYFYP4nA/bYUdfp043 SrfrB/YCEQmoNYDUr6TTalnzC1aB+N2N X-Received: by 10.31.61.7 with SMTP id k7mr2611734vka.82.1496378946081; Thu, 01 Jun 2017 21:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.111 with HTTP; Thu, 1 Jun 2017 21:49:05 -0700 (PDT) Received: by 10.176.83.111 with HTTP; Thu, 1 Jun 2017 21:49:05 -0700 (PDT) In-Reply-To: <3745683.4zdJlR4cAU@kitterma-e6430> References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: Kurt Andersen Date: Fri, 2 Jun 2017 12:49:05 +0800 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114da1e287e7710550f2df6a" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 04:49:09 -0000 --001a114da1e287e7710550f2df6a Content-Type: text/plain; charset="UTF-8" On Jun 2, 2017 8:24 AM, "Scott Kitterman" wrote: On Tuesday, May 30, 2017 05:58:51 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DKIM Crypto Update of the > IETF. > > Title : Cryptographic Algorithm and Key Usage to DKIM > Author : Scott Kitterman > Filename : draft-ietf-dcrup-dkim-usage-00.txt > I think that this does not quite go far enough in shifting the algorithms and acceptable key lengths into an IANA registry to future-proof the spec and allow more rapid response in the case of exploit advancement. I'd like to see both of those pieces "out sourced" to a registry with updates to be driven by crypto-competent people. --Kurt --001a114da1e287e7710550f2df6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jun 2, 2017 8:24 AM, "Scott Kitterman" <sklist@kitterman.com> wrote:
On Tuesday, May 30, 2017 05:58:51 PM internet-drafts@ietf.org wrote:<= br> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the DKIM Crypto Update of th= e
> IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Cryptographic Algorithm and Key Usage to DKIM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Scott Kitterman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dcrup-dkim-usage-00.txt
> =C2=A0

<= div dir=3D"auto">I think that this does not quite go far enough in shifting= the algorithms and acceptable key lengths into an IANA registry to future-= proof the spec and allow more rapid response in the case of exploit advance= ment.

I'd like to se= e both of those pieces "out sourced" to a registry with updates t= o be driven by crypto-competent people.

--Kurt

--001a114da1e287e7710550f2df6a-- From nobody Thu Jun 1 22:35:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB33127058 for ; Thu, 1 Jun 2017 22:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 YSLKRNzPKuw0 for ; Thu, 1 Jun 2017 22:35:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3242A126D05 for ; Thu, 1 Jun 2017 22:35:15 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A9A80C402AE; Fri, 2 Jun 2017 00:35:13 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496381713; bh=TH3m+GRJ6Kb1XH0bK96PQI61Ngzo+wsMT3whXK98TZE=; h=Date:In-Reply-To:References:Subject:To:From:From; b=WI63AAo5AeKOzgr72kPzJzvRg8mgrEaUqi7PELh1uRWtli5/y2CtdTmTQW/gH+kbW +J8AGpu1Tege1+I341KIMU7ffa1X932Er/EbTsd4pvcx3KW/ZA+gk9fgwFLLmeT3iT RF3eTzoaPsZ8EEpcnCSSnaBTofBexU5bfp2OVnew= Date: Fri, 02 Jun 2017 05:35:09 +0000 In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:35:17 -0000 On June 2, 2017 12:49:05 AM EDT, Kurt Andersen wrote: >On Jun 2, 2017 8:24 AM, "Scott Kitterman" wrote: > >On Tuesday, May 30, 2017 05:58:51 PM internet-drafts@ietf=2Eorg wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories=2E This draft is a work item of the DKIM Crypto Update of >the >> IETF=2E >> >> Title : Cryptographic Algorithm and Key Usage to >DKIM >> Author : Scott Kitterman >> Filename : draft-ietf-dcrup-dkim-usage-00=2Etxt >> > > >I think that this does not quite go far enough in shifting the >algorithms >and acceptable key lengths into an IANA registry to future-proof the >spec >and allow more rapid response in the case of exploit advancement=2E > >I'd like to see both of those pieces "out sourced" to a registry with >updates to be driven by crypto-competent people=2E I think that belongs in draft-ietf-dcrup-dkim-crypto=2E =20 Once we know what the new crypto is, how it will be represented in DNS, an= d what key lengths are appropriate, then it will be easy to lay out a prope= r registry=2E When that registry is created, this document can serve as th= e reference for the initial values=2E Let's not draw the additional complexity of other than the minimal IANA up= dates that are already specified into this draft=2E Scott K From nobody Thu Jun 1 22:35:38 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40AC127698 for ; Thu, 1 Jun 2017 22:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3BdoETlO5sUT for ; Thu, 1 Jun 2017 22:35:30 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D94126D05 for ; Thu, 1 Jun 2017 22:35:25 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id j17so39334944uag.3 for ; Thu, 01 Jun 2017 22:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KvtkZTG9G/DAx0sYePX1UFyHuIENmSqjWcZdus9awMU=; b=SVU19cSL3i9+K7y8iCBxONvPf13fa22upK0X2LBIo45QqbkHlP0cGoq6IEDAi6j1j/ Cd6pIHrZ4fElWRK5LmxfB5PpJMxkL0Y4owzU/kZ/OF5Tjclwc/A5GWHU4S+nnaNw/+si StGQDMHXL/KDnGqkLVd5EGYfz8/3Gj+N2kSwxT1SFjQFwSue0/+vREKeatw+X81m+bHE Dq0DUtgMaCk1enmsDNhFDz90gLvXdalsB0DUTy966Ox4thxWoooSqNsYE3RoinBqW7tp dcKaN27DV4orKgE6IT4GAHXycVlv/mN2AZ+YXomf0xEeF8ww1c8/Pv5ntTeqNmpcQJv2 rTew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KvtkZTG9G/DAx0sYePX1UFyHuIENmSqjWcZdus9awMU=; b=n7co/0r0z+zNEJ//av4w+D8MIcTW15NqbpgB5l1vxdXjc9E6I9Xi/FWLwZZ+nXmtDd SMbxSMs1srtVrMF25qRJMWkmmNi3XDHJ4WhD+GQ8+rHd0YA7ygayvxBDPXRc+CL1HSFO 6UzgybQTfPDwLGgC3jSbymfA0YFFpSnx10f5XQYHz6X+2xj7ScFufaXKn1qZECm772K+ efoBjUJZiBtMse0y7pcUluUW+mn/afmPK5ZA8dwxCn4e8vf/4Y5UIOlWUqiJ5fxjiG5R Be8CKT0VN2g83hAyUUr8s8Mv+OvKqgdXdCADLwAr95AytmJXFZwQqk4C8urYEJs3hx8O sbbw== X-Gm-Message-State: AODbwcDMeAgEKPUQPE4hkOaOxUEW1NhM2CqnYNrmlVlREtsJlogx07Ir /5d2S7pmp/9KxfYns23px1ybXGdMvb3G X-Received: by 10.176.81.4 with SMTP id e4mr2925514uaa.33.1496381725106; Thu, 01 Jun 2017 22:35:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:35:24 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:35:24 -0700 Message-ID: To: Kurt Andersen Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1914902c67140550f3858d" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:35:32 -0000 --94eb2c1914902c67140550f3858d Content-Type: text/plain; charset="UTF-8" (sans chapeau) I realize I have some threads to catch up on, but... On Thu, Jun 1, 2017 at 9:49 PM, Kurt Andersen wrote: > I think that this does not quite go far enough in shifting the algorithms > and acceptable key lengths into an IANA registry to future-proof the spec > and allow more rapid response in the case of exploit advancement. > > I'd like to see both of those pieces "out sourced" to a registry with > updates to be driven by crypto-competent people. > This notion feels weird to me. What would such a registry look like? Are there any other protocol registries that contain just a list of key sizes or lengths of things currently approved by the community? What would the update rules be on such a registry? -MSK --94eb2c1914902c67140550f3858d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(sans chapeau)

I realize I have some threads to cat= ch up on, but...

On Thu, Jun 1, 2017 at 9:49 PM, Kurt Andersen <kurt= a@drkurt.com> wrote:
I think that this = does not quite go far enough in shifting the algorithms and acceptable key = lengths into an IANA registry to future-proof the spec and allow more rapid= response in the case of exploit advancement.

I'd like to see both of those pieces "out so= urced" to a registry with updates to be driven by crypto-competent peo= ple.

This notion feels weird to= me.=C2=A0 What would such a registry look like?=C2=A0 Are there any other = protocol registries that contain just a list of key sizes or lengths of thi= ngs currently approved by the community?=C2=A0 What would the update rules = be on such a registry?

-MSK
--94eb2c1914902c67140550f3858d-- From nobody Thu Jun 1 22:40:51 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBB6127698 for ; Thu, 1 Jun 2017 22:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 4IuC2mmQ2sRy for ; Thu, 1 Jun 2017 22:40:49 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEA0127078 for ; Thu, 1 Jun 2017 22:40:49 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CFA8BC402AE; Fri, 2 Jun 2017 00:40:48 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496382048; bh=Inqa3ZrYJ9kvf3bF24ynoNBG94iwR17Yml8oMaP2Kag=; h=Date:In-Reply-To:References:Subject:To:From:From; b=jhHWMbiE60112XCXfqyEv2GBcO7230bs0DdQ4dpyRQ3vQaQG/Jyj9YNvC3KW0Lzuy ab5lZxwdydNaZRoLCW06hDDMyTcgupxT0yC/BFfZUt/8SLSleAZcBzD/5fiqCaz0v9 w9WGLZ1rGpcYGohz0+6h8M1GZ39ArjCcb1wNyyqE= Date: Fri, 02 Jun 2017 05:40:48 +0000 In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:40:51 -0000 On June 2, 2017 1:35:24 AM EDT, "Murray S=2E Kucherawy" wrote: >(sans chapeau) > >I realize I have some threads to catch up on, but=2E=2E=2E > >On Thu, Jun 1, 2017 at 9:49 PM, Kurt Andersen wrote: > >> I think that this does not quite go far enough in shifting the >algorithms >> and acceptable key lengths into an IANA registry to future-proof the >spec >> and allow more rapid response in the case of exploit advancement=2E >> >> I'd like to see both of those pieces "out sourced" to a registry with >> updates to be driven by crypto-competent people=2E >> > >This notion feels weird to me=2E What would such a registry look like?= =20 >Are >there any other protocol registries that contain just a list of key >sizes >or lengths of things currently approved by the community? What would >the >update rules be on such a registry? Great examples of the kinds of questions that would take some time to answ= er and thus why I think this document, which is supposed to be the quick, e= asy bits of the update isn't the place for it=2E Scott K From nobody Thu Jun 1 22:41:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5310E127698 for ; Thu, 1 Jun 2017 22:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 fQRaaK0CS7Ri for ; Thu, 1 Jun 2017 22:41:14 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F012B127078 for ; Thu, 1 Jun 2017 22:41:13 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id a136so23231428lfa.0 for ; Thu, 01 Jun 2017 22:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=imOo7hYC3haM/r+zKDuXU7WnUuCvnEassigflE70Jp4=; b=VSnPMjubX2LLBaUE26hgR1ALCSd5R7lklaiAjmwBKG78R/9M4ZGU1FiF2zDY/b27B4 EnlLH5nCrDl9QLfWV5Z5uYler3wSh4zmJZfhARsowI2Lvp8o6p/ghgHJEDt/GUML7mnT N+9oWX9lrPDV8lBei5Yuc/p421MUVkcit+m/KCiOTMcwxBVVdgx1GqBY2mMVy1cKMM0k Ih+oGL9i25B/bOJb5hYIkClZ0YOA217gvsvRhm2xobJI8QZ4m48fq4sByzlGKTFxiuAa HZNZd8OBXXEalpTIAMY5T6bET9xXrgnthIfVVuPOtKceVc7tgIqnvGUBTkW7KB5E7XD0 ZyhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=imOo7hYC3haM/r+zKDuXU7WnUuCvnEassigflE70Jp4=; b=OuHVq+oUO6pP4QrbD65x5Ry1KKb3rhUmUntIVPSXO5t3YzQBSQZL2z4dPof+EeiuXK 8rxwXNMDtZKrUfHk8bswupxgPdRky73HjjihUmNF5jzANVk87M+tRs6elBUmgrOKdHzX sK5iiuJbmJs6h1CKzKnZRKksvQkr+Ca6avPan83nN1SvyVXbndv67U8v0Sh9s2OtjLiF C5St0THdelev92QNuq1OF6d8G0rGd1Ic4hxqTGwEHtRiev1REJ2g0zoEmGsYmAQmGtlJ rs+Wop34O4/eUbNY7T8TB3uIlIJ5oaBgV2+4vJ8dPwxhAVTrdHFBvwcW80P/x3D3qoER 1j+A== X-Gm-Message-State: AODbwcBP0AixIjf+iTi+y8YKtz8lXnhJLgxbpMqY04ILES5BPY/N1/Zy AzFBwYIZLvO5uvVseu22BSovjhbrtyKN4OA= X-Received: by 10.25.145.66 with SMTP id y2mr1453577lfj.19.1496382072157; Thu, 01 Jun 2017 22:41:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Thu, 1 Jun 2017 22:41:11 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: Martin Thomson Date: Fri, 2 Jun 2017 15:41:11 +1000 Message-ID: To: "Murray S. Kucherawy" Cc: Kurt Andersen , dcrup@ietf.org, Scott Kitterman Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:41:16 -0000 On 2 June 2017 at 15:35, Murray S. Kucherawy wrote: > This notion feels weird to me. What would such a registry look like? Are > there any other protocol registries that contain just a list of key sizes or > lengths of things currently approved by the community? What would the > update rules be on such a registry? TLS does this for cipher suites. The policy there is to allow registration of entries with a low bar, but to require a higher bar (Standards Track) for entries that mark the entry as "recommended". See https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates#section-7 From nobody Thu Jun 1 22:41:45 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372F1127698 for ; Thu, 1 Jun 2017 22:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XE4IX_1fpARz for ; Thu, 1 Jun 2017 22:41:43 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C49D7127078 for ; Thu, 1 Jun 2017 22:41:42 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id x47so39443666uab.0 for ; Thu, 01 Jun 2017 22:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LR9pksm2DX4ob4D/0Y5mSh3LnrofS2ebUAH9vQYpM1A=; b=LXC0/XJ+rbXyese44u90l01yW0JhuEtnwt+xMqlUirdRMMku3oiEdxGxZEt32DfevA O5BTc7ZN9kZJIWoFKbzIUo+vxuiuNmkoX7XmyCHtm7210+jQ2EUVjFdXW5gGg1xLY75n JTbrpQuTUsaUjH6ovaBeHh8SWG1PNOywIB/1gJqzQh+WEH4Dr4s51qpJPdhD/S5E9n+y nfgJEUX8ndFQx8wNk9QaoUmimxP/zXDYeoISV2YsQgbnQNScqPWK9ot4Yph1zTNGpG+3 dc7SCO1rUGkAzqEIjJqTqgfXsznlMsSmlxm/iV2h04XitrNxU0BGy6EexPL5Y+m5vH5X qEXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LR9pksm2DX4ob4D/0Y5mSh3LnrofS2ebUAH9vQYpM1A=; b=PlRhx5fs1LyXMqHz571OprsIce0RvC9WRchOkhXRrcZuslji4RtJiQBdFDqqturUC2 ItBsdhfkrHSPAOCDnsIqabTS8sF42Zg96cyFPk8Qt3NjPZDjxGlTBa1iUYk0jJVo0En3 eYqVgH1auNVC2R/L1T+7RQYW0ZKUqjOC4Ja2/8tBjRWPkm4eHa5VKgiZaoa4zB5PWfvp ovInZx6QQifmA1+HqS0ykxzI1Ug3f3t9q+hfO7EN7aXugskL5NE79w8s6ZXKpfhNiD3v plKGQ+Fei8bVwMq9uIqb8dzMONUUAlN7RDSyE+Kpc508SfQwL8wo+64A2bgR87nPf23l uCMw== X-Gm-Message-State: AODbwcCbB4XY+eGfiuhEkS/nCQSn6GLOclv5muPiBqurvpzez0Azrn5c P9JvYUFdWsjZI1Z5Sp8aX87D2MIs3+yI X-Received: by 10.176.75.142 with SMTP id v14mr2904048uaf.14.1496382101957; Thu, 01 Jun 2017 22:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:41:41 -0700 (PDT) In-Reply-To: <3745683.4zdJlR4cAU@kitterma-e6430> References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:41:41 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f40304362654a2b18f0550f39b5f" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:41:44 -0000 --f40304362654a2b18f0550f39b5f Content-Type: text/plain; charset="UTF-8" As a participant only here: On Thu, Jun 1, 2017 at 9:24 PM, Scott Kitterman wrote: > 1. Changes signers SHOULD sha-256 and verifiers MUST support both sha-1 > and > sha-256 to signers/verifiers MUST sha-256 and MUST not sha-1. It does > nothing > about adding anything new as there will be other documents for that. > > 2. Changes signers MUST at least 1024 bits for long live keys (long lived > is > never defined) and verifiers MUST support 512 bits to 2048 bits to signers > SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers MUST > support > 1024 to 4096 bits. > I think my only issue with the document is the use of RFC2119 language about key sizes. I'm totally comfortable with saying what implementations have to support, because that goes to interoperability, which is what I understood the RFC2119 nomenclature to be for. But I'm not so sure about its use to talk about key sizes. More specifically: DKIM interoperates just fine with 512 bit keys or even smaller; the protocol itself doesn't break. The choice to use smaller keys is a risk issue, not an interoperability concern. We should certainly call that out firmly, but I'm iffy about the MUSTard here. Are there other standards track documents that do this? -MSK, hatless --f40304362654a2b18f0550f39b5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As a participant only here:
=
On Thu, Jun 1, 2017 at 9:24 PM, Scott Kitter= man <sklist@kitterman.com> wrote:
1.=C2=A0 Changes signers SHOULD sha-256 and verifiers MUST suppo= rt both sha-1 and
sha-256 to signers/verifiers MUST sha-256 and MUST not sha-1.=C2=A0 It does= nothing
about adding anything new as there will be other documents for that.

2.=C2=A0 Changes signers MUST at least 1024 bits for long live keys (long l= ived is
never defined) and verifiers MUST support 512 bits to 2048 bits to signers<= br> SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers MUST supp= ort
1024 to 4096 bits.

I think my only issu= e with the document is the use of RFC2119 language about key sizes.=C2=A0 I= 'm totally comfortable with saying what implementations have to support= , because that goes to interoperability, which is what I understood the RFC= 2119 nomenclature to be for.=C2=A0 But I'm not so sure about its use to= talk about key sizes.

More specifically: DKIM interoperates just fi= ne with 512 bit keys or even smaller; the protocol itself doesn't break= .=C2=A0 The choice to use smaller keys is a risk issue, not an interoperabi= lity concern.=C2=A0 We should certainly call that out firmly, but I'm i= ffy about the MUSTard here.

Are there other standards tra= ck documents that do this?

-MSK, hatless
<= /div>
--f40304362654a2b18f0550f39b5f-- From nobody Thu Jun 1 22:45:51 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37FE127775 for ; Thu, 1 Jun 2017 22:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 gjjBaEJtN2Lr for ; Thu, 1 Jun 2017 22:45:49 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C47126C0F for ; Thu, 1 Jun 2017 22:45:49 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id c184so33060436lfe.2 for ; Thu, 01 Jun 2017 22:45:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zVIn3sz5O9Bz+mlda+x0Ho8KyUSmv1ftHYvWHEUCTb4=; b=Qca9ktBgAuwKQ4rPkIOAklfazOXE6YVVF9+7HQyPqQt23c4BcJK39LtkfD01ZT83w4 YBtZIdFYWpkzGAZQSA4AMZ+/VV6LGa0weiGHNswHGjSjc82frmDfXy1mYTIizL5i+73f Rpp6kHsJ959oxAR4c+93wPOjm8uwRn5wtrGWt9LQHio8tIQX6tH0FH/751FsEfQ4Ty6R 2TkG7khz3DFSQfaPZCEeHFNO1V7F+8FCXB9VsH3a3FKLdnm1PnS8Cyk+XpSptCZYrVZS ZSIbc5I/UNZtm118NFU55/CtE9H2wFnFISlkObVFCZEmhD+WpZ9R68g/fm8KFv1ILxZP ApTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zVIn3sz5O9Bz+mlda+x0Ho8KyUSmv1ftHYvWHEUCTb4=; b=sP6GVa635NB0bHXr/39pxw7sI8DZge86QO/UBIJYY5QJ9JUVSb31tC+N5h6749r3MB CeE4cfwr5phx16Sd6vSHOgZevs7GjawD17p0LrpJCL8jGbNIjs99CzNWiH87V4zpQq65 pfuOdnCFBTKjPvXOi/l1hx8YUKilYdps5T8biVXC+imG5KUoCaLygwiG4+AotJVLeOJE xiJIOcJscLBIRjNkRo4uPfE2q+zjU1oobhUPf/d9AE2jt89zu4A7Mnne6kpE13zBTMpb z2v8s9dYpm041/kp36m5mnpUek54xzyUDvs++eiZzOsCrsem6KnUxwy6x0Oc/7jwYGLM RsWA== X-Gm-Message-State: AODbwcD2cSNcpvhDK8cNsJXzzDGV9FOeL03mZ/uT97LhyocwWyQ+KTcQ CbJ22Vrd3Qa4Op9Tj3ifK2PVYvlHxQ== X-Received: by 10.25.213.66 with SMTP id m63mr1687767lfg.50.1496382347467; Thu, 01 Jun 2017 22:45:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Thu, 1 Jun 2017 22:45:46 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: Martin Thomson Date: Fri, 2 Jun 2017 15:45:46 +1000 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:45:51 -0000 On 2 June 2017 at 15:41, Murray S. Kucherawy wrote: > I think my only issue with the document is the use of RFC2119 language about > key sizes. I'm totally comfortable with saying what implementations have to > support, because that goes to interoperability, which is what I understood > the RFC2119 nomenclature to be for. But I'm not so sure about its use to > talk about key sizes. RFC 7540 does just that. The recent trend is to signal fixed key sizes for algorithms, which does the same thing in a different way. For example, https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-protocol#section-3.3 That boat sailed for DKIM, but it is another way of applying MUSTard to key sizes. From nobody Thu Jun 1 22:46:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7D7126E3A for ; Thu, 1 Jun 2017 22:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SGrFRg2IlTtc for ; Thu, 1 Jun 2017 22:45:53 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD44126DFF for ; Thu, 1 Jun 2017 22:45:53 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id j17so39420524uag.3 for ; Thu, 01 Jun 2017 22:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VqB/+cljQqPYdVecoW17mmhoV0TZPUXXanY3YzsubPk=; b=Mz+ztszahhMD/tn5GbMgIyvybn/wN73SWj71whmA168xWGDvJZKvZru/ejEJ/5wBT9 wYga0EojeONgUr3MiLEP48vCGdu6Iddr+ntOzkUHoY5EKlc6KV8dxtIyOPFiLnb6ZYsa wB1v9FcMJMj1qt0GwsZe1UqC9Pa0rzmKc1dJJGOG3PZi8JRLyJMpNDa9KK+f2QtGP0ZY h2rF6bLyz80lyVYsgDnsdSISE2qwqH5NccapCbCYprPre6svw72hvDHjkvYddw1w2/zO 9/+sLiGLQbnHJ4U81N0NEWQ9XsH16XyZYZuS8tqzdaREOtdoGSKeyNoOA/vOrBPg/lDB 5qEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VqB/+cljQqPYdVecoW17mmhoV0TZPUXXanY3YzsubPk=; b=eO5pwLAsW/4EKgkbVONxZI2rAc4mYuLtj1LT/O2BvFD1EVK3tRvDuB+UAsiKJXg7eO AzGS/gElRbDUuWOIhCPnXvzweY/q8wv/ame9LRSQZ+l5Z5J0QgzZ1vdH4HzJZYIrzCqi OBdsxilcF/Pk7KiQ4ZRa2MEm8GF4fbc5/UmOSmLaDnUA9i2QJOW3tSU71AKEx8FpsZHN gW6HnXotBNNvQ0BBrKKake/R6w5cy4EHiz9R2tXpQzSm6hO79byf0hp4x3c/ZJ4F0qnO LHXCqX459TW/zFRKWcRG2RfvToVeToQecETf/y4HLn7jDiJ2hBfjhnBNyNZQmLNExAgC P7Ng== X-Gm-Message-State: AODbwcAVx1XVW4Kf+FB+7NBLYtB1urK7Z3Mo7wlM/TiR05GWmR4TInwx ExZgrgM1MelMUVCCvpUtGvIfxZ3mDg== X-Received: by 10.176.77.173 with SMTP id s45mr2954922uag.29.1496382352535; Thu, 01 Jun 2017 22:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:45:52 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:45:52 -0700 Message-ID: To: Martin Thomson Cc: Kurt Andersen , dcrup@ietf.org, Scott Kitterman Content-Type: multipart/alternative; boundary="f4030437a0709235d30550f3aabe" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:45:54 -0000 --f4030437a0709235d30550f3aabe Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 10:41 PM, Martin Thomson wrote: > TLS does this for cipher suites. The policy there is to allow > registration of entries with a low bar, but to require a higher bar > (Standards Track) for entries that mark the entry as "recommended". > > See https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana- > registry-updates#section-7 > So in our context, we would register a pile of entries that look something like: rsa-sha256-with-1024-bit-keys rsa-sha256-with-2048-bit-keys rsa-sha256-with-4096-bit-keys ...and possibly numerous other size-specific entries, each referencing a defining document? We already have a registry of supported signing algorithms, of which "rsa-sha256" would be the only valid one after this is published. So there would really be just a registry of permitted key sizes. -MSK --f4030437a0709235d30550f3aabe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 10:41 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
TLS does this for cipher suites.=C2=A0 The policy there is to allow=
registration of entries with a low bar, but to require a higher bar
(Standards Track) for entries that mark the entry as "recommended"= ;.

See https://data= tracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates#se= ction-7

So in our context, = we would register a pile of entries that look something like:

=
rsa-sha256-with-1024-bit-keys
rsa-sha256-with= -2048-bit-keys
rsa-sha256-with-4096-bit-keys

...and possibl= y numerous other size-specific entries, each referencing a defining documen= t?

We already have a registry of supported signing algorithms,= of which "rsa-sha256" would be the only valid one after this is = published.=C2=A0 So there would really be just a registry of permitted key = sizes.

-MSK
--f4030437a0709235d30550f3aabe-- From nobody Thu Jun 1 22:51:52 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC8C126E3A; Thu, 1 Jun 2017 22:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: superuser@gmail.com, dcrup@ietf.org, dcrup-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149638271023.31792.9812546546101995943.idtracker@ietfa.amsl.com> Date: Thu, 01 Jun 2017 22:51:50 -0700 Archived-At: Subject: [Dcrup] dcrup - Update to a Meeting Session Request for IETF 99 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:51:50 -0000 An update to a meeting session request has just been submitted by Murray Kucherawy, a Chair of the dcrup working group. --------------------------------------------------------- Working Group Name: DKIM Crypto Update Area Name: Applications and Real-Time Area Session Requester: Murray Kucherawy Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 20 Conflicts to Avoid: First Priority: lamps cfrg jmap dmarc dispatch People who must be present: Rich Salz Alexey Melnikov Murray Kucherawy Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 1 22:52:32 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E316126E3A for ; Thu, 1 Jun 2017 22:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 m4DWKybT8OB3 for ; Thu, 1 Jun 2017 22:52:29 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00874126DFF for ; Thu, 1 Jun 2017 22:52:28 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id u10so39561115uaf.1 for ; Thu, 01 Jun 2017 22:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pKuNHt5p6GCciSoHvVb0KQ2mcwXzhI3tqLHa9VyUBFs=; b=VichKlrEOHuMdYac8Jt+VhtYpJN62lOrIxSICqKH24PTVMGWPCNDoLf17RwPmY4+0k 3nCt8GHhhbBlSPMigMCx8eF1EyqTKBga743//QmSWBfnXD38Ps7237zDjRNO04E3VBUw c+BMGGGEvqIuK+LEaIPPUUl2P2dnbNRKqPaZnPqpYK3kRMIAAqwIfndUde/0xoX752CH ON0+NaJraX1dWbfLYKIlyYLNnBr3kqxNNeNt7X4Jxagl8KnleWIO73e/v8bKn2ATJkud m0LhyvaBmMU3XvahkpfptTtEDaHMlB/DaWbqYjOC+eKvv6bStbGgozFNU6hNNd3LPdUS kXAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pKuNHt5p6GCciSoHvVb0KQ2mcwXzhI3tqLHa9VyUBFs=; b=WHMAmJ+EL5cCxG8SfqqxTSfHXuYgVBJi32MK0HYZhPRhZs9Q69pzk3fK3zCW6xw/6N lnP0PScxnJH0aBbe04srjnhKn8yd8XKXbAJ7tnAAK/4qhC2U+V8B1ElnNZ8tVfPCBR+b JfNFypUSFve7KbAuG7zbtd9UoVTv6v893NV+OYzhNdp2vMm3V3fmXeIIQqDMc2AdCv8P iDAz+oK+5w0Ith4UwDjv4IWJDDLN6IuWVt/hqF2VbHfZjWRyKQeRRFjDbCpS8w6/2/+s XVgAUmIT40x4zp+sQOwZX86iSFipX/cD7VCSbusv0MtoXdfP9BoMGtnpHC5k2Dvn4PFe EP2w== X-Gm-Message-State: AODbwcC9bdnjPgOFj9W1MU45+ycLVItZBzsbLgmCBzOEaGO2OL/8ogG+ HO25Mf2XO9xovLoF1c9VmnaJ9JVkgQ99 X-Received: by 10.176.2.181 with SMTP id 50mr1361601uah.36.1496382748174; Thu, 01 Jun 2017 22:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 22:52:27 -0700 (PDT) In-Reply-To: <83146166.aPhNjP9IUJ@kitterma-e6430> References: <83146166.aPhNjP9IUJ@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 22:52:27 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113ce8d22730720550f3c2f9" Archived-At: Subject: Re: [Dcrup] References X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:52:30 -0000 --001a113ce8d22730720550f3c2f9 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 9:29 PM, Scott Kitterman wrote: > Would it be appropriate to add http://www.kb.cert.org/vuls/id/268267 to > the > references to help explain why this update is needed? > Sure. --001a113ce8d22730720550f3c2f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 9:29 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
Would it be appropriate= to add http://www.kb.cert.org/vuls/id/268267 to the references to help explain why this update is needed?
=
Sure.
--001a113ce8d22730720550f3c2f9-- From nobody Thu Jun 1 22:55:37 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2396E127B52 for ; Thu, 1 Jun 2017 22:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 6ssf8cVP1B-o for ; Thu, 1 Jun 2017 22:55:35 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEE9127A90 for ; Thu, 1 Jun 2017 22:55:35 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 95EAEC402AE; Fri, 2 Jun 2017 00:55:34 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496382934; bh=3ISTn0Qie13EdrjuH6n6t5kDEGkEikme4W2UIdgJD3E=; h=Date:In-Reply-To:References:Subject:To:From:From; b=jBRpGfTfyN05OHNIRW0i0KOUmU544/XqO1sT+tHeazQeO05WfRbSMy6UQCaUSp8mD iRAhXo1oktUwMkSbaW2zIg9MOcWqw8cAxAe65HgtlKayoZ4uE8Y9qYWpKOcPQfFnsD ewi2Fz+XlIaW5N14PqCAAYj6u2m/byCnCUTjJNI8= Date: Fri, 02 Jun 2017 05:55:22 +0000 In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <64542E13-8932-4810-9C4B-388417FD7637@kitterman.com> Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:55:36 -0000 On June 2, 2017 1:41:41 AM EDT, "Murray S=2E Kucherawy" wrote: >As a participant only here: > >On Thu, Jun 1, 2017 at 9:24 PM, Scott Kitterman >wrote: > >> 1=2E Changes signers SHOULD sha-256 and verifiers MUST support both >sha-1 >> and >> sha-256 to signers/verifiers MUST sha-256 and MUST not sha-1=2E It >does >> nothing >> about adding anything new as there will be other documents for that=2E >> >> 2=2E Changes signers MUST at least 1024 bits for long live keys (long >lived >> is >> never defined) and verifiers MUST support 512 bits to 2048 bits to >signers >> SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers >MUST >> support >> 1024 to 4096 bits=2E >> > >I think my only issue with the document is the use of RFC2119 language >about key sizes=2E I'm totally comfortable with saying what >implementations >have to support, because that goes to interoperability, which is what I >understood the RFC2119 nomenclature to be for=2E But I'm not so sure >about >its use to talk about key sizes=2E > >More specifically: DKIM interoperates just fine with 512 bit keys or >even >smaller; the protocol itself doesn't break=2E The choice to use smaller >keys >is a risk issue, not an interoperability concern=2E We should certainly >call >that out firmly, but I'm iffy about the MUSTard here=2E > >Are there other standards track documents that do this? I don't know, but it seems to me that if a signer uses a key length that r= eceivers will consider invalid, you've absolutely got an interoperability p= roblem=2E =20 It's no different than saying MUST use a particular crypto algorithm=2E I= t's one of the parameters that if the signer doesn't use something that the= verifier supports, there is no interoperability=2E Scott K From nobody Thu Jun 1 23:05:57 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11225127B73 for ; Thu, 1 Jun 2017 23:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kN-vTPy3fHy0 for ; Thu, 1 Jun 2017 23:05:54 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72815127137 for ; Thu, 1 Jun 2017 23:05:54 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id a136so23446916lfa.0 for ; Thu, 01 Jun 2017 23:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xt9PV575OHJe/uT+WFjM5MdkAN+iyXrgkVpi34LPfNg=; b=CjzEcgZIFroSYwOo1jUxLyL5gTPdD/IEZOzA6D2xHHwtkfbdgkUvB1bbvItTPKsdTN pid09Bp36z0axn95MPDGPCcTsPHU/PI+5b9qzN/ebK1F++x6dr+yr83q4nmaVhzSw54Y KVwj6pGDhsVYY/3TSuUDU14oYLhxYR1hu8KwtrcYkHzrbYD+0ZlOjpCFMTzUL9J4MKrg CjTqCWQZ0Gq13+WmfSv6Ki+/WX74lifGvi3+KoKjhGb+pyc//iF5WwAU1NesTvpe2LFE n/GmG0SPeALYv2fWFog+VxCvLkQ9ih3sslSWpVio9Von8WMmDM9RwR4MNwABO7zzo2/i L7EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xt9PV575OHJe/uT+WFjM5MdkAN+iyXrgkVpi34LPfNg=; b=P/ne5HgSjb/FTzW5GnauWEEE7JcqmJQQAz2tKHFFwrbTez2TwYNDZ7Krq/gF7DzZUw Jn2hwa7/ICrmblulc6gnOWHymmPPX1wph74oQP1vi9P6bR3GtkMsQUSJJc56sX+dXnkm wBDdCE3hDVaOgNS7yskcm2kqJmIdNS1J3GD1vvyWO/cCkI1KFfFuV0XFy36K4hglsrp0 X5R50VgJMq14Bp1+rb4PKzEDLA1xRyWaMhNLXes27of7joaSEkY5BKmo3o0YsaD/Rq3J pFX+cS+aV2VAX7PaGUPkVZVHKssNm94c0TqdZCLBl9MX1zCFXXYkmndRDRAD2Enpmpn2 WqVA== X-Gm-Message-State: AODbwcBpg0vREUuFsCu2EAac0JF8Q6FiJQwfE0QD34oSFR5eD9bYg5Uz Od2+9h0L8L13JoEg6GLi85MdGumW7g== X-Received: by 10.25.201.145 with SMTP id z139mr1724716lff.172.1496383552763; Thu, 01 Jun 2017 23:05:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Thu, 1 Jun 2017 23:05:51 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: Martin Thomson Date: Fri, 2 Jun 2017 16:05:51 +1000 Message-ID: To: "Murray S. Kucherawy" Cc: Kurt Andersen , dcrup@ietf.org, Scott Kitterman Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 06:05:56 -0000 On 2 June 2017 at 15:45, Murray S. Kucherawy wrote: > So in our context, we would register a pile of entries that look something > like: > > rsa-sha256-with-1024-bit-keys > rsa-sha256-with-2048-bit-keys > rsa-sha256-with-4096-bit-keys > > ...and possibly numerous other size-specific entries, each referencing a > defining document? Nah, you already have a generic codepoint for just "rsa", so keep that. ed25519 will come with a fixed size, and maybe anything *new* should. I'm just pointing to a trend that supports the notion that standards can choose key sizes. After all, if you don't standardize on a 513-bit rsa key, then you can't signal and use it (and everyone wins, because that would be too small). From nobody Thu Jun 1 23:06:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520E01293E4 for ; Thu, 1 Jun 2017 23:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 g-nj-nZ0Z-T3 for ; Thu, 1 Jun 2017 23:06:19 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17869128792 for ; Thu, 1 Jun 2017 23:06:17 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id y4so39579836uay.2 for ; Thu, 01 Jun 2017 23:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6SYfNt/KAqQmIIMoQA28VMs7YEQGm+D5iv3n3vtJqMU=; b=fZABzUTZ1et3n9c/x1S3Dh2iZZmKYE0Gz34e9g9xBSihA+BQqfoCI2gqcIY4mhpYaP r1Gymew+x9iJkXsW0poNKreme9h7Mraue/N7PpTKBOnasvDjQ8c2uNyqUP3NtVOxzmCJ liXDm1fb/o/5BNVru45cC6vDc2E1e4uHYIRyVM+NUpjtxQff1rQLGRcQBHJ3AhIZ1DHh 7ppTCsK2kzPo0UZWq+lj2aBtYHNTvoqBa2AtTL+j+9Y8aY/428VwN4gjRnGEfTvKX0OJ wV+HKqrYn36tGvX/QUz93CP0ov6j8URSo84UzSfORiUqbuRi8NM0KDCCU10DLalnI+Ih x+/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6SYfNt/KAqQmIIMoQA28VMs7YEQGm+D5iv3n3vtJqMU=; b=kJDOyCqDsHrXGOlM2MmYOue9dDrUO4d6C2Q19+gD0UzaRou4q23Sym4EyvpnBMErDt Z7tWGZly/iYtAY0Vk6twuM/4a43UQYYWzh/RQNXVttEaVBjNdFXPCewJhAPBaFYhft1q tYchuTuY7LIfpAFHpZdRwv96prmIz4Qkuaj3X7MF6kAPHZVXLWNw+adepX8VwoJxiZAX y9oxQquHaOVijQion5mT1Mg5OLXGlefZZRk7ROyPjcXOxX3sbetBtx72WHH705gCswfy Zt8kPzDpVF83ZatSln59FY6aHulSiMUoYatzLFhqu7U/oamj9yE+h+EQmkKdWQojaL8A zoFg== X-Gm-Message-State: AODbwcCyJXvbE0giwxq4FHie3aoZDy4TW6I6H7ASz5K53HMiVMn5mAC1 I8Mt4tWS6xBNK9WlqDkYYX9f0bHcQw== X-Received: by 10.176.69.65 with SMTP id r59mr2936671uar.80.1496383576222; Thu, 01 Jun 2017 23:06:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 23:06:15 -0700 (PDT) In-Reply-To: <64542E13-8932-4810-9C4B-388417FD7637@kitterman.com> References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> <64542E13-8932-4810-9C4B-388417FD7637@kitterman.com> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 23:06:15 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b9898823d0c0550f3f35f" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 06:06:20 -0000 --94eb2c0b9898823d0c0550f3f35f Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 10:55 PM, Scott Kitterman wrote: > I don't know, but it seems to me that if a signer uses a key length that > receivers will consider invalid, you've absolutely got an interoperability > problem. > You can do this in OpenDKIM today with a configuration setting. That's perhaps why I'm asking this question; to me, today, it's a local policy decision, not one that's demanded by the implementation, which means it's not truly an interoperability issue. It's no different than saying MUST use a particular crypto algorithm. It's > one of the parameters that if the signer doesn't use something that the > verifier supports, there is no interoperability. > I disagree. RSA works fine even with tiny keys. It's obviously not smart to use RSA that way, but publishing a document that says tiny keys are bad doesn't mean RSA breaks when you use them. It interoperates just fine. We're establishing an artificial interoperability constraint on RSA here by saying keys must be at least X size to use them with RSA in the context of DKIM. I don't disagree that this is the right thing to do, I just want to say it the right way. I had never seen the examples Martin presented, and perhaps they're precedent enough. -MSK --94eb2c0b9898823d0c0550f3f35f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 10:55 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
I don't know, but i= t seems to me that if a signer uses a key length that receivers will consid= er invalid, you've absolutely got an interoperability problem.

You can do this in OpenDKIM today with a config= uration setting.=C2=A0 That's perhaps why I'm asking this question;= to me, today, it's a local policy decision, not one that's demande= d by the implementation, which means it's not truly an interoperability= issue.

It's no different than saying MUST use a particular crypto algorithm.= =C2=A0 It's one of the parameters that if the signer doesn't use so= mething that the verifier supports, there is no interoperability.

I disagree.=C2=A0 RSA works fine even with tiny = keys.=C2=A0 It's obviously not smart to use RSA that way, but publishin= g a document that says tiny keys are bad doesn't mean RSA breaks when y= ou use them.=C2=A0 It interoperates just fine.

We're establishin= g an artificial interoperability constraint on RSA here by saying keys must= be at least X size to use them with RSA in the context of DKIM.=C2=A0 I do= n't disagree that this is the right thing to do, I just want to say it = the right way.

I had never seen the examples Martin prese= nted, and perhaps they're precedent enough.

-MSK
<= /div>
--94eb2c0b9898823d0c0550f3f35f-- From nobody Thu Jun 1 23:12:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7A512944C for ; Thu, 1 Jun 2017 23:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wjAlqKg7pbf1 for ; Thu, 1 Jun 2017 23:12:00 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79AB3127B52 for ; Thu, 1 Jun 2017 23:12:00 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id w1so35577135vkd.2 for ; Thu, 01 Jun 2017 23:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+iPd/AMXmRApBm43iC0C2dLTMqgOd36WVlqnjSFIhl4=; b=VCk+7//xB8esl3kuyCsNok4n65tDMAAwTxorZ6NRT0lQZLflnZT+hnw8VVtNL6Jvk4 /w8Av3xGVqO/e5z8wfRebbvovxqvENI0l5WPcjWrNzSr8yx4TOsRM0xrog0U+stfKmTL rIgztoKlxY+eIkxEYX5ZlNk5unEX2UYYVhtahwPVkPZycwm/mY0DUN75OpSboo6Rd2bm M1NwkQ3WaRyojWBcd2qTTyXuq4kWY/A/aPNMYPls0Z7iHstaARyCejfguk41Zp4KM4u6 6EmR9jZnSsyDCdAPdd4SO92Y5DzvZ3Ir8/Olb7X1oYBa6Elunl8ThyKHuYcCRQEBm4h/ bFCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+iPd/AMXmRApBm43iC0C2dLTMqgOd36WVlqnjSFIhl4=; b=K2GzJnGycSOzPUjilICO3uFdPYDyt0Iygul0YdJ3ZmPQZiBndJfk3Ow00EPH9gIm+G KRQKARBkLUylb75RzXDH2nwnAubllepIgMB+7syLiK3Uhw8mGPoXMD/WExfwi8BnW9Nl kcvFaqdOmd/qTJENdGuKmAAQVXn8WO990OlpEDRdri0jmWACwrcet7JgN0QwzOFqaAZC kl4/T1G6JUKF4wkUTuW4U3qo1wE1EYEuBwo2BIThPnbaLP+FFb6j4TAliwEUEsRZu27a vvm1OMnBiNvPwGS6vK7fAZGn9MIWRaCk5ivh+N5+w8kYrDXVerxy2w6rEXPpyejiybhs IAlQ== X-Gm-Message-State: AODbwcDSXArB417N26W0wq4RgqvG2mIU/R4vHJJLOpzokgVtGfcs7bgS IyiklC+Qk/eiW6wCwkVrf3DmEwLjng== X-Received: by 10.31.170.2 with SMTP id t2mr2756653vke.100.1496383919551; Thu, 01 Jun 2017 23:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Thu, 1 Jun 2017 23:11:59 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: "Murray S. Kucherawy" Date: Thu, 1 Jun 2017 23:11:59 -0700 Message-ID: To: Martin Thomson Cc: Kurt Andersen , dcrup@ietf.org, Scott Kitterman Content-Type: multipart/alternative; boundary="001a11430a72f8fb4c0550f407d5" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 06:12:02 -0000 --001a11430a72f8fb4c0550f407d5 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 11:05 PM, Martin Thomson wrote: > Nah, you already have a generic codepoint for just "rsa", so keep > that. ed25519 will come with a fixed size, and maybe anything *new* > should. > > I'm just pointing to a trend that supports the notion that standards > can choose key sizes. After all, if you don't standardize on a > 513-bit rsa key, then you can't signal and use it (and everyone wins, > because that would be too small). > Yeah, that's new information to me, and it's possibly good enough to address the concern. I'll wait and see what the registry looks like as these documents evolve. We don't signal anything about key sizes though, do we? They're an intrinsic part of the key that's fetched from DNS; openssl tells me the size of the key after I've opened it up. The only thing actually imposed right now by DKIM is a minimum size. -MSK --001a11430a72f8fb4c0550f407d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jun 1, 2017 at 11:05 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
Nah, you alread= y have a generic codepoint for just "rsa", so keep
that.=C2=A0 ed25519 will come with a fixed size, and maybe anything *new* should.

I'm just pointing to a trend that supports the notion that standards can choose key sizes.=C2=A0 After all, if you don't standardize on a 513-bit rsa key, then you can't signal and use it (and everyone wins, because that would be too small).

Yeah, that's ne= w information to me, and it's possibly good enough to address the conce= rn.=C2=A0 I'll wait and see what the registry looks like as these docum= ents evolve.

We don't signal anything about key sizes thou= gh, do we?=C2=A0 They're an intrinsic part of the key that's fetche= d from DNS; openssl tells me the size of the key after I've opened it u= p.=C2=A0 The only thing actually imposed right now by DKIM is a minimum siz= e.

-MSK
--001a11430a72f8fb4c0550f407d5-- From nobody Thu Jun 1 23:17:50 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E309A1294E6 for ; Thu, 1 Jun 2017 23:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 RMB1HwfDo2ln for ; Thu, 1 Jun 2017 23:17:46 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C085512944C for ; Thu, 1 Jun 2017 23:17:46 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 72209C402AE; Fri, 2 Jun 2017 01:17:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496384263; bh=+eLQXYRACUa0hgoqjaS+xP1f1t5xvKGKAOPi2zq/oz4=; h=Date:In-Reply-To:References:Subject:To:From:From; b=CrhvUfoFgXHY4Wl/00gHaIQF2soRxzHFaMrDAvg1UdeNfcZU/7lE4huH3WJRtRsuT 00c/sAaW690WkaIEyJy8jVMY3u0uwAceJYScQtn5anmbk1iwU+eAkjAG1ZwHdN8F5Z f31FyATWaDYIS46DKJgi37elPFiMRJVLqLHBAp5Q= Date: Fri, 02 Jun 2017 06:17:41 +0000 In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> <64542E13-8932-4810-9C4B-388417FD7637@kitterman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <73724FDF-5976-4AA3-8482-6CF44C1DC2DD@kitterman.com> Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 06:17:48 -0000 On June 2, 2017 2:06:15 AM EDT, "Murray S=2E Kucherawy" wrote: >On Thu, Jun 1, 2017 at 10:55 PM, Scott Kitterman >wrote: > >> I don't know, but it seems to me that if a signer uses a key length >that >> receivers will consider invalid, you've absolutely got an >interoperability >> problem=2E >> > >You can do this in OpenDKIM today with a configuration setting=2E That's >perhaps why I'm asking this question; to me, today, it's a local policy >decision, not one that's demanded by the implementation, which means >it's >not truly an interoperability issue=2E > >It's no different than saying MUST use a particular crypto algorithm=2E= =20 >It's >> one of the parameters that if the signer doesn't use something that >the >> verifier supports, there is no interoperability=2E >> > >I disagree=2E RSA works fine even with tiny keys=2E It's obviously not >smart >to use RSA that way, but publishing a document that says tiny keys are >bad >doesn't mean RSA breaks when you use them=2E It interoperates just fine= =2E > >We're establishing an artificial interoperability constraint on RSA >here by >saying keys must be at least X size to use them with RSA in the context >of >DKIM=2E I don't disagree that this is the right thing to do, I just want >to >say it the right way=2E > >I had never seen the examples Martin presented, and perhaps they're >precedent enough=2E > >-MSK Okay, but your 'just fine' only works if both signer and verifier make com= patible choices=2E When a correctly signed message fails verification, I w= ould definitely think that there's a lack of interoperability=2E Scott K From nobody Thu Jun 1 23:18:22 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126C412956B for ; Thu, 1 Jun 2017 23:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 C5mx9XNPYAD2 for ; Thu, 1 Jun 2017 23:18:18 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 721741294E6 for ; Thu, 1 Jun 2017 23:18:18 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id a136so23563047lfa.0 for ; Thu, 01 Jun 2017 23:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h1r12WsbNZHA7z5fTLQO/IGYnfyJ2Iwbf2mqXJxmz5g=; b=SJbDEQtLNdSJh3kDlbLd4YBmgUYd+4akRvLgvIJsRmtZ8CFKFtMwm0SJ9ngtu7w7x0 1Ul4xCesjWxW8GF7bnW7HYMbzehEiS+AU8Oy6y0yymw0D2dCgbb6M3pJV06nDglWa7Zm R+UEggfAZwl2CfXgGuhQll8WCXR8En/I4q/xPF2gzmWW0z50HnuNs2REOowjM9v4U7GD IWmWGwFlKQr65nF6oBoYItnJaQBOTxdTR6LLU2Ile0wLxFdH+xcfQi3mKXEZG26CpAEm bUK2Ni4rLT3JaLrkH7rxrZP07mBtIK51A1bXuimcEKfuNgzLzdZy5Oi3FhQXODITgfNu sp+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h1r12WsbNZHA7z5fTLQO/IGYnfyJ2Iwbf2mqXJxmz5g=; b=QDOpsPSFTTb2+0bw3LyNNaseNjzIiybFQ+j5biUQvzSQmSJ6e2MoIi8O6iVlMp4HTe jIWILNwGLC54DOhy4vd/SCd7kCdae/F6ueNVt+FbfvgiJSjkDA+hbwJYBhwUbMcy/TnV 4R/j0iI4aol1QJg2qWmGk3Hv4WnxqYk8/9JQvd3j47BXPPScWPQG2v5Bw0RohPueVBIV zZ/fuF2K4xRyHU1O4NpbUkMG2p2ZYKSeBjj9ghLXr93tX6boedZsSGAocQSIJc4eF/IX vulkD2/qjiL15tvRT6MFF8uNoiv8QgiKW5MYjkU19xcXGwAje+uOHzPR3TW6tqCIcqjH qkKg== X-Gm-Message-State: AODbwcACOoQFVVvQvP8xF8tFWA/R7yh86Uo4oTuwnqnify+JvT6lvyM4 urkp1pFa8RI5a8RR5lYFllCI8cfLSA== X-Received: by 10.46.21.68 with SMTP id 4mr1743523ljv.50.1496384296595; Thu, 01 Jun 2017 23:18:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Thu, 1 Jun 2017 23:18:15 -0700 (PDT) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> From: Martin Thomson Date: Fri, 2 Jun 2017 16:18:15 +1000 Message-ID: To: "Murray S. Kucherawy" Cc: Kurt Andersen , dcrup@ietf.org, Scott Kitterman Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 06:18:20 -0000 On 2 June 2017 at 16:11, Murray S. Kucherawy wrote: > We don't signal anything about key sizes though, do we? They're an > intrinsic part of the key that's fetched from DNS; openssl tells me the size > of the key after I've opened it up. The only thing actually imposed right > now by DKIM is a minimum size. Yeah, most RSA public keys just encode the numbers with a length prefix. You just look to see how big they are and decide if it's strong enough based on policy. You are right to point out that the question of whether you *could* use a key is orthogonal to whether you *want* to use the key. The former is interoperability, the latter is - yes - policy. Sometimes it makes sense to agree on a baseline for policy though. Fewer surprises that way. From nobody Fri Jun 2 06:16:00 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AD3129BD5 for ; Fri, 2 Jun 2017 06:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 KR9GD1APj0M0 for ; Fri, 2 Jun 2017 06:15:57 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E91E129421 for ; Fri, 2 Jun 2017 06:15:57 -0700 (PDT) Received: (qmail 56190 invoked from network); 2 Jun 2017 13:15:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Jun 2017 13:15:56 -0000 Date: 2 Jun 2017 13:15:34 -0000 Message-ID: <20170602131534.2266.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: martin.thomson@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 13:15:59 -0000 In article you write: >TLS does this for cipher suites. The policy there is to allow >registration of entries with a low bar, but to require a higher bar >(Standards Track) for entries that mark the entry as "recommended". TLS does cipher negotiation, DKIM doesn't, because TLS has a two-way path between sender and recipient. That means that adding new algorithm to DKIM is hard and slow, because signers can't use them (other than in parallel with older algorithms) until a sufficient number of verifiers implement them. That's why my draft adds one (1) new algorithm that is intended to be good enough to last for a long time. The current draft may not have the best algo for that goal, but that's why it's still a draft. I'm also somewhat sceptical of outsourcing key strength advice. You don't pick key strengths in a vacuum and DKIM is in an odd place with signatures that last for a week, not a few seconds like in TLS or years like S/MIME or PGP signatures. Writing a new RFC that updates key strength advice needn't be hard unless we make it hard. R's, John From nobody Fri Jun 2 07:02:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4E129521 for ; Fri, 2 Jun 2017 07:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hoXXQfmm6sy5 for ; Fri, 2 Jun 2017 07:02:39 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2699120721 for ; Fri, 2 Jun 2017 07:02:39 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 2 Jun 2017 10:02:30 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Fri, 2 Jun 2017 10:02:36 -0400 Received: from [129.6.140.7] ([129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v52E2RRw007040 for ; Fri, 2 Jun 2017 10:02:27 -0400 From: "Rose, Scott" To: Date: Fri, 2 Jun 2017 10:02:27 -0400 Message-ID: In-Reply-To: <20170602131534.2266.qmail@ary.lan> References: <20170602131534.2266.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:02:41 -0000 Some communities have a larger security policy on algorithms, key lengths, etc. that they are compelled to comply to rather than per-protocol recommendations. Usually admins follow it out of routine or simply to keep auditors from complaining. Listing what a validator MUST be able to support is good, but dictating what a sender MUST use might lead to issues. I agree on only adding 1 (two at most) algorithms to DKIM. Too many algorithms leads to confusion among implementors and deployments as to what is the recommended algorithm. DNSSEC is facing this now and there are now several drafts about which algorithms should be mandatory, which should be retired, etc. Scott On 2 Jun 2017, at 9:15, John Levine wrote: > In article > > you write: >> TLS does this for cipher suites. The policy there is to allow >> registration of entries with a low bar, but to require a higher bar >> (Standards Track) for entries that mark the entry as "recommended". > > TLS does cipher negotiation, DKIM doesn't, because TLS has a two-way > path between sender and recipient. That means that adding new > algorithm to DKIM is hard and slow, because signers can't use them > (other than in parallel with older algorithms) until a sufficient > number of verifiers implement them. That's why my draft adds one (1) > new algorithm that is intended to be good enough to last for a long > time. The current draft may not have the best algo for that goal, but > that's why it's still a draft. > > I'm also somewhat sceptical of outsourcing key strength advice. You > don't pick key strengths in a vacuum and DKIM is in an odd place with > signatures that last for a week, not a few seconds like in TLS or > years like S/MIME or PGP signatures. Writing a new RFC that updates > key strength advice needn't be hard unless we make it hard. > > R's, > John > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== From nobody Fri Jun 2 07:41:44 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 692E81242EA; Fri, 2 Jun 2017 07:41:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149641449629.31859.14544571541039601302@ietfa.amsl.com> Date: Fri, 02 Jun 2017 07:41:36 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-ecc-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:41:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update of the IETF. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-ietf-dcrup-dkim-ecc-00.txt Pages : 7 Date : 2017-06-02 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-ecc-00 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 2 07:47:13 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D894712EBD2 for ; Fri, 2 Jun 2017 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gyhLo4xjf8GL for ; Fri, 2 Jun 2017 07:47:08 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [IPv6:2610:20:6005:13::150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CA312EBD5 for ; Fri, 2 Jun 2017 07:47:08 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 2 Jun 2017 10:46:52 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Fri, 2 Jun 2017 10:47:06 -0400 Received: from [129.6.140.7] ([129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v52EkxfX009809 for ; Fri, 2 Jun 2017 10:46:59 -0400 From: "Rose, Scott" To: Date: Fri, 2 Jun 2017 10:46:59 -0400 Message-ID: <2D2E54E1-23A0-4470-85AD-F861770B10B1@nist.gov> In-Reply-To: <149641449629.31859.14544571541039601302@ietfa.amsl.com> References: <149641449629.31859.14544571541039601302@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-ecc-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:47:11 -0000 Updated to reflect WG status. Also made the following changes: 1. Reduced new algorithms list to just one (ECDSA P=256). 2. Included revised definition of key:value pairs for DKIM keys and signatures. One thing I thought about: should the “k=“ in keys to be mandatory now that RSA isn’t the only algorithm? Or leave the default as is, so that anyone using ECDSA must use the “k=“ tag to signal its use? 3. Just noticed that the format is mess up for the ABNF notation - dang. Will fix that. Scott On 2 Jun 2017, at 10:41, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DKIM Crypto Update of the IETF. > > Title : Defining Elliptic Curve Cryptography > Algorithms for use with DKIM > Author : Scott Rose > Filename : draft-ietf-dcrup-dkim-ecc-00.txt > Pages : 7 > Date : 2017-06-02 > > Abstract: > DomainKeys Identified Mail (DKIM) uses digital signature to > associate > a message with a given sending domain. Currently, there is only > one > cryptography algorithm defined for use with DKIM (RSA). This > document defines four new elliptic curve cryptography algorithms > for > use with DKIM. This will allow for algorithm agility if a weakness > is found in RSA, and allows for smaller key length to provide the > same digital signature strength. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dcrup-dkim-ecc-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== From nobody Fri Jun 2 07:53:35 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79680120727 for ; Fri, 2 Jun 2017 07:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 JA_LWKYSAHw2 for ; Fri, 2 Jun 2017 07:53:32 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74223129537 for ; Fri, 2 Jun 2017 07:53:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9971D300563 for ; Fri, 2 Jun 2017 10:53:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id r0feFX2SQQyM for ; Fri, 2 Jun 2017 10:53:30 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E5261300429; Fri, 2 Jun 2017 10:53:29 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <2D2E54E1-23A0-4470-85AD-F861770B10B1@nist.gov> Date: Fri, 2 Jun 2017 10:53:29 -0400 Cc: dcrup@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <885BDE45-DFB7-4BC5-8C98-C5D40C82DAE3@vigilsec.com> References: <149641449629.31859.14544571541039601302@ietfa.amsl.com> <2D2E54E1-23A0-4470-85AD-F861770B10B1@nist.gov> To: "Rose, Scott" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-ecc-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 14:53:34 -0000 Scott: Since ECDSA P-256 and SHA-256 have the same security strength, what is = the reason for adding SHA-512 at this time? I do not see anything in = the Introduction or Security Considerations to answer that question. Russ > On Jun 2, 2017, at 10:46 AM, Rose, Scott wrote: >=20 > Updated to reflect WG status. Also made the following changes: >=20 > 1. Reduced new algorithms list to just one (ECDSA P=3D256). >=20 > 2. Included revised definition of key:value pairs for DKIM keys and = signatures. One thing I thought about: should the =E2=80=9Ck=3D=E2=80=9C = in keys to be mandatory now that RSA isn=E2=80=99t the only algorithm? = Or leave the default as is, so that anyone using ECDSA must use the = =E2=80=9Ck=3D=E2=80=9C tag to signal its use? >=20 > 3. Just noticed that the format is mess up for the ABNF notation - = dang. Will fix that. >=20 > Scott >=20 > On 2 Jun 2017, at 10:41, internet-drafts@ietf.org wrote: >=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the DKIM Crypto Update of the IETF. >>=20 >> Title : Defining Elliptic Curve Cryptography = Algorithms for use with DKIM >> Author : Scott Rose >> Filename : draft-ietf-dcrup-dkim-ecc-00.txt >> Pages : 7 >> Date : 2017-06-02 >>=20 >> Abstract: >> DomainKeys Identified Mail (DKIM) uses digital signature to = associate >> a message with a given sending domain. Currently, there is only = one >> cryptography algorithm defined for use with DKIM (RSA). This >> document defines four new elliptic curve cryptography algorithms = for >> use with DKIM. This will allow for algorithm agility if a weakness >> is found in RSA, and allows for smaller key length to provide the >> same digital signature strength. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-dcrup-dkim-ecc-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scott Rose > NIST ITL > scott.rose@nist.gov > +1-301-975-8439 > GV: +1-571-249-3671 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Fri Jun 2 08:07:26 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28098120454 for ; Fri, 2 Jun 2017 08:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 LFjc7guyPf9v for ; Fri, 2 Jun 2017 08:07:18 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A607F12EBCA for ; Fri, 2 Jun 2017 08:07:18 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 2 Jun 2017 11:07:02 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Fri, 2 Jun 2017 11:07:16 -0400 Received: from [129.6.140.7] ([129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v52F6WuK011086; Fri, 2 Jun 2017 11:06:32 -0400 From: "Rose, Scott" To: Russ Housley CC: Date: Fri, 2 Jun 2017 11:06:32 -0400 Message-ID: In-Reply-To: <885BDE45-DFB7-4BC5-8C98-C5D40C82DAE3@vigilsec.com> References: <149641449629.31859.14544571541039601302@ietfa.amsl.com> <2D2E54E1-23A0-4470-85AD-F861770B10B1@nist.gov> <885BDE45-DFB7-4BC5-8C98-C5D40C82DAE3@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-ecc-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 15:07:25 -0000 Mainly to have something pre-defined if SHA-256 is found to be vulnerable. I’m not very concerned about that, if the community is responsive in the event that does happen. I have no qualms about dropping it since it gives the draft a single focus. It’s more for potential future-proofing. Scott On 2 Jun 2017, at 10:53, Russ Housley wrote: > Scott: > > Since ECDSA P-256 and SHA-256 have the same security strength, what is > the reason for adding SHA-512 at this time? I do not see anything in > the Introduction or Security Considerations to answer that question. > > Russ > > > >> On Jun 2, 2017, at 10:46 AM, Rose, Scott wrote: >> >> Updated to reflect WG status. Also made the following changes: >> >> 1. Reduced new algorithms list to just one (ECDSA P=256). >> >> 2. Included revised definition of key:value pairs for DKIM keys and >> signatures. One thing I thought about: should the “k=“ in keys >> to be mandatory now that RSA isn’t the only algorithm? Or leave >> the default as is, so that anyone using ECDSA must use the “k=“ >> tag to signal its use? >> >> 3. Just noticed that the format is mess up for the ABNF notation - >> dang. Will fix that. >> >> Scott >> >> On 2 Jun 2017, at 10:41, internet-drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the DKIM Crypto Update of the IETF. >>> >>> Title : Defining Elliptic Curve Cryptography >>> Algorithms for use with DKIM >>> Author : Scott Rose >>> Filename : draft-ietf-dcrup-dkim-ecc-00.txt >>> Pages : 7 >>> Date : 2017-06-02 >>> >>> Abstract: >>> DomainKeys Identified Mail (DKIM) uses digital signature to >>> associate >>> a message with a given sending domain. Currently, there is only >>> one >>> cryptography algorithm defined for use with DKIM (RSA). This >>> document defines four new elliptic curve cryptography algorithms >>> for >>> use with DKIM. This will allow for algorithm agility if a >>> weakness >>> is found in RSA, and allows for smaller key length to provide the >>> same digital signature strength. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-dcrup-dkim-ecc-00 >>> https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Dcrup mailing list >>> Dcrup@ietf.org >>> https://www.ietf.org/mailman/listinfo/dcrup >> >> >> =================================== >> Scott Rose >> NIST ITL >> scott.rose@nist.gov >> +1-301-975-8439 >> GV: +1-571-249-3671 >> =================================== >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== From nobody Fri Jun 2 11:54:57 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12549126E01 for ; Fri, 2 Jun 2017 11:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no 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 QvpqoPDc81Cl for ; Fri, 2 Jun 2017 11:54:53 -0700 (PDT) Received: from mail.smeinc.net (x-bolt-wan.smeinc.net [209.135.219.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899851200E5 for ; Fri, 2 Jun 2017 11:54:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EC6F33005A4 for ; Fri, 2 Jun 2017 14:54:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id d_iiTG0g2zu8 for ; Fri, 2 Jun 2017 14:54:51 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 6F20A3004AF; Fri, 2 Jun 2017 14:54:51 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A77FB047-F152-43B1-BFEC-EB4DD06B6355" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 2 Jun 2017 14:54:51 -0400 In-Reply-To: Cc: dcrup@ietf.org To: "Murray S. Kucherawy" , Kurt Andersen References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <3745683.4zdJlR4cAU@kitterma-e6430> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 18:54:55 -0000 --Apple-Mail=_A77FB047-F152-43B1-BFEC-EB4DD06B6355 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 2, 2017, at 1:35 AM, Murray S. Kucherawy = wrote: >=20 > (sans chapeau) >=20 > I realize I have some threads to catch up on, but... >=20 > On Thu, Jun 1, 2017 at 9:49 PM, Kurt Andersen > wrote: > I think that this does not quite go far enough in shifting the = algorithms and acceptable key lengths into an IANA registry to = future-proof the spec and allow more rapid response in the case of = exploit advancement. >=20 > I'd like to see both of those pieces "out sourced" to a registry with = updates to be driven by crypto-competent people. >=20 > This notion feels weird to me. What would such a registry look like? = Are there any other protocol registries that contain just a list of key = sizes or lengths of things currently approved by the community? What = would the update rules be on such a registry? I am aware of some registries that include a column to mark aged = algorithms as =E2=80=9CNot recommended.=E2=80=9D I have not seen a registry that included a minimum key size column. Russ --Apple-Mail=_A77FB047-F152-43B1-BFEC-EB4DD06B6355 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 2, 2017, at 1:35 AM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

(sans chapeau)

I = realize I have some threads to catch up on, but...

On Thu, Jun 1, 2017 at 9:49 PM, Kurt Andersen <kurta@drkurt.com> wrote:
I = think that this does not quite go far enough in shifting the algorithms = and acceptable key lengths into an IANA registry to future-proof the = spec and allow more rapid response in the case of exploit = advancement.

I'd like to see both of those pieces "out = sourced" to a registry with updates to be driven by crypto-competent = people.

This notion feels weird to me.  What would such a = registry look like?  Are there any other protocol registries that = contain just a list of key sizes or lengths of things currently approved = by the community?  What would the update rules be on such a = registry?

I am aware of some registries that include a = column to mark aged algorithms as =E2=80=9CNot recommended.=E2=80=9D
=

I have not seen a = registry that included a minimum key size column.
Russ

= --Apple-Mail=_A77FB047-F152-43B1-BFEC-EB4DD06B6355-- From nobody Sat Jun 3 04:13:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599F6128B51 for ; Sat, 3 Jun 2017 04:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fZz0V8NzBnfr for ; Sat, 3 Jun 2017 04:13:15 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA7D128799 for ; Sat, 3 Jun 2017 04:13:14 -0700 (PDT) Received: (qmail 30885 invoked from network); 3 Jun 2017 11:13:13 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2017 11:13:13 -0000 Date: 3 Jun 2017 11:12:50 -0000 Message-ID: <20170603111250.3799.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: scott.rose@nist.gov In-Reply-To: <2D2E54E1-23A0-4470-85AD-F861770B10B1@nist.gov> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-ecc-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 11:13:16 -0000 In article <2D2E54E1-23A0-4470-85AD-F861770B10B1@nist.gov> you write: >2. Included revised definition of key:value pairs for DKIM keys and >signatures. One thing I thought about: should the “k=“ in keys to >be mandatory now that RSA isn’t the only algorithm? Or leave the >default as is, so that anyone using ECDSA must use the “k=“ tag to >signal its use? It needs to be backward compatible, so no k= still means RSA. R's, John From nobody Sat Jun 3 11:02:19 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98EF12EB5B for ; Sat, 3 Jun 2017 11:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 ffkushCWzSTi for ; Sat, 3 Jun 2017 11:02:16 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA9912EB55 for ; Sat, 3 Jun 2017 11:02:16 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 44D4DC4010C for ; Sat, 3 Jun 2017 13:02:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496512934; bh=qyu+TOYZMslF5m9MOTVcZCBe+OpoujYB0+2J2kZbE80=; h=From:To:Subject:Date:From; b=D0SfxJPz0beBfglczZpP4B6wmv0dTEQKxtZbXjfPbQ8qwE4DSRK3mpUnm1qB/dMhB 1KIGet2E28lp+hl50Y2OgO98UMQimavoQYv0h2ZFpkSj61VLQYJOMGmDGzOZULiUuO W4jbasHA+245ORLOt+4dYvZwS8swAKFTcqIIixos= From: Scott Kitterman To: dcrup@ietf.org Date: Sat, 03 Jun 2017 14:02:13 -0400 Message-ID: <1870784.2tGGxD3xed@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1965194.WfSBeShprZ" Content-Transfer-Encoding: 7Bit Archived-At: Subject: [Dcrup] Work on draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2017 18:02:19 -0000 This is a multi-part message in MIME format. --nextPart1965194.WfSBeShprZ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" I have locally updated the draft based on my interpretation of the discussion on the list. Rfcdiff attached. Added an informative reference to the US-CERT vulnerability report on this issue. Added updates to header field and key records that I missed in my first draft. Also, I forgot to mention before that, since all the cool kids are doing it, I put this up on my github account. This is, of course, in no way officially anything at all. It's only a way for me to keep track of changes. https://github.com/kitterma/draft-ietf-dcrup-dkim-usage I did not take on the question of adding key sizes to the IANA registry for several reasons: 1. Adding it at all is somewhat controversial and I'm hoping to limit the controversy in this particular document so we can get it done. I view this document as the minimum update to RFC 6376 required to update DKIM to remove known insecure things. An IANA registry doesn't affect that. 2. Different types of algorithms have widely different key size requirements, so I don't believe we will really know what such a registry would need to look like until after we've finished working through questions about what is the next generation DKIM algorithm going to be. Making a registry now would mean we might need to redo it later. Let's do it once, if we are going to to it at all. 3. There is some nuance about key size rules that I'm not sure how to fit into an IANA registry. One other thing that perhaps should go into this draft is more on Security Considerations. If you look at the Security Considerations in RFC 6376, it does not mention risks associated with using an obsolete hash algorithm or a key that is too small. Adding a new security consideration as an "update" to RFC 6376 that describes the problem this draft is solving might be a good thing? As revisions are cheap, unless someone objects, I'll go ahead and post this (or something similar based on feedback) soon. Scott K --nextPart1965194.WfSBeShprZ Content-Disposition: attachment; filename="draft-ietf-dcrup-dkim-usage-from--00.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-dcrup-dkim-usage-from--00.diff.html" Diff: draft-ietf-dcrup-dkim-usage-00.txt - draft-ietf-dcrup-dkim-usage.txt
 draft-ietf-dcrup-dkim-usage-00.txt   draft-ietf-dcrup-dkim-usage.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Updates: 6376 (if approved) May 30, 2017 Updates: 6376 (if approved) June 3, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: December 1, 2017 Expires: December 5, 2017
Cryptographic Algorithm and Key Usage to DKIM Cryptographic Algorithm and Key Usage to DKIM
draft-ietf-dcrup-dkim-usage-00 draft-ietf-dcrup-dkim-usage-01
Abstract Abstract
The cryptographic algorithm and key size requirements included when The cryptographic algorithm and key size requirements included when
DKIM was designed in the last decade are functionally obsolete and in DKIM was designed in the last decade are functionally obsolete and in
need of immediate revision. This document updates DKIM requirements need of immediate revision. This document updates DKIM requirements
to those minimaly suitable for operation with currently specified to those minimaly suitable for operation with currently specified
algorithms. This document updates RFC 6376. algorithms. This document updates RFC 6376.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 1, 2017. This Internet-Draft will expire on December 5, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. DKIM Signing and Verification Algorithms . . . . . . . . . . 3 3. DKIM Signing and Verification Algorithms . . . . . . . . . . 3
3.1. The rsa-sha1 Signing Algorithm . . . . . . . . . . . . . 3 3.1. The rsa-sha1 Signing Algorithm . . . . . . . . . . . . . 3
3.2. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3 3.2. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3
3.3. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
3.4. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4 3.4. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. The DKIM-Signature Header Field . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Key Management and Representation . . . . . . . . . . . . . . 4
5.1. DKIM Hash Algorithms . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Normative References . . . . . . . . . . . . . . . . . . . . 4 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 7.1. DKIM Hash Algorithms . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
Discussion Venue: Discussion about this draft is directed to the Discussion Venue: Discussion about this draft is directed to the
dcrup@ietf.org [1] mailing list. dcrup@ietf.org [1] mailing list.
DKIM [RFC6376] signs e-mail messages, by creating hashes of the DKIM [RFC6376] signs e-mail messages, by creating hashes of the
message headers and content and signing the header hash with a message headers and content and signing the header hash with a
digital signature. Message recipients fetch the signature digital signature. Message recipients fetch the signature
verification key from the DNS where it is stored in a TXT record. verification key from the DNS where it is stored in a TXT record.
The defining documents specify a single signing algorithm, RSA The defining documents specify a single signing algorithm, RSA
[RFC8017], and recommends key sizes of 1024 to 2048 bits (but require [RFC8017], and recommends key sizes of 1024 to 2048 bits (but require
verification of 512 bit keys). While 1024 bit signatures are common, verification of 512 bit keys). As discussed in US-CERT VU#268267
stronger signatures are not. Widely used DNS configuration software [VULNOTE], the operational community has recognized that shorter keys
places a practical limit on key sizes, because the software only compromise the effectiveness of DKIM. While 1024 bit signatures are
handles a single 256 octet string in a TXT record, and RSA keys common, stronger signatures are not. Widely used DNS configuration
software places a practical limit on key sizes, because the software
only handles a single 256 octet string in a TXT record, and RSA keys
longer than 1024 bits don't fit in 256 octets. longer than 1024 bits don't fit in 256 octets.
2. Conventions Used in This Document 2. Conventions Used in This Document
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. DKIM Signing and Verification Algorithms 3. DKIM Signing and Verification Algorithms
skipping to change at page 4, line 23 skipping to change at page 4, line 23
o The security goals of DKIM,[RFC6376], are modest compared to o The security goals of DKIM,[RFC6376], are modest compared to
typical goals of other systems that employ digital signatures typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes. See [RFC3766] for further discussion on selecting key sizes.
3.4. Other Algorithms 3.4. Other Algorithms
Other algorithms will be defined in the future. Verifiers MUST Other algorithms will be defined in the future. Verifiers MUST
ignore any signatures using algorithms that they do not implement. ignore any signatures using algorithms that they do not implement.
4. Security Considerations 4. The DKIM-Signature Header Field
This section updates the a= tag in [RFC6376] Section 3.5.
The text description of the tag is now:
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha256"; Signers MUST
sign using "rsa-sha256". See [RFC6376] Section 3.3 (as updated
by this document) for a description of the algorithms.
The following ABNF element is updated:
ABNF:
sig-a-tag-h = "sha256" / x-sig-a-tag-h
5. Key Management and Representation
This section updates the h= tag in [RFC6376] Section 3.6.1.
The following ABNF element is updated:
ABNF:
key-h-tag-alg = "sha256" / x-key-h-tag-alg
6. Security Considerations
This document does not change the Security Considerations of This document does not change the Security Considerations of
[RFC6376]. It reduces the risk of signature compromise due to weak [RFC6376]. It reduces the risk of signature compromise due to weak
cryptography. cryptography.
5. IANA Considerations 7. IANA Considerations
IANA is requested to update registries as follows. IANA is requested to update registries as follows.
5.1. DKIM Hash Algorithms 7.1. DKIM Hash Algorithms
The following value is changed in the DKIM Hash Algorithms The following value is changed in the DKIM Hash Algorithms
+------+-----------------+----------+ +------+-----------------+----------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
+------+-----------------+----------+ +------+-----------------+----------+
| sha1 | (this document) | obsolete | | sha1 | (this document) | obsolete |
+------+-----------------+----------+ +------+-----------------+----------+
Table 1: DKIM Hash Algorithms Changed Value Table 1: DKIM Hash Algorithms Changed Value
6. Normative References 8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004, RFC 3766, DOI 10.17487/RFC3766, April 2004,
<http://www.rfc-editor.org/info/rfc3766>. <http://www.rfc-editor.org/info/rfc3766>.
skipping to change at page 5, line 20 skipping to change at page 5, line 48
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <http://www.rfc-editor.org/info/rfc6376>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<http://www.rfc-editor.org/info/rfc8017>. <http://www.rfc-editor.org/info/rfc8017>.
8.2. Informative References
[VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys
Identified Mail (DKIM) Verifiers may inappropriately
convey message trust", October 2012.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and The author wishes to acknowledge the following for their review and
constructive criticism of this proposal: TBD (surely there will be constructive criticism of this proposal: TBD (surely there will be
someone). someone).
Thanks to John Levine for draft-ietf-dcrup-dkim-crypto-00, which was Thanks to John Levine for draft-ietf-dcrup-dkim-crypto-00, which was
the source for much of the introductory material in this draft. the source for much of the introductory material in this draft.
Author's Address Author's Address
 End of changes. 12 change blocks. 
18 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart1965194.WfSBeShprZ-- From nobody Sat Jun 3 17:55:47 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D037C129A9D for ; Sat, 3 Jun 2017 17:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yxkiOL4yGORq for ; Sat, 3 Jun 2017 17:55:44 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FADD129AA4 for ; Sat, 3 Jun 2017 17:55:44 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id x47so61342406uab.0 for ; Sat, 03 Jun 2017 17:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CyLlmcl8Mnt8aIpXKlD/jR8Qp2g7iroiOrd2Ywr507M=; b=J6WvuxXRExJzQR+UoNwRlPEUFcWR8ttV3Yd5KKJQbUllbaxUayHm5gqdrxR0T/CxPZ HUhiFWnx6BQlQlVdjxLRgUj8GVqSajqdhMyPmVAlardR5knS8+6NSUENz7eTsF79KatZ nd3F1t4SowLvWKU7BDyRQDmsnFY4Y71vgpIBgtidD5xSYo0FFOLj4tj5sXC6NdBqXgLA nZyVWQtlEgI65qRUwJfNqmtQBilrghoi/K/ewB8HQUugknTlQmcft9Inkf2esf3RmcgV pPZJ49QBVuskExO2xyDU1QysSXn7F7LgnljUmw9BmnAYQmg/xMxbbkUtKlTL23vmtnV4 PVNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CyLlmcl8Mnt8aIpXKlD/jR8Qp2g7iroiOrd2Ywr507M=; b=W8nYgDt2xauQxhhmLFu+CFmdnz54BAKSpckBoagq5MSYxTb8LG5w+hPXQa5wNZhrol ocs6q0/+DI6h+tyZyfh9D0RHp33NI0d91mSeoiBOgEkhCd7BTYpCCUcQTO9XrADhTzH6 zZmA8XCatJGhc36TQJI9yedNfyuiZkGHCrtBvH/yhtq0VAbvtNqXzVw9xKfk930ZT3x9 tBv3Od5aEJWbMq0w1RbGcVtsh0EMRdUb7q6XdWAys2qNXiZrE/P3tMe9JRVvvWOh7Tw9 ZzCdmvnVhNqw2qFFODdXpuDAkJlcGVa3rEkv1hxx8ADH2K03da3MEDyLqRWscSlQjQ7v 8CXA== X-Gm-Message-State: AODbwcCPFxcFIRvxMrqT3H/WP7PZYsxIiaD2rSIEvHqRhojcq5S20gyG 3vdGfS1pZB5XaAbCxDpmZrCdsDj+aJ3e X-Received: by 10.176.81.4 with SMTP id e4mr7855152uaa.33.1496537743243; Sat, 03 Jun 2017 17:55:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Sat, 3 Jun 2017 17:55:42 -0700 (PDT) In-Reply-To: <1870784.2tGGxD3xed@kitterma-e6430> References: <1870784.2tGGxD3xed@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sat, 3 Jun 2017 17:55:42 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c191490943f27055117d89d" Archived-At: Subject: Re: [Dcrup] Work on draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jun 2017 00:55:46 -0000 --94eb2c191490943f27055117d89d Content-Type: text/plain; charset="UTF-8" On Sat, Jun 3, 2017 at 11:02 AM, Scott Kitterman wrote: > Also, I forgot to mention before that, since all the cool kids are doing > it, I > put this up on my github account. This is, of course, in no way officially > anything at all. It's only a way for me to keep track of changes. > > https://github.com/kitterma/draft-ietf-dcrup-dkim-usage I believe the IETF now has a github repository of its own that we can use. I can't remember if it's a single common one for all activity or one per working group though, but it's meant as a way to enable and encourage collaboration among participants. No need to change it now, necessarily. Just for future reference. -MSK --94eb2c191490943f27055117d89d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 3, 2017 at 11:02 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
Also, I forgot to menti= on before that, since all the cool kids are doing it, I
put this up on my github account.=C2=A0 This is, of course, in no way offic= ially
anything at all.=C2=A0 It's only a way for me to keep track of changes.=

https://github.com/kitterma/draft-ietf-d= crup-dkim-usage

I believe the IETF now = has a github repository of its own that we can use.=C2=A0 I can't remem= ber if it's a single common one for all activity or one per working gro= up though, but it's meant as a way to enable and encourage collaboratio= n among participants.

No need to change it now, necessari= ly.=C2=A0 Just for future reference.

-MSK
=
--94eb2c191490943f27055117d89d-- From nobody Mon Jun 5 09:21:38 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ABC129B47 for ; Mon, 5 Jun 2017 09:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1xbxRS_R81fI for ; Mon, 5 Jun 2017 09:21:33 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75215129B44 for ; Mon, 5 Jun 2017 09:21:33 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 5 Jun 2017 12:21:28 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Mon, 5 Jun 2017 12:21:30 -0400 Received: from [129.6.140.7] ([129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v55GL8EF019409 for ; Mon, 5 Jun 2017 12:21:09 -0400 From: "Rose, Scott" To: Date: Mon, 5 Jun 2017 12:21:08 -0400 Message-ID: In-Reply-To: <149619233095.19793.14947085917778354002@ietfa.amsl.com> References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:21:37 -0000 I’ve read the draft and I admire the willingness to plant a stake in the ground in making rsa-sha1 obsolete. I think it would help to be more explicit about which requirement applies to which role (implement vs deploy/administrate). For example: 3 DKIM Signing and Verification Algorithms This section replaces [RFC6376] Section 3.3 in its entirety. DKIM supports multiple digital signature algorithms. Two algorithms were defined by [RFC6376]: rsa-sha1 and rsa-sha256. Signers MUST implement and sign using rsa-sha256. Verifiers MUST implement rsa- sha256 and MAY implement rsa-sha1 for backwards compatibility. The rsa-sha1 signing algorithm is obsolete and MUST NOT be used. 3.1. The rsa-sha1 Signing Algorithm This algorithm is obsolete and MUST NOT be used by signers. This doesn’t change the main idea, but calls out the fact that rsa-sha1 will be sticking around for a period of time as administrators are not going to read this doc and/or not going to change things that are working for them now. Scott On 30 May 2017, at 20:58, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DKIM Crypto Update of the IETF. > > Title : Cryptographic Algorithm and Key Usage to > DKIM > Author : Scott Kitterman > Filename : draft-ietf-dcrup-dkim-usage-00.txt > Pages : 5 > Date : 2017-05-30 > > Abstract: > The cryptographic algorithm and key size requirements included when > DKIM was designed in the last decade are functionally obsolete and > in > need of immediate revision. This document updates DKIM > requirements > to those minimaly suitable for operation with currently specified > algorithms. This document updates RFC 6376. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== From nobody Mon Jun 5 09:53:56 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3AFF129B73 for ; Mon, 5 Jun 2017 09:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 9fHHQd9nleRl for ; Mon, 5 Jun 2017 09:53:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27BC129B6F for ; Mon, 5 Jun 2017 09:53:39 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8BA00C401BE for ; Mon, 5 Jun 2017 11:53:38 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496681618; bh=W4T0rtCwLynls8m6pzaiWQVUVVCzEjCeyYPu+6tTAZI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=R6mgzQwuDFU9DP9xONlSmwLomD+Nf8Rhd9ygA8Isiq0no0fWwiYq1D9H1t7bAeeXA jSW1yzgGk9mJu4xvXhOxEtIlvKt0Hb8aiahh75eb8KbuA5eP0Cfb9VgeEuvzCD6NYC pcPYZPG13NA/bEjOpZIBvgKeQJrb04GFmrzvxS90= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 05 Jun 2017 12:53:38 -0400 Message-ID: <1830430.b8hTZcbnc5@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 16:53:54 -0000 I hear you. I expect this to be the most contentious part of the draft= . Here's my counter argument: The first DKIM RFC (RFC 4871), published in 2007 said: > Signers MUST implement and SHOULD sign using rsa-sha256 I believe that the only reason rsa-sha1 was included at all was to make= =20 transition from domainkeys easier (see RFC 4870). That's also (as I=20= understand it where the 512 bit minimum key size came from). We've already had a decade for transition. I think we are well into th= e=20 territory that if there are signatures being done with rsa-sha1, it's u= nlikely=20 to change until they stop working. In related news, I added an informative reference to RFC 6194 and menti= oned it=20 in security considerations. Fundamentally, I don't think anything other than removing it entirely c= hanges=20 anything. As long as receivers MAY, they probably will and if they don= 't=20 senders will complain "Why didn't you?", it's still allowed. MUST NOT = on both=20 sides of the equation gives a clear answer. "Go read RFC XXXX. If it'= s a=20 problem for you, you aren't doing something you SHOULD have been doing = since=20 2007, so you own the interoperability problem." If someone doesn't want to drop rsa-sha1, they are free to not implemen= t that=20 change, so I don't see leaving the MAY in there for receivers as advant= ageous. We know we need to add a new algorithm to replace it and two is plenty.= Let's=20 kill it dead. As a working group document editor, I'll change it however the group wa= nts (of=20 course), but I think we should either kill rsa-sha1 entirely in this do= cument=20 or leave it out entirely and let one of the follow-on documents add a n= ew=20 algorithm and remove rsa-sha1. Preferably a clean kill or, failing tha= t, not=20 at all is what I think we should do. Scott K On Monday, June 05, 2017 12:21:08 PM Rose, Scott wrote: > I=E2=80=99ve read the draft and I admire the willingness to plant a s= take in > the ground in making rsa-sha1 obsolete. >=20 > I think it would help to be more explicit about which requirement > applies to which role (implement vs deploy/administrate). For exampl= e: >=20 > 3 DKIM Signing and Verification Algorithms >=20 > This section replaces [RFC6376] Section 3.3 in its entirety. >=20 > DKIM supports multiple digital signature algorithms. Two algorit= hms > were defined by [RFC6376]: rsa-sha1 and rsa-sha256. Signers MUST= > implement and sign using rsa-sha256. Verifiers MUST implement rs= a- > sha256 and MAY implement rsa-sha1 for backwards compatibility. > The rsa-sha1 signing algorithm is obsolete and MUST NOT be > used. >=20 > 3.1. The rsa-sha1 Signing Algorithm >=20 > This algorithm is obsolete and MUST NOT be used by signers. >=20 >=20 > This doesn=E2=80=99t change the main idea, but calls out the fact tha= t > rsa-sha1 will be sticking around for a period of time as administrato= rs > are not going to read this doc and/or not going to change things that= > are working for them now. >=20 > Scott >=20 > On 30 May 2017, at 20:58, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DKIM Crypto Update of the IETF. > >=20 > > Title : Cryptographic Algorithm and Key Usage to > >=20 > > DKIM > >=20 > > Author : Scott Kitterman > > =09 > > =09Filename : draft-ietf-dcrup-dkim-usage-00.txt > > =09Pages : 5 > > =09Date : 2017-05-30 > >=20 > > Abstract: > > The cryptographic algorithm and key size requirements included w= hen > > DKIM was designed in the last decade are functionally obsolete a= nd > >=20 > > in > >=20 > > need of immediate revision. This document updates DKIM > >=20 > > requirements > >=20 > > to those minimaly suitable for operation with currently specifie= d > > algorithms. This document updates RFC 6376. > >=20 > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ > >=20 > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-00 > > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-0= 0 > >=20 > >=20 > > Please note that it may take a couple of minutes from the time of > > submission > > until the htmlized version and diff are available at tools.ietf.org= . > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > _______________________________________________ > > Dcrup mailing list > > Dcrup@ietf.org > > https://www.ietf.org/mailman/listinfo/dcrup >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scott Rose > NIST ITL > scott.rose@nist.gov > +1-301-975-8439 > GV: +1-571-249-3671 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Mon Jun 5 13:18:17 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32831294C4 for ; Mon, 5 Jun 2017 13:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ko2eURvPWfv9 for ; Mon, 5 Jun 2017 13:18:14 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F2F1270A7 for ; Mon, 5 Jun 2017 13:18:14 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id h39so27883505uaa.3 for ; Mon, 05 Jun 2017 13:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i5289MxHFpYmvp/17XT4fxV1cybYEpFFAImeOBY1SBc=; b=oP4xY7f32HxQcjnqwDG0jax+jhHEvg1wda39klhGe1kn7lE7/hADQfz6u17XNzNbdV bWSLgJ94Luey06vM3ZkJ9savpQCd9M10pVHm3ON4PlHxrclnq60C2SIKjNHVymxNs9q8 0uoR6yTC8OG2f+qkhjQK2FYoxjvGtv56AfoUdkfkpQeVdZlqG/1eA7NFgcZ01BOA3BRh qvbyY11XN7GJQorv5XBU0cQrrUC9Kqi30Dh7tLpTcZhIox6TTFQ2LAH6gIHUF4/rFL3n VC2uxcc6vf3w0s0iAbhmlV8im5GLEzidHdSBGIvYM91k6K6g4S16mGxpDdHI2zyi0NIZ Xzow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i5289MxHFpYmvp/17XT4fxV1cybYEpFFAImeOBY1SBc=; b=DZFlTPBjGyHvujDGiMBzPymd3v2K0iHEYN7iEjVbvrLjtQw6u20uUM57YNYCfxiDkM 13GN/swXxUBCoZiB7NhjMbqmobec+rQ0U/3WvzcsNMZgEBUbBd6kTkeMTKxVCtpIxCax uVfqSdkhZ+vX+z7HGnUT4FfxVW9Xh3f6MXia/Oz20GSqSIxHJXzr+84URE16Ep8ZfsjL 0h6SPy06FMsgTawyhP7flIF/q+sUE3bx4uecZgEdB/M0uY/whfybVM2G2n75YDHvAU8q /k/8KupvoJtqHnIIoNWAA0xDLzkWPJXpP6/aE/wZEq0c5odYVBRkGRV9ODJFBJ24+hMS ELPg== X-Gm-Message-State: AODbwcB33Ss92M4pVwjOZGJlBNFE4DlTH4MoDrs3xU0pW9cGYw2GDht6 fCTFJbVPhE/XvkQtHZAwoOhyfyD49A== X-Received: by 10.176.81.4 with SMTP id e4mr12937419uaa.33.1496693893686; Mon, 05 Jun 2017 13:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.25.69 with HTTP; Mon, 5 Jun 2017 13:18:13 -0700 (PDT) In-Reply-To: <1830430.b8hTZcbnc5@kitterma-e6430> References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <1830430.b8hTZcbnc5@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 5 Jun 2017 13:18:13 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c191490deea6705513c338c" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:18:16 -0000 --94eb2c191490deea6705513c338c Content-Type: text/plain; charset="UTF-8" On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman wrote: > I hear you. I expect this to be the most contentious part of the draft. > > Here's my counter argument: > > The first DKIM RFC (RFC 4871), published in 2007 said: > > > Signers MUST implement and SHOULD sign using rsa-sha256 > > I believe that the only reason rsa-sha1 was included at all was to make > transition from domainkeys easier (see RFC 4870). That's also (as I > understand it where the 512 bit minimum key size came from). > As I recall, there were also implementations of DKIM made during its development (even before its IETF time) that supported both, and defaulted to rsa-sha1 because support for SHA256 in OpenSSL was new and not universally deployed. Some of them were still running in the wild, and SHA1 wasn't fully deprecated, so the choice was made to be inclusive while encouraging use of the newer stuff as much as possible. > As a working group document editor, I'll change it however the group wants > (of > course), but I think we should either kill rsa-sha1 entirely in this > document > or leave it out entirely and let one of the follow-on documents add a new > algorithm and remove rsa-sha1. Preferably a clean kill or, failing that, > not > at all is what I think we should do. > I would omit it from the updated version entirely, and mark it "obsolete" in the registry. -MSK, from the floor --94eb2c191490deea6705513c338c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
I hear you.=C2=A0 I exp= ect this to be the most contentious part of the draft.

Here's my counter argument:

The first DKIM RFC (RFC 4871), published in 2007 said:

> Signers MUST implement and SHOULD sign using rsa-sha256

I believe that the only reason rsa-sha1 was included at all was to make
transition from domainkeys easier (see RFC 4870).=C2=A0 That's also (as= I
understand it where the 512 bit minimum key size came from).

As I recall, there were also implementations of DKIM = made during its development (even before its IETF time) that supported both= , and defaulted to rsa-sha1 because support for SHA256 in OpenSSL was new a= nd not universally deployed.=C2=A0 Some of them were still running in the w= ild, and SHA1 wasn't fully deprecated, so the choice was made to be inc= lusive while encouraging use of the newer stuff as much as possible.
=C2= =A0
As a working group document edi= tor, I'll change it however the group wants (of
course), but I think we should either kill rsa-sha1 entirely in this docume= nt
or leave it out entirely and let one of the follow-on documents add a new algorithm and remove rsa-sha1.=C2=A0 Preferably a clean kill or, failing th= at, not
at all is what I think we should do.

I = would omit it from the updated version entirely, and mark it "obsolete= " in the registry.

-MSK, from the floor
--94eb2c191490deea6705513c338c-- From nobody Mon Jun 5 13:23:51 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB06129C6B for ; Mon, 5 Jun 2017 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net 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 rDmKgWJ8zmTi for ; Mon, 5 Jun 2017 13:23:49 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 70843128BB6 for ; Mon, 5 Jun 2017 13:23:49 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:3898:64a5:7bf:a335]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v55KNlvA022171 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 5 Jun 2017 13:23:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1496694229; bh=Lz2yQ1zjEmcF4IaJ2dMfGPtOxq+r+jQ+RPMbG1/NngM=; h=Subject:To:References:From:Date:In-Reply-To; b=mBU6rPmVH9LwTE2VaZNXZR7iHd+KDqWOAvQyf23CZAuPtarjIiQ/TH3c8909oKrFa XbSXj0cWOeX/PZ7mU5a4GeUUVveRC6847Nsqrgu6Iy+grlj6U2VN831jSbalQRMCwG iIaFF5uEGkVZ6cMWL0bqjgkyG7IcYUCuvkw1tLGk= To: dcrup@ietf.org References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <1830430.b8hTZcbnc5@kitterma-e6430> From: Jim Fenton Message-ID: <5b4fafd6-11f7-5c9e-6c28-bcbfb38b108f@bluepopcorn.net> Date: Mon, 5 Jun 2017 13:23:41 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8B18006C9753EC90D438D5C1" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:23:51 -0000 This is a multi-part message in MIME format. --------------8B18006C9753EC90D438D5C1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 6/5/17 1:18 PM, Murray S. Kucherawy wrote: > On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman > wrote: > > I hear you. I expect this to be the most contentious part of the > draft. > > Here's my counter argument: > > The first DKIM RFC (RFC 4871), published in 2007 said: > > > Signers MUST implement and SHOULD sign using rsa-sha256 > > I believe that the only reason rsa-sha1 was included at all was to > make > transition from domainkeys easier (see RFC 4870). That's also (as I > understand it where the 512 bit minimum key size came from). > > > As I recall, there were also implementations of DKIM made during its > development (even before its IETF time) that supported both, and > defaulted to rsa-sha1 because support for SHA256 in OpenSSL was new > and not universally deployed. Some of them were still running in the > wild, and SHA1 wasn't fully deprecated, so the choice was made to be > inclusive while encouraging use of the newer stuff as much as possible. That matches my recollection. There was an effort to maintain DomainKeys compatibility for selector (DNS TXT) records but the choice of hash doesn't affect them. The signatures were different anyway. > > > As a working group document editor, I'll change it however the > group wants (of > course), but I think we should either kill rsa-sha1 entirely in > this document > or leave it out entirely and let one of the follow-on documents > add a new > algorithm and remove rsa-sha1. Preferably a clean kill or, > failing that, not > at all is what I think we should do. > > > I would omit it from the updated version entirely, and mark it > "obsolete" in the registry. Concur. -Jim --------------8B18006C9753EC90D438D5C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/5/17 1:18 PM, Murray S. Kucherawy wrote:
On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman <sklist@kitterman.com> wrote:
I hear you.  I expect this to be the most contentious part of the draft.

Here's my counter argument:

The first DKIM RFC (RFC 4871), published in 2007 said:

> Signers MUST implement and SHOULD sign using rsa-sha256

I believe that the only reason rsa-sha1 was included at all was to make
transition from domainkeys easier (see RFC 4870).  That's also (as I
understand it where the 512 bit minimum key size came from).

As I recall, there were also implementations of DKIM made during its development (even before its IETF time) that supported both, and defaulted to rsa-sha1 because support for SHA256 in OpenSSL was new and not universally deployed.  Some of them were still running in the wild, and SHA1 wasn't fully deprecated, so the choice was made to be inclusive while encouraging use of the newer stuff as much as possible.

That matches my recollection. There was an effort to maintain DomainKeys compatibility for selector (DNS TXT) records but the choice of hash doesn't affect them. The signatures were different anyway.
 
As a working group document editor, I'll change it however the group wants (of
course), but I think we should either kill rsa-sha1 entirely in this document
or leave it out entirely and let one of the follow-on documents add a new
algorithm and remove rsa-sha1.  Preferably a clean kill or, failing that, not
at all is what I think we should do.

I would omit it from the updated version entirely, and mark it "obsolete" in the registry.

Concur.

-Jim

--------------8B18006C9753EC90D438D5C1-- From nobody Mon Jun 5 13:24:46 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AFB129C6E for ; Mon, 5 Jun 2017 13:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 1zSLmu5j7D7n for ; Mon, 5 Jun 2017 13:24:43 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCD1128BB6 for ; Mon, 5 Jun 2017 13:24:43 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DEFB7C401BE for ; Mon, 5 Jun 2017 15:24:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496694279; bh=SsCgk/M1/CH0oE8W2KSUWB7RlSfBdsq2nejSh1lfgCM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=p62QGJBd3Mi3Ds/3bAfjnHjScWwjqM6h+MWj9Wqx2Vao0/NV4V9YLt1G4UoQWiRzn wlV1c0ZbmSPhHi8YhwuCOLxamifes/rPfV4a0zSWseW5i6CRcl/pt7XNw/Ixq+QczV azYPaF4DHA9OGZq5Ri5AzNvqdwwxUQy4mLxd8wS8= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 05 Jun 2017 16:24:39 -0400 Message-ID: <15443906.qFJeu8PeI7@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <1830430.b8hTZcbnc5@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:24:45 -0000 On Monday, June 05, 2017 01:18:13 PM Murray S. Kucherawy wrote: > On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman > > wrote: > > I hear you. I expect this to be the most contentious part of the draft. > > > > Here's my counter argument: > > > > The first DKIM RFC (RFC 4871), published in 2007 said: > > > Signers MUST implement and SHOULD sign using rsa-sha256 > > > > I believe that the only reason rsa-sha1 was included at all was to make > > transition from domainkeys easier (see RFC 4870). That's also (as I > > understand it where the 512 bit minimum key size came from). > > As I recall, there were also implementations of DKIM made during its > development (even before its IETF time) that supported both, and defaulted > to rsa-sha1 because support for SHA256 in OpenSSL was new and not > universally deployed. Some of them were still running in the wild, and > SHA1 wasn't fully deprecated, so the choice was made to be inclusive while > encouraging use of the newer stuff as much as possible. > > > As a working group document editor, I'll change it however the group wants > > (of > > course), but I think we should either kill rsa-sha1 entirely in this > > document > > or leave it out entirely and let one of the follow-on documents add a new > > algorithm and remove rsa-sha1. Preferably a clean kill or, failing that, > > not > > at all is what I think we should do. > > I would omit it from the updated version entirely, and mark it "obsolete" > in the registry. > > -MSK, from the floor OK. Unfortunately I mashed the upload button on -01 before I saw this, but that makes sense to me. I'll do it for -02. Unfortunately the draft submission site got confused about me being me, so I'm waiting for an email to confirm it's OK to change the author of the draft from me to me, so it may be a few minutes before it shows up. Thanks, Scott K From nobody Mon Jun 5 13:25:27 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA79129C62; Mon, 5 Jun 2017 13:25:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149669432653.3250.262026628393369373@ietfa.amsl.com> Date: Mon, 05 Jun 2017 13:25:26 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-01.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:25:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update of the IETF. Title : Cryptographic Algorithm and Key Usage Update to DKIM Author : Scott Kitterman Filename : draft-ietf-dcrup-dkim-usage-01.txt Pages : 6 Date : 2017-06-05 Abstract: The cryptographic algorithm and key size requirements included when DKIM was designed in the last decade are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimaly suitable for operation with currently specified algorithms. This document updates RFC 6376. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-01 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 5 13:35:15 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5C12E03C for ; Mon, 5 Jun 2017 13:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 eRcDICE0Q5Vw for ; Mon, 5 Jun 2017 13:35:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93042128D6F for ; Mon, 5 Jun 2017 13:35:09 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9D43DC401BE for ; Mon, 5 Jun 2017 15:35:08 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496694908; bh=E54FToQ9wsZVD/6nrHX1BaCI4ZHZY1VZPBDw6dHQbCY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=1r44IkAS4fYiD9QwZ48mJjn8PRRSWzEAM2F7wLggFTqEyXdq+7fpreKfWOw5YYzez /GHG+S8EGuKp3rXd3uHcJgI8aaiPJ0UC5mjvve4VKtyJuUhJmm30L5HKTn3V+slWFT atTmVRmu4/wqWus9LCgUFznG2VqULJ1lXvrPV2AI= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 05 Jun 2017 16:35:08 -0400 Message-ID: <1707162.iKDblKR2ho@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149619233095.19793.14947085917778354002@ietfa.amsl.com> <1830430.b8hTZcbnc5@kitterma-e6430> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart4873468.UmegzGKBkX" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2017 20:35:12 -0000 This is a multi-part message in MIME format. --nextPart4873468.UmegzGKBkX Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Monday, June 05, 2017 01:18:13 PM Murray S. Kucherawy wrote: > On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman > > wrote: > > I hear you. I expect this to be the most contentious part of the draft. > > > > Here's my counter argument: > > > > The first DKIM RFC (RFC 4871), published in 2007 said: > > > Signers MUST implement and SHOULD sign using rsa-sha256 > > > > I believe that the only reason rsa-sha1 was included at all was to make > > transition from domainkeys easier (see RFC 4870). That's also (as I > > understand it where the 512 bit minimum key size came from). > > As I recall, there were also implementations of DKIM made during its > development (even before its IETF time) that supported both, and defaulted > to rsa-sha1 because support for SHA256 in OpenSSL was new and not > universally deployed. Some of them were still running in the wild, and > SHA1 wasn't fully deprecated, so the choice was made to be inclusive while > encouraging use of the newer stuff as much as possible. > > > As a working group document editor, I'll change it however the group wants > > (of > > course), but I think we should either kill rsa-sha1 entirely in this > > document > > or leave it out entirely and let one of the follow-on documents add a new > > algorithm and remove rsa-sha1. Preferably a clean kill or, failing that, > > not > > at all is what I think we should do. > > I would omit it from the updated version entirely, and mark it "obsolete" > in the registry. > > -MSK, from the floor How about this (rfcdiff attached)? Scott K --nextPart4873468.UmegzGKBkX Content-Disposition: attachment; filename="draft-ietf-dcrup-dkim-usage-from--01.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-dcrup-dkim-usage-from--01.diff.html" Diff: draft-ietf-dcrup-dkim-usage-01.txt - draft-ietf-dcrup-dkim-usage.txt
 draft-ietf-dcrup-dkim-usage-01.txt   draft-ietf-dcrup-dkim-usage.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Updates: 6376 (if approved) June 5, 2017 Updates: 6376 (if approved) June 5, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: December 7, 2017 Expires: December 7, 2017
Cryptographic Algorithm and Key Usage Update to DKIM Cryptographic Algorithm and Key Usage Update to DKIM
draft-ietf-dcrup-dkim-usage-01 draft-ietf-dcrup-dkim-usage-02
Abstract Abstract
The cryptographic algorithm and key size requirements included when The cryptographic algorithm and key size requirements included when
DKIM was designed in the last decade are functionally obsolete and in DKIM was designed in the last decade are functionally obsolete and in
need of immediate revision. This document updates DKIM requirements need of immediate revision. This document updates DKIM requirements
to those minimaly suitable for operation with currently specified to those minimaly suitable for operation with currently specified
algorithms. This document updates RFC 6376. algorithms. This document updates RFC 6376.
Status of This Memo Status of This Memo
skipping to change at page 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. DKIM Signing and Verification Algorithms . . . . . . . . . . 3 3. DKIM Signing and Verification Algorithms . . . . . . . . . . 3
3.1. The rsa-sha1 Signing Algorithm . . . . . . . . . . . . . 3 3.1. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3
3.2. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3 3.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4
3.4. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4
4. The DKIM-Signature Header Field . . . . . . . . . . . . . . . 4 4. The DKIM-Signature Header Field . . . . . . . . . . . . . . . 4
5. Key Management and Representation . . . . . . . . . . . . . . 4 5. Key Management and Representation . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7.1. DKIM Hash Algorithms . . . . . . . . . . . . . . . . . . 5 7.1. DKIM Hash Algorithms . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 3, line 16 skipping to change at page 3, line 16
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. DKIM Signing and Verification Algorithms 3. DKIM Signing and Verification Algorithms
This section replaces [RFC6376] Section 3.3 in its entirety. This section replaces [RFC6376] Section 3.3 in its entirety.
DKIM supports multiple digital signature algorithms. Two algorithms Generally, DKIM supports multiple digital signature algorithms. One
were defined by [RFC6376]: rsa-sha1 and rsa-sha256. Signers MUST algorithms, rsa-sha256, is currenlty defined. Signers MUST implement
implement and sign using rsa-sha256. Verifiers MUST implement rsa- and sign using rsa-sha256. Verifiers MUST implement rsa-sha256.
sha256. The rsa-sha1 signing algorithm is obsolete and MUST NOT be
used.
3.1. The rsa-sha1 Signing Algorithm
This algorithm is obsolete and MUST NOT be used.
3.2. The rsa-sha256 Signing Algorithm 3.1. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described The rsa-sha256 Signing Algorithm computes a message hash as described
in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the
hash-alg. That hash is then signed by the Signer using the RSA hash-alg. That hash is then signed by the Signer using the RSA
algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg
and the Signer's private key. The hash MUST NOT be truncated or and the Signer's private key. The hash MUST NOT be truncated or
converted into any form other than the native binary form before converted into any form other than the native binary form before
being signed. The signing algorithm SHOULD use a public exponent of being signed. The signing algorithm SHOULD use a public exponent of
65537. 65537.
3.3. Key Sizes 3.2. Key Sizes
Selecting appropriate key sizes is a trade-off between cost, Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
all keys. Verifiers MUST be able to validate signatures with keys all keys. Verifiers MUST be able to validate signatures with keys
ranging from 1024 bits to 4096 bits, and they MAY be able to validate ranging from 1024 bits to 4096 bits, and they MAY be able to validate
signatures with larger keys. Verifier policies can use the length of signatures with larger keys. Verifier policies can use the length of
the signing key as one metric for determining whether a signature is the signing key as one metric for determining whether a signature is
acceptable. acceptable.
skipping to change at page 4, line 9 skipping to change at page 4, line 4
Factors that should influence the key size choice include the Factors that should influence the key size choice include the
following: following:
o The practical constraint that large (e.g., 4096-bit) keys might o The practical constraint that large (e.g., 4096-bit) keys might
not fit within a 512-byte DNS UDP response packet not fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 2048 bits may be o The security constraint that keys smaller than 2048 bits may be
subject to off-line attacks subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email o Larger keys impose higher CPU costs to verify and sign email
o Keys can be replaced on a regular basis; thus, their lifetime can o Keys can be replaced on a regular basis; thus, their lifetime can
be relatively short be relatively short
o The security goals of DKIM,[RFC6376], are modest compared to o The security goals of DKIM,[RFC6376], are modest compared to
typical goals of other systems that employ digital signatures typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes. See [RFC3766] for further discussion on selecting key sizes.
3.4. Other Algorithms 3.3. Other Algorithms
Other algorithms will be defined in the future. Verifiers MUST Other algorithms will be defined in the future. Verifiers MUST
ignore any signatures using algorithms that they do not implement. ignore any signatures using algorithms that they do not implement.
4. The DKIM-Signature Header Field 4. The DKIM-Signature Header Field
This section updates the a= tag in [RFC6376] Section 3.5. This section updates the a= tag in [RFC6376] Section 3.5.
The text description of the tag is now: The text description of the tag is now:
skipping to change at page 5, line 4 skipping to change at page 4, line 45
This section updates the h= tag in [RFC6376] Section 3.6.1. This section updates the h= tag in [RFC6376] Section 3.6.1.
The following ABNF element is updated: The following ABNF element is updated:
ABNF: ABNF:
key-h-tag-alg = "sha256" / x-key-h-tag-alg key-h-tag-alg = "sha256" / x-key-h-tag-alg
6. Security Considerations 6. Security Considerations
This document does not change the Security Considerations of This document does not change the Security Considerations of
[RFC6376]. It reduces the risk of signature compromise due to weak [RFC6376]. It reduces the risk of signature compromise due to weak
cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are
resolved. resolved due to the removal of rsa-sha1 from DKIM..
7. IANA Considerations 7. IANA Considerations
IANA is requested to update registries as follows. IANA is requested to update registries as follows.
7.1. DKIM Hash Algorithms 7.1. DKIM Hash Algorithms
The following value is changed in the DKIM Hash Algorithms The following value is changed in the DKIM Hash Algorithms
+------+-----------------+----------+ +------+-----------------+----------+
 End of changes. 9 change blocks. 
19 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart4873468.UmegzGKBkX-- From nobody Wed Jun 7 22:47:21 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F081129B9B; Wed, 7 Jun 2017 22:47:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149690083334.25644.8501543904193079634@ietfa.amsl.com> Date: Wed, 07 Jun 2017 22:47:13 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 05:47:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update of the IETF. Title : Cryptographic Algorithm and Key Usage Update to DKIM Author : Scott Kitterman Filename : draft-ietf-dcrup-dkim-usage-02.txt Pages : 6 Date : 2017-06-07 Abstract: The cryptographic algorithm and key size requirements included when DKIM was designed in the last decade are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimaly suitable for operation with currently specified algorithms. This document updates RFC 6376. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-02 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 7 22:50:24 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69414126C3D for ; Wed, 7 Jun 2017 22:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 UWbhHC7mlEJC for ; Wed, 7 Jun 2017 22:50:20 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C19A120726 for ; Wed, 7 Jun 2017 22:50:20 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6039CC401DD for ; Thu, 8 Jun 2017 00:50:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1496901019; bh=00huhCfYyytfOMIGE/wRWTiTdB71qVn7hSFSFuFSk4s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=CceGq1RVkaxCs1zM5wJ7hPyBBtZAZPcs+7MGG4qQWireNdiBgDl0SU7W67jigj/sv puB0T/9nS9pbSjtQ1b/ZuzuIELSlz/GsHyv9xneFbiKkwMqcY1GhjnmtX6I6Q4Xvb+ jbdPGctW0ybngEKoSvEn/H1ungox69FnOBojYGO4= From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 08 Jun 2017 01:50:13 -0400 Message-ID: <59890109.NLzkLIiF7F@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <149690083334.25644.8501543904193079634@ietfa.amsl.com> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jun 2017 05:50:22 -0000 On Wednesday, June 07, 2017 10:47:13 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DKIM Crypto Update of the > IETF. > > Title : Cryptographic Algorithm and Key Usage Update to > DKIM Author : Scott Kitterman > Filename : draft-ietf-dcrup-dkim-usage-02.txt > Pages : 6 > Date : 2017-06-07 > > Abstract: > The cryptographic algorithm and key size requirements included when > DKIM was designed in the last decade are functionally obsolete and in > need of immediate revision. This document updates DKIM requirements > to those minimaly suitable for operation with currently specified > algorithms. This document updates RFC 6376. There are only a few small changes in this revision. I applied the diff I posted in response to msk's suggestion about saying even less about rsa-sha1 and I filled out the acknowledgements with everyone who's commented about the draft (if I missed you or you'd rather not be listed, please let me know). Please give this revision a good review and based on the feedback to date, I think it's pretty close to done. Scott K From nobody Fri Jun 9 09:12:20 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F501205D3 for ; Fri, 9 Jun 2017 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 AKll8cVntrJd for ; Fri, 9 Jun 2017 09:12:17 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81FC7124234 for ; Fri, 9 Jun 2017 09:12:17 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id m47so398769iti.0 for ; Fri, 09 Jun 2017 09:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iGVjVIgEUba/TZGmnsA7AzREC0rFAUxteQznIXRWVqc=; b=Awfrh/RLT9jixbo0NTY85coZDSYT5o2rbgk/Au0AHScGKp8FaKH0QhBxmKv+bjYflU 8i4TunLHCG12crNtrqB5i+Ie853rijz6fUoS3tOeXb46p7dKW1ozpyGT3SgEWO8p0mre NbQxLjZvNTGBk9o98utXGB/FQ4/OF7nDGbJjCvTyEQFl+tCqe10WIuCn9Y9L1xOG0rJW r05+ru+SvKkAzIOWcljfmHG13Ue7yweVIT1i3OXManP1CSRnztCfvS4W+iL/seAwe600 ed6e4quFZ5PSys+GlI2OCQDQfTWH5C5bzlcPs6GqhBrjLeU/q02d6GCs6cyh4SVy+clW gX8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iGVjVIgEUba/TZGmnsA7AzREC0rFAUxteQznIXRWVqc=; b=NpnhoGAMLNFiBaJWzlfDRx0bkVFtimGCiqPgC4AlABbfJbG5CLp1hGoVdyWPtjgE7e ILUojxjE8liAq+v3AmJVPvx3PBh3yFhJGSuwdoW46hWtkF6raks5psoNNeFdtU9xFKOp jkLVJY+txwsCiiOt4e5CccZ1E95HeaU09EHT8Oi8DnRaGUQxwgNpGRp5HSbhph1lG8s0 RdJCrOIA6ROF8LmzSmmbKOr21sLawXvVwjLfkSw0Gc/41onsTUmKCVyNC/tkys925LJB WL9nIkiihlcNAcXBiwevKwDx1pFbq6Qcn1dOn13qDt3casPrX3EQFEKaCSNz/uLr/WTn vfTg== X-Gm-Message-State: AODbwcBOocoxCvqjtLrwRnxHkNQRA5khYXEAckSwV7tie3UYRYAQRRWF jl4lzsuq3fpUFqKgZDigEd/ODxiwytUXUsI= X-Received: by 10.36.165.74 with SMTP id w10mr313715iti.14.1497024736705; Fri, 09 Jun 2017 09:12:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.66.7 with HTTP; Fri, 9 Jun 2017 09:12:16 -0700 (PDT) From: "Murray S. Kucherawy" Date: Fri, 9 Jun 2017 09:12:16 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403045fb5b0a6c09f0551893bea" Archived-At: Subject: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:12:19 -0000 --f403045fb5b0a6c09f0551893bea Content-Type: text/plain; charset="UTF-8" Colleagues, The IETF process doesn't require that working group documents be shepherded by the chairs. In an effort to increase the pool of people skilled at our processes, we started encouraging the use of non-chair shepherds even before the merged ART area was formed. I'd like to do that here too. It's been suggested that draft-ietf-dcrup-dkim-usage is ready for Working Group Last Call, but before we pull that trigger, I'd like to ask: Is anyone here interested in acting as document shepherd for this or any other DCRUP document? The chairs will happily help you through the process. -MSK, DCRUP co-chair --f403045fb5b0a6c09f0551893bea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

The IETF process doesn't requi= re that working group documents be shepherded by the chairs.=C2=A0 In an ef= fort to increase the pool of people skilled at our processes, we started en= couraging the use of non-chair shepherds even before the merged ART area wa= s formed.=C2=A0 I'd like to do that here too.

It's been sugg= ested that draft-ietf-dcrup-dkim-usage is ready for Working Group Last Call= , but before we pull that trigger, I'd like to ask: Is anyone here inte= rested in acting as document shepherd for this or any other DCRUP document?= =C2=A0 The chairs will happily help you through the process.

<= div>-MSK, DCRUP co-chair

--f403045fb5b0a6c09f0551893bea-- From nobody Fri Jun 9 09:57:46 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC71127419 for ; Fri, 9 Jun 2017 09:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 tqgwksomFGMX for ; Fri, 9 Jun 2017 09:57:42 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED4FB126C89 for ; Fri, 9 Jun 2017 09:57:41 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id w1so82348936qtg.2 for ; Fri, 09 Jun 2017 09:57:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=R9+4yFCeqglQGcZasiDy4UjzfP7YVw6DbflkwvSEtUk=; b=IUA56X+1skjiNTQChI/hSpnQTBtDrrF7PgactAeqojKYFQCMeb1UR01LEJPh1Lmfb1 CGK3rU9m5Hy5dqPx5UEKHCyCfkaul92RJli+IXR8Ob1lSfCVEzXjBk9tBNyF68klJ/Xo mseHLUk5cALxNKBKTh9uvVRnwhC++majchyCSdAcezJL1UuE2BIKGft2yWttNRaAZSwh O5TrcFxnphYcajdHg9fYjR9IkJ7hTewTMWPIZBSWzL5OXZ6kFKyyKiuQsJlhwrZf3AJN m8ZK3IL0pvSoJJ2qa9Dmgdp+8666RLyaSZEBpRJsGFAtqKUyBfzhme8szQLBccFTlnMq LIVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=R9+4yFCeqglQGcZasiDy4UjzfP7YVw6DbflkwvSEtUk=; b=AITA6jcrw52VZOA8Z9GiVYxV7BQcAAXCmtYCXXpyCkNwr9W7man70uASR090He0X6x /3fsZindrEugkuIZAZSCC9pjbFXYc/87h0JXfxuLwSTEsrz85WZEiKJTGVMslYGzDT/P eQD8K9pzRVABv+/i441jz4YsZJa9kTfe+ZrGbK4beGXLxOXn8+inotGJcu5DW3oXSg7o 3em/A7KDuICgbu9WYGS9oTpVonKv5liXgkt066Ne3RApLP/wYnOoAu32P1wB83Sb7Jme uqxHYlwkplDJaRxPlGF7b0YOYm1quyajiFiDdr3pw3Z3rWJxgnQSU/rW34Wt69rk0/om 7GEQ== X-Gm-Message-State: AODbwcD5qUnLyHxsSjl3fKBuJ2eqQCODltK6OHdTlIOaxkp7U5MHbPhG ckcdSxUU3gLHZncCUA8hGb41ji2KDJAFQto= X-Received: by 10.200.34.66 with SMTP id p2mr5273486qtp.2.1497027460452; Fri, 09 Jun 2017 09:57:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.242 with HTTP; Fri, 9 Jun 2017 09:57:20 -0700 (PDT) In-Reply-To: References: From: Seth Blank Date: Fri, 9 Jun 2017 09:57:20 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113d4df6005121055189def0" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 16:57:44 -0000 --001a113d4df6005121055189def0 Content-Type: text/plain; charset="UTF-8" I'm happy to volunteer to shepherd this document. On Fri, Jun 9, 2017 at 9:12 AM, Murray S. Kucherawy wrote: > Colleagues, > > The IETF process doesn't require that working group documents be > shepherded by the chairs. In an effort to increase the pool of people > skilled at our processes, we started encouraging the use of non-chair > shepherds even before the merged ART area was formed. I'd like to do that > here too. > > It's been suggested that draft-ietf-dcrup-dkim-usage is ready for Working > Group Last Call, but before we pull that trigger, I'd like to ask: Is > anyone here interested in acting as document shepherd for this or any other > DCRUP document? The chairs will happily help you through the process. > > -MSK, DCRUP co-chair > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a113d4df6005121055189def0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm happy to volunteer to shepherd this document.

On Fri, Jun 9, 2= 017 at 9:12 AM, Murray S. Kucherawy <superuser@gmail.com> = wrote:
Colleagues,<= br>
The IETF process doesn't require that working group documents be= shepherded by the chairs.=C2=A0 In an effort to increase the pool of peopl= e skilled at our processes, we started encouraging the use of non-chair she= pherds even before the merged ART area was formed.=C2=A0 I'd like to do= that here too.

It's been suggested that draft-ietf-dcrup-dkim-u= sage is ready for Working Group Last Call, but before we pull that trigger,= I'd like to ask: Is anyone here interested in acting as document sheph= erd for this or any other DCRUP document?=C2=A0 The chairs will happily hel= p you through the process.

-MSK, DCRUP co-chair


_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup




--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

<= a href=3D"mailto:seth@valimail.com" target=3D"_blank">seth@valimail.com= <= br>+1-415-894-2724
--001a113d4df6005121055189def0-- From nobody Fri Jun 9 13:13:33 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C372128DE7 for ; Fri, 9 Jun 2017 13:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CJ8a-MjjfVMa for ; Fri, 9 Jun 2017 13:13:30 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DF5128D3E for ; Fri, 9 Jun 2017 13:13:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A58ED300494 for ; Fri, 9 Jun 2017 16:13:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id N8E7TqUn_cYl for ; Fri, 9 Jun 2017 16:13:28 -0400 (EDT) Received: from new-host-4.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 763EF300425; Fri, 9 Jun 2017 16:13:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <59890109.NLzkLIiF7F@kitterma-e6430> Date: Fri, 9 Jun 2017 16:13:28 -0400 Cc: dcrup@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <08494F93-697D-4765-BAD9-BD4046340DC2@vigilsec.com> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <59890109.NLzkLIiF7F@kitterma-e6430> To: Scott Kitterman X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 20:13:32 -0000 > On Jun 8, 2017, at 1:50 AM, Scott Kitterman = wrote: >=20 > On Wednesday, June 07, 2017 10:47:13 PM internet-drafts@ietf.org = wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the DKIM Crypto Update of = the >> IETF. >>=20 >> Title : Cryptographic Algorithm and Key Usage Update = to >> DKIM Author : Scott Kitterman >> Filename : draft-ietf-dcrup-dkim-usage-02.txt >> Pages : 6 >> Date : 2017-06-07 >>=20 >> Abstract: >> The cryptographic algorithm and key size requirements included when >> DKIM was designed in the last decade are functionally obsolete and = in >> need of immediate revision. This document updates DKIM = requirements >> to those minimaly suitable for operation with currently specified >> algorithms. This document updates RFC 6376. >=20 > There are only a few small changes in this revision. I applied the = diff I=20 > posted in response to msk's suggestion about saying even less about = rsa-sha1=20 > and I filled out the acknowledgements with everyone who's commented = about the=20 > draft (if I missed you or you'd rather not be listed, please let me = know). >=20 > Please give this revision a good review and based on the feedback to = date, I=20 > think it's pretty close to done. I think the document is ready for WG Last Call. Russ From nobody Fri Jun 9 14:19:04 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351CE1275AB for ; Fri, 9 Jun 2017 14:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 8iQ38IxBuzNL for ; Fri, 9 Jun 2017 14:19:01 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0094.outbound.protection.outlook.com [104.47.37.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755C1120724 for ; Fri, 9 Jun 2017 14:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=54LBUyxZrTuUw4ZacWjqx4jMmQzinUehFTTtYj62NS4=; b=OzdvnZtQHeyPi/C8uxk7HNZhMa6D9ZfCLwF0aGiCFX6q9sDe6NSnUJFsDNVOp8mbpDIfMbr2xIqg37KEa53jRGAb/XkHjSlVrYmdV2sHpumkbyaXTi/kOY7v+J3wG/GZTID+JhK076+o7NJelvN+BGKQBUdWgxuc1zZszMaJr+M= Received: from SN1PR05CA0008.namprd05.prod.outlook.com (10.163.68.146) by SN1PR05MB1984.namprd05.prod.outlook.com (10.162.132.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Fri, 9 Jun 2017 21:19:00 +0000 Received: from BY2NAM05FT033.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by SN1PR05CA0008.outlook.office365.com (2a01:111:e400:5197::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5 via Frontend Transport; Fri, 9 Jun 2017 21:19:00 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by BY2NAM05FT033.mail.protection.outlook.com (10.152.100.170) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1143.19 via Frontend Transport; Fri, 9 Jun 2017 21:18:59 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 9 Jun 2017 14:18:58 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v59LIvPR006554; Fri, 9 Jun 2017 14:18:57 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 0F68E1144F; Fri, 9 Jun 2017 14:18:56 -0700 (PDT) To: , Russ Housley CC: Scott Kitterman In-Reply-To: <08494F93-697D-4765-BAD9-BD4046340DC2@vigilsec.com> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <59890109.NLzkLIiF7F@kitterma-e6430> <08494F93-697D-4765-BAD9-BD4046340DC2@vigilsec.com> Comments: In-reply-to: Russ Housley message dated "Fri, 09 Jun 2017 16:13:28 -0400." From: "Mark D. Baushke" Date: Fri, 9 Jun 2017 14:18:56 -0700 Message-ID: <28932.1497043136@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39860400002)(39450400003)(39840400002)(39410400002)(2980300002)(199003)(189002)(9170700003)(189998001)(77096006)(53416004)(76506005)(6392003)(7846003)(105596002)(55016002)(2950100002)(53936002)(230783001)(6246003)(6266002)(356003)(38730400002)(81166006)(8936002)(117636001)(8676002)(7696004)(5003940100001)(305945005)(229853002)(2906002)(4326008)(478600001)(54356999)(48376002)(50986999)(76176999)(86362001)(5660300001)(558084003)(47776003)(2810700001)(7126002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB1984; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT033; 1:UlaxR1KhQuGz63dDPnTo7ChF6y205r4OybJgbDH1CdJyTONGlj2ykcOCe8DAbgQLLP5Ew/9fFr5jAEWflIQmw1zs71vSFDkPTePiCm2Rety4MeWlXpEowbJ56jWQf/VNRh0OSSvQRmzPjs0mkdI+7Ie2zi/W58JRqj0MocVcOPW+TIiI/Fx8Ln0MBm25epE1b7fC0P5DUl9butaGMAf/oGDd6A3EbZvsTYc/J0L24eumAQzCcpJAaMMw67Gz7WIF94AtZQk/pgfcNSAqKZFoWniycy/vLI57Cfvwhog4zMYqM544+fZsWB+XmCMjTK+M9UawC1M5RThh9m6l6KJSaQ64Vxf4TevD/rYn5R38Tf83AGh4S2ks27N+guiy1Igv6Kxjx0EmN/nWiPc33XGFvQwauS1GoOpPCbmZ5HgwmtlbVVmjNN4AqxYkO9QEnmXCQnSePsxt4hPPIfxzMA9CzzqbBmXL2uANuotgwKZf0EVYzta1C/b45PWU8obSAdHUhYyn0LGfeX09SgWz2h1hcw== X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PR05MB1984: X-MS-Office365-Filtering-Correlation-Id: 3e035cb3-0e51-4705-f829-08d4af7d2589 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN1PR05MB1984; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 3:VZW64D7rhu+iSH2VWgsbdX/KJY3cdOeMwEj6vKo17kMlIzlaxXWus0EJiNF4dZdzx3UqH6l9e39I05txYwNjuY6qSC/M2eDA1rzMD4yDVZYDE3nSPMtpG0wCGrRjSUdwsBEdQl/I8RIkoOHcrR1YkmT5gn0/Uh4d/F66J5HQqjs0ctRT1YTH67ujJ+S7Eh5FXeRgrzWTu8CLhs3ULV4pXh4rmcKq5/twmkqpu6u8fnDYSLw5IIN2zkgtnKnzSkoi6yF2Fc1iKk58l7cTeYU8TPlR7GGD25osr8bOsKPl8Qkz+/1Dsjs6ESEE+NfHvsrJQZYW7wKDBdVtAyrKicUbceCYXR4BcDPp1S9LiTXQWedZ0mu2m5guv51bqCni/OZ1lxX448v25GEXWoza86TdBNcqAfMCu5QinFxh5060kh49Z9jIJ+buYGbh+/uXLXCPagG7nc4xFkNmaEn61eriMA== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 25:Fl60xKVJW+Cs7r+HqUbKaE9CpgmeJZ838y86blqgQHzhCMz9ql5vEmvNXALJLBPCGV2DYuU29Ukuxv8K3QyaY00z+avCxKo6f2+5rPa2Vkb0+uDU0W/zUnMvqeLHtPagPF32j/NBpPGw5QT1igcJDA03SH2MRUW0EXZqlIb/flJZFTb6QGHTlxUSWbeRTo3hIeS285+jwNYOYyigpSURb4i+0ZCJ5ZkDzGGoKx9pxWquFamvsVn1dfSCd5zOmiHskff3IeCMqhmecePyBKGQSsDrQ0OfMb1/AA+gNQX47mc5sxr4FZYlKOnR7j5E3qDCGaEirklp05icKWCgnVL8pKTTMyeH5x1wCySMtXYNhlnil2L95ZFmrIz3C/2EW4OFBBZTu/cygcXnRLMirznKQMrP9SUL/lo5+kibFwlglRXV/tgQAFEQkm/HGtgF+znq6TxrvyAeNG0RLUk0yfOkb0UmAfeKe3NRU83ZhYokwUo=; 31:QNZCbP4T3coBD5+WLdaKXztwwbrNT8tmsBOC68h2XnoidjBh7Woz7Q81fCSdnTcvvfi/lLmPye1PDC5plTuy9EJ8WdBf8wOax2abZ7C8vBr6re8KKPlCa28ZxpMVvAPObKx7dwxPQJ2S00OC9lSJ0URjLUkGyYsbOHXZJwtqCG7yvoBOSTRNvHI0XLPj4xmoy6UOoAB2nTG6DSwtFZkKfDRoZJGc5fkKnOe1ao4Za2uA+1XH1DpaY6ocsS1di58zmK6iatXI27dedysFSZ1OAw== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 20:yGG+uknPJw+wzig+bU5Jd8LhFY5OsPiKcoY63Jja7uJ6XaHpJZXhfIEr4cnI1LDROzShx02y+sNuI9WffaoBdXQmFRfCqkSsV7ts7yg1uSBhGJdmVWgy8GnUiLd/xD5fqyTvLEYYJnw5pA5APSF7uhmxzg/ZonVE3f4uh9O7TWnlHeaev8o8HBj2Z5NyK5AYHB+4R27qslXXBJQdkzH/JjkQYFK42Y2KhYEeSm9h4GX7g56GhmZSqTuDtiCYopOXjjCl/VwGiRYnTX1MKwmSR9YPL0ihGRKuIg7j++z48Prp7Kp81WoaMSzwNgFY3GJrpPdFOF1/0JfCyA7wItta87KmwnvwPtUaWtwfYaUckS5CK1y71w2qYqbEPNNjLhVHcRiQxy931H494UfPnNpY18Aw3NMX0oN6Hrd/X4NiK5pzfXeFYjvsWf0vB4VlF/GVLcdKsZ2FwXE9Sj5jjtGsbZJZz9dQLTWnPo4lZaoQdn3JBoqlxE+nxkCeOSwSJiaN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(13016025)(8121501046)(5005006)(93006095)(93003095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR05MB1984; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR05MB1984; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB1984; 4:W/FmOobU49sRktR+WriJoW5UfdBCs7BmofrSprPwTl?= =?us-ascii?Q?G+gx9uPvxA7cBKV1JydM4EO2IwQKOtPeQwvJBRi0HPfgurugWgew7SFfvyG1?= =?us-ascii?Q?9N2mV79WBJbROSMOq+Z1bbe7R7CqnC8AmXTaEvGkUK19p82Wfw9bntlNwsEt?= =?us-ascii?Q?xG5IW+2vyOhI5VvJXLS7NZtXlq+ojCSRFkcWhcVGmuKnVdJqwGTMsbfwRSPl?= =?us-ascii?Q?I+i/VjR3Sq2kRc0YRvFEiuNepq/TYKJTS6ZFCSrApONJ7zN1KqbDiTbwjHKD?= =?us-ascii?Q?h4iqT4e94PG9yjTGW+SWyd4lSn6ahE135zZk26DWw9mBIHw3/GC4wrymnKih?= =?us-ascii?Q?buMdJQM7qRRAT/KAN44CeyHzmSuMPTGW+uWN+s1Jn4cQDrfCpNzvMXuvdGIW?= =?us-ascii?Q?4jtgwLwjveuo3RmInUqoGvnh/J01z2/P0OhCSWjb7tv5xWPlFy+OuzZWJ/Z8?= =?us-ascii?Q?PqgLeAUsb6pS7MtnxOldkJGD4iJ9ybJkG/ZvOtS1qTaSg7MBqKNAiNhGtGlJ?= =?us-ascii?Q?sb+PPDSuDldPsFJ5SJ6JyJc57ZmZZI94yHQRnGEuvJa6sJXw7+N5vmY4NcpX?= =?us-ascii?Q?4NgHgkezjUslySOKtQ+iMs9xPH7Ts/pqpQYkQKzgqosxXzZhfG1DzZemCJ64?= =?us-ascii?Q?8LsTh2UDbi8k81aByzXiG9g/BSLF4F9+KnVK1e+ITka+aZWLeqoj/nU0ffwU?= =?us-ascii?Q?6uSwtjkUsbNZK32ceZMp+yVlFn/KmFeFzFUqwizchRqNtQ/T0dvUBri8UVo6?= =?us-ascii?Q?HzA4wO4fnLRQmh9EcBuym9QXGY8mG6nS1eVPfDjHzJHfKnlL7sW5aRk1wwUY?= =?us-ascii?Q?VS5aljUzDVXoog6nPE/kAAxQc/BPx+RlOiAwTR3+dkVsEdbTWSdWZLvLBP7w?= =?us-ascii?Q?F8GMWF6GjT+eUOqTfiTm7RBNqyx4KbF1JKJPZyOn9JHp5FOzN0slZta4tRmG?= =?us-ascii?Q?80nHkcHZ5LpCpz9tITE+Uge6pqBv1IRQwMS7y5lLOYDa6EXHrVsH1EQCyCj5?= =?us-ascii?Q?OUe67biPRxoGwHlLdBNheCIbZ9o59MWtkMSQiFqXWaM22ukhHhTJOJNNVUu0?= =?us-ascii?Q?hVTyWJ9RBshYo7eu0JwVF8d/rkrrG0LZa1uqjeUw2MSfZURvJLgjLMRmyL7P?= =?us-ascii?Q?r5KQci2MXMZ2jw2KHDeABqllfCM5zF9ZJkFTfO2JAvuxnoqxqUgKipOrWVcD?= =?us-ascii?Q?6q+UvOda8TQl/lthpZJyetBDN52wsRV7EpMje1lYSPm6jWI0O28xPhVw7JhG?= =?us-ascii?Q?qUOjbYsWNJi2tYYVE=3D?= X-Forefront-PRVS: 03333C607F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB1984; 23:7A3x/ejKGlFaZizN93I9bXie4wyURi4VrscfZ8f3T?= =?us-ascii?Q?qSS4X9Zpd+mfeFexNIJDusaxmFsRUpfZByFZyMao3e8cumtWQ6lnpu3xHPDv?= =?us-ascii?Q?wvCnloeF4GdRIwBXyH2fjYi8t+a4nVRuJJ3YHJNatcCZ//RghCTHDh9BBLpW?= =?us-ascii?Q?0FrQhCWLQuMbHfnX0N9/yo/Lkraap3U84aYecRFm4hTWN227v2pOks5yV0qs?= =?us-ascii?Q?cVS92mjBlKAwFpED86vlbcoD1D+vLEKIn3tOfLG1Sv+6w8ikAb1NyBcvoCTm?= =?us-ascii?Q?Cfr2m6eDVS2AiNBDzgz5jAUB0Yb9xVRNNoYpaHNUopS59x3eRIlp6p1jxd3n?= =?us-ascii?Q?TK37NnYAPDLCQ2Z9S/vrpdc2k9UT9g8VAkWrb4wXpnSNET0ZQ4uVbwxTqYgM?= =?us-ascii?Q?rZ8Vciv2u5QvQWLTk4Vb/ygCo57Fv5vTriggswN4rNQx52cr8tGmNlayPDR1?= =?us-ascii?Q?/1I0hTymK6sR/x0APc+YthEe/8/dR0kXhR8Idw6/48y+Aau17NhVS9bB3LJq?= =?us-ascii?Q?qPGuVncr8Aq1Cy9IU7jnr9//f3S8WYz3XeWkdVJRNQTRcKqZT2dP7qlnjtmf?= =?us-ascii?Q?i15CI7jrj9r371qoC2fhy11qiyR58rDCyB8LE6dKAb8fMlry7WLV/FFY2aqA?= =?us-ascii?Q?4b5zCga3CJAiOoHlHSwZKUkFlKkNvjn1a7Q4iyF46I5b8qF4ksJ2hFE3NAoL?= =?us-ascii?Q?I1vni7F6fLKhX7+z6foc/hheTgpT2D/UZ+ToJBKJ3rzNMw3jQJCTG2V9dGOl?= =?us-ascii?Q?HMg8fdr0YIJCiGhWLDhoQvP2aGpOseLGC99S18Pu0T8JbA5+shKWe2ttvS/F?= =?us-ascii?Q?0mEyqcWVpBGw01swK/q4hcLzYUbD8RnrQCL0zwsDKi/oBuMfwEnOWnQVBXVa?= =?us-ascii?Q?EPjRvFCRtOFAeZS1OmUa6bQc0WE3m34WgrqP0eDFB7oJyTFixoSiQjTuP+k0?= =?us-ascii?Q?AwvvuS4OYGDWzvqKD8sANEjJtHqCn0bMieSOZ54etPBYtG3FnMmf4kCkC2L5?= =?us-ascii?Q?v3jf87B+Dnl81mfOCL+LPOubJwGWK361fLp69ANjO0xaOk1apMH8o7k4vKkE?= =?us-ascii?Q?JfzKXE2gso2bFbtQWk73RUI+sKW1sBi1ImBMTfQjmogRSS+peD5h9e3UU1Nx?= =?us-ascii?Q?tBivYzsYAR8jK7pdn1c4WLyyNFb+fuVhgVK5khL0Umy8gbBQREL8hUlMlVIF?= =?us-ascii?Q?RHN16o4aehomosPNw1ouO89vhtqM9408aHk?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 6:mv/TvoOxQ6Evi1H5PNd8418A0Yw56OzJchKMpb7uQtvzW481Dk2woRFGW7oYU+PfTpJS6fhJ35ybnEhAEoDoOGiuyOIrim9dkd4NRNzuCbOsrNSUNNA8VyHs5M7TI67HjCePCZKEnWndO9sFNTLl4koBlsyVDwDjEmY0Wr9hc+MA9K0lTizPmjhU/cdCQPLh/2vHzTpECA2s4pGQMsCJXzfNC+XWsqOgLtYZD032QcjHjaKdYVdNcZWYwPu+V0aoBkSNlfG6PWX9ID4o5lA4eHdHiTiedq3yEdpIXtp2LnzrzhDrq4bvoD2058Sg2JDjUy/FqUlTwmQelpqZRQ9yWsD1MPyqWU+hjHoE+woHg6KSpdPyVfehOMKrtUNK9R1OY35OGmml0KXZsRiw2FmQY2NEqBla5SvnL/4OHxHzeAJP+GLhkbkhH3vIMdAA/WJdl6HNeIg4TY75PaYy7e75hweX478i467QBcM/leqcxcX2uBCB4b6P3GXAH9T5f2zznzQPnXmzLIM4S+zqWl5v13fBl6w/tfEj3bwHo7s66bs= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 5:TS3mK39cg12Vm5Ot0YLNgFAnstK1nQh6k+QH1as8X5U1Te4ZhdYm+rjRMDWaAQV0p6AJKW/N65+iwM5RUUBkzZcWG4hoWDa/AZF4RkMgQ4Dsc0Vl49uDr4f+C4D+0CCvwO5GY+qiCDIwdi92+awILUakU4XqFSf1js90DLyLhQVHD6R6Ii6ybBfAAOJGo9Dsrc5MFhTzzcBYmjqhNLiDOxL1eY17xoKPOYHLpqGLCw1H5GIzbT3BqXcTEbxjWjxvQ89eb1QSitKfJL/3OHu8lL1kPYUi15sIJ6jfzJbUcO5jrkegIN3oGdVLtlgmE3cSj/gmb31B+W0dX1dFkJGypTy0sL6iA1q/zBhe3WgCKBfVAzCC++yvVsyO8AgtJwWBXymmTTbEtOl+huisrTDdJL60pUvIuhIUkBBLV1FzNCuvxs3980W4hdHA3DbD0f4kS3bNjFolKmisEF3pcprrMrxXYmN3xpuIUDIghFeVG/yM78e2ycv3TGXrUqOQ/5aE; 24:ZJAewPe0s9YgdIfBl/4vreDtlCNdQmZEe15bSFE5oggU+Wgw1aYFb6k9TsQNYStFkmuHa3f/kOX6rTlCl4MGGmCyePTrwoJqgWTzdJZeBs0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 7:x+m8ppi4wqB8O4ocOe8mw75xpX1i/PC0HyXQSVGYr/r0R7W1+UtjwLZp10Lvr2V7dJPNEOOHdMutO0YOsBeTac6D4yIo5UhkjGboWkpc28SHMCokRTlj905LoGeJIQ3A7jZ1GN9xQQb7awXuImDbm7GjaIMZ8qtTWYDQRWWZdplLQ23vnBiyHT6BmY9rAFAaBe8xBabWECEVew0+IrGLkDGEQ0NSM+PDLntS0PrlFJU8IzDHkV9GTmTn7iBvShYBbokFBnHzTYU8UEHsh7FXd70LeFn8clhnBFlgqzEdayKsJu/wrLcUBxPPMGnX3wAhjRTGVIQIvA1RDcUOYxbAWQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jun 2017 21:18:59.9310 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB1984 Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2017 21:19:03 -0000 Russ Housley writes: > I think the document is ready for WG Last Call. I agree. fwiw: The only typo I see remaining is at the end of Section 6 Security Considerations 'from DKIM..' uses two period characters rather than just one. -- Mark From nobody Fri Jun 9 17:26:04 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87391126557 for ; Fri, 9 Jun 2017 17:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ygCIDtxXw3GR for ; Fri, 9 Jun 2017 17:26:01 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283E41200FC for ; Fri, 9 Jun 2017 17:26:01 -0700 (PDT) Received: (qmail 78614 invoked from network); 10 Jun 2017 00:26:00 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jun 2017 00:26:00 -0000 Date: 10 Jun 2017 00:25:38 -0000 Message-ID: <20170610002538.10992.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 00:26:02 -0000 In article you write: >It's been suggested that draft-ietf-dcrup-dkim-usage is ready for Working >Group Last Call, ... Given that we are nowhere close to deciding what elliptic algorithm(s) to add, it seems kind of premature to me. R's, John From nobody Fri Jun 9 19:14:38 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A476126CD6 for ; Fri, 9 Jun 2017 19:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 ejadxdZWwcUy for ; Fri, 9 Jun 2017 19:14:35 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8788D126C7A for ; Fri, 9 Jun 2017 19:14:35 -0700 (PDT) Received: from [10.240.183.25] (mobile-166-171-59-202.mycingular.net [166.171.59.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 99915C402C5; Fri, 9 Jun 2017 21:14:31 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497060871; bh=pVMAaMmcCVTGYzo2E7inD16hwVSveTRMaV/fNCa/hqM=; h=Date:In-Reply-To:References:Subject:To:From:From; b=Y3PpUEL6Q22Z8mx++k6h5uFhYyXxQZOUa2rgruv60d+uvXu8CKIHeGm8n67B9RPca 58vwi3WzAhIj7HFEO7SfWenktE7Ds03E6uownzGuZjf+Mxh9Rt+//D0USkar8+XVPN HBiGmV8pJsiDn9TDQiIoCF+wq76vuU/M0bc3cpkU= Date: Sat, 10 Jun 2017 02:14:29 +0000 In-Reply-To: <20170610002538.10992.qmail@ary.lan> References: <20170610002538.10992.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 02:14:37 -0000 On June 9, 2017 8:25:38 PM EDT, John Levine wrote: >In article > >you write: >>It's been suggested that draft-ietf-dcrup-dkim-usage is ready for >Working >>Group Last Call, =2E=2E=2E > >Given that we are nowhere close to deciding what elliptic algorithm(s) >to add, it seems kind of premature to me=2E Why would that matter? This draft just gets rid of the obsolete cruft=2E = It clears the deck for adding a new algorithm, but in no way requires we h= ave that sorted out=2E Scott K From nobody Fri Jun 9 20:04:27 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E246C128854 for ; Fri, 9 Jun 2017 20:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1DKXFCTJHApF for ; Fri, 9 Jun 2017 20:04:24 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD6C12009C for ; Fri, 9 Jun 2017 20:04:24 -0700 (PDT) Received: (qmail 91391 invoked from network); 10 Jun 2017 03:04:22 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jun 2017 03:04:22 -0000 Date: 10 Jun 2017 03:04:00 -0000 Message-ID: <20170610030400.12835.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 03:04:26 -0000 In article you write: >>Given that we are nowhere close to deciding what elliptic algorithm(s) >>to add, it seems kind of premature to me. > >Why would that matter? This draft just gets rid of the obsolete cruft. It clears the deck for adding a new >algorithm, but in no way requires we have that sorted out. I had the perhaps overoptimistic hope that we could wrap up the new algorithm reasonably quickly and update DKIM once rather than twice. There is a significant cost to each RFC, both in what it costs to produce it, and to people's attention in the future. The more places you spread around the spec, the more likely it is that people will miss part of it. If it's going to take us another year to decide which elliptic curve to use and whether to add key hashes, then OK, we can push this out now, but I hope we can do better than that. R's, John From nobody Fri Jun 9 20:39:12 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB319128B37 for ; Fri, 9 Jun 2017 20:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 EwmcK3CKziFT for ; Fri, 9 Jun 2017 20:39:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B68D12708C for ; Fri, 9 Jun 2017 20:39:08 -0700 (PDT) Received: from [10.240.183.25] (mobile-166-171-59-202.mycingular.net [166.171.59.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BFDB4C402C5; Fri, 9 Jun 2017 22:39:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497065947; bh=i/ujr+4MziwwFmivkArDLupRJHVmY9pJVu9+iwN9uqc=; h=Date:In-Reply-To:References:Subject:To:From:From; b=njFJxOked8wKFyPd3zu9+31IBciTVlDFx4zGAXH4HF6nY7WZLmUOLlc8mdSeBqmtf BEuiSkWxPzvt1XCmknBYg7cIXzHhJ8swrFXKMnBWlYPp9mxqt2uMaUOWLqfDZb3eyj X+adF2w4EnpF/J0CcQXqzBtJb8ubLee9qu2D3Mpk= Date: Sat, 10 Jun 2017 03:39:05 +0000 In-Reply-To: <20170610030400.12835.qmail@ary.lan> References: <20170610030400.12835.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 03:39:11 -0000 On June 9, 2017 11:04:00 PM EDT, John Levine wrote: >In article you >write: >>>Given that we are nowhere close to deciding what elliptic >algorithm(s) >>>to add, it seems kind of premature to me=2E >> >>Why would that matter? This draft just gets rid of the obsolete >cruft=2E It clears the deck for adding a new >>algorithm, but in no way requires we have that sorted out=2E > >I had the perhaps overoptimistic hope that we could wrap up the new >algorithm reasonably quickly and update DKIM once rather than twice=2E > >There is a significant cost to each RFC, both in what it costs to >produce it, and to people's attention in the future=2E The more places >you spread around the spec, the more likely it is that people will >miss part of it=2E > >If it's going to take us another year to decide which elliptic curve >to use and whether to add key hashes, then OK, we can push this out >now, but I hope we can do better than that=2E I think it will take awhile=2E This particular discussion is the one I th= ought we'd already had when the group agreed to split this out into a separ= ate draft=2E This particular draft is already roughly five years late=2E If we don't get something that rips out the obsolete crypto soon, then ARC= is either going to have to wait or have a separate crypto specification fr= om DKIM=2E I don't see a new protocol with rsa-sha1 512 bits getting appro= ved=2E Neither of those options is good=2E Scott K From nobody Fri Jun 9 23:30:52 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90F1293D6 for ; Fri, 9 Jun 2017 23:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 m3mXry4nYe8X for ; Fri, 9 Jun 2017 23:30:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01571205F1 for ; Fri, 9 Jun 2017 23:30:48 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E6DDCC402C5 for ; Sat, 10 Jun 2017 01:30:45 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497076245; bh=8ZPFi9XWo6DKOwqlhOq8nGHHlnUA82nepp+MW225wWA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=nCtVO1rGJOl8NnY0HT/XCuQScTMjzVeXmpMAhOKd9MdUhtoHAIZImP9IkUaDbUha0 BCYTo40ZDX9c+6JECIlWLva1YMGQvM1zMN6OtP2sHWB+egYjnDcJhnE6VFmB7Qk8Eo T2TElfXZX+JHo8htSSAqNSbBzynN8dSJ5ieNMmIA= From: Scott Kitterman To: dcrup@ietf.org Date: Sat, 10 Jun 2017 02:30:44 -0400 Message-ID: <2801920.07GlA6OWUC@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <28932.1497043136@eng-mail01.juniper.net> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <08494F93-697D-4765-BAD9-BD4046340DC2@vigilsec.com> <28932.1497043136@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 06:30:50 -0000 On Friday, June 09, 2017 02:18:56 PM Mark D. Baushke wrote: > Russ Housley writes: > > I think the document is ready for WG Last Call. > > I agree. > > fwiw: The only typo I see remaining is at the end of Section 6 Security > Considerations 'from DKIM..' uses two period characters rather than just > one. Thanks. Fixed locally for the next revision. Scott K From nobody Sat Jun 10 02:42:40 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28C11201F2; Sat, 10 Jun 2017 02:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 HshM-7TxpZX4; Sat, 10 Jun 2017 02:42:37 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0AB126D46; Sat, 10 Jun 2017 02:42:36 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id v20so37124858lfa.1; Sat, 10 Jun 2017 02:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U/XPBijQCZaMgpIeuXwnknSlXEGscb3oFTyVYZTV1NQ=; b=OaNT2wEf8N3veG+u00DscE/f/rnP3AySvIgQl1W//XIFJbl86CnwZ9zAeRql3KN5TU 2NWbDXU3zS5EDAaqcg2c7E+mCd6n2bV3N3VbSJIy3aj9eynqVOSGxScPgCGCl3+vl6IE CYlphMklvGwpBoGndfOK99tJKCoOsIMXS5xHLb7Z2/2Y2tCCRGmpwXropr7V+d6bS3mI YirfWODf+WB+foEyq8ki/pkFCxYvCr5H3CYrXS9z8CVfxlVzkmaO1TPTbNOcL0OIdGwe LS5s7wu1Y3kRelgjI2MgCGr+/rKmqKyGUaciSKMobqbQ8me89WsDyYAIlRg4sW4Y+fqI iROw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U/XPBijQCZaMgpIeuXwnknSlXEGscb3oFTyVYZTV1NQ=; b=t/EqULTLf3ut097V4Zd5ufAG3FCXMLdthi6ABR+IfEGCXOJdyWc4JpGGxTZT81yQAU Pj/1tO4mQ7SfNDb3vvHyzDP9C8jjLbTW3o8Ud600jOxT+vew9a7FKT5W9akdqZKmPfN6 qHXkqYIR8m7kw2DVsQT9QYdZOUrP6pwfhf3NCYlaqejV6hYXB/9oDg55Pelfh/grM+Fr BlgFTcUj1d1SptU1wgZqeumMiMsUCx4XfwPIAfUfgjgjRnm1kjPtyoqp+ebkBcEcDzQl Eld5pkfU4xF7kUg4SKiAvBVLv8B+3gjkYVWPV34eWOAso5jMDmuNSPQqn9U9UbfZs6wk E5NA== X-Gm-Message-State: AODbwcATKajOat5WC9CKKr8kLwovIr/XMOmqdZ1uEipM/4p4pSZ2s9Ki suBXoiIZU00bQZbu2sz/WakgmcPIQZYgPFo= X-Received: by 10.46.77.196 with SMTP id c65mr10887192ljd.113.1497087754687; Sat, 10 Jun 2017 02:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Sat, 10 Jun 2017 02:42:34 -0700 (PDT) In-Reply-To: <149690083334.25644.8501543904193079634@ietfa.amsl.com> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> From: Martin Thomson Date: Sat, 10 Jun 2017 10:42:34 +0100 Message-ID: To: internet-drafts@ietf.org Cc: i-d-announce@ietf.org, dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 09:42:39 -0000 I find the construction of this draft strange. Why not simply say "verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"? The remainder of the text is largely unchanged, which took me a while to validate. The problem here is that removing the definition of rsa-sha1 is not the point. The code point can't be undefined (Section 7 gets that right), and we don't really benefit from having the definition removed. What we want is to have rsa-sha256 implemented and deployed. So say two things, just to be perfectly clear: 1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted. 2. DKIM implementations MUST use rsa-sha256. Signers MUST create signatures using rsa-sha256 and verifiers MUST verify those signatures. I disagree with John about the publication of this draft without the new schemes. It's worth doing now and the extra overheads of publication are small. Nits: Section 3, two errors here: > One algorithms, rsa-sha256, is currenlty defined. Section 3.2 s/,/ / here: > DKIM,[RFC6376] Section 6 has an extra period. Collapse Section 7.1 into Section 7: """ IANA is requested to update the "sha1" registration in the "DKIM Hash Algorithms" as follows: """ On 8 June 2017 at 06:47, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DKIM Crypto Update of the IETF. > > Title : Cryptographic Algorithm and Key Usage Update to DKIM > Author : Scott Kitterman > Filename : draft-ietf-dcrup-dkim-usage-02.txt > Pages : 6 > Date : 2017-06-07 > > Abstract: > The cryptographic algorithm and key size requirements included when > DKIM was designed in the last decade are functionally obsolete and in > need of immediate revision. This document updates DKIM requirements > to those minimaly suitable for operation with currently specified > algorithms. This document updates RFC 6376. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Sat Jun 10 05:53:27 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37181293EC for ; Sat, 10 Jun 2017 05:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6AdGKbwQiCXW for ; Sat, 10 Jun 2017 05:53:24 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537A612711E for ; Sat, 10 Jun 2017 05:53:24 -0700 (PDT) Received: (qmail 41784 invoked from network); 10 Jun 2017 12:53:22 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jun 2017 12:53:22 -0000 Date: 10 Jun 2017 12:53:00 -0000 Message-ID: <20170610125300.14197.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] we need to do the work, was draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 12:53:26 -0000 In article you write: >This particular draft is already roughly five years late. Sure. So's mine. >If we don't get something that rips out the obsolete crypto soon, then ARC is either going to have to wait or have a >separate crypto specification from DKIM. I don't see a new protocol with rsa-sha1 512 bits getting approved. >Neither of those options is good. The whole point of spinning up this group was to fix the DKIM crypto before ARC is published. Since RSA with more than 1K keys has the same TXT record problem with ARC as for DKIM, I think it's at least as urgent to add a future-resistant algorithm with smaller keys as to deprecate old stuff, probably more so. This shouldn't be hard, we're not trying to invent anything. I was hoping Scott and others who know more about crypto than I do would be making concrete suggestions about which elliptical algorithm to add, by now. R's, John From nobody Sat Jun 10 05:56:12 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708401293EC for ; Sat, 10 Jun 2017 05:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 9AomNNIV3jMQ for ; Sat, 10 Jun 2017 05:56:09 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E3F12711E for ; Sat, 10 Jun 2017 05:56:09 -0700 (PDT) Received: (qmail 42079 invoked from network); 10 Jun 2017 12:56:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jun 2017 12:56:07 -0000 Date: 10 Jun 2017 12:55:45 -0000 Message-ID: <20170610125545.14232.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 12:56:10 -0000 The first goal here was to add an elliptical curve algorithm to DKIM (and ARC.) I'd like to get back to that. Desiderata: * Small keys that will fit in a TXT record * Code widely available * Signing and verification interfaces similar to RSA so the calling code doesn't need to change much. Any suggestions? R's, John From nobody Sat Jun 10 06:42:29 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C8F126BF3 for ; Sat, 10 Jun 2017 06:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com 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 Tl9Bajd8gIgl for ; Sat, 10 Jun 2017 06:42:27 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94A7120227 for ; Sat, 10 Jun 2017 06:42:26 -0700 (PDT) Received: (qmail 66252 invoked from network); 10 Jun 2017 13:42:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=102ca.593bf741.k1705; bh=j6y6/qFFkWJxXA/ziN0rxC2kguYgJVUz6MjtIZFNbfU=; b=q73coLWiw2pfe22DY3CtoRplQ4NyCujz9J4s+tmJi49ZWHvrWOJdFWqHfVgtpNAWVvb58H++ubZY+wGASDD0+NZUb6kkfCdczP971Es3TFwxDGcmRtISkvP953V+kf7A2EsMb7CvP5jtvcOxT4KcqyXFA8VeQ67fiONopnnwwW9+JYo4QoOzwZyc9whxNA0mcDVWm7vHRAeppMoZb+aO+ZY76xzHyfrXoWIy26mF0D1CdUj8wJXHRITR3J+StwOG Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jun 2017 13:42:25 -0000 Date: 10 Jun 2017 09:42:25 -0400 Message-ID: From: "John R. Levine" To: "Scott Kitterman" Cc: dcrup@ietf.org In-Reply-To: References: <20170610030400.12835.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 13:42:28 -0000 > If we don't get something that rips out the obsolete crypto soon, then > ARC is either going to have to wait or have a separate crypto > specification from DKIM. I don't see a new protocol with rsa-sha1 512 > bits getting approved. Neither of those options is good. I'm not clear on what sequence you're expecting here. Is this it? * Update DKIM to take out old crypto * Publish ARC with only sha256 and RSA1024. * Update DKIM to add new algorithm and maybe key hashes * What about ARC? I'm seeing at least four documents where we should only need two, one to update DKIM, one to publish ARC with the same crypto. R's, John From nobody Sat Jun 10 07:51:08 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1EF127B57 for ; Sat, 10 Jun 2017 07:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ojsm7GYFRiki for ; Sat, 10 Jun 2017 07:51:06 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82A5126CE8 for ; Sat, 10 Jun 2017 07:51:05 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id p189so38382062lfe.2 for ; Sat, 10 Jun 2017 07:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0HA6pkBn/otgV8dx/y4ViCtbLc1PDCytSYNPvsg9ugE=; b=iRkMG0ljdxw9JXDJ8O9aXdEMxlu3m6SSD4/JcC4PuY3jXFG2ImXwt0i3GI8JYFCFJl QaFe8r5NM4eqKz8bFF5a+9K1E45EUR1kb5xOCVpbJDBOmRHFMrAXIVcOfsvoPTqf618+ MRaO1C+rSScfJvltmwP2doSrtgs7xND+Hra04zA3DClN/H/9NJtbqxTbxw6Knpk39+z8 AEJrrgmhgqomFlD4Ef4L/qeXJbG8IZl/RKK/ub47RAHNnjp5BG403o1sEXDB6aHCIiT4 BfAFaaRyLQTtQ2hxOc0i9jZY6SxyPcq3PiI+lClhZzS5cDnoWl8lh8UjzxoiQp5VsHpP zh9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0HA6pkBn/otgV8dx/y4ViCtbLc1PDCytSYNPvsg9ugE=; b=gAWWvwKA7elHLgatb/0ROv0ACYnPnEuWlf5JQ5pWxIyBiGKZld6F8pRXidbD5jm9Un XcBQEQ4cNvs/4bgSqcdOCnfJD1Fdy+eAM2UhCPY3925dWcLhAyq7nGY/0DDO7bS4xUjw QIHJHHXeoo8XQwS3pezT7mSh1Z3Ddhjqtm9ss7ShiRTiFysIxjUordEuCm7apk2XUdEZ LrmFI8ID+UqB6g+6EarkdMK1MaVpe4ZgVSLqis2JePtLZWjVHYkPDJt1ydb4WFetG/mN p+14Z5zrnWLfmex6mDsbNpw8KtQM6gVa14WzOOT9zAgBziLT5LkyBInFW3wcLE2rpLFC JWlQ== X-Gm-Message-State: AODbwcDlF6DzHYCQWVXP7cublX//5QWQSsPRNLiFF60JdA/DW1+U4U9h vtEIU7YCO3MlN6tJS/fTtgj5kJPeqz7h X-Received: by 10.25.145.66 with SMTP id y2mr12349233lfj.19.1497106264140; Sat, 10 Jun 2017 07:51:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Sat, 10 Jun 2017 07:51:03 -0700 (PDT) In-Reply-To: <20170610125545.14232.qmail@ary.lan> References: <20170610125545.14232.qmail@ary.lan> From: Martin Thomson Date: Sat, 10 Jun 2017 15:51:03 +0100 Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 14:51:07 -0000 On 10 June 2017 at 13:55, John Levine wrote: > Any suggestions? I thought that you had already settled on Ed25519. Availability is the only concern of note based on your criteria. We don't have it in NSS (yet) and it's a bit green in some other libraries, but it's still pretty widely available. I see no huge motivation for Ed448 or ECDSA at this stage. From nobody Sat Jun 10 07:53:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FC7127B57 for ; Sat, 10 Jun 2017 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 gNGQ64yScn_6 for ; Sat, 10 Jun 2017 07:53:40 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48DBA126CE8 for ; Sat, 10 Jun 2017 07:53:40 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l75so27132650ywc.3 for ; Sat, 10 Jun 2017 07:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l2lsYW0GR5zF96yDmZh2C4GRakKfMeQm+cnkTWvc10c=; b=BCnS1HfJjKqzBWSt8lWmV79BbJaDFFMMpA4fk54bmkY7JD0NgeT6W4HIVwl0EnuUTk 1+Z9AHkuFn4uaG78QQq8NqMO3Iv0+gsANjdZ7WNXteJb93YTtpp6P53OoFf3jkuP5WQ9 ixi7+mawGV5Btwe/vAssmkZP5gXJKGEuqElMe3BMFIkzxeSVvcGRPU4+Cv/E5MdtytPu 030RkYh2uirh2Nq/uJCMqX6DmDrWQihJ7VtZ825OrFymEi8pnJmFcMV4dKLL5l+7maM3 /NAFjm8zRKaSvn3EBtR7moFaDg6vc3KKKmay6W8lQX2cIjTmPI1KUTPloosZr8zeZpuc TWWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l2lsYW0GR5zF96yDmZh2C4GRakKfMeQm+cnkTWvc10c=; b=H9ASa67GKgmCa+guo/9H8q7DbrhyXtxan1qweFq1v13Kv5Fi4yaCUk0Q/MlHnPaHgH Z8PeNmjNl92BB9Lo6UVxigO0Dpbs5yx+AykjKoIaS1O1gZi8bmhr0BRUnFmEiFWEcOEj gn9MSAha/2i2oeIEZgt8Zlol1Zkl2+4SMgq87pzw11veohbAxKwAL3u+61maT5gpArdo E6fjPoBY5NyLRMvodAIIVA+fLTNGrEfu5Kes6y2lUh085OA7ziC4X23f82EoaxnwnJve 8u/hF2HFHm2uwDUT9qTjwPDyy/z57oqoRzCey7Wtkig2asaY59PXOpA0k2+zOJL0PFBA JwGA== X-Gm-Message-State: AODbwcAVScAImqeq8YP4RMfpPSk9VY/s9NyH6BBoZWkM5SRcsOfWL23A 0jDhWG+mrEJuwGXemnzO4HOarybkULaY X-Received: by 10.129.146.9 with SMTP id j9mr18261091ywg.283.1497106419480; Sat, 10 Jun 2017 07:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 10 Jun 2017 07:52:59 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> From: Eric Rescorla Date: Sat, 10 Jun 2017 15:52:59 +0100 Message-ID: To: Martin Thomson Cc: John Levine , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0928d4531add05519c40ed" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 14:53:42 -0000 --94eb2c0928d4531add05519c40ed Content-Type: text/plain; charset="UTF-8" I think clearly either Ed25519 or ECDSA P-256. Either seems fine, with ECDSA having an advantage on the availability and Ed25519 an advantage on the modernness. -Ekr On Sat, Jun 10, 2017 at 3:51 PM, Martin Thomson wrote: > On 10 June 2017 at 13:55, John Levine wrote: > > Any suggestions? > > I thought that you had already settled on Ed25519. Availability is > the only concern of note based on your criteria. We don't have it in > NSS (yet) and it's a bit green in some other libraries, but it's still > pretty widely available. > > I see no huge motivation for Ed448 or ECDSA at this stage. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c0928d4531add05519c40ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think clearly either Ed25519 or ECDSA P-256. Either seem= s fine, with ECDSA having an advantage on the availability and Ed25519 an a= dvantage on the modernness.

-Ekr


On Sat, Jun 10= , 2017 at 3:51 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 10 June 2017 at 13:55, = John Levine <johnl@taugh.com> = wrote:
> Any suggestions?

I thought that you had already settled on Ed25519.=C2=A0 Availability is the only concern of note based on your criteria.=C2=A0 We don't have it= in
NSS (yet) and it's a bit green in some other libraries, but it's st= ill
pretty widely available.

I see no huge motivation for Ed448 or ECDSA at this stage.

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--94eb2c0928d4531add05519c40ed-- From nobody Sat Jun 10 09:07:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0849D127076 for ; Sat, 10 Jun 2017 09:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=lz6xhIvU; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=jv+M0iet 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 vXjM1FG4AP5L for ; Sat, 10 Jun 2017 09:07:40 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B061200E5 for ; Sat, 10 Jun 2017 09:07:39 -0700 (PDT) Received: (qmail 81570 invoked from network); 10 Jun 2017 16:07:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13ea0.593c194a.k1705; bh=7ao1h2odoVh+QM7PWIWjBlVfGaIWiDd8PIL3E9ZDEig=; b=lz6xhIvUH5156sdiaIIg00PT94P/8JtjqIfw1RqURdOqm3ubowXSokUr6QmKcCaGxOeXwzWNmRqF7L5K43bKCaLMP+q/+99ZUiZYl7L1b3myUEob1qpOE8+TNauIMVLQYpL4NTVbC7plrL+eve3gyyzJYAD0udJTKucNzOH/S8JzXPBZl2/QJZ1ZH7ZV7hVksPK5ze+TGfS/DHneX7CJgabsNkr2A4+XPcNQ0+iGXZ4sd5URSesg4HuTveEBTzca DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=13ea0.593c194a.k1705; bh=7ao1h2odoVh+QM7PWIWjBlVfGaIWiDd8PIL3E9ZDEig=; b=jv+M0ieteMusBk7pCs0skT0eCifvoUZnKThJvl8cxn8Zc0/DchbtUkgGnWyYNOVZTAi8J0XZfbll21BFBZl5Ew4na+eyBoNHrU4Jrha2Lb9x5BB3/1Ey3lkS4Yo/52u5R7pGECGYXVmNhdVY8uf+JQYUZwNcbWikGXqYkD1hO0SPNHUFMNG6I2e0jNY/RAVnL9nC72E3PndYfIt8Q66FBoY6gtL8ACK15twHiGOMKLW1xtba3fCGMe4k5dYm6aSD Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jun 2017 16:07:38 -0000 Date: 10 Jun 2017 12:07:37 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:07:42 -0000 > I think clearly either Ed25519 or ECDSA P-256. Either seems fine, with > ECDSA having an advantage on the availability and Ed25519 an advantage on > the modernness. Great. How about the sign/verify interface compared to RSA ? RSA has a length parameter but I gather that's in the blob of base64 key info. R's, John From nobody Sat Jun 10 09:09:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B0C124BFA for ; Sat, 10 Jun 2017 09:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 0nDfRChAPSNr for ; Sat, 10 Jun 2017 09:09:00 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D032E1200E5 for ; Sat, 10 Jun 2017 09:08:59 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id e142so19352594ywa.1 for ; Sat, 10 Jun 2017 09:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YJDoJ73y5wxD198hIZ+bJb9ysgLDdTg8NS0gsPQ/nRE=; b=KflDMRi6X9tBb9t9ilM/J2Kf81vo8YEAyBLIPo0vkhWh9qtIVGVxwmQQSNVgPRl3XV J7KBz3fPD0drcFJLDoUYridUztSXm2C7/v7qDaMefd+UG1oUFH37DSMxZo9qFLzt5O9/ Wa2h3qmJb7t8I/ZotlnFQeWWYBOK1zcgOmRo4psczCAnRBGibSPeJUy8gJ9rMk5RyGLD OEFmMVNSgIvaI/xe1suI35+5VMKiJgHSMFsJp9mhn9Kcrif8bpQoeZoFedlCmPPaKyga WzgPWQpxQETvw+tdb0CWSNzZuXWGPwvJfo4ZOd2Iu60aQCWfd/9AVrY3y+N3ulXAdOQy OlAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YJDoJ73y5wxD198hIZ+bJb9ysgLDdTg8NS0gsPQ/nRE=; b=I9aGUrUb2FL24HUYWD+ZmsnQyD9BqmGRguFV9HXUuQBOgrxNjxkgrVlqrVtKuVpSpP 2TG/DIMPFUh851WcwZldC7V7+5X4FO1Nzr5HdqM73564PDyWAfdN5rpX/t3OfZKN4RFk Kd3jLzhEBgzuqwEDcR2zexBuEQRR+i2jp+Mw+4Ys677/dMeYqLP6aQ7J7yWmK8gS9+Y0 5tj04YB97g97o49hE/V7YXqQrCriCQQtGApgeWGV0yLnP2YEdVpNWv4y7aiz5+cL7EyJ fj83TLEMWMlpxi2FlKasJmpJc8CH6ee8BuR8jWEsRRpSLvzadT8x1iHzmesgbr55/o+3 Bltg== X-Gm-Message-State: AODbwcD1Gp7RwUta710/SW6/j32ngQwqEs5dym3Nb+2JAAT8xmJa7uNW KUJm3aFMsFbRjG43Sc071lWcWHHi3PkEDNg= X-Received: by 10.129.97.195 with SMTP id v186mr15832825ywb.270.1497110938957; Sat, 10 Jun 2017 09:08:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 10 Jun 2017 09:08:18 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> From: Eric Rescorla Date: Sat, 10 Jun 2017 17:08:18 +0100 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11490122b4d9bf05519d4d06" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:09:01 -0000 --001a11490122b4d9bf05519d4d06 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 10, 2017 at 5:07 PM, John R Levine wrote: > I think clearly either Ed25519 or ECDSA P-256. Either seems fine, with >> ECDSA having an advantage on the availability and Ed25519 an advantage on >> the modernness. >> > > Great. How about the sign/verify interface compared to RSA ? RSA has a > length parameter but I gather that's in the blob of base64 key info. > I'm not sure what you mean by a length parameter. Length of what? -Ekr > R's, > John > --001a11490122b4d9bf05519d4d06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 10, 2017 at 5:07 PM, John R Levine <johnl@taugh.com><= /span> wrote:
I think clearly either Ed25519 or ECDSA P-256. Either seems fine, with
ECDSA having an advantage on the availability and Ed25519 an advantage on the modernness.

 Great.=C2=A0 How about the sign/verify interface compared to RSA ?=C2=A0 RS= A has a length parameter but I gather that's in the blob of base64 key = info.

I'm not sure what you mean by= a length parameter. Length of what?

-Ekr


R's,
John

--001a11490122b4d9bf05519d4d06-- From nobody Sat Jun 10 09:11:39 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB28127076 for ; Sat, 10 Jun 2017 09:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=REXANx9t; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=NDE7oEI4 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 C3vT6XjErxK7 for ; Sat, 10 Jun 2017 09:11:36 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3591200E5 for ; Sat, 10 Jun 2017 09:11:36 -0700 (PDT) Received: (qmail 82022 invoked from network); 10 Jun 2017 16:11:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14064.593c1a37.k1705; bh=eBz+b8/mauJmDpX/BSXyVMl3CkKmzmtd/O8oD7Seins=; b=REXANx9t6KkzDetK/W+LYpqv1CwMJ1ysBoSNoPTHvf67XDatg0+uH6Wn+AfOzpkZar9qZlpil1xi5Bj5yXxolw42o5KkEotIVU0hw54feOUad5HZxk38dsGNvXqse0QuMM0x1rLmJGNOly7aqWLrWp+qCIqFWySmOq5WH6DbFwQsXpf3DtRhqzoYOG1vfwF/AtGef+Isr33FvmlIH7s1RHUPmDyEDArgvsQnY6pPb9r+ibubYLCs9j9HPrgv69qy DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14064.593c1a37.k1705; bh=eBz+b8/mauJmDpX/BSXyVMl3CkKmzmtd/O8oD7Seins=; b=NDE7oEI4hWCKiZz75AmCDa20D9yKAzBu1bNx3FiDJUuhvdSTfgXqGK/rwrfOA9bjKQnajpXsbBdPpKKP9PyQ9CfgReanE+5ObS2FJo/7Q+pGL4HINcU92gEHlt3iYfHyua94/x31NejDB+ylkgOIUSsuUOGpi1eF/P2W/dbWjP57tZmTXiEf5N4X+SWjTKalSl+DSZaQwC+x1gf3gjLtY8aSlXM4am3bFiLbAwRHBqiSkvjKNwFrLOkj6A4TU6EY Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jun 2017 16:11:35 -0000 Date: 10 Jun 2017 12:11:35 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:11:38 -0000 >> Great. How about the sign/verify interface compared to RSA ? RSA has a >> length parameter but I gather that's in the blob of base64 key info. > > I'm not sure what you mean by a length parameter. Length of what? The key. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 10 09:38:06 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF6A126E3A for ; Sat, 10 Jun 2017 09:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6bTFzzZwh5Ic for ; Sat, 10 Jun 2017 09:38:02 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1D3A1200E5 for ; Sat, 10 Jun 2017 09:38:01 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id p189so38834523lfe.2 for ; Sat, 10 Jun 2017 09:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fThr0Wwq3cZQqDg2DZmf6Dv5br6q6dmoHJlRShEu/qk=; b=fr2lBYUwZEEXfXFZjgLk1x7YTz+Jz7IaMg3tda+6FMyOE373F6AB9obre4KuWjbtlc qXO5sSszElqGRvLeqwX15GSSfF807x0x0cyybV+TDxM4DVZIR0V77flM8F28WESP95cF HS7+m0YD/f8MELgY7/1Xiw9DjX6VBavS2X+3fBrdwWI8DzRMWm/FqzRQzOB9QSUf1vmT AZ4LJHtOuJVgP2IYjJG3myAonF+7j4ifCoEHl5djr1K19OruwJHVC46DjGxYWey+HTi9 KItyuECOzob5LnOSDZb7v7qgzzyBZWruiLgFDMmY8yBkINEfvkTs/17a4CNOjtjV6B6V 7wAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fThr0Wwq3cZQqDg2DZmf6Dv5br6q6dmoHJlRShEu/qk=; b=iT2miW8rv/zJSCe/46EOiRaVVAU0GveZOxrh2e1l3OCPCVQBNX+/OQqws1UtyywdtC xOsR+MKAwegG7djS7RNu5Oo5YdkSgHDDLogOtwjvHHL+av5lOZOepnruRNRrF7zDidL+ m2qXRUFYCosmSfhbmlWtrvmYDO5NreAVCvQZMAjsYKGtdv/PVVIxr2pnAqCfO0Z3HSxA ndNzetqPHtF1AQ8cv9cn+A7pmwuwQbKwyaEAa5oxQCwVii0RsjWufZfx3kdjC8otH4JZ MqQ7d2sYX1LOJeV18/gYAp6hT03WH/cYCyPe5vE9rpfGdiE9Y2caABzkf7mbdCiXQ1ZJ D73g== X-Gm-Message-State: AODbwcB6ugTswjMEdu6QXOD7LklhZ0kw3Yri6TZevjPonmzf3xapWyhX Cj077ciztjDwqcywOGPUuvgX2LzYjBMx X-Received: by 10.25.201.18 with SMTP id z18mr11278604lff.172.1497112679998; Sat, 10 Jun 2017 09:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Sat, 10 Jun 2017 09:37:59 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> From: Martin Thomson Date: Sat, 10 Jun 2017 17:37:59 +0100 Message-ID: To: John R Levine Cc: Eric Rescorla , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:38:04 -0000 On 10 June 2017 at 17:11, John R Levine wrote: >>> Great. How about the sign/verify interface compared to RSA ? RSA has a >>> length parameter but I gather that's in the blob of base64 key info. >> >> >> I'm not sure what you mean by a length parameter. Length of what? > > > The key. Well, keys are fixed size, but you could include an argument if you need to have a consistent API. From nobody Sat Jun 10 09:49:40 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0C0127076 for ; Sat, 10 Jun 2017 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dQuMC2yr5Fie for ; Sat, 10 Jun 2017 09:49:37 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584B71200E5 for ; Sat, 10 Jun 2017 09:49:37 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id o65so40437082oif.1 for ; Sat, 10 Jun 2017 09:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hoSAjWJ2PPIIk9AHg/1tYvcC19tfMnjYSwljqv4m0OI=; b=OSI3nXh35zkhoxCMkECOv/oWwfZbgo3BuioTBC8oLYgdWeI4tXEgPrvwWkieQLdeuQ RQeGKnaZCHdufsAI5a7QubCENKFduF0Fx1v/qNgKg466jLfS0Dcr1jmJZ+RBz7jUzH97 R6S3rUc5TgI5I0BKoTmVk6uD+2Ska2l/8g9hifAyVtzE3VfKwhW7tGgQB6wEzDF+zuFw frnF8MPFScXj3wBf1hho8gsO0OUHe55wDVQ5edzIZPCHVvYtjBTq+9j7HWC6ATWG1NIZ aD2QPuXE/b9A/jXq51MlxDXyt8Jg/k3FD8MphAF+k4Q0BAAlZmUd8088Wk26CVCoAvp/ Rjpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hoSAjWJ2PPIIk9AHg/1tYvcC19tfMnjYSwljqv4m0OI=; b=oub8xEyMqXcon6pUQ+tmV7tWXrAakBLQq0oJ0fp4jHM17GjWEASbFgWJbVdHKOEzG3 7WfYKZo7hU2GIGCyAVhYNU0wpWcBem4RI4shYdFaPoriPY+n0zRrrfd1QV08lWX8vMeh EEra207akAVLlTNXKL4J0PJ+Q9NaBTdIT0H0gOpDrZMD34OT7/LGOqZeLvEDAGu0kbLI 50AzBXZQfnvUfEYz4NAWy+O/JWJo11wBJ4ci7xA5JYIVLHhQm1ZouohSLNUwdEfX1Vob BSrjMr9669GRL8Ye6J4dys0Wcw/UZnvJ8bPOM2ADyxscSseI8k7zl5ZnjtbnVP0TZpa5 fLEA== X-Gm-Message-State: AODbwcAGpo7xA0X90IAUDjUq7z7bZdGm1rY8HckmYTxVcPTXGMpefJoT T5NZVkhk3MCcP6upkHC4m2Wai6H9vQ== X-Received: by 10.202.220.67 with SMTP id t64mr21691293oig.134.1497113376783; Sat, 10 Jun 2017 09:49:36 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Sat, 10 Jun 2017 09:49:36 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> From: Phillip Hallam-Baker Date: Sat, 10 Jun 2017 12:49:36 -0400 X-Google-Sender-Auth: bdbovqT3G8OQ8N3NqFgLaNWXbuQ Message-ID: To: Eric Rescorla Cc: Martin Thomson , dcrup@ietf.org, John Levine Content-Type: multipart/alternative; boundary="001a113d21a20302a405519ddfef" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:49:39 -0000 --001a113d21a20302a405519ddfef Content-Type: text/plain; charset="UTF-8" I think IETF is pretty much set on the 25519 approach. Use RFC 8032, it is what it is for. On Sat, Jun 10, 2017 at 10:52 AM, Eric Rescorla wrote: > I think clearly either Ed25519 or ECDSA P-256. Either seems fine, with > ECDSA having an advantage on the availability and Ed25519 an advantage on > the modernness. > > -Ekr > > > On Sat, Jun 10, 2017 at 3:51 PM, Martin Thomson > wrote: > >> On 10 June 2017 at 13:55, John Levine wrote: >> > Any suggestions? >> >> I thought that you had already settled on Ed25519. Availability is >> the only concern of note based on your criteria. We don't have it in >> NSS (yet) and it's a bit green in some other libraries, but it's still >> pretty widely available. >> >> I see no huge motivation for Ed448 or ECDSA at this stage. >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a113d21a20302a405519ddfef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I t= hink IETF is pretty much set on the 25519 approach.

Use RFC 8032, it is what it is for.=C2=A0

On Sat, Jun 10, 2017 at 10:52 AM, = Eric Rescorla <ekr@rtfm.com> wrote:
I think clearly either Ed25519 or ECDSA P-256. Eithe= r seems fine, with ECDSA having an advantage on the availability and Ed2551= 9 an advantage on the modernness.

-Ekr


On Sat, Jun 10, 2017 at 3:51 PM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 10 June 2017 at 13:55, John Levine <johnl@taugh.com> wrote:
> Any suggestions?

I thought that you had already settled on Ed25519.=C2=A0 Availability is the only concern of note based on your criteria.=C2=A0 We don't have it= in
NSS (yet) and it's a bit green in some other libraries, but it's st= ill
pretty widely available.

I see no huge motivation for Ed448 or ECDSA at this stage.

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a113d21a20302a405519ddfef-- From nobody Sat Jun 10 09:52:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0D1205D3 for ; Sat, 10 Jun 2017 09:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 WibYp1lCfcPO for ; Sat, 10 Jun 2017 09:52:04 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1317C1200E5 for ; Sat, 10 Jun 2017 09:52:04 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id f192so20711798yba.2 for ; Sat, 10 Jun 2017 09:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kupM61LZdF0LFEdxsQnwuzuW1NtAPnu+3/M/VHW8vZk=; b=KjQDKgaNL0fpwOWWPbZ8olXTQmz5Ef6W4n7KaVaATxiMBlwGyFvhWDl2FAfG+ZhvL5 AttPDdIb7DfUYfuwM6a0CLRQsyQX6c9wtXt4E5qaJ1SXv0zf/NdAnixxGIn6F4rd5gKd bKEQiP8N1jsu9DpQJXyJ+xS4pKGrZ3j05pLomnOEH3eQP43f9cCROe8neULhlpdemL7H kebiVzTVH6HBvEPznaRJ/jeCcnm1mzhpYFuH+nrB3dN4vf3bimCquvFcztU5GtyynvpK Yee4Yd0WB6C7iL6UvfvBEIcKzSAndJocvxWpGkcUT+jpk/jAiE8GrCDHQEKytPC6Pph+ 9diw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kupM61LZdF0LFEdxsQnwuzuW1NtAPnu+3/M/VHW8vZk=; b=R3akIasg5SbetRG6RX/J27689fn+RJrAz8gFvIP5Osfub2Yss5gD609kz/rntbI4cM aidR2Zr/G03dUPcyx4GK/gZz6YjBPFAvyf4C/v9TLMfq373idNi3PJGUmXEenah20zMl HQaSnr+xHsuTxUxGR7Pc/X0tpOpaYryKfF+2wCuT+Oa1E7MZ8khwjHghINhNW2mRJu/a GFi0atMG26CbV3+8NN2oyqKBb4DpO6NYqBWXPejU+sfxxqGG+gw97CTXTbvhFYKBX74e XxeOVLLq+sT7NLmSrXTnwbdaZpljs2ulY/f4ZNjGdixXLQeWhuTXQ6z/p1KZQf5LzqbY iJ/A== X-Gm-Message-State: AODbwcCN/DvyIGi90pvmULbfwOeBGS5qdJ8Mbuel4ggTPWpjEtU7Ik3r wDYwGpK9RLRSGahHcEqML6KgFcGfpDjnrJnXUQ== X-Received: by 10.37.177.164 with SMTP id h36mr19357959ybj.15.1497113523339; Sat, 10 Jun 2017 09:52:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 10 Jun 2017 09:51:22 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> From: Eric Rescorla Date: Sat, 10 Jun 2017 17:51:22 +0100 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403045eaaa4bf6f8d05519de7d0" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 16:52:07 -0000 --f403045eaaa4bf6f8d05519de7d0 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 10, 2017 at 5:11 PM, John R Levine wrote: > Great. How about the sign/verify interface compared to RSA ? RSA has a >>> length parameter but I gather that's in the blob of base64 key info. >>> >> >> I'm not sure what you mean by a length parameter. Length of what? >> > > The key. > Hmmm... That's not really part of the standard RSA signing interface that I'm familiar with. See for instance [0].. Can you send me a pointer to what you have in mind. -Ekr [0] https://wiki.openssl.org/index.php/Manual:RSA_sign(3) > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --f403045eaaa4bf6f8d05519de7d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 10, 2017 at 5:11 PM, John R Levine <johnl@taugh.com><= /span> wrote:
Great.=C2=A0 How about the sign/verify interface compared to RSA ?=C2=A0 RS= A has a
length parameter but I gather that's in the blob of base64 key info.

I'm not sure what you mean by a length parameter. Length of what?

 The key.

Hmmm... That's not really = part of the standard RSA signing interface that I'm familiar with. See = for instance [0].. Can you send me a pointer to what you have in mind.

-Ekr=C2=A0


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--f403045eaaa4bf6f8d05519de7d0-- From nobody Sat Jun 10 10:44:42 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6F71270A3 for ; Sat, 10 Jun 2017 10:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 L4b02O0Hz7ye for ; Sat, 10 Jun 2017 10:44:39 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C44126DC2 for ; Sat, 10 Jun 2017 10:44:39 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D70D4C403A4; Sat, 10 Jun 2017 12:44:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497116677; bh=+KfNaz3SBXJTydwgzHbK08Ny9BlzmGT5GEC7+os1plE=; h=Date:In-Reply-To:References:Subject:To:From:From; b=XbFt8uk5SodoH2O02haGef6Kt29RLAmsKkI4ib4Jnmw+1KHmdMpTFyT+rI0wMR5C0 ZdYVpeXER8KtjOU1lOp4vKX9i7YRZ0xQjHiGyqRhXYVfTHUFH/03fazxrcs63Qx1pA U260dgb+8Hy2VY8Wu5A1PgYCcZCJX11vEbt6Bh3c= Date: Sat, 10 Jun 2017 17:44:34 +0000 In-Reply-To: References: <20170610030400.12835.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 17:44:41 -0000 On June 10, 2017 9:42:25 AM EDT, "John R=2E Levine" wro= te: >> If we don't get something that rips out the obsolete crypto soon, >then=20 >> ARC is either going to have to wait or have a separate crypto=20 >> specification from DKIM=2E I don't see a new protocol with rsa-sha1 >512=20 >> bits getting approved=2E Neither of those options is good=2E > >I'm not clear on what sequence you're expecting here=2E Is this it? > >* Update DKIM to take out old crypto > >* Publish ARC with only sha256 and RSA1024=2E > >* Update DKIM to add new algorithm and maybe key hashes > >* What about ARC? > >I'm seeing at least four documents where we should only need two, one >to=20 >update DKIM, one to publish ARC with the same crypto=2E Ideally, ARC will be able to use DKIM's crypto requirements by reference a= nd not need its own separate definition=2E If ARC can do that, then it doe= sn't need to be modified once this WG completes=2E Today's DKIM crypto requirements are completely unsuitable and would (I ho= pe) never get IETF consensus for a new protocol=2E Getting from "unsuitabl= e" to "suitable for today, but not future proofed" is easy=2E That's what = my draft does=2E It's the minimal change needed to avoid ARC having to spe= cify its own crypto requirements, which is what prompted, finally, this wor= king group=2E Eventually the working group lands another document that defines the post = rsa-sha256 future as an update to DKIM=2E Since ARC will incorporate the D= KIM crypto requirements by reference, it won't need updating again=2E So I see two documents from this WG: - one now to get DKIM crypto requirements to be minimally acceptable for = today's use - another to define requirements to be secure in the future so that someda= y, when it's no longer appropriate, rsa-sha256 can be replaced Alternately, as you suggest, we land one document that does both=2E I tho= ught we made that decision when we adopted this document, so I don't know w= hy we're having the conversation again now=2E If we were going to land onl= y one, then we don't need this document at all=2E I think you are substantially underestimating the time it will take to get= IETF consensus on a new approach based on ECC=2E I think if it's done in = a year, that'll be fast=2E I think I'm done on this particular topic=2E =20 Scott K From nobody Sat Jun 10 10:48:32 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897D51270A3 for ; Sat, 10 Jun 2017 10:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=gxqa2b40; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=Bdgfn2O6 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 NeEnU5Zdr6Iw for ; Sat, 10 Jun 2017 10:48:30 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC1C7126DC2 for ; Sat, 10 Jun 2017 10:48:29 -0700 (PDT) Received: (qmail 90475 invoked from network); 10 Jun 2017 17:48:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16169.593c30ec.k1705; bh=qf6kwkZOACvbHR6+ppB3/4K4HcfnfhN8l4vRVgdFAhk=; b=gxqa2b40l+d0/TJe0nLYGPSv7VZloqOK5TJi0FT36eXEy8sBxbBNFc3HN+/6+D5ObV2WnzA+k3d3NCDLLS2U/fzey0yrnpA7vVb5iCNodK9W4MoFnNsRFbZYEoTtjNJsjdX0GUfs64cMXASzIPqzfDEDybEPHgTerGfnn/nVV1xfzEPuSUrhMP7Lj+T1EwnJN9AosI8daizdBF1+KHCfodQbPH1rKi26mBXr4z+wIpv4w0+8zuQqIBTBVdHAA+ya DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16169.593c30ec.k1705; bh=qf6kwkZOACvbHR6+ppB3/4K4HcfnfhN8l4vRVgdFAhk=; b=Bdgfn2O6jByxPvekb6WZ6SApelCrr2vsA24XAeE1h92gOgtkCX/VBtgzRltKpE4/uEAdmuxrfc6+tSkhNpaxTLpvNMNZvlh6eq2DOUizB5bufJU8jc4nO7NAxAfD4u/EZSEGd4Py/HXLwSv4Ot4H+LIyEiX+Yn9hbS9Ds4gQ7pk8BmfqqX1l5x3nXhG/N+1ejZ4cpqiFBIQxl/SdsOujYgCanGtalwE53GWPOuwqEDYm/XSQso8a7kBjfFE6bFpZ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jun 2017 17:48:28 -0000 Date: 10 Jun 2017 13:48:28 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 17:48:31 -0000 > Hmmm... That's not really part of the standard RSA signing interface that > I'm familiar with. See for instance [0].. Can you send me a pointer to what > you have in mind. I do this to generate the key: $ openssl genrsa -rand /dev/random -out key.example.com 1024 $ openssl rsa -in key.example.com -pubout | munge > key record where munge removes the BEGIN/END PUBLIC KEY puts the key on one line Somehow that blob includes the key length, since I can change the length and the signing and validation code is the same. For the interface, it would be nice if the EC key were similarly self-describing. Or it may be moot since the key sizes are fixed. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 10 11:29:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1C2129420 for ; Sat, 10 Jun 2017 11:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 BPiMgEDh_jlD for ; Sat, 10 Jun 2017 11:29:38 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 BAE36126C83 for ; Sat, 10 Jun 2017 11:29:38 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5AIRno9031844; Sat, 10 Jun 2017 19:29:36 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=CfXNndG0lAMhiJTDQtc302Wzld5B56nUnXBBiU9oatw=; b=YoJslr/RRCW3Xf9nnmeD+kZZ6+Q0Xr/aT4OlrMqB4OZWIxICaf/ZQ7nHCj7BkckxMH4T D+qwNMRit0Mx3ArTlx1JWPXgp8Cu1ufmy9tz4wbfb9gmYC9XYoHM2nxhV3RxKYugVGAk KtJYEHhaO2eS1y3O5/Ut28oHFtdCHx3fuQQnaYlNn/RBUrjYV97Ka0u8bJY2dSL9djBH LuWOAeeETGUEKe1i9Lz1RnA7cFfYFlh+PlGt18ohe3mklwewVbyVOWIs0vV9TgO9+tcS Du7nn6XMJ/iRElOD89vjE5Opr1DQa+I7FofH/M2WqVREm2SAOEAhTDt5bM9KQ0N9x59u 3Q== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b096b2kk3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 19:29:36 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5AIQUGO000423; Sat, 10 Jun 2017 14:29:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3u1742-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 14:29:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 14:29:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 14:29:33 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "sklist@kitterman.com" Thread-Topic: [Dcrup] we need to do the work, was draft-ietf-dcrup-dkim-usage and document shepherds Thread-Index: AQHS4eiQsw/ddRnyGkSZUMFLQTl9oqIeaKgA Date: Sat, 10 Jun 2017 18:29:32 +0000 Message-ID: <68d03c39527d4f3d972e45c877d248ba@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170610125300.14197.qmail@ary.lan> In-Reply-To: <20170610125300.14197.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.139] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100312 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100312 Archived-At: Subject: Re: [Dcrup] we need to do the work, was draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 18:29:40 -0000 Speaking as an individual and co-chair for CURDLE, not this group... > This shouldn't be hard, we're not trying to invent anything. I was hopin= g > Scott and others who know more about crypto than I do would be making > concrete suggestions about which elliptical algorithm to add, by now. If there is any reason why DKIM cannot use the signature methods just-defin= ed by CURDLE for CMS https://datatracker.ietf.org/doc/draft-ietf-curdle-cms= -eddsa-signatures/ =09 From nobody Sat Jun 10 11:34:00 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F44812702E for ; Sat, 10 Jun 2017 11:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 pH-ebkjA6NYr for ; Sat, 10 Jun 2017 11:33:57 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53786126C83 for ; Sat, 10 Jun 2017 11:33:57 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 61628C403A4 for ; Sat, 10 Jun 2017 13:33:55 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497119635; bh=1ZKMA+Lt/BPwwSYNEko/gptilU+vj9myRiO2+jbdFDs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=m3KlBwSEwGrYdzFbwVa8fRSe9vJYIM0R9XAECe+NCTIbkBSqVCXpReqKrw1mjiMbN fkp4F6WtCmDO6XrYhly037ILQ6+i5G+e+7Dgo16flm4iHC31LIrnUAWRZqq0Vw2BCy OYIxEq9/Nm3XlD1QoK3NX03xoPGdDzbjKSkpUSgU= From: Scott Kitterman To: dcrup@ietf.org Date: Sat, 10 Jun 2017 14:33:54 -0400 Message-ID: <30567530.MBenZTfLgc@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 18:33:59 -0000 On Saturday, June 10, 2017 10:42:34 AM Martin Thomson wrote: > I find the construction of this draft strange. Why not simply say > "verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"? > The remainder of the text is largely unchanged, which took me a while > to validate. > > The problem here is that removing the definition of rsa-sha1 is not > the point. The code point can't be undefined (Section 7 gets that > right), and we don't really benefit from having the definition > removed. What we want is to have rsa-sha256 implemented and deployed. > > So say two things, just to be perfectly clear: > > 1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted. > > 2. DKIM implementations MUST use rsa-sha256. Signers MUST create > signatures using rsa-sha256 and verifiers MUST verify those > signatures. This is pretty much what we had in -01 and this approach was suggested instead. In XML, sorry, here's the diff: https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/commit/b3956a026c18b88ac2f47f8a012610598149e286 I liked it better before, which is more like I believe you are suggesting, so let's see what others say on that particular topic. > I disagree with John about the publication of this draft without the > new schemes. It's worth doing now and the extra overheads of > publication are small. Exactly. > Nits: > > Section 3, two errors here: > > One algorithms, rsa-sha256, is currenlty defined. Done. > Section 3.2 s/,/ / here: > > DKIM,[RFC6376] Done. > Section 6 has an extra period. Fixed. > Collapse Section 7.1 into Section 7: > > """ > IANA is requested to update the "sha1" registration in the "DKIM Hash > Algorithms" as follows: >
> """ Done. snip. Scott K From nobody Sat Jun 10 11:43:06 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755BE129420 for ; Sat, 10 Jun 2017 11:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=mM/WCwjV; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=DmBAp6YM 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 0uJzv81eu2gj for ; Sat, 10 Jun 2017 11:43:04 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DB012773A for ; Sat, 10 Jun 2017 11:43:03 -0700 (PDT) Received: (qmail 96269 invoked from network); 10 Jun 2017 18:43:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1780b.593c3db6.k1705; bh=Q6NDyJXAWec+Z3IE0kNoBJzUxnQyDcBCHChT+75O7Fg=; b=mM/WCwjV2xqQOy6w3vYfNFDyYdMZ1ndhUpE0mmCoAD4EiS4F6yFZy8x8tz6HjQbi4q4pQ3JTjQ/k9eC79S2hq97AIn7thUf6R9ix0cpUT9kB2vg/ytPolffPWtNij8G+06pi2cSwC5IrgnYDKsWJRr2Q6uKojPxB7pVQJ6hPwypJYVZ8vrTlVoWdss9BIpoBFIrDRvZCV6xsHT5iq7PvDel+XdNjYwGbC/CBCOTHvEonfaiL+pqn0QtKaq5YtO8U DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1780b.593c3db6.k1705; bh=Q6NDyJXAWec+Z3IE0kNoBJzUxnQyDcBCHChT+75O7Fg=; b=DmBAp6YMvVxaI2+hHBVjW4UPzF17wLMh3OtS0fDOroA1uktJhmgJfW1E+OM78JTAJOcKgzHkc1tFiRwOfl0acdMm9bMUpoRSR7bUoZXz+kEVK0F8TXsdXDEBw6h3ZIHu+hyCHSvwhrjnT+qeaDfV8NVyNJbj0yIIdvDfQ4l8JQh2aQzNKDhCUe1jfbhFX9huKwdv+5RFNYLmoeh9lUv1uu7iQNp/6BHgub5S83fD+419RBTP3LlunZWh9rLshP9l Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jun 2017 18:43:02 -0000 Date: 10 Jun 2017 14:43:02 -0400 Message-ID: From: "John R Levine" To: "Salz, Rich" Cc: "dcrup@ietf.org" In-Reply-To: <68d03c39527d4f3d972e45c877d248ba@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170610125300.14197.qmail@ary.lan> <68d03c39527d4f3d972e45c877d248ba@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] we need to do the work, was draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 18:43:05 -0000 > If there is any reason why DKIM cannot use the signature methods > just-defined by CURDLE for CMS > https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ As far as I know, that would probably work, although DKIM has no CMS or ASN.1, just bare base64 keys and signatures. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 10 11:59:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A2A129440 for ; Sat, 10 Jun 2017 11:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 4MB-IUq0b7Ds for ; Sat, 10 Jun 2017 11:59:18 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 3D87E1293E8 for ; Sat, 10 Jun 2017 11:59:17 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5AIugwd023406; Sat, 10 Jun 2017 19:59:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=/vXE3JpqClFjIcPZjd/gTg4YgzHQ+5UizI2Azz6RUt4=; b=WlavdUQs+DxycjYk4SArf5hVM26k0iFwCtZjQXkqSDdtNlJaHwZEVxj6BN33SE0Kshru A7mvG5KvaZS4mYYoeGdY9qSFkwsJG2UgD/PLuzC7+452INUE/UF2QExV0qfsEFPQ9kcr 0bTCw6c5UMfte7wnhU8vtnC3jS3KUMlrJEYK5Flazq/xXKL9WafdXE4y3Z8MxfeOFc2D v7u+7P7YrQGJeyFfl+Nf5FqIRAYkoJzf8Jq/cKUQMas5KVPn7525db4ivD72C8jtQyub pLsHD3TmngI0eOMpCCwBptP0vbtKRbd70OwQEWpipwy0l/v63oPfoLq+O+VQ9O1UEBoy eQ== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b096b2pcy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 19:59:16 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5AItmFg018174; Sat, 10 Jun 2017 14:59:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3u18s4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 14:59:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 14:59:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 14:59:12 -0400 From: "Salz, Rich" To: John R Levine , Eric Rescorla CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] Hey, crypto experts, what signing algorithm should we add Thread-Index: AQHS4fkAIjgLds0hJ0GvmXIka/pM/KIecZyAgAAU24CAAAAwAIAAAOuAgAALHgCAAA/0AP//ysQg Date: Sat, 10 Jun 2017 18:59:10 +0000 Message-ID: References: <20170610125545.14232.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.139] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100322 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100322 Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 18:59:20 -0000 > Somehow that blob includes the key length, since I can change the length > and the signing and validation code is the same. The encoding of an RSA key includes the key size. =20 > For the interface, it would be nice if the EC key were similarly self-des= cribing. > Or it may be moot since the key sizes are fixed. Yes, the key sizes are fixed depending on the curve. The encodings of curv= es are different and not self-describing. If you see a string of bytes lyi= ng on the ground, you can't necessarily tell anything about the key -- if i= t is one, it's size, and which curve applies. You need external state such= as knowing the signing algorithm; that shouldn't be a problem. Supporting Ed25519 will not come with zero code changes. But minimal I thi= nk. From nobody Sat Jun 10 12:16:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6CB129468 for ; Sat, 10 Jun 2017 12:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=juniper.net 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 afYyz6dw7uSG for ; Sat, 10 Jun 2017 12:16:17 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0126.outbound.protection.outlook.com [104.47.34.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE93B129466 for ; Sat, 10 Jun 2017 12:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dIHu5xxyFA1oYbR+j510CepGixks4huB81IqlY/nH7M=; b=fitKZRhm3hqjs6LSJvJI/PmCoV/8bbOtPgPsq7K3keRZr2xHx0JPTd3OX8IHgQvzTXBl3kz+Q1G3fnXrBq1w/CGUe4izQzhhXGrjguHalZZLOs3zxVXkP9mBatfZTzTGpTCEOZa2NY/3fag5t30kQ99TNMF4NskajNurOCe7lNg= Received: from BY1PR0501CA0035.namprd05.prod.outlook.com (10.162.139.45) by SN1PR05MB1984.namprd05.prod.outlook.com (10.162.132.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1157.9; Sat, 10 Jun 2017 19:16:16 +0000 Received: from DM3NAM05FT028.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::203) by BY1PR0501CA0035.outlook.office365.com (2a01:111:e400:4821::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.5 via Frontend Transport; Sat, 10 Jun 2017 19:16:16 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT028.mail.protection.outlook.com (10.152.98.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1143.19 via Frontend Transport; Sat, 10 Jun 2017 19:16:15 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 10 Jun 2017 12:16:03 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v5AJG2TP021469; Sat, 10 Jun 2017 12:16:02 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id D61EC1144E; Sat, 10 Jun 2017 12:16:01 -0700 (PDT) To: John R Levine CC: Eric Rescorla , In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> Comments: In-reply-to: John R Levine message dated "Sat, 10 Jun 2017 13:48:28 -0400." From: "Mark D. Baushke" Date: Sat, 10 Jun 2017 12:16:01 -0700 Message-ID: <81246.1497122161@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(39860400002)(39840400002)(39450400003)(39850400002)(39400400002)(39410400002)(2980300002)(189002)(199003)(9170700003)(53416004)(6246003)(6266002)(110136004)(93886004)(7846003)(6392003)(478600001)(189998001)(2950100002)(6916009)(4326008)(305945005)(117636001)(47776003)(55016002)(7126002)(5660300001)(356003)(106466001)(38730400002)(229853002)(50986999)(81166006)(53936002)(76176999)(105596002)(8676002)(54356999)(5003940100001)(54906002)(7696004)(77096006)(86362001)(48376002)(76506005)(575784001)(2810700001)(2906002)(50466002)(8936002)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB1984; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; MX:1; A:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT028; 1:H+Hi90d79dZu/ZMGxmFuyxiBCyJg9bRXmXjlSxezLy+GTh0vM0mgzV332KISKzUpsJ4NfapRIxt8cTKynSQWa7DNnPLE8WxsUUYJ83uFBOLnZi1wF0KVlMs94bWq22VGjBq8knqTZ9M8h2T1TPfEVybQLFDHo/rxx4SWeKodHi7cQLkWpOnNeZmgvNhTiFduN6pamBRtbugcCF3aQJGBvvWs0w+ikG1fBXTzqDjATU6tdeH46iqpzR/B+CRnhbUMuzUccxJprJ8QZMhaZjHFqB+cM7/uqxFoz67CSo7IqNJXJMbo7/HlWJYGRTNxCoD4HRvPZd6Zl8Mb1fX56E5PXdBE1mIdngWoPN0yOrWYzNaoECeYD8xZsuUj3yb7OAfgnWnZNAe3uLLlFvGI4lxHKnrPtJN1JWByAd+FdGdi74qvMv5+uWo5nG91t6sMclND504oBFfKyCjfA/3Qf94+43ji695qs+RVe1LHXqPUFgvsLogid2mi+0L16dC0UtOAWZITIrX8J3NPqu9DyGvnlz1QUGlnmpoIMVUHISPLRJ5K7aCoEkVIv6i4nL92pMdT X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SN1PR05MB1984: X-MS-Office365-Filtering-Correlation-Id: 7643d704-ab56-46bf-05ac-08d4b0352a97 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN1PR05MB1984; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 3:Mu0m3/fpvW5OtEF9TmDqhdbDk4IaGC7fwYRpT5YdbfufJ5NQdVa0E6t3A9QITRYSduF080oQdmjpn9h4+bcKKJnb2yIdBKOEno7L8Xx+JeFXYa4RJnDhOSlP9Q81f6WAY6pAdFtzWWcb4uFtKo1gXLHDgn2BS+XhLNZ0ubSK/d6fwZXyPCR4P4+JHiFRERIyaGhPyu4rGJPD1+Edsa7YkJ1OUORrRg2UfI4vSJQQY4r4+TZXBaYdrdH6AogK/4EQ6IstFupEbRDVMMeQV7ZttrFcaJOKEjGxDC/zzr+HV1nTNMC3CEwqEmLoylcVWg5txHQb6mLuupopuzPJVwKXkB0dZRsMd1wyB5nF09wyglKVjUa7iXI12LqePgqI/68dLRc9OBvDRNv9ubDxiNhf4X0tW75e4Lzrpo16ZGy/VWZ/L8mVsFk6TVQ9UO+9PlCdJXDXF+Z03Oz/zyI6VHp+7Q== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 25:CzuLkp0hcMi1HwNuNp8FyFbl80xKKLh7u+EKqY6LhIH/sBuofroZy0EaibltrRuDE5QxuFyfIzgg1LoOYE0mxNSGu+oFfWkhMDrgdpi+q1ggFdGBNPS1fUnEW8dXSVGII/Lk6mN+A9AtEkLcuM8cKW9lDbSj0xdXibbr4pnEPxbYvCK8tubdac4rq50V9qVu1cJr2+tdNXHE+3onvnFXWjX0fikYh7ICMQPXSu6/j4eEvINoLVnRGzYx+IKH2H0s3+DWW6FWxzlwOhkwGTvyGh2SLn9/Ik0JgPkIVwJPp25iWBS+7QeoQMWG9PibK99Sm88d2lXu4wJsi6TOJLV2Ej4PgVp1rItj30NejVZHQDNTd+sqstyDsx9HV4KkljhiTu9gPmLmqBMHWRmCQlsJ2jQQ58LKY8g6jS+2jZaBdq5Og+kBMrxf87ZdyMuLj5B0pA13hUpoZa2cBQXdwPHjnJuxLemHyUiFCk+/L6TyRrA=; 31:otTEK0OIXMaV5U1fhbCHGEOy39x8M5f3YM9s0xM168kiT+d3NnbcBAUtjwYzvRfyVKtREgNFfUobBgyz7n34UDbVK4089AN2rrW93/qQiLl/1f01kz/rd34fvetLwYmdOnYB0IAIDvriMrDUXWtXGoWL2tfLp3e3bdVoOn0zOFz3CpJ0vfmvr7gWxvgbCaME1HCvevawI9hk/wWrdgco4Hi13voQogyiEQxpPHQ/0ijOwlsj+cUKxhRPUew4bfxUS25IcGqxribOyg5DnnOREQ== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 20:KRYyTgXtTUKVzclFV6KD4xrzkZ1BYO/E4O6xQq5LWw3r0iG9WKDnRDswat8Vfrbjjf8d+SlDTiP8VJrHh9vS0oemfW4gFZ9UlaqYTgXQTU2R2YPutwwTiOUjctGGlP4YC+EgXEgJW8Gyzb/OCfJqeZ6V4Fw4kd2/+Wv4+g5PF/hyUZCOQpzzS3+M1QKmVstDun+Uhp8oKvVUySZD8KU2f7SAnjj9H+MTE3e4Gm1MR3mtuDWU2jFAapovBFag7YtYN2gD2MJxbd5eWkW04PVN5zBu5B6pE7XHjazAKHxeOUfvrzal6kKHIcIYJUGeeyktbbzUqtjjqu6heBgFw+lRQDF3QPKW4THRII8mkdgFLL7ZlHNgqMUWbY2CejczWzSNHkTBNljOv74FZGDvtw6ItilJUuMQioHr5+0f+eIpCj8zmUjg+Yqrsd2GcqT5vREjxIgwrJhN3+2pyklmhLbYZBZ8lQgDnw2Q1jbU22bAQYvvR4PoHtoz7Thit6NQuh8n X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(13018025)(13016025)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93003095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:SN1PR05MB1984; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:SN1PR05MB1984; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB1984; 4:yR78KkqT/yN/zMj/vCkSC8Tq+v0qIOYr+gFhKU2NCO?= =?us-ascii?Q?fs+5PGU08d9yHJ/wE9+yMftsRJJbIc0aRayOIxmCIFcA9zcG61bzzXF+wbnj?= =?us-ascii?Q?Bn+7gFU7A/oF1nQOWnGiaSRfdf11pJMgSN7pms1kCVyozkbYHCZ0SMkH0h0V?= =?us-ascii?Q?Q4TlJpaHidtZl59nLVqdBnCzPFZtlPRIDASgSSyz6TnjbRB7BUGAvGqVzbRu?= =?us-ascii?Q?3z9WPqT16AnKi8DAHuJyvfB5pTNPhcA7XYo7kSvPyWCfo8WxEw7QGInCCwj6?= =?us-ascii?Q?e73wq4lWBFxZO9xgBbqykTF66jrj5EyIMVIye2lNS3OT/0fe7cWXBfMAjV5H?= =?us-ascii?Q?AxzwXhWUwHMINVLCT077xKDxZLfEstDTmr7+KwywF+6EJz4PRh4HYygNrOd8?= =?us-ascii?Q?xd4m3/O3U9585t+av7n9C+/lT3SPdmjFWx4WRabxw+AkF70wRfxT2jdSprxq?= =?us-ascii?Q?oOjlkfFV7vAPL0Y9+/MadSHZO//w9IlBeqCTOWEu0f9mgxr6UEtMEFwuNuPE?= =?us-ascii?Q?NqR77J5Rm1Ff1bT3H7PL1t1k4ronv1Dq7J1b1C9CcAIyxuBTvECaa0Br6nWO?= =?us-ascii?Q?YLpzzVstVqtLMkkarXQj4AtR5SsCLzjPZDnQ43RNn8BVYYNUxxKEB8nEejLR?= =?us-ascii?Q?LmD+ynL3hE1FXwKYAWmkI7uZZEW5/UITUABjvQrbo6nlTyneBfAo2dA21oVU?= =?us-ascii?Q?g0sAEpdv2ilr6/ICxM/B29pfCMfcZSPH5P9kPu8dGF7EW0WTpSBQAH3XjLxy?= =?us-ascii?Q?VHPc//eXjyRL0gl4W1etZF22IHcFud3aNDkTDQfFNdqWGyJIrmFrkyHeRDVr?= =?us-ascii?Q?MJrZ5vlhc8JG9vJNphNhFwJbXIjqsP00H+YhWLvQqtqPgeXlDPksmWduOkcd?= =?us-ascii?Q?No53d/QeftOFO67Gr76F0ExecfD+lKjWvfa9FVIoFoto87TSNCk3jEzr7OsN?= =?us-ascii?Q?O15M4CxozACFe40AG0H18CSKAFnIYljMFQvAP1DsZ85mXs0FhMZbqmjT4kfb?= =?us-ascii?Q?H6UfSuS1TLTFTjWrOxvkYoCaqHd50NijB91sYhOEE1/rEyt6CiL16zEZH8M0?= =?us-ascii?Q?dBlGw5x96kF+AWOGlenGLLhBiIHDteohG/PrSxFj/UpVZR9CUtSvjjCi0kYL?= =?us-ascii?Q?FwFG52JehUDO0gFCUXyuIJqY6E991qCS3+NUIK9D3Aa33e9te94+uWUB+4qX?= =?us-ascii?Q?HvBZgeioSXDp9ogq0UkS0hk6Wn4GlMjqQm?= X-Forefront-PRVS: 0334223192 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB1984; 23:ywwfQZYxfev92TjZUapdQ7XLZtvgk3VV0hwg6Qqm9?= =?us-ascii?Q?kWJGAXmhs5UXGvb9q9I0uF7tQweJ0OCrgy5aqNGZf1647EHaR8yc7ByPnYaj?= =?us-ascii?Q?mdMYRFiYk0E+Iba9eyccDMaAofFLngD5wab3Ku16PBKmYuv503kiEmwM5I25?= =?us-ascii?Q?Myqu+XwSfQssecq1GZO1aUd3K6NeC1RghF1zO221msIRl35KfeCQTO9IOunZ?= =?us-ascii?Q?JhRSU1PkpNUAy5AYCP/0IY48+8O++qnK6ev69UJbiTBetmb7RZVQOby2HCwP?= =?us-ascii?Q?uLVtM89YMZiH4EA454R00jnat1xzWkhBp56IWUS1Snmzoz5LXbNevduUI7oy?= =?us-ascii?Q?tKcOEuj0TT+RN6jW7dhXd2DCJjpiplu44199fO61hbor5OMtjGDVsgs7TSzk?= =?us-ascii?Q?guMRsfm/Uw1Lk2zRXnyU+wvGT9yklZ1fBoc9BYnZNCxnEp8fLz+p5GiiqlwY?= =?us-ascii?Q?nHq6wIRe0DbhxGJLusMm2zAG4s9Ga+7sPrTNbOHo5ykk7dLkKnPN/CEXGb1e?= =?us-ascii?Q?KlpZU8oAszSVPRbqnQJ5q6GmzNE0IPxmvkEAELy4MsqDZ6SlYcthZIXwetuX?= =?us-ascii?Q?axgRjr5ACG64WidGrTwya7i4uOAIiyeZIvvq1saJKwM+7e22jVfGmhL7tDaE?= =?us-ascii?Q?9TVbuX8rm9v6ROMOu4CyOqanSfMZy1YkqONOgbX63IbsGShZTOvpa0AszB07?= =?us-ascii?Q?2lVgureolouB+QtXu58EUy6il8F+ZcqgEUXPUbxpJIe6hBeYovPmUGIYEv2P?= =?us-ascii?Q?X08BkrBjP1wVZwFHSbv32eKCMT4eGT1r82+om3d+5gRBCHZKT/rM1vmRgYSJ?= =?us-ascii?Q?lrBTUzMxX3AJkrysiCxJV8dEQVvyMjo8Bj+zw3OdrlYWJmTuohOeKKYFMPye?= =?us-ascii?Q?MbE6S/LWZ7Ut2BEzX5zefRr/P23rZK8/XLlwuQRFEN/OdXN5mjkuoQDWt0Ip?= =?us-ascii?Q?/jAbUjRlNvznKasZ9oH7oYFMt6yoRAqsL18dOjYX9EHJbsgiVUkPX9jU29Ar?= =?us-ascii?Q?PKFRpXNovlZSQ7e4IzZffZXlu/RERUSsGDojpqDgWLrkxFgX8P6mntbIpbdX?= =?us-ascii?Q?XjjoS3DhFvmtOfyScBcQl3C64od9zdjkVUpS2BIdQvmImH1mucYYzqN5ZKic?= =?us-ascii?Q?Qtj36bIiRVsjBR5TupfiHVWN7sKfWHMJLxcyg7JBtYvWtEDaaSXfhaJbR5ZO?= =?us-ascii?Q?fnQBuAJyJz8vDQq1wkHZ5KtqvKkyUZW7zEXM+UKsa4WrEvLHGMI+XosEeYJD?= =?us-ascii?Q?IS6K/Yw8VgjelVE/nux2OgJiykflw3dqf0e8/tMoP0u5vPoGHIiBRE+0jrcR?= =?us-ascii?Q?ZnEhQxw9S2xScqWo7ne+xPjOmZhG72/n/SM5Qv8+vQ0fp5y9odq5jYC8xjSO?= =?us-ascii?Q?6Q2aPGFWRc4KcZvtxbn9IxOu6FWLftb98S6jA0kI/XtPwZZ?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 6:SRE3Gvxr6KKVqm/vn3UXQZw7B0QVScfg68gaqhtsC5zW8FJ7KSe0l2gAlXj9XOcvQUStx3pqc1kkrlepC1TONW0eZU3T55SIf6mLzMlLtAr9+77cJ0k+u6FgLdQTIoZujy2I71x1KzM3ltLUALr/geiG/Yx5DdZjAIZy+t70Wuj9glNIiVvm4RRAG4LP0YNqxehWp1cwKgDV4j8yVlpL3x6V8jwadPCDUSfWFg3d+9hnw4fEkk4mOAIX0lYnf+7zFf14DSI+PQPTRz55lpuIQsSG8XAuiqPYFv35vzzSkC6bK7SA0fwVq2+ZacMwcf4vbNlemyppuQ6MmVAg9UZiA6USf+F93uyZc1kVUifXr4NPpW22Hzc9tldW1VRAUKSp89WPHS9/k17KAly44JpXSfnoykkBSebw3BFWJjTHADRtoE2aZ/GtwxdHs28IP7k9lGCood60BLJNZKaQv1cYom+5IVbjRzGXYhZsueIKr7Zul/iEX+ToiS2LzgTYKOuRtr8zaTvu1CzjGr5WceKElQuFYoijBr8JyxJ9jef4mkU= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 5:bPDWc17h+vpWJujdREQVrILOQqHFxGxE181fZuND9HXPTYc2mQHsilc1RZchAoE9pjjDq8K7RsHEx5yQJvD9EIUz5Ac3aJjC3kRy/v8AhmkIXxQD5vyEpYXJ80oTeElapWqrQLerJvnBECKKrxE+Ovk66bMXQl4Rco8Z6giyxaMKbZEX8uDgHywV+zPFczDEMbaEeUcL0NZtYppJLqdJPC1/fwlNP38xQN2Xqs75Z3mEr1lo3ijE1p9QQjAT0zMZ88RboOHVm2UwSkc2DvzGNcKJNxQugUjjv24M19T56sEGZepmkMbGMcW/9Dd3BIvhmNIZbQB8MM7G4HfueD7pyAqsvNnVz9KjpYzbE9zIAPTFFNpGepV0WgEkAf7PX8bN+77Naf/gQm7D6eW6RTaSRBMOTvjPd217Ft78qWmoPn+mEKtrhqSxTqOOXn/Va99aiQ0cmAZiN4PBRqPlYN48BqmcbFIw4iYb8QPOx7ZctN6reFmwup27iByzaU83CTka; 24:mh3tc6Mx9OD/vXKmySfJy1Cf3TWGgmED5VApS1UXfO+DQdGF9F4qAaXSazCpEET0BxUofyezMNT4uYdPEdNAN7rPF8WkGDosjOz7XZE2Ttw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1984; 7:QZlF6LqcEnwVo5zt5QWvpTch0DcRvAtxaiIM8M+j6QPkBFiUEQnsagXHeJWAOHaqyik/ptb0U1KDZsDj1kO+GEDZgK1+iGjOzTZvVA9jv5B2XMYN6XusWSet/GEQsuH/idZoTr2dAiLlpwPFW8hpkeuF7OqHMGw9vOMQjy/4G8ElQRK9W2TnepZhVVQg2cY63hvtx9L/QHoRsGMtaDEBf5mV+ULjBh7zd4w/QJqtR4s7U082ZD+hSyBH3bnpQVKoIGQv/8h20YrwrhbW8vq4JZSS8iy32lfTrnlJvzqqpcmH3N8fCikcr8imncpn0insTQ1Du2GpsWMObN5LzJjIig== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2017 19:16:15.7096 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB1984 Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 19:16:20 -0000 For OpenSSL and ECDSA, the following example may help you: $ openssl version OpenSSL 1.0.2l 25 May 2017 $ : Tell OpenSSL what Elliptic Curve you want to use: prime256v1 in this case $ openssl ecparam -out prime256v1-param.pem -name prime256v1 $ cat prime256v1-param.pem -----BEGIN EC PARAMETERS----- BggqhkjOPQMBBw== -----END EC PARAMETERS----- $ : Generate a private key based on the prime256v1 $ openssl ecparam -in prime256v1-param.pem -genkey -out my_privatekey.pem $ cat my_privatekey.pem -----BEGIN EC PARAMETERS----- BggqhkjOPQMBBw== -----END EC PARAMETERS----- -----BEGIN EC PRIVATE KEY----- MHcCAQEEIEwjT+3tXgsoPmQ4dGnVtAzuC03S7HHRiqPxifL0cE8UoAoGCCqGSM49 AwEHoUQDQgAEFTtSp6kPe2fjNNfHiaKGpMYFs19xnj6hTfpdmklxE1Y1ERP2Zlgj 2QG5vSbb13xbQ+EPcMdoLt4lBTpy+wxDQw== -----END EC PRIVATE KEY----- $ openssl ec -in my_privatekey.pem -noout -text read EC key Private-Key: (256 bit) priv: 4c:23:4f:ed:ed:5e:0b:28:3e:64:38:74:69:d5:b4: 0c:ee:0b:4d:d2:ec:71:d1:8a:a3:f1:89:f2:f4:70: 4f:14 pub: 04:15:3b:52:a7:a9:0f:7b:67:e3:34:d7:c7:89:a2: 86:a4:c6:05:b3:5f:71:9e:3e:a1:4d:fa:5d:9a:49: 71:13:56:35:11:13:f6:66:58:23:d9:01:b9:bd:26: db:d7:7c:5b:43:e1:0f:70:c7:68:2e:de:25:05:3a: 72:fb:0c:43:43 ASN1 OID: prime256v1 NIST CURVE: P-256 $ : Generate public key $ openssl ec -in my_privatekey.pem -pubout -out my_publickey.pem read EC key writing EC key $ cat my_publickey.pem -----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFTtSp6kPe2fjNNfHiaKGpMYFs19x nj6hTfpdmklxE1Y1ERP2Zlgj2QG5vSbb13xbQ+EPcMdoLt4lBTpy+wxDQw== -----END PUBLIC KEY----- $ If you look the PEM file contains the following prefix before the "pub:" key $ openssl ec -in my_privatekey.pem -pubout -out my_publickey.der -outform der read EC key writing EC key $ od -t x1 my_publickey.der 0000000 30 59 30 13 06 07 2a 86 48 ce 3d 02 01 06 08 2a 0000020 86 48 ce 3d 03 01 07 03 42 00 04 15 3b 52 a7 a9 0000040 0f 7b 67 e3 34 d7 c7 89 a2 86 a4 c6 05 b3 5f 71 0000060 9e 3e a1 4d fa 5d 9a 49 71 13 56 35 11 13 f6 66 0000100 58 23 d9 01 b9 bd 26 db d7 7c 5b 43 e1 0f 70 c7 0000120 68 2e de 25 05 3a 72 fb 0c 43 43 $ Which decomposes to some front material: 30:59:30:13:06:07:2a:86:48:ce:3d:02:01:06:08:2a: 86:48:ce:3d:03:01:07:03:42:00: followed by the public key: 04:15:3b:52:a7:a9:0f:7b:67:e3:34:d7:c7:89:a2: 86:a4:c6:05:b3:5f:71:9e:3e:a1:4d:fa:5d:9a:49: 71:13:56:35:11:13:f6:66:58:23:d9:01:b9:bd:26: db:d7:7c:5b:43:e1:0f:70:c7:68:2e:de:25:05:3a: 72:fb:0c:43:43 Use the key... $ echo hello world > hello.txt $ openssl dgst -sha256 -sign my_privatekey.pem hello.txt > hello.sig $ openssl dgst -sha256 -verify my_publickey.pem -signature hello.sig hello.txt Verified OK $ od -t x1 hello.sig 0000000 30 45 02 20 55 5b 3c 3a ab 2a 5f 70 de 62 a7 32 0000020 19 ea e1 98 bb 13 1e a7 00 9a e4 52 ab 85 74 d8 0000040 c4 b0 4e 98 02 21 00 c0 aa 55 54 83 0f 54 33 f1 0000060 b4 53 fa e9 f2 94 71 3c 5a b7 83 a3 76 51 e1 24 0000100 84 d2 8c 41 dc 3d 5c 0000107 $ I suggest you not actually USE the public/private keypair provided above given it is no longer secret. -- Mark From nobody Sat Jun 10 12:29:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DF61270AC for ; Sat, 10 Jun 2017 12:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=t+gx5hRv; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=dNwjFpe6 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 eCgJf9QkZTEW for ; Sat, 10 Jun 2017 12:28:59 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 050161267BB for ; Sat, 10 Jun 2017 12:28:58 -0700 (PDT) Received: (qmail 993 invoked from network); 10 Jun 2017 19:28:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3df.593c4879.k1705; bh=4SRrdYcxdwYL4YdvZhBxYwGXkxZutYpA6Q7zNQrr1Dk=; b=t+gx5hRvzD5RDzfOvx/tIgcZ1PDjk8rFS8uVbziZ4LttnHxSB0MIRlICEnC4aD7UOaayh2j4qY7uiT1MGF9zGXYwMC1EmUD/HALqnM4G9xfW+CzIaBIW2lktJfOgrAS96nP+pJfAsGndxHzLyjO5fhg0+2O6sVuM3qlOZ8v9N8m9QcsUid4rbqWD77uA6ERER9r6IHN9scX4+iVZ9hznh4c8RQHWvr1XhzRc+9CQxB6hnxFuXeDulSWgVgTD+ofm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=3df.593c4879.k1705; bh=4SRrdYcxdwYL4YdvZhBxYwGXkxZutYpA6Q7zNQrr1Dk=; b=dNwjFpe650y9B9F2jSeimxs+yal++s1ArGl9k/KpqILjz7/EWfcMnRX3/8gTu4OaRX6Y64otX6uD5TevbTEZr7B4A8FLoXuFd3K6T9OMKAPmtgnFhF6o0MgYjdXM8hZzR1z+YQ5PSaZo4Cc4ToGrg7dtR6plTOmBQXuzZflBF4Xvw8/wwqfea6q6u9nA/zabkn3J1y2sb43NH7JVfdy6NAlKqglCt/auAHKHdLrpjaszD3AnFkV0DZvz/Glfaq85 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 10 Jun 2017 19:28:57 -0000 Date: 10 Jun 2017 15:28:57 -0400 Message-ID: From: "John R Levine" To: "Salz, Rich" Cc: "John R Levine" , "Eric Rescorla" , "dcrup@ietf.org" In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 19:29:01 -0000 > Yes, the key sizes are fixed depending on the curve. The encodings of > curves are different and not self-describing. If you see a string of > bytes lying on the ground, you can't necessarily tell anything about the > key -- if it is one, it's size, and which curve applies. You need > external state such as knowing the signing algorithm; that shouldn't be > a problem. That's no problem, the DKIM key record has a field for the algorithm. > Supporting Ed25519 will not come with zero code changes. But minimal I think. Since we have a lot of lazy programmers who will need to do this, how different is ED25519 sign/verify from RSA? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 10 12:32:25 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC431270AC for ; Sat, 10 Jun 2017 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XRZe-SVb6xeh for ; Sat, 10 Jun 2017 12:32:22 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801E81267BB for ; Sat, 10 Jun 2017 12:32:22 -0700 (PDT) Received: (qmail 1496 invoked from network); 10 Jun 2017 19:32:21 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jun 2017 19:32:21 -0000 Date: 10 Jun 2017 19:31:59 -0000 Message-ID: <20170610193159.15077.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 19:32:24 -0000 In article <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> you write: >Alternately, as you suggest, we land one document that does both. I thought we made that decision when we adopted >this document, so I don't know why we're having the conversation again now. If we were going to land only one, then >we don't need this document at all. I thought the plan was one update doc that will combine the relevant bits. >I think you are substantially underestimating the time it will take to get IETF consensus on a new approach based on >ECC. I think if it's done in a year, that'll be fast. I sure hope you're wrong. R's, John From nobody Sat Jun 10 12:45:17 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558631270AC for ; Sat, 10 Jun 2017 12:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 EZckFny8vZ4Z for ; Sat, 10 Jun 2017 12:45:14 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8C4091267BB for ; Sat, 10 Jun 2017 12:45:14 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5AJgTFv025715; Sat, 10 Jun 2017 20:45:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=PsGpViXkrBtNsnpWEugQyiT+89D/SU47efm+ZMQIleE=; b=aUNgimc+IKUc5e3N3p0++T7UUXiVD6luUY4PfhLc2DwbbkaPTZkdkGH4/bNgj9jXrAbg JIgBhjfaY0crSL1j/vC51CVhUhQW7IcfSwITMKvgdh2Z+H1qZMq0sWNnt5fUQ+lkrCHb A1w15rH5YsryO5axA6pOTPK1cXJ55lVMWG3hWneSCqRyHVU6yPdcOIw3hC/MXZdIhnQQ D7y3YQsyq8oIeCcjXnthn9sogXPI+PIEz0p4Qk+wYYw2dC6nRKidgdguN1pH/KG8UY8N VyYQnbm5LApZMOkGtCrHaY5YxYBq/me4i0pJSoDiuCFHs0dXKo9bixvcxq4y4ozFoauD FA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b096b2tas-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 20:45:12 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5AJekna012648; Sat, 10 Jun 2017 15:45:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3u1bb5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 15:45:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 15:45:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 15:45:10 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "sklist@kitterman.com" Thread-Topic: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds Thread-Index: AQHS4e9v76FDRZ1/SkmxsKHlHcgK+6IeoaAAgAAeA4D//74GsA== Date: Sat, 10 Jun 2017 19:45:09 +0000 Message-ID: <006b65316e4640b09ef9e08350048695@usma1ex-dag1mb1.msg.corp.akamai.com> References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> <20170610193159.15077.qmail@ary.lan> In-Reply-To: <20170610193159.15077.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.139] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100336 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100336 Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 19:45:16 -0000 > >I think you are substantially underestimating the time it will take to > >get IETF consensus on a new approach based on ECC. I think if it's done= in a > year, that'll be fast. >=20 > I sure hope you're wrong. CFRG already spent all the time working to get consensus on algorithms. We= should be able to have a WGLC-ready document in a couple of months, if we = can get a direction and writer(s) by Prague. From nobody Sat Jun 10 12:59:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092A01270FC for ; Sat, 10 Jun 2017 12:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 CBMewh5w1lME for ; Sat, 10 Jun 2017 12:59:18 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4B4126C3D for ; Sat, 10 Jun 2017 12:59:18 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3E9FBC403A4 for ; Sat, 10 Jun 2017 14:59:17 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497124757; bh=kJm2r2aHyvcasTfJwEM7lCLbrzKr5ukKUaClF8Y6sIk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oDITlQJoWPPRsdTREklykBvtDSl/9FSIZ/+RLuNXI6uRCnKUYmkYqnmNXEJumuwSu RS7hYZlJTX52INyWM4Z/PA7lLhILueIsU1UL8P59/11NTRuyVLgRH5b2Qc6kdj4M1Y bQfDeefDmyMUtT9KP8PfOclHMXeiKRRFO98AFMGc= From: Scott Kitterman To: dcrup@ietf.org Date: Sat, 10 Jun 2017 15:59:16 -0400 Message-ID: <3226783.Zmkt5g0zON@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <006b65316e4640b09ef9e08350048695@usma1ex-dag1mb1.msg.corp.akamai.com> References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> <20170610193159.15077.qmail@ary.lan> <006b65316e4640b09ef9e08350048695@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 19:59:20 -0000 On Saturday, June 10, 2017 07:45:09 PM Salz, Rich wrote: > > >I think you are substantially underestimating the time it will take to > > >get IETF consensus on a new approach based on ECC. I think if it's done > > >in a> > > year, that'll be fast. > > > > I sure hope you're wrong. > > CFRG already spent all the time working to get consensus on algorithms. We > should be able to have a WGLC-ready document in a couple of months, if we > can get a direction and writer(s) by Prague. Given that (which I wasn't aware of), I'll revise my estimate downwards. I still think a separate draft for clearing out the obsolete cruft is worth advancing and getting done. Scott K From nobody Sat Jun 10 13:00:26 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39B51270FC for ; Sat, 10 Jun 2017 13:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 IzwnagX5tBlP for ; Sat, 10 Jun 2017 13:00:24 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 2D6C312025C for ; Sat, 10 Jun 2017 13:00:24 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5AJuulg021065; Sat, 10 Jun 2017 21:00:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=qXDZf2xuLcaDLuMC9Xexboay+wwHyRjKROz9Y2uw4lU=; b=nRgrwlOPQeRe71mE9aoNiua5pj/ORD2eS9OkQZvzbcHulhB7HV8kkLfBlRz3M/7bgr7B i0rQyOzdtZ2hO3ooeH/EqCza7i88jimQSUWgS2J4jiboDD6KKJoiNySvACW05q31w2lk VUX56kYy8lAMqg3+iwX1/XSoUikf4fBmavBAtW5RDQN2q6xvENVw37TKI18Eb9pOOcYu doW2l75IT4yOpjnrzDwVoCk4mXDKijx0a/CcwJJG0U6mwsoOi8PzyNY8AGI2WAShv1QQ T5pM4/i2kiKOl5acwmlqNI3WwUR3AMNq6QEC+vZcWcYZSTQ+Od8tyiRad9kPzdx5y+2w Fw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b05uauj7k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 21:00:21 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5AJu8Xb021526; Sat, 10 Jun 2017 16:00:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3u1c80-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 16:00:21 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 16:00:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 16:00:20 -0400 From: "Salz, Rich" To: John R Levine CC: Eric Rescorla , "dcrup@ietf.org" Thread-Topic: [Dcrup] Hey, crypto experts, what signing algorithm should we add Thread-Index: AQHS4fkAIjgLds0hJ0GvmXIka/pM/KIecZyAgAAU24CAAAAwAIAAAOuAgAALHgCAAA/0AP//ysQggABRT4D//8G4sA== Date: Sat, 10 Jun 2017 20:00:18 +0000 Message-ID: References: <20170610125545.14232.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.139] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100341 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100341 Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:00:26 -0000 > That's no problem, the DKIM key record has a field for the algorithm. Good. =20 > Since we have a lot of lazy programmers who will need to do this, how > different is ED25519 sign/verify from RSA? Rough estimate: every time you do an RSA thing (load key, sign, etc) add a= n if test and six-10 additional lines. From nobody Sat Jun 10 13:02:54 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9E112871F for ; Sat, 10 Jun 2017 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 XGOXPV9oR9Iu for ; Sat, 10 Jun 2017 13:02:51 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7C4551270FC for ; Sat, 10 Jun 2017 13:02:51 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5AK1jq1013741; Sat, 10 Jun 2017 21:02:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=SUdj6mFol2ztnXvOY44Lw98p36a399INY+BqkaEY/UQ=; b=bStbjdcuDmpdNNzQV329Y+r2mv/piZXbrSOd7pxB/q5McWKvQKjcj09txfuX+iE0Sh+F UeqVZfIZQoP0mEgT3r7+u7JL0KhB0tnWzgsPzKyCaXh/j02RpscRDOuHL9PPssyoPu85 GW52gw9kVeCnkeQIMViDBg2JJtL3s8YVIYjmX9P18zSHDfBekzUJcdSqAYZLF/gOG3eR OeAL5N3jJbAjX1Q2hVqSEYZKE99hd4fiCg+Rh8LImgVXL5EVQR2zMNDloOmDhu26plRg yzrujbHU32xKEMhxN+kQbMo462DlbREdq6KzZgULsE6vWN3EGLj26d2ln+R1vMXqZdyl nQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2b08aak836-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 21:02:49 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5AK0vho004777; Sat, 10 Jun 2017 16:02:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b0c3urxew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 10 Jun 2017 16:02:48 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Jun 2017 13:02:47 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 10 Jun 2017 16:02:47 -0400 From: "Salz, Rich" To: Scott Kitterman , "dcrup@ietf.org" Thread-Topic: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds Thread-Index: AQHS4e9v76FDRZ1/SkmxsKHlHcgK+6IeoaAAgAAeA4D//74GsIAASZoA//+9ehA= Date: Sat, 10 Jun 2017 20:02:46 +0000 Message-ID: References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> <20170610193159.15077.qmail@ary.lan> <006b65316e4640b09ef9e08350048695@usma1ex-dag1mb1.msg.corp.akamai.com> <3226783.Zmkt5g0zON@kitterma-e6430> In-Reply-To: <3226783.Zmkt5g0zON@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.139] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100342 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-10_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706100343 Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:02:53 -0000 > Given that (which I wasn't aware of), I'll revise my estimate downwards. = I > still think a separate draft for clearing out the obsolete cruft is worth > advancing and getting done. Yes, there's a growing tradition for "die-die-die" documents. From nobody Sat Jun 10 13:29:27 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31629128D69 for ; Sat, 10 Jun 2017 13:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 EuNEsRNmXpu2 for ; Sat, 10 Jun 2017 13:29:24 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA958126D85 for ; Sat, 10 Jun 2017 13:29:24 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A7518C40218 for ; Sat, 10 Jun 2017 15:29:23 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497126563; bh=KPkOdvtIlC3mWr5EqQXX774+g1p0/VR7yOd/zLzeU7I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sre4VWSVbx24M2FrkB/2eeRx5lu76xEylkYy2MJF2N4w09uc9GqSe4u80Wt1+C7ga Mf/J760ksPvEMyXuWW/uqfNZPA7onXTf0WfXjzFH56TdLjHD02kGkaqZGcG8dxJEVm pIV8YlwvWZboViakbf8bdwA7pe1R578rbZyjyClw= From: Scott Kitterman To: "dcrup@ietf.org" Date: Sat, 10 Jun 2017 16:29:23 -0400 Message-ID: <44047203.rS5CgVd1do@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> <3226783.Zmkt5g0zON@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:29:26 -0000 On Saturday, June 10, 2017 08:02:46 PM Salz, Rich wrote: > > Given that (which I wasn't aware of), I'll revise my estimate downwards. > > I > > still think a separate draft for clearing out the obsolete cruft is worth > > advancing and getting done. > > Yes, there's a growing tradition for "die-die-die" documents. OK. Given that, I'd like to resolve the question of how to refer to rsa-sha1 in section three. There, as far as I can tell, two visions, roughly what's in -02 and what was in -01: Current (-02): > 3. DKIM Signing and Verification Algorithms > > This section replaces [RFC6376] Section 3.3 in its entirety. > > Generally, DKIM supports multiple digital signature algorithms. One > algorithm, rsa-sha256, is currenlty defined. Signers MUST implement > and sign using rsa-sha256. Verifiers MUST implement rsa-sha256. > > 3.1. The rsa-sha256 Signing Algorithm > > The rsa-sha256 Signing Algorithm computes a message hash as described > in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the > hash-alg. That hash is then signed by the Signer using the RSA > algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg > and the Signer's private key. The hash MUST NOT be truncated or > converted into any form other than the native binary form before > being signed. The signing algorithm SHOULD use a public exponent of > 65537. > > 3.2. Key Sizes ... and -01: > 3. DKIM Signing and Verification Algorithms > > This section replaces [RFC6376] Section 3.3 in its entirety. > > DKIM supports multiple digital signature algorithms. Two algorithms > were defined by [RFC6376]: rsa-sha1 and rsa-sha256. Signers MUST > implement and sign using rsa-sha256. Verifiers MUST implement rsa- > sha256. The rsa-sha1 signing algorithm is obsolete and MUST NOT be > used. > > 3.1. The rsa-sha1 Signing Algorithm > > This algorithm is obsolete and MUST NOT be used. > > 3.2. The rsa-sha256 Signing Algorithm > > The rsa-sha256 Signing Algorithm computes a message hash as described > in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the > hash-alg. That hash is then signed by the Signer using the RSA > algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg > and the Signer's private key. The hash MUST NOT be truncated or > converted into any form other than the native binary form before > being signed. The signing algorithm SHOULD use a public exponent of > 65537. > > 3.3. Key Sizes ... Personally, I prefer the explicit MUST NOT we had in -01 and I think that's along the lines of what Martin Thomson was suggesting. A hatless msk preferred something more like what's there now. Technically, I think the amount to the same thing. Is it better to be more explicit about what's being removed or be implicit by removing it from what's specified? Personally, I think explicit is better than implicit, but being a Python guy, I would [1] Scott K [1] https://www.python.org/dev/peps/pep-0020/ From nobody Sat Jun 10 13:34:55 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFABF126D85 for ; Sat, 10 Jun 2017 13:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 AGxK2jE4kyLe for ; Sat, 10 Jun 2017 13:34:52 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 635C312944B for ; Sat, 10 Jun 2017 13:34:49 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B330CC40218 for ; Sat, 10 Jun 2017 15:34:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497126887; bh=CO2ME56P3GOxHwWRsrK50ZCeeRk6axsUc3Kr6qnh2N8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=aa5WGiU85Q+q/ialUlVMKt0qw9ukUus+h2rxe1jqH5Edwi4+BZE+6ZzaHFRksbZCm VrUiHLfw9HFi2MyiP5mPwmWh464SZ/MGIvPfoNvFucOQptfzUPXitlAhCFrleCdlpj 1zQ1iXX15S1oKCs/FcZ+mu27f9TuE00untU/a8zs= From: Scott Kitterman To: dcrup@ietf.org Date: Sat, 10 Jun 2017 16:34:47 -0400 Message-ID: <8667981.ECuWKPzl1m@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jun 2017 20:34:54 -0000 On Saturday, June 10, 2017 03:28:57 PM John R Levine wrote: > > Yes, the key sizes are fixed depending on the curve. The encodings of > > curves are different and not self-describing. If you see a string of > > bytes lying on the ground, you can't necessarily tell anything about the > > key -- if it is one, it's size, and which curve applies. You need > > external state such as knowing the signing algorithm; that shouldn't be > > a problem. > > That's no problem, the DKIM key record has a field for the algorithm. > > > Supporting Ed25519 will not come with zero code changes. But minimal I > > think. > Since we have a lot of lazy programmers who will need to do this, how > different is ED25519 sign/verify from RSA? For Python (I know, not everyone cares, but I do), PyNaCl offers a maintained and reasonably simple API for this: https://pynacl.readthedocs.io/en/latest/signing/#example As an implementer that would need to implement this, it seems eminently doable. I'd prefer something supported in the Python standard library, but I'm certainly not holding my breath for it. Scott K From nobody Sat Jun 10 19:21:39 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FDC1294B8 for ; Sat, 10 Jun 2017 19:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=3220nsfg; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=wbbkV2Io 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 jKb3vVCjEeKK for ; Sat, 10 Jun 2017 19:21:36 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0451B1294B2 for ; Sat, 10 Jun 2017 19:21:35 -0700 (PDT) Received: (qmail 40046 invoked from network); 11 Jun 2017 02:21:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9c6b.593ca92e.k1705; bh=N/qFQ1B92qHqy13bBAjbyzV/V/KN4us3YbX3DO7BaXs=; b=3220nsfg1w5+SMZhaEIbwWaiRsBOpw7X36B/mkNgtHMUz7gWaTboHTmZQhUavNq4mHTpQYhYWRXII8YQC7Rr0zmcbvTRTgh/LEJOOfHVgNB6vig9q9ky+dHRNRTXAt8xP+GWP/hYUiHrfE2/QkYvAgx3xvHC+zH1361xMuwL4nkh6Dh/wrLU6etWa0/886ERP6eaQO9qz6ozLNRShEeWFrUgQ3xae2/rW9N1BMbcGSVdD0sEpHC4E9W4OygJddlT DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9c6b.593ca92e.k1705; bh=N/qFQ1B92qHqy13bBAjbyzV/V/KN4us3YbX3DO7BaXs=; b=wbbkV2IoTylauFrakcxYy9gx+vlyrGIcdDIgqD/eD4HrdDw6B6CNVMYCArs79lfS8X3RiGsislX12xyiNmCSV0CQNODOn6zJxL1sUc7xl096Pe6VjJFYNbtcGy4QHqnqR7zoHZMIPi55sL/VYgFAOX6OWSKqXm5kZPN0arnVVIhWnjcOQZquGBUNxLm8BPREUCiC1dSd7obfrncYqqOF5CC+mbHzjcbQVZ9PcuTqy7vXltp/4dngIdc+BJ5hTVpd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 11 Jun 2017 02:21:34 -0000 Date: 10 Jun 2017 22:21:43 -0400 Message-ID: From: "John R Levine" To: "Salz, Rich" Cc: "dcrup@ietf.org" In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 02:21:38 -0000 On Sat, 10 Jun 2017, Salz, Rich wrote: >> Since we have a lot of lazy programmers who will need to do this, how >> different is ED25519 sign/verify from RSA? > > Rough estimate: every time you do an RSA thing (load key, sign, etc) add an if test and six-10 additional lines. If we want to add ED25519 as a new algorithm, can we just say that you use it where you would have used RSA, with standard base64 formats, and the discussions about key size don't apply? Or do we need to say more? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sat Jun 10 23:56:14 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA71128D40 for ; Sat, 10 Jun 2017 23:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 zyVPkcUkR6xr for ; Sat, 10 Jun 2017 23:56:11 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C041273E2 for ; Sat, 10 Jun 2017 23:56:11 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id f192so22004765yba.2 for ; Sat, 10 Jun 2017 23:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E4iCvOZAtdL1iflR78EAYD4D0y7F6CF8AVU2UtasYcs=; b=G6xGiLEnNtvjveBpWCvS6YBp5LFb7XOTzDzDUZE1qgavLZvnSjbD++c4CKKuWsk9i2 NDODd7IUnW7IfiwLDKgCS+BKhtLbWViKGbvVuPD/s9/7QOYz+htFHnlbNE4GpEx90wBs iu6sZs85T5nHRTK0SvJCb8yno+4vDAHZs7skfIykMMlZDjBkgU1wOBDH3gsnnj51pab+ 7yKJ5cAkuAAK8/gep3Mp06OGLlBe/ysnfDLLW36jvfMvfV5FX3EblmLyywvm2s/0RvGl v11U+e2KMxklGfKy6VJeNcpe2bABJBRiBDhEDNXGxoHe46TlFjVn2Yx2VlbXDRGcLhXb 2Cfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E4iCvOZAtdL1iflR78EAYD4D0y7F6CF8AVU2UtasYcs=; b=mMmgSesQ+MYsNo40/w1nxrsyGS2U6jCHk4l6ELvB3meTXwhirzQ9wi5RyC+eaZ1p76 2kdNfEh6Pvi+Z3XoKWflCzEZoeTat8NiOLfeV5lbgAuMmHe72uTg2ceifYcOjuMNLwYW Mb2Bsul+h9hUzwGDQ/6Bh77P0OCCwezocdI4chhaAc0+7ugMUI8Qe8/LADpMNOUo58sG O06Xddt4ICNAOpmTzQ984Ml0ryE+lyP7HXx5mb1f7XCy3W8wJjrW/IMTD//W8fI8xOXY +Z3dn+biA3mMTgt7mdcGjX2DztRzlHo2f5qcow9ozkwSeOHyyd+NHlI4TTZDCsmUKtEZ vMVQ== X-Gm-Message-State: AODbwcAsbUrclc6RuQxweC87RFCNz4khXiM2HkgK1mlBWr0K+lg2fe8B F2Nu/puuz9CmgOACyB77yqlKStCCLkdjQkM= X-Received: by 10.37.44.72 with SMTP id s69mr19676561ybs.89.1497164170821; Sat, 10 Jun 2017 23:56:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sat, 10 Jun 2017 23:55:30 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> From: Eric Rescorla Date: Sun, 11 Jun 2017 07:55:30 +0100 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11432ade9299050551a9b298" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 06:56:13 -0000 --001a11432ade9299050551a9b298 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 10, 2017 at 6:48 PM, John R Levine wrote: > Hmmm... That's not really part of the standard RSA signing interface that >> I'm familiar with. See for instance [0].. Can you send me a pointer to >> what >> you have in mind. >> > > I do this to generate the key: > > $ openssl genrsa -rand /dev/random -out key.example.com 1024 > > $ openssl rsa -in key.example.com -pubout | munge > key record > > where munge removes the BEGIN/END PUBLIC KEY puts the key on one line Thanks for the explanation. That helps. > > Somehow that blob includes the key length, since I can change the length > and the signing and validation code is the same. > > For the interface, it would be nice if the EC key were similarly > self-describing. Or it may be moot since the key sizes are fixed. Yes the EC keys are self-describing. They say which curve they are on, which tells you the length, so you should be good. Best -Ekr > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --001a11432ade9299050551a9b298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jun 10, 2017 at 6:48 PM, John R Levine <johnl@taugh.com> w= rote:
Hmmm... That's not really part of the standard RSA signing interface th= at
I'm familiar with. See for instance [0].. Can you send me a pointer to = what
you have in mind.

 I do this to generate the key:

$ openssl genrsa -rand /dev/random -out key.example.com 1024

$ openssl rsa -in key.example.com -pubout | munge > key record

where munge removes the BEGIN/END PUBLIC KEY puts the key on one line

Thanks for the explanation. That helps.
=C2=A0
=C2=A0
Somehow that blob includes the key length, since I can change the length an= d the signing and validation code is the same.

For the interface, it would be nice if the EC key were similarly self-descr= ibing.=C2=A0 Or it may be moot since the key sizes are fixed.<= div>
Yes the EC keys are self-describing. They say which curv= e they are on, which tells you the length,
so you should be good.=

Best
-Ekr



Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--001a11432ade9299050551a9b298-- From nobody Sun Jun 11 01:40:08 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9CB1294E7 for ; Sun, 11 Jun 2017 01:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cZaMT3TJLrzp for ; Sun, 11 Jun 2017 01:40:04 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA511294D8 for ; Sun, 11 Jun 2017 01:40:03 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id v20so41731124lfa.1 for ; Sun, 11 Jun 2017 01:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SABYmdhtAZNQBKdbUwxswLVDL1epoabZPQdB0SzsJU4=; b=VZTXg1G/8Y/6YZ6iFmGLmQosx+K1PN2zPnDrCXgmgQxsoa1Td+PtpV20Vr+z3Emywp Gw+kFoytFvgmtLe1/pfJx9ybnROhAgpPr1gQa//DrUGRwymBJ5Rwnf8cUObnflQwBjPd +KgmoM/Fjv+jhVltFCx3sRZZfcnJqi1BWlkqRKLFLk69+E1JY6POW3v4ZS0MGftCA6jp 0j1WDRrOXkn+iMsuecSchSdqAk2f234cB/Y9pgXzViq/eWsyJ1+IXvwZx8bf7R58vP6u iV8XpT3Ba2WDu4z1wghZIZLzAQ3TcDwI5nWCa1QOGFdy8AgY4lxiMLLrKgD5uD4PT6Ot PQqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SABYmdhtAZNQBKdbUwxswLVDL1epoabZPQdB0SzsJU4=; b=Y70aV6E5CgalAtb6JU80pAkDH0833Lryccu/Sl21E5AH2g/3f20T4WSKDhfHedB11n p46aQPWKgkiR2VkRlbvXSAr78yAlofed+miNYTInUZQEit1/otXSpyakKdGu+MFXcWHD YpzAeqlrvFGREeTwrgQpZHt0eWN76zG1mRLrJZ/iL9oN1+L2vd4zRCs2WjfBfzaepDId jttMLlybVhmZNcsUh6azaQyW3vv6EzHYo1ztpX0Hwhc3aLWxCeyZZvIMzRaizTfvce77 OQkZJiR6psIV5QiDfvNxp3uTNifALrUIuxAK/sIEJ15JVzFdKSX7+Ro5cvfy5GkBBXkx xKGg== X-Gm-Message-State: AKS2vOyc22EDM7koB8odhH3mBMac3v6caNuqz8X0JgVS3h8GH9nNha2x WGabBMirSbGmARfFlMlqV+7DRx1KlmAc2UU= X-Received: by 10.25.196.17 with SMTP id u17mr198483lff.19.1497170401321; Sun, 11 Jun 2017 01:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Sun, 11 Jun 2017 01:40:00 -0700 (PDT) In-Reply-To: <30567530.MBenZTfLgc@kitterma-e6430> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <30567530.MBenZTfLgc@kitterma-e6430> From: Martin Thomson Date: Sun, 11 Jun 2017 09:40:00 +0100 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 08:40:06 -0000 On 10 June 2017 at 19:33, Scott Kitterman wrote: > This is pretty much what we had in -01 and this approach was suggested > instead. In XML, sorry, here's the diff: > > https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/commit/b3956a026c18b88ac2f47f8a012610598149e286 That's not quite what I was suggesting. I have sent you a PR for what I think you should say: https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1 I think that I got the essence of your changes there. And it's a lot shorter. Another issue I encountered when doing this: The defining documents specify a single signing algorithm, RSA , and recommends key sizes of 1024 to 2048 bits (but require verification of 512 bit keys). As discussed in US-CERT VU#268267, the operational community has recognized that shorter keys compromise the effectiveness of DKIM. While 1024 bit signatures are common, stronger signatures are not. Widely used DNS configuration software places a practical limit on key sizes, because the software only handles a single 256 octet string in a TXT record, and RSA keys longer than 1024 bits don't fit in 256 octets. Aside from the extra space after the first xref, there are two problems with this paragraph. First, this document doesn't change anything about the recommendations regarding key sizes. That makes the whole paragraph a little misleading. You give the impression that you are doing something about key sizes, but then you don't. Second, you can fit a key larger than 1024 bits in less than 256 octets. A 1536-bit key isn't that great, but it's a huge amount better than 1024. I haven't done the math, but I'm sure that you could find a number that maximizes key length without blowing the 256 octet limit. This might be good advice to add (which would also mean that you can keep the paragraph). From nobody Sun Jun 11 10:43:14 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43FC4129601 for ; Sun, 11 Jun 2017 10:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 OVn5-drnnPAW for ; Sun, 11 Jun 2017 10:43:11 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 ECFF312957B for ; Sun, 11 Jun 2017 10:43:10 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5BHgKNL011095; Sun, 11 Jun 2017 18:43:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0LCuFWSFNKrEMjSxYdwJ4NSXL9bA2pgF7f7ibxx1pw8=; b=kOrVwkBNk4NFSkZJ9g7YwHm9c3mNmXu2xjtePSVsroTXM8EKJ5z68At6GNpzPM3BPui1 zXCrOXNovPYPOy/P+sqcUUNQUdosfPsCpdNxBp++8G+0q+QA12SoLI31fE/ovnuycuAk UOtSQmuI5sCPj3NFoxZb8/WLKu5iKAcPCV5sd3pkjIzsOXiSp+E03b3mbcVO+KZ8wUSy 53Bw4rF+NjvV32PfN069KJ/jNQZba8/Td3xhtoIaeW+m3HKxrd32PCCBefqAIsk78ady k/tU6HbjFWAXrtApm+NgnCYLLi5TmTYKoVFpYZ9v7pqSRs0vT1W9qXIo5Jqi5ifspiRy lg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b08aaq3g4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 11 Jun 2017 18:43:10 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5BHf6ta028273; Sun, 11 Jun 2017 13:43:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3ubssx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 11 Jun 2017 13:43:09 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 11 Jun 2017 13:43:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 11 Jun 2017 13:43:07 -0400 From: "Salz, Rich" To: John R Levine CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] Hey, crypto experts, what signing algorithm should we add Thread-Index: AQHS4fkAIjgLds0hJ0GvmXIka/pM/KIecZyAgAAU24CAAAAwAIAAAOuAgAALHgCAAA/0AP//ysQggABRT4D//8G4sIAAsZuAgAC+UCA= Date: Sun, 11 Jun 2017 17:43:06 +0000 Message-ID: <152cd69567124a1aa2fec7fbe63c936c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170610125545.14232.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.183] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-11_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706110331 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-11_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706110331 Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 17:43:12 -0000 > If we want to add ED25519 as a new algorithm, can we just say that you us= e it > where you would have used RSA, with standard base64 formats, and the > discussions about key size don't apply? Or do we need to say more? That should do it. From nobody Sun Jun 11 11:18:08 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62934129AB0 for ; Sun, 11 Jun 2017 11:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 nMiabi56DDZQ for ; Sun, 11 Jun 2017 11:18:05 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5ED129A9C for ; Sun, 11 Jun 2017 11:17:57 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id g66so41547264vki.1 for ; Sun, 11 Jun 2017 11:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=97INXmU7U4YnYkyloiU+SBx2ORewK+lzNFbnXKMG+jg=; b=V7etiMQx1m4JLMEmLt1EfQMapCJBcUUJWCLDFDWt136Qpr42yZRjyk2r5ZrqytyE4u FmvHsh6n8l7mgo/qo8Hv9xaLgEhDgECSkmj0EZWH5q7oimGEJqHx0MCxD3azmHraUOOF LiGtK/okxELn8wpO1zA+FSZmaFo1a9shhk7rU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=97INXmU7U4YnYkyloiU+SBx2ORewK+lzNFbnXKMG+jg=; b=uJNFtDRAE9zkiZV8EmVPZ4EVp4lr9Xo9bz99s2Dy1gNLsKTW4/SQZ5/8IdWtVoNKTn lGEMhBsVRSwS4fXrpp0OcFSPpn+BQuD/4OWf2o1dfaS1HKg87uvIYQR8AXMfEiw6OA6f IzDXlEDxCuCojpjL4bFOF2RDtTkInI61PZ00M4eruEd9pW3CjE5i8do26k0CNG4c8H0U ynIko96XEFtmHa25bW7aFwfcBxgYBIZhTxb1NJCFiCBS58t3Jn1DrGEAye5UTD5zhZYg qsf/K8EgxNpllNnnpsUHqS3ItyLvTzlrPU406Mc8quAJYwiG4oUbJXOROAtekryDpdCj 2NxA== X-Gm-Message-State: AODbwcD01xvi3sFc5XS9BONszU/1zKckeb+ZdOdgX6IJcUjMa98/FRKX heiFg541iOhhpNBLY7kBw8NJGx7eARoWOtg= X-Received: by 10.31.72.2 with SMTP id v2mr25830023vka.72.1497205076097; Sun, 11 Jun 2017 11:17:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.75.153 with HTTP; Sun, 11 Jun 2017 11:17:55 -0700 (PDT) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> From: Kurt Andersen Date: Sun, 11 Jun 2017 19:17:55 +0100 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dae3eb794480551b33859" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:18:07 -0000 --001a114dae3eb794480551b33859 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 10, 2017 at 3:14 AM, Scott Kitterman wrote: > > > On June 9, 2017 8:25:38 PM EDT, John Levine wrote: > . . .it seems kind of premature to me. > > Why would that matter? This draft just gets rid of the obsolete cruft. > It clears the deck for adding a new algorithm, but in no way requires we > have that sorted out. > While RFCs do have a cost, can the ADs weigh in on the relative benefits of doing this "sweep the decks clean" first update to be followed by "add more algorithms" vs. bundling it all together? I too think that it might be a bit premature to make a last call though I'm in support of the two-pass approach. --Kurt --001a114dae3eb794480551b33859 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jun 10, 2017 at 3:14 AM, Scott Kitterman <sklist@kitterman.com= > wrote:


On June 9, 2017 8:25:38 PM EDT, John Levine <johnl@taugh.com> wrote:
. . .it seems kind of premature t= o me.

Why would that matter?=C2=A0 This draft just gets rid of the obsolet= e cruft.=C2=A0 It clears the deck for adding a new algorithm, but in no way= requires we have that sorted out.

Whil= e RFCs do have a cost, can the ADs weigh in on the relative benefits of doi= ng this "sweep the decks clean" first update to be followed by &q= uot;add more algorithms" vs. bundling it all together?

<= /div>
I too think that it might be a bit premature to make a last call = though I'm in support of the two-pass approach.

--Kurt=C2=A0

--001a114dae3eb794480551b33859-- From nobody Sun Jun 11 11:44:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F070A1279EB for ; Sun, 11 Jun 2017 11:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5ps7FpsgtWfS for ; Sun, 11 Jun 2017 11:44:38 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9920127419 for ; Sun, 11 Jun 2017 11:44:37 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id s64so3214971oif.1 for ; Sun, 11 Jun 2017 11:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=kPytU6TCs498+DJidWOzVrYwDAIzPH0ia8UIOaYqjz4=; b=Gzz3K8b20J9v9nw6+xCqOKx4inPOl6U2zyjvkcCgj3ivkp1TWjeTC5qjIncoRKUbqi eaqZ5jl1lEzGhtZhUs9nJXttA9LUkWYT7HlYmZriP0arWCCQM4dBqjwU50RMxUiyJlWs naaU3k0vGRtvgcY7c+o9Oyx/O013VaUDlJLnT4uiUsRWyTN5G0weyiyuv82/9PhX8pJE W7WoLzJ96UGwydZ59Z1rH2OsIXxacpdBKYAJD2rNqPu6oQ04HCutHl6ELZN1AytOlJVN hcW2ToPoDATZJY3dfhV4j/cEqDLHPoLog6fu8A/UFCdIIBLL16/7LI1vxeA+vvjQpVsO AFgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=kPytU6TCs498+DJidWOzVrYwDAIzPH0ia8UIOaYqjz4=; b=ETHfDk8g3kPU/EHHLYqd/Ziq5uvb8yF5EEfAfK1GyRsugEt2gV6Yf6qI5EcNQQHhnK uNLwqD4dRrz3vm7HEE6bIcHUjBLzocHoEdcmRYS8vJUqhFnYvGyohNG98BBPvatlKDFZ a8B+V9Q+Vvife3wehZLPn3DDT3FVcKnGix0i8knckyVd9x0zb6HZyZ3WGYtM3XwqS++O G6MPyXIBDd4xNVUKF+ormHs8yVVmlXm+KGwE2+ZLXXRPkYK9flh3XoJSlPZSBJ8C0I8a t2TbxD77DGil89bE6RU3C4LFB8zvCBizLSy1jbnRkbEFCRk3qpRxmT/4vNrA6i98npCE rzCA== X-Gm-Message-State: AODbwcAgaSVRddG/vAGkQY2VqXE8FVhuYbe5Yg4x177ZgRr/WQ2/D8qP pQXVrHv+i7vbhayf0TICUr4NaK5rnQ== X-Received: by 10.202.64.131 with SMTP id n125mr20555371oia.154.1497206677392; Sun, 11 Jun 2017 11:44:37 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Sun, 11 Jun 2017 11:44:36 -0700 (PDT) In-Reply-To: <152cd69567124a1aa2fec7fbe63c936c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170610125545.14232.qmail@ary.lan> <152cd69567124a1aa2fec7fbe63c936c@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Sun, 11 Jun 2017 14:44:36 -0400 X-Google-Sender-Auth: elOCJ3aVjMWf98GImdFqscfJ8eE Message-ID: To: "Salz, Rich" Cc: John R Levine , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a113de01429548e0551b39850" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:44:40 -0000 --001a113de01429548e0551b39850 Content-Type: text/plain; charset="UTF-8" Which flavor of Ed25519? Are we talking about RFC 8032 or something else. Because there really needs to be a very very good reason not to use the standard as written. The amount of code that needs to be writ is irrelevant to me. People will have to write code whatever. It took me a day to write RFC8032. It will take a lot longer to write a spec for anything else, do test vectors, etc. On Sun, Jun 11, 2017 at 1:43 PM, Salz, Rich wrote: > > If we want to add ED25519 as a new algorithm, can we just say that you > use it > > where you would have used RSA, with standard base64 formats, and the > > discussions about key size don't apply? Or do we need to say more? > > That should do it. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a113de01429548e0551b39850 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Whi= ch flavor of Ed25519?

Are= we talking about=C2=A0RFC 8032 or somethi= ng else. Because there really needs to be a very very good reason not to us= e the standard as written.

The amount of cod= e that needs to be writ is irrelevant to me. People will have to write code= whatever. It took me a day to write RFC8032. It will take a lot longer to = write a spec for anything else, do test vectors, etc.


<= /div>

On Sun, Jun = 11, 2017 at 1:43 PM, Salz, Rich <rsalz@akamai.com> wrote:
=
> If we want to add ED25= 519 as a new algorithm, can we just say that you use it
> where you would have used RSA, with standard base64 formats, and the > discussions about key size don't apply?=C2=A0 Or do we need to say= more?

That should do it.

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a113de01429548e0551b39850-- From nobody Sun Jun 11 11:54:10 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064441292AE for ; Sun, 11 Jun 2017 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=t3RNZ/wK; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=lQBEvSPb 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 h7yqVLd88lTL for ; Sun, 11 Jun 2017 11:54:07 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDF61293E4 for ; Sun, 11 Jun 2017 11:54:05 -0700 (PDT) Received: (qmail 52985 invoked from network); 11 Jun 2017 18:54:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cef7.593d91cc.k1705; bh=jCFnT+ckuXq4dbHNf55RZK/ORqpocIFw/jNpm2EXC+E=; b=t3RNZ/wKDFRV9nGd+QkQCW5rhVtSSkz1r2gX1qEtE39d+l5rnPVMh99DC02s7O7qz7El/8U0gooOKWlSy8U/Ewx2Un9eIqXHGlYkik2+WOgobk9u8IhJTIqd3nhNzfMw+80D61bZ3e/UdKyZON190/hAe0UNuAcLREBqsOTqtZ+ByZwUvHvM4DgiVNQbwvxiqXyfm7SBfZAh4+Lq474uy/F7HGL28Rsc/5DA57Io8QgaIgvNs90Rxw+j/LJ9y1+x DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cef7.593d91cc.k1705; bh=jCFnT+ckuXq4dbHNf55RZK/ORqpocIFw/jNpm2EXC+E=; b=lQBEvSPb7xw3m44L8eCsxP0DAGk1ipF/VZzfhYrqGBGgQvvs15DsEUBJeLmvsmLVpNEoCVi6a6BoEQTZQEBhLd48aJQ2PuFrvQhujG+EQ7qgJbXeRWxXht/jBTkEgsgRDn4oJ8jthqLJn6Apxx8lFFzPdVheuu8hxSfcltw6d7emD55MoDt/6Gk0ahobq/8/lmesezIMCCieMXyQJ1l9bC4VIrMFKisPWOIJR95uBEazvifA61dWfBcF7UGE9ItY Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 11 Jun 2017 18:54:03 -0000 Date: 11 Jun 2017 19:54:02 +0100 Message-ID: From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "dcrup@ietf.org" In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> <152cd69567124a1aa2fec7fbe63c936c@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 18:54:09 -0000 > Which flavor of Ed25519? > > Are we talking about RFC 8032 or something else. Because there really needs > to be a very very good reason not to use the standard as written. I'm not aware of any reason to use anything other than RFC 8032. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Sun Jun 11 12:52:46 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5278412702E for ; Sun, 11 Jun 2017 12:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UZhrp57CaJHD for ; Sun, 11 Jun 2017 12:52:43 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D7C01200F3 for ; Sun, 11 Jun 2017 12:52:43 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id k4so57946536otd.0 for ; Sun, 11 Jun 2017 12:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=hrfbHOqwHWrO5OQwl9eVpdCuuzej34z3GajxiIGMP0I=; b=V4PNIZDA38u70K3Q3tprFBsTCXw9S4uieVY8BJ4YV490B3TfPMCbytCwwd1gjnw6tm 6Lqv7cBPwAexSc98kxTTfSMcD7LabiU5GqkRlIexBD7K4IhpNapxHHUdFYk6KbzFK1XY xTddJB8lFPyvPwaiMLKWtP8fjOSckyJeNj85Aqxpvze2IsoqDPUCn8zeHgJL9TN5CEr7 Bw4O3/L9MsGArXBYEEnELzd3+7QdzUMN0LE0LM5/IaPt8rQCI/cyxIEhcgvUh5nNEa9l jEnitGOWksoUCZppc6/RYnD9LPzfEe3NfLJ5ZywCaIAUq9Pq/snh4WDnfrfcbHV5IPdR bsbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=hrfbHOqwHWrO5OQwl9eVpdCuuzej34z3GajxiIGMP0I=; b=r0yYVnI2+6bR7p+kQsnxVA4nFqM2ZBANAw5xLI8Jy30hf1TbkQJo/n+a1Ie4PhQ2mn R2/rfqTdEIZztGrjKq6a21FZ9YYooNpWg2XsttvNwS78Qy16ZhdD3+e7dfDF93Ehq4Qm oQ3PwbDereY5Ts6NYyD9vVD9CdFco6Cca2wDlBM5ZBGKv34HNYhPskVsy0zsx9UDvjnR GYP71Xieqmc++2SGhSnlvbKM1j/M6su8k18I53FuLrwpdthS5KsYmWFtOCKP4vJGgVku qNqwrVfV82JirJ1NAzPQN+PZcRqDiMC9EqnMRfDRuL2J5/AEkUBiLE0QGbTBKzO63yXs 0PFw== X-Gm-Message-State: AODbwcAl+/7zvAxfwR+LgUlUNVflZ6Xfe/q9WyJNvK5C6mXKVsT0xm1R V78+0G22rqRE57jGnl4TCGYjz2HQYQ== X-Received: by 10.157.44.102 with SMTP id f93mr29390922otb.199.1497210762890; Sun, 11 Jun 2017 12:52:42 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Sun, 11 Jun 2017 12:52:42 -0700 (PDT) In-Reply-To: References: <20170610125545.14232.qmail@ary.lan> <152cd69567124a1aa2fec7fbe63c936c@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Sun, 11 Jun 2017 15:52:42 -0400 X-Google-Sender-Auth: N46-U7YHmTpG3TgPPM-NS15GV1A Message-ID: To: John R Levine Cc: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d5864ad13570551b48b72" Archived-At: Subject: Re: [Dcrup] Hey, crypto experts, what signing algorithm should we add X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jun 2017 19:52:45 -0000 --94eb2c0d5864ad13570551b48b72 Content-Type: text/plain; charset="UTF-8" I just want to make sure we are clear on that. On Sun, Jun 11, 2017 at 2:54 PM, John R Levine wrote: > Which flavor of Ed25519? >> >> Are we talking about RFC 8032 or something else. Because there really >> needs >> to be a very very good reason not to use the standard as written. >> > > I'm not aware of any reason to use anything other than RFC 8032. > > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --94eb2c0d5864ad13570551b48b72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I j= ust want to make sure we are clear on that.


On Sun, Jun 11, 2017 at 2:54 PM, John R Levine <johnl@= taugh.com> wrote:
Which flavor of Ed25519?

Are we talking about RFC 8032 or something else. Because there really needs=
to be a very very good reason not to use the standard as written.

 I'm not aware of any reason to use anything other than RFC 8032.


Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--94eb2c0d5864ad13570551b48b72-- From nobody Sun Jun 11 20:03:36 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33999129B77 for ; Sun, 11 Jun 2017 20:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 x7P44VRyafsT for ; Sun, 11 Jun 2017 20:03:32 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D0B1200F1 for ; Sun, 11 Jun 2017 20:03:32 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id m31so51576011uam.1 for ; Sun, 11 Jun 2017 20:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s+kqxF1Vu8yLnWHGQHMXH8ghYZsJgA7uJdXe0Nqtqjg=; b=C/k2T2M8qFK3o3qyGYiRvcnOpcGZ7HtezVF944n5NrYb9xWR3tqcGr+lryz8iuXKte DcXnNg94T41nTYi/dvoV8F4cOTCKyQJ/qdZ6hnpx7TtKU1hoK71y+pswt9/GKtBhb4dw 7Wnen7K3gf8oXovRiR9zBt+805+Xz8YD7ggyIzw9lGzJt++1nDcFLsCvH2EE2cJECxo4 7/pxu4AFoefsVEev71CLamG3QL1UBjUNMJB4VaqqhzdRepfRyskBfTSYz+L+NdGfiWP5 8PopXzrF6UMmNhCahBApLeIIjkDKunKmD0LX7x8oXNQQb859DhHmFBWkmnc8TsYxGgAj vDvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s+kqxF1Vu8yLnWHGQHMXH8ghYZsJgA7uJdXe0Nqtqjg=; b=W3WJetAjzVIYpfONrkSN8EG1n0MQ8iTrlzOA8jnJuCUsNdxFjH0Ov9KQHtvyESHne4 u+ETWzxgwP2Qvd6HPx+QJmc6j5mU6ALSz30IiE2v9lSM0zezQtwhpS55C/ELNsmd9Yzv 4Hcrx7vGstbFJ52KWghkrPNTVX/m3Hsg0ki0hX67PyHycHb6ePKGmjd+fE2VNHM5jOfP LTDxhPLq7RHLAPdnOZgu8ZS/mFESglC7AZRf3HOoSwzVDLZ9tFXvGjtfuXs11kewUfI2 nrWSj8k0UDE8XbBmtZ8jtSQAolUwHaQk/cPcqWHZI4kWBolCENzlA5wsuuSSfWogjcf5 +Vkw== X-Gm-Message-State: AODbwcCIViT7mPjU6/W5dKuOnqbh2zDaPqkftcBAIwXeEggGe/QSmLbA jlhTHI2tyHBNOvy70wNIscFRNb3PPdgi X-Received: by 10.176.92.71 with SMTP id a7mr25694884uag.155.1497236611294; Sun, 11 Jun 2017 20:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Sun, 11 Jun 2017 20:03:30 -0700 (PDT) In-Reply-To: <44047203.rS5CgVd1do@kitterma-e6430> References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com> <3226783.Zmkt5g0zON@kitterma-e6430> <44047203.rS5CgVd1do@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sun, 11 Jun 2017 20:03:30 -0700 Message-ID: To: Scott Kitterman Cc: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="f403043eee1c5c6a500551ba90c4" Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:03:34 -0000 --f403043eee1c5c6a500551ba90c4 Content-Type: text/plain; charset="UTF-8" I'll reply about the document sequence separately, but on this point: On Sat, Jun 10, 2017 at 1:29 PM, Scott Kitterman wrote: > Personally, I prefer the explicit MUST NOT we had in -01 and I think that's > along the lines of what Martin Thomson was suggesting. A hatless msk > preferred something more like what's there now. > > Technically, I think the amount to the same thing. Is it better to be more > explicit about what's being removed or be implicit by removing it from > what's > specified? Personally, I think explicit is better than implicit, but > being a > Python guy, I would [1] > I think the discussion never fully landed, and it may have gotten mixed in with the discussion about how to regulate key sizes, if it's even possible to do that. Only a few opinions have been expressed, and nobody's commented up or down on the -02 text yet. Remaining hatless, I prefer the current approach because, like key sizes, we're not talking about an interoperability concern but rather a policy one. There's nothing broken about DKIM implementations that use rsa-sha1. It's just a bad idea now although it wasn't yet when RFC4871 came out. Although many receivers may choose to treat all rsa-sha1 signatures as failed on principle, that's not (and, I would argue, shouldn't be) intrinsic in the protocol. My understanding of the use of RFC2119 language is that it's used to describe choices that affect interoperability, while small key sizes and use of SHA1 are choices that clearly reduce security but interoperate just fine. Then Martin suggested that there's precedent in other RFCs for using RFC2119 language to discourage use of obsolete security mechanisms. If that's the case and we're fine with it, then I'll go along with consensus. That aside, simply not describing rsa-sha1 going forward, and including an IANA action to mark it "deprecated" in the registry, seems right to me. If we want to add a paragraph in an appendix paying homage to it and including advice about why its use is no longer a good idea, that's fine too. -MSK --f403043eee1c5c6a500551ba90c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'll reply about the document sequence separately, but= on this point:

On Sat, Jun 10, 2017 at 1:29 PM, Scott Kitterman <sklist@kitterman.com> wrote:
=
= Personally, I prefer the explicit MUST NOT we had in -01 and I think= that's
along the lines of what Martin Thomson was suggesting.=C2=A0 A hatless msk<= br> preferred something more like what's there now.

Technically, I think the amount to the same thing.=C2=A0 Is it better to be= more
explicit about what's being removed or be implicit by removing it from = what's
specified?=C2=A0 Personally, I think explicit is better than implicit, but = being a
Python guy, I would [1]

I think the dis= cussion never fully landed, and it may have gotten mixed in with the discus= sion about how to regulate key sizes, if it's even possible to do that.= =C2=A0 Only a few opinions have been expressed, and nobody's commented = up or down on the -02 text yet.

Remaining hatless, I pref= er the current approach because, like key sizes, we're not talking abou= t an interoperability concern but rather a policy one.=C2=A0 There's no= thing broken about DKIM implementations that use rsa-sha1.=C2=A0 It's j= ust a bad idea now although it wasn't yet when RFC4871 came out.=C2=A0 = Although many receivers may choose to treat all rsa-sha1 signatures as fail= ed on principle, that's not (and, I would argue, shouldn't be) intr= insic in the protocol.

My understanding of the use of RFC= 2119 language is that it's used to describe choices that affect interop= erability, while small key sizes and use of SHA1 are choices that clearly r= educe security but interoperate just fine.=C2=A0 Then Martin suggested that= there's precedent in other RFCs for using RFC2119 language to discoura= ge use of obsolete security mechanisms.=C2=A0 If that's the case and we= 're fine with it, then I'll go along with consensus.

<= div>That aside, simply not describing rsa-sha1 going forward, and including= an IANA action to mark it "deprecated" in the registry, seems ri= ght to me.=C2=A0 If we want to add a paragraph in an appendix paying homage= to it and including advice about why its use is no longer a good idea, tha= t's fine too.

-MSK
--f403043eee1c5c6a500551ba90c4-- From nobody Sun Jun 11 20:25:53 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E68D12741D for ; Sun, 11 Jun 2017 20:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2_RsNJ_5nEaC for ; Sun, 11 Jun 2017 20:25:50 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2DA612700F for ; Sun, 11 Jun 2017 20:25:49 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id q15so51667820uaa.2 for ; Sun, 11 Jun 2017 20:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RwwNK2GqSL+QB3Ss1awyaRBzXqV3BXhnp2wGm5I5r5c=; b=MKTPVtI5B65B+Kq5De3prX8FTDDnpfUCh2UFw8xADEZhv0TFNrQvIV8hJsvFnGUHaa tAmZs46b88MUHkhj5N1huvP0pIJFvz9sbGqXWhE5x7zUDZ2gepZRucHmPgUKQzTyWfBu 4mvdSt12s/Eh5mEEFSKwSoKjcmXWUmSrg+3tesylYNMr1LbT3O+OoaiKZ7Pm2TK4MyIQ 9MFTKXWQyjINNNOSk04Unvf9VVQ7fDN6gx+plKCzfHphdGe3ANAArT4bS96IzRHsFfiW ok+2YqlaDbta6Ei6gMwKcYhXHX2KJwa0Quoq8v6r6T71q4dp+UKRITSM81jVyxJzAqDf EH4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RwwNK2GqSL+QB3Ss1awyaRBzXqV3BXhnp2wGm5I5r5c=; b=OU7qOq0nMalsQwfx4j9VWztpVVumU3Jsp7NW5P0uvfhu0CYOsynSvD0YQO3qmUCDpe Uenuz2u9kakpjBphm0egx9sHFU9jG3IsBh2AyfIdcwu3mlPo1fLYmVWDcVbmL+tiOSfC yWVjmZAAIrVTCyT06ZO8Bo+6Ltbeb0NhH/HpEsbIFl7hHZfPhD3T24ahRJY3sH89NTSV +xpKdiMH9CK/VqFRzhxoJYDkExrGdxukNx1FwcH88FPcTwMGgdbzqgoh5zxP7Iv991Ut vzuDfF+yZtIKjNQg+xQgYmzmFv+a3tJEFcuUG1hhZcWOXQILXHlWtBdz7e7e8qqy83MD 9ZmA== X-Gm-Message-State: AODbwcAbSWLB0qmMMeZDxoMecGmwnkmPCZmlqQC9vmXycErJYs2UMjlB LdCjyVuDVuTjfMzZ0/+fLXwXDXHtGg== X-Received: by 10.176.77.230 with SMTP id b38mr31859505uah.76.1497237948956; Sun, 11 Jun 2017 20:25:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Sun, 11 Jun 2017 20:25:48 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <30567530.MBenZTfLgc@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sun, 11 Jun 2017 20:25:48 -0700 Message-ID: To: Martin Thomson Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403043c34cc1784940551bae0dd" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:25:52 -0000 --f403043c34cc1784940551bae0dd Content-Type: text/plain; charset="UTF-8" On Sun, Jun 11, 2017 at 1:40 AM, Martin Thomson wrote: > https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1 > > I think that I got the essence of your changes there. And it's a lot > shorter. > Can you explain what you mean by "rely on"? Second, you can fit a key larger than 1024 bits in less than 256 > octets. A 1536-bit key isn't that great, but it's a huge amount > better than 1024. I haven't done the math, but I'm sure that you > could find a number that maximizes key length without blowing the 256 > octet limit. This might be good advice to add (which would also mean > that you can keep the paragraph). > Interesting. And there's a bit of a variability since the key record can have other stuff in it (3.6.1 of RFC6376) which reduces the amount of space available for the "p=" value. My possibly ignorant run at the math: - my 1024-bit public key encodes to base64 in 217 characters - there are 255 octets available in a character-string in a TXT record - subtracting 10 from that for "v=DKIM1;p=" which are required, leaves 245 assuming there's no other cruft or spaces in the record - for 217:1024 = 245:x, x=1156 So by that logic, you can put a 1156-bit key in a record now without changing anything. For anything bigger you will need multiple character-strings in the TXT field which I believe is one of the things John says doesn't fly in current provisioning software. -MSK --f403043c34cc1784940551bae0dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 11, 2017 at 1:40 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
<= div class=3D"gmail_extra">
https://github.com/kitterma/draft= -ietf-dcrup-dkim-usage/pull/1

I think that I got the essence of your changes there.=C2=A0 And it's a = lot shorter.

Can you explain what you m= ean by "rely on"?

Sec= ond, you can fit a key larger than 1024 bits in less than 256
octets.=C2=A0 A 1536-bit key isn't that great, but it's a huge amou= nt
better than 1024.=C2=A0 I haven't done the math, but I'm sure that = you
could find a number that maximizes key length without blowing the 256
octet limit.=C2=A0 This might be good advice to add (which would also mean<= br> that you can keep the paragraph).

Inter= esting.=C2=A0 And there's a bit of a variability since the key record c= an have other stuff in it (3.6.1 of RFC6376) which reduces the amount of sp= ace available for the "p=3D" value.

My possibly= ignorant run at the math:
- my 1024-bit public key encodes t= o base64 in 217 characters
- there are 255 octets available i= n a character-string in a TXT record
- subtracting 10 from th= at for "v=3DDKIM1;p=3D" which are required, leaves 245 assuming t= here's no other cruft or spaces in the record
- for 217:1= 024 =3D 245:x, x=3D1156

So by that logic, you can put a 1= 156-bit key in a record now without changing anything.=C2=A0 For anything b= igger you will need multiple character-strings in the TXT field which I bel= ieve is one of the things John says doesn't fly in current provisioning= software.

-MSK
--f403043c34cc1784940551bae0dd-- From nobody Sun Jun 11 20:29:01 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7E1129B81 for ; Sun, 11 Jun 2017 20:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 BUChbt2ViNXO for ; Sun, 11 Jun 2017 20:28:58 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7BE129B7D for ; Sun, 11 Jun 2017 20:28:58 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id h39so51741325uaa.3 for ; Sun, 11 Jun 2017 20:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UXb2o3gVEcoGkmIGY5pvh36Ce3iYLU8M+fd0cVyYdxE=; b=r2TnFFcHrW2DWPrRkM0i/xIes5ocbKq+WF1imaF5ipwNN7ObKfv3iyYIfBIYEZsjWK qS9dlxc2LPkW5a7FWNuRrXQ+1K7HFW2XaMXHJg2uCpI3mHV1TPeOoILogG/YIqla60fh hCMvYUyyCEOP0Bv/wcVBEwLDh0r2j2MZ1ZhALvTuWmz9IQtk3iEl2sF+/E6W/rrt1kwn Sq1Gft7qUl/3ZXR71O8Jlv6ChW6YY/Fr3FhHs1qd7mPWB6zMRzn4mlLniIRrE1nPV5/U 8B4wxM74DLINPAbzedE1xEXoo+pvFTBpPVwi4RkBHZoPClZoP0e9ZwH4rjFaNj4TvYik VbJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UXb2o3gVEcoGkmIGY5pvh36Ce3iYLU8M+fd0cVyYdxE=; b=L+OeloMRYEkJXr6xfN26LdPm0PPEF40YJlgDYjrExy1gmY2FxLIE9IIVAz6/QKP1T1 PaJN/kWGoEE86XogXdETKRavXKbL207bHWm0IB6ysAKjS3JVErPxyLWXIOklySWr0L1r JLly9CnjZEfUeRVVLhgm4JIs983lClLzx8uhZesQK7RZj/ZFvHzM8CSPS/hXjTQft80P aiMT37xsA1JAY5gkrhb3Xc5Ula9MuegQc1+C+0OzzMWL4VUrSIUPZr/KHCKF5dU44gd8 re86PMC2Ko8kORcIz7Tu16vET0QTmlG9WZig/xSdA9sfvgFb4fbViuicOCf+PsTeVbuB KXRQ== X-Gm-Message-State: AODbwcCuW6ptGqdzYUR3Ci+Psz2SZrRaFQnsQHgZ+epMBV+erEk6lIZg n8+ccrZrtLbgU9Hb8TJDlLAQiFgPz7xE X-Received: by 10.176.0.248 with SMTP id 111mr24349547uaj.133.1497238137453; Sun, 11 Jun 2017 20:28:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Sun, 11 Jun 2017 20:28:56 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 11 Jun 2017 20:28:56 -0700 Message-ID: To: Martin Thomson Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113ac2d453bf730551baeb48" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:29:00 -0000 --001a113ac2d453bf730551baeb48 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson wrote: > I find the construction of this draft strange. Why not simply say > "verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"? > The remainder of the text is largely unchanged, which took me a while > to validate. > > The problem here is that removing the definition of rsa-sha1 is not > the point. The code point can't be undefined (Section 7 gets that > right), and we don't really benefit from having the definition > removed. What we want is to have rsa-sha256 implemented and deployed. > > So say two things, just to be perfectly clear: > > 1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted. > > 2. DKIM implementations MUST use rsa-sha256. Signers MUST create > signatures using rsa-sha256 and verifiers MUST verify those > signatures. > That idea is fine with me. Specifically, I think "MUST NOT rely on" is better than "MUST NOT implement". -MSK --001a113ac2d453bf730551baeb48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I find the cons= truction of this draft strange.=C2=A0 Why not simply say
"verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"= ?
The remainder of the text is largely unchanged, which took me a while
to validate.

The problem here is that removing the definition of rsa-sha1 is not
the point.=C2=A0 The code point can't be undefined (Section 7 gets that=
right), and we don't really benefit from having the definition
removed.=C2=A0 What we want is to have rsa-sha256 implemented and deployed.=

So say two things, just to be perfectly clear:

1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted.

2. DKIM implementations MUST use rsa-sha256.=C2=A0 Signers MUST create
signatures using rsa-sha256 and verifiers MUST verify those
signatures.

That idea is fine with me.= =C2=A0 Specifically, I think "MUST NOT rely on" is better than &q= uot;MUST NOT implement".

-MSK
<= /div> --001a113ac2d453bf730551baeb48-- From nobody Sun Jun 11 20:37:27 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6139F129B89 for ; Sun, 11 Jun 2017 20:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 K4FuE5ra4BBf for ; Sun, 11 Jun 2017 20:37:24 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8125F127867 for ; Sun, 11 Jun 2017 20:37:24 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id p62so43719566vkp.0 for ; Sun, 11 Jun 2017 20:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZC54AhRgcyfXGwb8/X2cNL2S9DJ7S6Q7l5Dt7DFwrXk=; b=bjDar7OYij2kpN433JsbALnPZltrncvJoyovqtJVoxhA7t2kHWeooR7mUKBKh2fKRs AOxcr74LkNoPFzVq10KOYJpB4ukG61UZUpXUf4KQpuH8Xi2gPbTUfmu7Jbmdl+LM475w rE6U78whU4avzmrgWbxAPN88n350zomWItNvFEjwVVg5xk4yI4bnX7yEwAKBpcUNNysF zqitrStbO6a2VMq+y0sshPGVHPuf/+vRy+dm0L+iqLGZNp5AiQK2iVziqrm5NMZpDtLX JhOJ0Pg07dGJ590a51pc9Q6x32W80mgPL3K0yEp1Z+5qh0NDTkm5tM3IVfqwx/15/3vV 9F8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZC54AhRgcyfXGwb8/X2cNL2S9DJ7S6Q7l5Dt7DFwrXk=; b=tj8sQn3vYdQTAmqiRyKPa7hHFZvXWFHkrfe0U3qDayqomc1CCNnlU5op4cgEbMbp9C r9yrJt/I8vzTeTQG5dkxoc6rKt+BXSV4toA9AedYz++gCptDB6M0U56nYUMfeKu0XhgQ 5jOboBPcFolKGJxXWrT7o6xu97xGVbC83tWdMAXDzur+zp7cpOrIE2nO5vkOgGwEFnmB IOIqaAAXKhyga4FoWODXwubC/Q1N0kUtbwj2N+A5765ThLqtmdq5o0k5x4vex/c1CZE2 R65YrqzLqSXqt2EKu0s1XxiD5SlTeGtmxEsz+dKY71kA6pvdmvcJURk/P9hPMlExG4NU vTrw== X-Gm-Message-State: AODbwcCZ0v/9MJVy6LGGWIhLLzpYbGL4HwfL9kof9gEFRpjfTF3ohxLe 2araxGQIvIzQWSNF5OGGuJD8HIL0PSLN X-Received: by 10.31.65.197 with SMTP id o188mr26773022vka.7.1497238643657; Sun, 11 Jun 2017 20:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Sun, 11 Jun 2017 20:37:23 -0700 (PDT) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Sun, 11 Jun 2017 20:37:23 -0700 Message-ID: To: Kurt Andersen Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dde627fd1840551bb0926" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 03:37:26 -0000 --001a114dde627fd1840551bb0926 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 11, 2017 at 11:17 AM, Kurt Andersen wrote: > On June 9, 2017 8:25:38 PM EDT, John Levine wrote: > >> . . .it seems kind of premature to me. >> >> Why would that matter? This draft just gets rid of the obsolete cruft. >> It clears the deck for adding a new algorithm, but in no way requires we >> have that sorted out. >> > > While RFCs do have a cost, can the ADs weigh in on the relative benefits > of doing this "sweep the decks clean" first update to be followed by "add > more algorithms" vs. bundling it all together? > Regardless of the answer to that, I don't think we should be in some sort of hurry here. >From where I'm sitting, ARC has other questions it needs to work out before this will be a pressing issue for them, and for the most part they just say "do what DKIM does" in terms of key management anyway, so when we change DKIM, ARC will just follow. -MSK --001a114dde627fd1840551bb0926 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 11, 2017 at 11:17 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:
On June 9, 2017 8:25:38 PM EDT, John Levine <johnl@taugh.com> wrote:=
. . .it seems kind of premature to me.

Why would that matter?=C2=A0 This draft just gets r= id of the obsolete cruft.=C2=A0 It clears the deck for adding a new algorit= hm, but in no way requires we have that sorted out.
=

While RFCs do have a cost, can the ADs weigh in on the = relative benefits of doing this "sweep the decks clean" first upd= ate to be followed by "add more algorithms" vs. bundling it all t= ogether?

Regardless= of the answer to that, I don't think we should be in some sort of hurr= y here.

From where I'm sitting, ARC has other questions it needs= to work out before this will be a pressing issue for them, and for the mos= t part they just say "do what DKIM does" in terms of key manageme= nt anyway, so when we change DKIM, ARC will just follow.

= -MSK
--001a114dde627fd1840551bb0926-- From nobody Sun Jun 11 21:38:35 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B95129BB2 for ; Sun, 11 Jun 2017 21:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 8taA6rBzMO8s for ; Sun, 11 Jun 2017 21:38:32 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD54129BAE for ; Sun, 11 Jun 2017 21:38:32 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DC229C40236 for ; Sun, 11 Jun 2017 23:38:28 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497242309; bh=/eqkKGTWOQwwFK36Pr1hdVEzqBHh/MnKyRJ58BOyZXU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LpX4+BeEY1RmNP++ljuZoBouF1pxGZmYWttkmzJVu/dE+9icb0EOZwZnYgCLStiRr z50mAeKL4bowvCVqmQi20W+rbdiO+3Bj+XewyOTvJR0q6x5SNr8l630P2iBVQ0C4Tn HAEPubBJIuVNYuVaY4iPch69Po0zlKHluK1qACz4= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 12 Jun 2017 00:38:28 -0400 Message-ID: <2034638.szbv6KSWyz@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 04:38:34 -0000 On Sunday, June 11, 2017 08:37:23 PM Murray S. Kucherawy wrote: > On Sun, Jun 11, 2017 at 11:17 AM, Kurt Andersen wrote: > > On June 9, 2017 8:25:38 PM EDT, John Levine wrote: > >> . . .it seems kind of premature to me. > >> > >> Why would that matter? This draft just gets rid of the obsolete cruft. > >> It clears the deck for adding a new algorithm, but in no way requires we > >> have that sorted out. > > > > While RFCs do have a cost, can the ADs weigh in on the relative benefits > > of doing this "sweep the decks clean" first update to be followed by "add > > more algorithms" vs. bundling it all together? > > Regardless of the answer to that, I don't think we should be in some sort > of hurry here. > > From where I'm sitting, ARC has other questions it needs to work out before > this will be a pressing issue for them, and for the most part they just say > "do what DKIM does" in terms of key management anyway, so when we change > DKIM, ARC will just follow. The IETF is five years late with action on this front. At least. Whatever is happening in this working group, hurrying isn't on the list. I have no idea what should be in this draft or if it should even exist anymore. I also really don't understand why we have a discussion about if a draft should be adopted before a WG adopts it if we just get to re-have the same discussion periodically. Scott K From nobody Mon Jun 12 00:20:24 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D63129C3B for ; Mon, 12 Jun 2017 00:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bSGn5nM3-3WT for ; Mon, 12 Jun 2017 00:20:21 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0418129C36 for ; Mon, 12 Jun 2017 00:20:20 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id p189so47329779lfe.2 for ; Mon, 12 Jun 2017 00:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8Noyq1mAyPwL0uV7kvAz8mGeD29MYGZn4cNQA0eS6k=; b=H1OfE6DX6BFbxoFFeXdm0t0iyYLnSH3cNVGMuB9joINnwFpigXgEoIXo6Ku2AyVytb clUSic3/GG4kgIALrF7PzFXxzs3XKLPIzd3EnvPd/d2sW2k7PuXDjjXjgu0xna8MHXXG qfillhgcdh8C3gl+PB/X+O+bqka2p1vnYivpIQUjf70MXupiVmj5V+ujhNyuoRQMKWTh agtlld9aO2B8rhxOQ8bEYHNIr8Xnk2SzDBDU+CbvOeVYV9OO3O5/tydBDv2I9qNA/GvZ O+skckjZnoF5oZEVpzGZCP/vLrXt3wGCx53fCZ8Z2e7C0tGnuPJlKpimlK/tLIo3IO4z Zwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8Noyq1mAyPwL0uV7kvAz8mGeD29MYGZn4cNQA0eS6k=; b=lXg9N0BsKR31P+6nlewBqasCZd+BI0ND3XAOYb1zjX5nhQvL8YwZL3JvbzF4LJXRjU J0bmCsW6hd5ERDq921EiivmvV2lrg/imEHyHgsUMi6+DiV1q0e+l+0mo9t6OJzADx7tH 2yTZgzMpZuiX9fokiQh+yKslS6r4rKf2OA/EO08oOBN4TE70RrixhDOCBvi4etypJMJi /ihGG7ZRuULXvAWzjPFn5iGzoEKBD80iOdfJqFmoE1xCPNDX4dZNgZr7C6/Yln4ELKms RJBtCGtRYt4gdbg5/gWalkaafEYXSDqBkz28jmuJnVXw1L+VBI+VN43hpiI7h8oHEtLl PxZw== X-Gm-Message-State: AODbwcACOLg2ULjy6SRvYQTv2V//4z59bL4OqHgK0YDsDyzZvIGFNCQV GdzkL/ZmNl0bLO/K3CPZMrkIFzch1g== X-Received: by 10.25.166.15 with SMTP id p15mr7331995lfe.43.1497252018913; Mon, 12 Jun 2017 00:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Mon, 12 Jun 2017 00:20:18 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <30567530.MBenZTfLgc@kitterma-e6430> From: Martin Thomson Date: Mon, 12 Jun 2017 08:20:18 +0100 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 07:20:23 -0000 On 12 June 2017 at 04:25, Murray S. Kucherawy wrote: > On Sun, Jun 11, 2017 at 1:40 AM, Martin Thomson > wrote: >> >> https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1 >> >> I think that I got the essence of your changes there. And it's a lot >> shorter. > > > Can you explain what you mean by "rely on"? Sure, that's probably a bit of an imprecise way of saying that a verifier needs to insist on receiving a valid rsa-sha256 signature and that it can't just fall back to rsa-sha1. > So by that logic, you can put a 1156-bit key in a record now without > changing anything. For anything bigger you will need multiple > character-strings in the TXT field which I believe is one of the things John > says doesn't fly in current provisioning software. 1156 is better, but I was hoping for a bit higher than that. I would include text that suggests this (explaining the limitations you set out regarding the whitespace and so forth), but note that the additional security margin is, well, marginal. From nobody Mon Jun 12 00:23:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F75129C36 for ; Mon, 12 Jun 2017 00:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2e7L5IQ9N8NX for ; Mon, 12 Jun 2017 00:23:18 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85261243FE for ; Mon, 12 Jun 2017 00:23:17 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id p62so44893117vkp.0 for ; Mon, 12 Jun 2017 00:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DjDF2QK0YdVq52ZojKCgV1jfw8tK5EZx0t7esWmj4M0=; b=ZayjnNhqQwmD7EdI46UnleZX7b+GtvqczkBq3PmdAwXvszr55OgTLC2VPTjkfnwdwb PtbcFYEnrtS0UW2KZ/Ylc/uk3Ln8HKgJIBPlwMxcGf+vAbT7U8UGf0rLLREJa9l186q8 0jSZEKqD+9QtZPGDwDVqqUZ5Z6hEZVijp66JOBIQjM6AYE5lZUpfn7l0hhSfdAZWisvX waqbUHdLriBGQLdOncvQE3Jx4iOK4AxXi8ZsD2JhZbs3uowKcGE/lNVvGTQDfinTXvBO yffRu6wjs4QUOXZs3F7hVk+rmVUgwHGWKSAEL9X5BgMIDVnOluEhCtLRZFQy00JU/YQN a+5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DjDF2QK0YdVq52ZojKCgV1jfw8tK5EZx0t7esWmj4M0=; b=QdjCDs30RUFpVI4CPW5kITj/LT7FIbPB56bHrEcPH74zYqKvS56aPG8ew/MYnidRzP Tp6T5oCfbeDDseaApf7S62DAJVvWm088+izSTKRr1xQnSMk5cgEHB0jYJDJPdgy7DDBw v5MViiGHnE7wpH5XFcuCsl2gS08YNKXq6LgLbV73JFSksR1gvW9XW8oupaSTTHrusoYn NWWMDc5tU99URdvis8VKsEft4fhew3f74STq5bDLO6uPgexmVuYxgAkHUzDOmd+LyIlP fGATBHISJ93A+hbRemT0XTDXE1MSzvejcJUCfGh6XGc+CVvSHxj3BnXJssOHmioqbpyr 5gyA== X-Gm-Message-State: AODbwcBMDm+I0QHDCdyrP5vmKMUFF96Hl4TiG9qU1fl3w76jD2w6boTM 4GNuMWx2qd6iBH35aQk1Bi4HEPhysjId X-Received: by 10.31.96.150 with SMTP id u144mr19092338vkb.124.1497252196941; Mon, 12 Jun 2017 00:23:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Mon, 12 Jun 2017 00:23:16 -0700 (PDT) In-Reply-To: <2034638.szbv6KSWyz@kitterma-e6430> References: <20170610002538.10992.qmail@ary.lan> <2034638.szbv6KSWyz@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 12 Jun 2017 00:23:16 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114e24a256ac5d0551be311f" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 07:23:19 -0000 --001a114e24a256ac5d0551be311f Content-Type: text/plain; charset="UTF-8" On Sun, Jun 11, 2017 at 9:38 PM, Scott Kitterman wrote: > The IETF is five years late with action on this front. At least. > Whatever is > happening in this working group, hurrying isn't on the list. > Then I don't understand why this thread seems to be so tense with frustration. I have no idea what should be in this draft or if it should even exist > anymore. > I really don't think the proposed changes are all that major here. > I also really don't understand why we have a discussion about if a draft > should be adopted before a WG adopts it if we just get to re-have the same > discussion periodically. > You think working groups should not be allowed to revisit their choices? -MSK --001a114e24a256ac5d0551be311f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 11, 2017 at 9:38 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
The IETF is five years = late with action on this front.=C2=A0 At least.=C2=A0 Whatever is
happening in this working group, hurrying isn't on the list.

Then I don't understand why this thread seems= to be so tense with frustration.

I have no idea what should be in this draft or if it should even exist
anymore.

I really don't think the p= roposed changes are all that major here.
=C2=A0
I also really don't understand why we have a discussion about if a draf= t
should be adopted before a WG adopts it if we just get to re-have the same<= br> discussion periodically.

You think work= ing groups should not be allowed to revisit their choices?
-MSK
--001a114e24a256ac5d0551be311f-- From nobody Mon Jun 12 02:14:47 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0439E12AF6E for ; Mon, 12 Jun 2017 02:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 D037kkRM7XGw for ; Mon, 12 Jun 2017 02:14:43 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FFB1294E0 for ; Mon, 12 Jun 2017 02:14:43 -0700 (PDT) Received: (qmail 57613 invoked from network); 12 Jun 2017 09:14:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Jun 2017 09:14:41 -0000 Date: 11 Jun 2017 23:08:02 -0000 Message-ID: <20170611230802.17551.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: superuser@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] sequence of drafts, draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:14:45 -0000 In article you write: >That aside, simply not describing rsa-sha1 going forward, and including an >IANA action to mark it "deprecated" in the registry, seems right to me. If >we want to add a paragraph in an appendix paying homage to it and including >advice about why its use is no longer a good idea, that's fine too. That's what I'd suggest. The spec should say what to do if you want to interoperate. It needn't call out things not to do in the spec -- there's an unlimited number of them. If you want to put an appendix explaining why the current things to do have changed, that's OK but not urgent. R's, John From nobody Mon Jun 12 02:20:23 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178D21294C8 for ; Mon, 12 Jun 2017 02:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 F6c7mFJjg63S for ; Mon, 12 Jun 2017 02:20:21 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01A312708C for ; Mon, 12 Jun 2017 02:20:20 -0700 (PDT) Received: (qmail 58383 invoked from network); 12 Jun 2017 09:20:19 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Jun 2017 09:20:19 -0000 Date: 11 Jun 2017 23:13:40 -0000 Message-ID: <20170611231340.17586.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: martin.thomson@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:20:22 -0000 In article you write: >1156 is better, but I was hoping for a bit higher than that. I would >include text that suggests this (explaining the limitations you set >out regarding the whitespace and so forth), but note that the >additional security margin is, well, marginal. Of course it is. My draft has two approaches to stronger crypto in 256 bytes of TXT. One is key hashes with the key in the signature, the other is elliptic crypto. At this point it seems likely that we'll do the elliptic crypto so I'm inclined to skip the key hashes. R's, John From nobody Mon Jun 12 02:26:58 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77DB1294DB for ; Mon, 12 Jun 2017 02:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XR_SO-I7HRGl for ; Mon, 12 Jun 2017 02:26:56 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2AE1294BD for ; Mon, 12 Jun 2017 02:26:56 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id m77so23789207lfe.0 for ; Mon, 12 Jun 2017 02:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wUCwbUbLX66V7QG4sbHbAGJ+DtdCJ02khJSs74/0RaM=; b=WDAVEymb3TRb1zsyIqOkPY1IiShePVPUUt2//iGEBiogQTTfYrrvQwlJV27s1IGDsd OoqMYqPY+5Lon/dPDdE3tbvGN30pPkrhpe6vM8tGMqSckAw+QwIkGAySp+R9y2EzzcIO yj6b031RXbGsn5/DuQzfSDa7ZRc0eIvqjln3Ocp96vAxgyTEyorThLtbjHm14IduLZY8 oFTVJOeD7xJBj/SDIcWJqdPtwd47NjGMIHt5K31GyyW3PGaS4TmP3Rq6AubsSaipN9w5 idROStux4wn5bnP23ssI2OzKNCIWsCpMrFiERnAFeI9Z5ODy6Zo1xVq6VsmctNc+KrZR v7lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wUCwbUbLX66V7QG4sbHbAGJ+DtdCJ02khJSs74/0RaM=; b=mNEW6x+WE0QrNLeFvW3zJ0rclTVuIjnNDqSAi67twXcAmXnuVptCsnoj+g++ZAQwG+ FwHEY6HWl8vl0sMPQ4ST++/VsdRU7GqO8mHRgODvD405z1MUj4Kz6LzRzvlNqVQcHNGO /Bng+c6xPGJJaAWA9PJfcaf1/wdr/RzRPUL3OF8z2alT09l8jbCRapIppx5tlATt5Obi 4he06T+Wrj+I13hbZIW4pDsO2lg0B0EKdZptu4yARys2hm9NwW85gpdViEfuJaeQ57pg oWWDA4tYF+eU2CYBniYhQ/30ZnHKTtcdi1lY7jrR/9x6MICfAyelVjRVDV37kiERPSJM 4qRA== X-Gm-Message-State: AKS2vOworOwfKjxCl0Srkf804gbn6HWS0CBesTJej+tS+b5bo61I+dKu tj/Fhgi3Bos67SHrkUI4W+aPwcXxd2xu X-Received: by 10.25.87.6 with SMTP id l6mr1193524lfb.76.1497259614278; Mon, 12 Jun 2017 02:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Mon, 12 Jun 2017 02:26:53 -0700 (PDT) In-Reply-To: <20170611231340.17586.qmail@ary.lan> References: <20170611231340.17586.qmail@ary.lan> From: Martin Thomson Date: Mon, 12 Jun 2017 10:26:53 +0100 Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:26:58 -0000 On 12 June 2017 at 00:13, John Levine wrote: >>1156 is better, but I was hoping for a bit higher than that. I would >>include text that suggests this (explaining the limitations you set >>out regarding the whitespace and so forth), but note that the >>additional security margin is, well, marginal. > > Of course it is. My draft has two approaches to stronger crypto in > 256 bytes of TXT. One is key hashes with the key in the signature, > the other is elliptic crypto. > > At this point it seems likely that we'll do the elliptic crypto so I'm > inclined to skip the key hashes. This is an odd angle to take here. Key hashes would remove the limit entirely. I appreciate that you think that 1024-1156 is of marginal benefit, but the benefit of key hashes is that you can use the existing, certified, and tested primitives AND keys that you have already. It's a much smaller increment. That makes me inclined to think that hashed-RSA has some value. From nobody Mon Jun 12 02:30:46 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD681294D4 for ; Mon, 12 Jun 2017 02:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 bah96PS0buFF for ; Mon, 12 Jun 2017 02:30:42 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1411E1294BD for ; Mon, 12 Jun 2017 02:30:42 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id 63so33995947ywr.0 for ; Mon, 12 Jun 2017 02:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VPg6j2WAnWB+YsepBWl8u5HzAjZnPT9FtprRE9/h67I=; b=rGQ3jN08EHOzM/1pSEBi8D6PRnCw3f7FVWiyWGfm8YWREQF+CjF/sKR/9ycrrPCJ04 7oLXtnId+EugDRiU09yp9zAWRkyL7gV36WmzL3MmsFqZdk5ZoDfNMjku1kQelyWO4yJG x3xKm5Qq36psCz9NBjnzlKD8mChYjkhFsvxwE5wO6aIXTiYStBsaOxz6A9J74IDABJ21 +c/Ltk2NZ2SVG0PqmNMfKpu1YdDtp/66Bih4O3eqZR1qBgY3Wx4/xu6uWhtca3GtSrlU D7nPwUx4T1ZHZTLtrYl4vJC/48zAODjvvrqqnzIvNvAHr31VFAZYFWdDQ7Szh9KVNxnR t1yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VPg6j2WAnWB+YsepBWl8u5HzAjZnPT9FtprRE9/h67I=; b=KMr2AEymf6UtrA5ACfIT6QAHgilQZICAmp5kWYBIYjNT2cHGuvZh0SqH9dWl8i5BxW mU7kvDFrHQm5vAKz/mCpyP0LZjfrSeHIcrZ9m5dg61KD73S+YRvQgszBWwhCj57NajJk c1ZCBCBhe2ZQE+yZ5ErVPKoDD/x/0s9dwDLWQJ4ZqscP4Kx3YyyW+NnJkAI/6NsdbNwr 6/SD7dPWFxkHJgjkv6kyg+nz5+xqUkhhiDXhm0biv0txCFdWH2MnPRjtSZQ3p60S/ShT w7e1+3ciY2EEwYiAmBssuzpE34+ZM4Mj6s0WZgZ1Zl0gUawYnfg5VZqI5KbdjmTiEUln 9g8g== X-Gm-Message-State: AODbwcD17o+qKU2Cch8TuPekzn/HABGbWrlBbTcAwQT/SSgH1CLooiq9 BQIvnMhXtvseRQlJm0jjOZe3fx2fw/4y X-Received: by 10.129.109.4 with SMTP id i4mr25017276ywc.3.1497259841203; Mon, 12 Jun 2017 02:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 12 Jun 2017 02:30:00 -0700 (PDT) In-Reply-To: References: <20170611231340.17586.qmail@ary.lan> From: Eric Rescorla Date: Mon, 12 Jun 2017 10:30:00 +0100 Message-ID: To: Martin Thomson Cc: John Levine , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dd184f8c5660551bff8c2" Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:30:45 -0000 --001a114dd184f8c5660551bff8c2 Content-Type: text/plain; charset="UTF-8" Yes, I think we should do hashed-, for obvious reasons. -Ekr On Mon, Jun 12, 2017 at 10:26 AM, Martin Thomson wrote: > On 12 June 2017 at 00:13, John Levine wrote: > >>1156 is better, but I was hoping for a bit higher than that. I would > >>include text that suggests this (explaining the limitations you set > >>out regarding the whitespace and so forth), but note that the > >>additional security margin is, well, marginal. > > > > Of course it is. My draft has two approaches to stronger crypto in > > 256 bytes of TXT. One is key hashes with the key in the signature, > > the other is elliptic crypto. > > > > At this point it seems likely that we'll do the elliptic crypto so I'm > > inclined to skip the key hashes. > > This is an odd angle to take here. > > Key hashes would remove the limit entirely. I appreciate that you > think that 1024-1156 is of marginal benefit, but the benefit of key > hashes is that you can use the existing, certified, and tested > primitives AND keys that you have already. It's a much smaller > increment. That makes me inclined to think that hashed-RSA has some > value. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114dd184f8c5660551bff8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I think we should do hashed-<everything>, for o= bvious reasons.

-Ekr


On Mon, Jun 12, 2017 at 10= :26 AM, Martin Thomson <martin.thomson@gmail.com> wro= te:
On 12 June 2017 at 0= 0:13, John Levine <johnl@taugh.com> wrote:
>>1156 is better, but I was hoping for a bit higher than that.=C2=A0 = I would
>>include text that suggests this (explaining the limitations you set=
>>out regarding the whitespace and so forth), but note that the
>>additional security margin is, well, marginal.
>
> Of course it is.=C2=A0 My draft has two approaches to stronger crypto = in
> 256 bytes of TXT.=C2=A0 One is key hashes with the key in the signatur= e,
> the other is elliptic crypto.
>
> At this point it seems likely that we'll do the elliptic crypto so= I'm
> inclined to skip the key hashes.

This is an odd angle to take here.

Key hashes would remove the limit entirely.=C2=A0 I appreciate that you
think that 1024-1156 is of marginal benefit, but the benefit of key
hashes is that you can use the existing, certified, and tested
primitives AND keys that you have already.=C2=A0 It's a much smaller increment.=C2=A0 That makes me inclined to think that hashed-RSA has some value.

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a114dd184f8c5660551bff8c2-- From nobody Mon Jun 12 02:45:08 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C4412E042 for ; Mon, 12 Jun 2017 02:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=cCvA5h4Z; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=ayHkDT+B 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 9xto0drZKkQF for ; Mon, 12 Jun 2017 02:45:04 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB6F1294D8 for ; Mon, 12 Jun 2017 02:45:04 -0700 (PDT) Received: (qmail 60834 invoked from network); 12 Jun 2017 09:45:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=eda0.593e629f.k1705; bh=V+AbKZRNSHUaI9X4Mycc1J2/hYDH3jpXs69H7mHTzzs=; b=cCvA5h4ZDZjecMnRSiK/vW4MkuYFJM4S8XVGiAgm2CrsFaY9OZNWC856gkcF410ixfsCl9D+1tX+tLx0vG654AOdlt6rFv4SIMkxdzI9yqxxzXmVjDeYzmv3jKYmpuKRx5TrWho3LIxLDB4fnMXngeWFeGtdeTjZYKfdEBdo6mPsmZL4cXgde39QDRHvyHNfSEUeN9VRRJ+I6z/u04Ie3gA1j3OqiTbAqG/3LfmpxxkfNF9L1CYN+LRol+2TWuBr DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=eda0.593e629f.k1705; bh=V+AbKZRNSHUaI9X4Mycc1J2/hYDH3jpXs69H7mHTzzs=; b=ayHkDT+BncW2kPaSrF8tTX+YCoomwse1bhe/XYGyRiB7GEvLvN+BBg76WZuo0z7kRfBOgRzwoPvEUMSgXKqjO4s271QCey2JYcj85XAm7x47/3QMtdkzFdPuWJheCw7+jWYTlUjt1XIQE14hH3mLFfV1ROozd2GyPvQMZfLin25RO8VSv7Cnze7v1+GKFbuWCvx0adwMcTFKe7CShdNS3vptUVsWZsyFFH5VKJAHquaSqnDcbQXfjxd4HoZqY9DD Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 12 Jun 2017 09:45:03 -0000 Date: 12 Jun 2017 10:45:02 +0100 Message-ID: From: "John R Levine" To: "Martin Thomson" Cc: dcrup@ietf.org In-Reply-To: References: <20170611231340.17586.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:45:06 -0000 >> At this point it seems likely that we'll do the elliptic crypto so I'm >> inclined to skip the key hashes. > > This is an odd angle to take here. > > Key hashes would remove the limit entirely. I appreciate that you > think that 1024-1156 is of marginal benefit, but the benefit of key > hashes is that you can use the existing, certified, and tested > primitives AND keys that you have already. It's a much smaller > increment. That makes me inclined to think that hashed-RSA has some > value. If the RFC 8032 algorithm isn't existing, certified, and tested, we've got problems beyond DCRUP. Hashes in principle are simple, but they got taken out in 2006 because of complaints about bulking up the signature with the key, and we can bikeshed forever on which hash to use and how to represent it. If people are going to make one change to update their DKIM signers and verifiers, I'd rather they add a protocol switch to add better crypto. Also remember that 2K RSA signatures work fine in DKIM. The problem is cruddy DNS provisioning software that won't publish multi-string TXT records. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jun 12 02:49:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF391294D8 for ; Mon, 12 Jun 2017 02:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 d9ZWuACfXwxg for ; Mon, 12 Jun 2017 02:49:40 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650F01204DA for ; Mon, 12 Jun 2017 02:49:40 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id m77so24000260lfe.0 for ; Mon, 12 Jun 2017 02:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kcn9f+3e2XLvPSVDV8II4Mogzm99Y/ypE8ONBg/ojpY=; b=ZvlqxVQE+9jLBjJz3Y3fP7C0LpbQ0hN2meccwRZNn+TXMHrCnm9aZc87rMU29oSYJd i3DiAqZszMsLfkc7ENehfQ0ayr/PRxcC0z8fEixNoZha6n3PSgGSt8WUh6nEtgILtUYo 1JK2cCciTm4ll/uZkIebulYwKC51WyNlyeXaMsh/K7drsQC1jjDSjzZ3Z4eGQviPXezE mgydkk6qXEdwlR5EkmG55PWXih/kxJSoqEezrIGIN+HflZPsvsOHPduE4kyL3vnsrAs2 hyRz9xxUbQ3JSETZv7ZA+3r4Lkgv2x8WQlUNxm0q4wVClNzLexnG+YEGH6NrckoEAfCf tG1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kcn9f+3e2XLvPSVDV8II4Mogzm99Y/ypE8ONBg/ojpY=; b=L1AKjJfMXiZRaJ5SLLCxA0bju4q4PQ16EA1TriiRT9YexasQYEO6WWVKmUTZSqtGF0 1GvE4cWoPogRqdM4+z3YJvP45rmoYRtBV911Z6opq6NkWzCe+shQnDurbRI7qOf0K527 CodJ4T/3Ob68pcnoEhzkaWC1CjtAJYlQS6LGXCTEQi45e62cOShufC+alFZ4XMwW8K/K 27trI3ixiniGg7jXkzWJBq5uXHPsR053RPMDvpZXm6lFyX7Ss9lekjQCHEWpYkoCC2uZ Ou2TYBkJ8ck2ULA2ka3V5WooQs5Pgjxf9JsL1gtXxQjJlf9T8jSzIB8LQWjCzk3zsCYS MUqw== X-Gm-Message-State: AODbwcCGDw/Ke8U8igeBDaBIjsvTCLWQ/sJPyHOD/NNkqg+n+8XTIlPX 6ocRZSg57p9Aojyw184jFfBba1YcaQ== X-Received: by 10.46.84.28 with SMTP id i28mr9052675ljb.44.1497260978694; Mon, 12 Jun 2017 02:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Mon, 12 Jun 2017 02:49:38 -0700 (PDT) In-Reply-To: References: <20170611231340.17586.qmail@ary.lan> From: Martin Thomson Date: Mon, 12 Jun 2017 10:49:38 +0100 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:49:42 -0000 On 12 June 2017 at 10:45, John R Levine wrote: > If the RFC 8032 algorithm isn't existing, certified, and tested, we've got > problems beyond DCRUP. That wasn't my point. It was that deploying something based on RSA is potentially more attractive. That's a trend I've witnessed. Cautious management/developers/operations will avoid the new thing for a range of reasons. From nobody Mon Jun 12 02:50:09 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7784812E043 for ; Mon, 12 Jun 2017 02:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 Wwnv1NYBuwlv for ; Mon, 12 Jun 2017 02:50:06 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659931204DA for ; Mon, 12 Jun 2017 02:50:06 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id l75so34056753ywc.3 for ; Mon, 12 Jun 2017 02:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Ce/uPotIVtDo5q3dqcXI6iORgk2vhHs1QVvURxnm/4=; b=ZNqky3QtuB5I3KyXDd4CLyoS9GOOU4SDYgEPPN3gNjU4KW2ytsNSCDeJWaaNbyYjkj 4OhAZRa/sGSBu/XLPDBqPGfvz7F99MTM2tYpZxVs46mv1l7WSjujti6fspvNWA2y0yWw 11J0yTkuaIPu4rYi+iyMXY+LkiEay16id6c1/QdMt29VMcTYkcrDju0a+sNxMx6FJVob uKHrHnnKBkEPbM5e90QuA/muB/SJ9oJ5RxExABnA3scxnHpeI5Ld0vebW9Y5vydJAH/q lKY8nv5xMN7YQaACzypYCgRrzJZBZM8oFLsJl2Kp/D20ORqhKDXVJHoDRPWlAhPhtqnM o/tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Ce/uPotIVtDo5q3dqcXI6iORgk2vhHs1QVvURxnm/4=; b=eUQicC0EiA2zakxC/GtTNGvvrluSNw27J/avwIzFMl+k2gMRoKSG6Gzo8zkGHRYGkL pFLQPBdLBoPPiDwL/K4wIzoWO10Alv7JO/rldsQNtTGdDBiIoqRUnFTWI9yNmZk2m3m0 k5j19wLh1c7Cr9P4e2IofYWM+NsA8nIk5v9DhRcvTh6stBnuzwXjnZxEoMkB3Xmf4zBT /dc75rdgpAHzvhpLeBnpcFVpVzVGQvLDLARzqlIgin1O7RJ17opYr8ainw1c/y/6QFJK k4ZVAnbSCqt0Ad5YB3wEyfjjyr5KPrCkakirLP9bjlHLJnqVt1K8qyUN5LKmK0b2a63h E54A== X-Gm-Message-State: AODbwcCGmwYa3gnmK2+kR6AeEF/RTKqwjLgYN8JtyGsG8ec5Jv0RrC39 OmMdio0Jbu3WJMuDi1xfaSh8rUFU87KQ X-Received: by 10.129.109.4 with SMTP id i4mr25059788ywc.3.1497261005621; Mon, 12 Jun 2017 02:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 12 Jun 2017 02:49:25 -0700 (PDT) In-Reply-To: References: <20170611231340.17586.qmail@ary.lan> From: Eric Rescorla Date: Mon, 12 Jun 2017 10:49:25 +0100 Message-ID: To: John R Levine Cc: Martin Thomson , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dd184605d890551c03e98" Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 09:50:09 -0000 --001a114dd184605d890551c03e98 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 10:45 AM, John R Levine wrote: > At this point it seems likely that we'll do the elliptic crypto so I'm >>> inclined to skip the key hashes. >>> >> >> This is an odd angle to take here. >> >> Key hashes would remove the limit entirely. I appreciate that you >> think that 1024-1156 is of marginal benefit, but the benefit of key >> hashes is that you can use the existing, certified, and tested >> primitives AND keys that you have already. It's a much smaller >> increment. That makes me inclined to think that hashed-RSA has some >> value. >> > > If the RFC 8032 algorithm isn't existing, certified, and tested, we've got > problems beyond DCRUP. Hashes in principle are simple, but they got taken > out in 2006 because of complaints about bulking up the signature with the > key, and we can bikeshed forever on which hash to use and how to represent > it. You can bikeshed on anything, but I don't see how this is actually a particular problem, given that you can pin the hash to the signature algorithm, as we do with elliptic curves. TBH, I'm not sure why we're debating this point, given that hashes are actually in the charter: "DCRUP will consider three types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, changes to key strength advice and requirements, and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records." If people are going to make one change to update their DKIM signers and > verifiers, I'd rather they add a protocol switch to add better crypto. > Yeah, the issue here is that hashes set us up for the future. -Ekr > > --001a114dd184605d890551c03e98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 10:45 AM, John R Levine <<= a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.com>= wrote:
At this point it seems likely that we'll do the elliptic crypto so I= 9;m
inclined to skip the key hashes.

This is an odd angle to take here.

Key hashes would remove the limit entirely.=C2=A0 I appreciate that you
think that 1024-1156 is of marginal benefit, but the benefit of key
hashes is that you can use the existing, certified, and tested
primitives AND keys that you have already.=C2=A0 It's a much smaller increment.=C2=A0 That makes me inclined to think that hashed-RSA has some value.

If the RFC 8032 algorithm isn't existing, certified, and tested, we'= ;ve got problems beyond DCRUP.=C2=A0 Hashes in principle are simple, but th= ey got taken out in 2006 because of complaints about bulking up the signatu= re with the key, and we can bikeshed forever on which hash to use and how t= o represent it.

You can bikeshed on anythin= g, but I don't see how this is actually a particular problem,
given that you can pin the hash to the signature algorithm, as we do with = elliptic curves.

TBH, I'm not sure why we'= re debating this point, given that hashes are actually in the
cha= rter:

"DCRUP will consider three types of cha= nges to DKIM: additional signing
algorithms such as those based on ellip= tic curves, changes to key
strength advice and requirements, and new pub= lic key forms, such as
putting the public key in the signature and a has= h of the key in the
DNS to bypass bugs in DNS provisioning software that= prevent publishing
longer keys as DNS TXT records."
=C2= =A0

=C2=A0 If people are going to make one change to update their DKIM signe= rs and verifiers, I'd rather they add a protocol switch to add better c= rypto.

Yeah, the issue here is that has= hes set us up for the future.

-Ekr

--001a114dd184605d890551c03e98-- From nobody Mon Jun 12 03:03:47 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF47B129353; Mon, 12 Jun 2017 03:03:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149726181966.10297.4161787727272663051@ietfa.amsl.com> Date: Mon, 12 Jun 2017 03:03:39 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-01.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 10:03:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update of the IETF. Title : Cryptographic Update to DKIM Author : John Levine Filename : draft-ietf-dcrup-dkim-crypto-01.txt Pages : 6 Date : 2017-06-12 Abstract: DKIM was designed to allow new cryptographic algorithms to be added. This document adds a new algorithm and a new way to represent signature validation keys, and deprecates obsolete signing algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-01 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 12 03:07:54 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E781294EC for ; Mon, 12 Jun 2017 03:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=6FXWe9UN; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=djV9eN9G 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 8DbtaKy_fIkM for ; Mon, 12 Jun 2017 03:07:50 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C2212704B for ; Mon, 12 Jun 2017 03:07:49 -0700 (PDT) Received: (qmail 63030 invoked from network); 12 Jun 2017 10:07:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=f634.593e67f5.k1705; bh=E+VQfiyeNviUupXcNxNcraehhthTrixnIo0vH8mjpm4=; b=6FXWe9UN62zvMTM3Ztuw/McKexCErqg55VUQ8De6bNVtm/XwEQ1nxE6oobVo5IHABIYBxDg2ZQOMJ4IuCR/hlCdJgEpZGXjOBIvW4iAYtOEPnRbTp59+hWUGz7G19nUKeHtmu0fpap8ldktgTQVcjG2oj0y5kBrxhByWqpoLatdOLpFN3XvL+ic0wMSLP3S1BDqxHy7SM7u/HiNR26FtfrB3HH5r+Z8zZ30GDDKXoqma9U0jomfrrRUypPVv2xTV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=f634.593e67f5.k1705; bh=E+VQfiyeNviUupXcNxNcraehhthTrixnIo0vH8mjpm4=; b=djV9eN9GGafxTtNVRN6SFGhPn+engPpo/058Q5iL5pE9aS/EMY6kbYHEDMCDfCq058hp9ORS23Kfha1+V9V1/C8r4BQdcN39g+n5HEnc+xT+lQOcbHgBQ0IabZCY5rcyVxFCyCRdDN68+zOS7mOIBnFj4hBKh0gKa3i250zEL2apfXDtexOuTl3Ty1TuikjQ3KCaMpDQqFNRiaGl0F8dWsLF9Hk5iJstG++7wtjm+CWfIcqBpCyyCyyH1SkLtk5w Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 12 Jun 2017 10:07:49 -0000 Date: 12 Jun 2017 11:07:48 +0100 Message-ID: From: "John R Levine" To: dcrup@ietf.org User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [Dcrup] combo update draft-ietf-dcrup-dkim-crypto-01 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 10:07:52 -0000 Per recent discussion I just updated the original dcrup draft. Changes * new algorithm is now EdDSA, tags updated appropriately * sha1 hash is moved to historic * place marker to splice in deprecation text from Scott's draft if we want to. My draft has always provided updated text for section 3.3 of RFC 6376. It says which algorithms signers and verifiers are supposed to use. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Jun 12 05:15:15 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9CC128B93 for ; Mon, 12 Jun 2017 05:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6yPSpJiboO8B for ; Mon, 12 Jun 2017 05:15:12 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D0A12EA94 for ; Mon, 12 Jun 2017 05:15:12 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id e11so12291381oia.2 for ; Mon, 12 Jun 2017 05:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4y/jiQs1dl1chJPXl/qMFropQrVHLvjBJWO9ijNWv/M=; b=Wq54D6sX/MLpkkFdH8vpAYFNlNi9iMgF8Ta9EI/pc9MkodCExXd59d9sIFzBmzcOQA jeB+0CFkpRKKZrF+Pri6KFl7DtUibujFFR3vOPtn+9s7JFUB76Yj339MbwzsrXPxHJBq EIfCwqDXTnmaPi5OxABnWR02pnAgrAQGpCvR9Ur2To6lYEobrZtc2jGqcjHQjenlQMYl BMZgdh6nP3jiAubdeYAPfoYR7JfOll2NWy/cYLyGEgLhoEJmU0FadiB3cEVN2/88igHj X1WZq+mKNPrVAwzld7EED/INyYl1PN9rMUShUTmoFWRP2Fozaauxk4ix3nwjWtVL5cc8 ijLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4y/jiQs1dl1chJPXl/qMFropQrVHLvjBJWO9ijNWv/M=; b=My238mNzJIq7szz/csgdi2vaADaQa5Qabu90bQ6Ssj3ClXt1gwXpg1kWKLYKdG1gaG YpDb39HzBXKy7VdOSWdafJfZwyulUsWkJD9NaKVo3w4Exigsr7gfKgOxCZC9cm7b+nq9 tHGysk7Sq3arwU3l/5of2GBr1sl/AINxJSYbeSOzU4jE5V3pq5xHhdKd4COZik23gtha MZnyb7ktYPkcjn3OJ7JUDpExKdDnQCov4PyMv2HYdd5O6EwvBQbe+jiG4D/tdXBRwGFf s0u6M0qNeRfXD0HJb6a16tXeNS8rZ9Jo47Bbp0hlx3espqPUKm010fdC+2VbcNOn6HVU R+3Q== X-Gm-Message-State: AODbwcDitxUGUWUtIjhHUHr12BlNYVhowCX72wIE/Eyw/18IvOY+RIAv G0gWGdl8R29cYzdNuq2NuU711apGTQ== X-Received: by 10.202.239.9 with SMTP id n9mr23933544oih.70.1497269711436; Mon, 12 Jun 2017 05:15:11 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Mon, 12 Jun 2017 05:15:10 -0700 (PDT) In-Reply-To: <20170611231340.17586.qmail@ary.lan> References: <20170611231340.17586.qmail@ary.lan> From: Phillip Hallam-Baker Date: Mon, 12 Jun 2017 08:15:10 -0400 X-Google-Sender-Auth: ijxJkDKdsdVjDsdNsB4yiUkTQz8 Message-ID: To: John Levine Cc: dcrup@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c0957044880930551c24560" Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 12:15:14 -0000 --94eb2c0957044880930551c24560 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 11, 2017 at 7:13 PM, John Levine wrote: > In article gmail.com> you write: > >1156 is better, but I was hoping for a bit higher than that. I would > >include text that suggests this (explaining the limitations you set > >out regarding the whitespace and so forth), but note that the > >additional security margin is, well, marginal. > > Of course it is. My draft has two approaches to stronger crypto in > 256 bytes of TXT. One is key hashes with the key in the signature, > the other is elliptic crypto. > > At this point it seems likely that we'll do the elliptic crypto so I'm > inclined to skip the key hashes. > =E2=80=8BKey hashes may be of use when we come to do quantum safe algorithm= s. Though it might well be that given the vulnerabilities DCRUP is ultimately addressing, non QCR algorithms will remain satisfactory.=E2=80=8B --94eb2c0957044880930551c24560 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Ju= n 11, 2017 at 7:13 PM, John Levine <johnl@taugh.com> wrote:
In article <CABkgnnXAVni8Xg= ms2snX9LrGRd+xKuyt8VTU_XmXgh4ksBqHEw@mail.gmail.com> you w= rite:
>1156 is better, but I was hoping for a bit higher than that.=C2=A0 I wo= uld
>include text that suggests this (explaining the limitations you set
>out regarding the whitespace and so forth), but note that the
>additional security margin is, well, marginal.

Of course it is.=C2=A0 My draft has two approaches to stronger crypto in 256 bytes of TXT.=C2=A0 One is key hashes with the key in the signature, the other is elliptic crypto.

At this point it seems likely that we'll do the elliptic crypto so I= 9;m
inclined to skip the key hashes.

=E2=80=8BKey hashes may be of = use when we come to do quantum safe algorithms.

Though it might well be that given the vulnerabiliti= es DCRUP is ultimately addressing, non QCR algorithms will remain satisfact= ory.=E2=80=8B
--94eb2c0957044880930551c24560-- From nobody Mon Jun 12 05:39:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7DB12EAA7 for ; Mon, 12 Jun 2017 05:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M-PT-G8i5nXS for ; Mon, 12 Jun 2017 05:39:41 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 305D7126B6D for ; Mon, 12 Jun 2017 05:39:41 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id v20so50354244lfa.1 for ; Mon, 12 Jun 2017 05:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QrVwPgUSgkB/C1Lk9EZtkRrPUHXpnMF5/ycIcqdsgCE=; b=AIY8+LbgiGjWYYnD9m1JwkBWxd144dSSXsRu6wBxWOiqoTGcXmJs6Lhi3sAde59Csu DxqiZNzg71AJq9L0ar42x7KhM4dH5Rfh6AIc7r8ySb+9seCR0Lk2ajvZcKRHcU45R+3F /QtT7n10GLHXGExMVasP9IAwfGviIanNcPIVnlEibOFn0Y4DE3w3EoUgaot5R5+YxNjg v4gqgHHgDlqU+5hGssFU3I+Bw7CFGyP2qJ0KJSEbM2YdreYqOelmQ9kJWZqF3RQ3V01b cmo6Jne45ku8F8/5+0eY+HJiOCVYBUUSlBGa24Jzy19LCzFRSsITET+xqken9FAE7z1q 5L1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QrVwPgUSgkB/C1Lk9EZtkRrPUHXpnMF5/ycIcqdsgCE=; b=uCHLRWnbeZFpOBsO4a+wiTJWiAfyWM0rHnZZk0a6/R0adpqsi9QwCeg1mc29M0oh51 GmuqvqurAGjDmGgSuJ3F94KbZiO/q32NSj0ogA3kr4KTN9jDb1jLGiNpJ/WlEDOEHScW H9Ihtk64utW6e4JgTb09kkovxL1vIQnXbVXuHvEh9oiPu+lSPmU+Ap7GHxA2m+5aLrNx kJNfGvDROzWe6x7RGjd1vsKViNmm5qPL7jTpMR7kFYFHNY35gEjskYcLOju/DZFhNCHC K+sEaZi9G5J3qtXcEAr4zSDvUTefq6+OryKAR3HYNWwDsghpkzFMD609m0OFCl1YoZdB Wb4w== X-Gm-Message-State: AODbwcBU5L8+1NXl8Y775De38K4m1ODsztqhp/7pfmtdmUWTi0LGpInn TY1PyrpFeZnvuhx/Sxip2/XwfV32glVuzbQ= X-Received: by 10.25.166.15 with SMTP id p15mr7704522lfe.43.1497271179286; Mon, 12 Jun 2017 05:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Mon, 12 Jun 2017 05:39:38 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 12 Jun 2017 13:39:38 +0100 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] combo update draft-ietf-dcrup-dkim-crypto-01 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 12:39:43 -0000 Quick comments: sig-a-tag-k = "rsa" / "rsafp" / "eddsa" / "eddsafp" x-sig-a-tag-k This is missing a '/' for the extension piece. Also, I would instead do: sig-a-tag-k /= "rsafp" / "eddsa" / "eddsafp" I found the description to be hard to follow and I know how this works. You really need more information on how the fingerprint-based schemes work here. 1. You need to explicitly state that the hash function for the signature scheme is used to construct the fingerprint. 2. You need to explain how to validate a signature. This description could be made generic so that (for example) PQ schemes could use this. On 12 June 2017 at 11:07, John R Levine wrote: > Per recent discussion I just updated the original dcrup draft. Changes > > * new algorithm is now EdDSA, tags updated appropriately > > * sha1 hash is moved to historic > > * place marker to splice in deprecation text from Scott's draft if we want > to. > > My draft has always provided updated text for section 3.3 of RFC 6376. It > says which algorithms signers and verifiers are supposed to use. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Mon Jun 12 07:12:15 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4761129401 for ; Mon, 12 Jun 2017 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 eoJNyGtLfKCj for ; Mon, 12 Jun 2017 07:12:12 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4AFA9129329 for ; Mon, 12 Jun 2017 07:12:12 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5CE7A0o023246; Mon, 12 Jun 2017 15:12:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=02OJXbxTYMPwTxutNbIRGY9SQ+UcMnrwlaQ/oog0QNw=; b=ahVvcsqoUh4XzUoORB3nUn6dLsgNZUGS1dl7XtnLIAYi7kNrFDmXkNq368ab/DI2JTYU OO4tP0qAi39NxrSy7HuQvvFlqbEG+eiB6aUOmwa8Nvx8nIPEj5bUnbzav/3C1XFbvGX4 e6zXc5HJhKsZ1iLnmICwTVevxmWeppseuXjltldPA9st2npRmO6dcP1cdjfSjKLfrYiE HdXQiqOsKrLD7kO/5YyxmZc1Ji1LhfuTKX14H7TEdUTNNq7VdwWFszMmKiIvRbEv2iOD 9OGTnJdCoZK+5V7SdZ4fd2wUT/AhI3obQW4trlCuJmONNaoQc1qz5Hzd4/9ohlrsXxAl mg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2b05ub3bnd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 15:12:09 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5CEAuZm003216; Mon, 12 Jun 2017 10:12:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vmet5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 10:12:09 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 10:12:08 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 10:12:08 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "martin.thomson@gmail.com" Thread-Topic: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt Thread-Index: AQHS410gNVJS/qWhYEGUI0m2cJxiEKIhRNJQ Date: Mon, 12 Jun 2017 14:12:07 +0000 Message-ID: <9af51e0982084a14b94a512b43b3cda1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170611231340.17586.qmail@ary.lan> In-Reply-To: <20170611231340.17586.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.177] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120248 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120247 Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:12:14 -0000 > At this point it seems likely that we'll do the elliptic crypto so I'm in= clined to > skip the key hashes. Speaking purely as an individual, I am in favor of this. We used to think = things would go 1KRSA 2KRSA 4KRSA, but people are moving to ECC instead of = 4KRSA. From nobody Mon Jun 12 07:18:59 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC21293E3 for ; Mon, 12 Jun 2017 07:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 TgORRF4769WS for ; Mon, 12 Jun 2017 07:18:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 249BC127601 for ; Mon, 12 Jun 2017 07:18:56 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5CECK6P011734; Mon, 12 Jun 2017 15:18:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=OggAh0Z//Sj7dYtmdRXEHADRHSZ1zvrIYy6vDtGrF3o=; b=UPmzbBijVlb6OT2YBYADUDGZlY0K36R4uSqMheGqvLh8FdLVtL4ber1liAJgVlrFTIUk yzsFORzgP504o4eV0GPjCX/PkeMU+6/k7UGzog/d6p4NzYddgSabU5zrqPWmBLR1eK5o wivs3DqPOndKm+PhHIaTtraUYcRKIcMrL2lrOQ7taulStkvlP0Szehfv04S2dNlN6py2 vOcPsC+6jkmpM5B0Jht4vv2Wf4pgU/Y0jfdy6oYO3UdIIxo0nBb0UkulvneYDoquzUUc kdH/C3eEQF3uM8D7oSElxsT/PKdP6BHlpIUs7bMPlGZhWfO59ugHaCKWeM4+OVzhO6Hs iQ== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b1rnbh5ec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 15:18:52 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5CEFxwT015283; Mon, 12 Jun 2017 10:18:52 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3ueegg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 10:18:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 07:18:51 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 10:18:51 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "martin.thomson@gmail.com" Thread-Topic: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt Thread-Index: AQHS410gNVJS/qWhYEGUI0m2cJxiEKIhRNJQgAAB35A= Date: Mon, 12 Jun 2017 14:18:50 +0000 Message-ID: <6fddf78ffb794365b148c544183e766b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170611231340.17586.qmail@ary.lan> <9af51e0982084a14b94a512b43b3cda1@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <9af51e0982084a14b94a512b43b3cda1@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.177] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120249 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120248 Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:18:58 -0000 > Speaking purely as an individual, I am in favor of this. We used to thin= k things > would go 1KRSA 2KRSA 4KRSA, but people are moving to ECC instead of > 4KRSA. I also, as an individual, prefer things to be as self-contained as possible= . From nobody Mon Jun 12 07:29:15 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DAC1293E0 for ; Mon, 12 Jun 2017 07:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 sX2O7GohhXYj for ; Mon, 12 Jun 2017 07:29:09 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19F3124D68 for ; Mon, 12 Jun 2017 07:29:08 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B38E8C40236 for ; Mon, 12 Jun 2017 09:29:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497277747; bh=+lWxMvfBp6LYSdViBZr7cxSMW2d47B1J1gQ3cZnJVHw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=w+7WRKNXulzJbkHXYd+pZwOncfxtKP8pJ4oU25zBhtgItY2le8EBDSdR1EP3YEM4j ARDo0SLBsq77v+6tD2Rn2YMfdZvdo/s2gqNP35W5bMt2vkB4AQqJe2mU6CouVfO4TH Ng1Cn2y1KQkV7F2406anAzxeZ4bXFDhp1WZvEpBI= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 12 Jun 2017 10:29:07 -0400 Message-ID: <4379310.8G0EpGEsGj@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> <2034638.szbv6KSWyz@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:29:13 -0000 On Monday, June 12, 2017 12:23:16 AM Murray S. Kucherawy wrote: > On Sun, Jun 11, 2017 at 9:38 PM, Scott Kitterman > > wrote: > > The IETF is five years late with action on this front. At least. > > Whatever is > > happening in this working group, hurrying isn't on the list. > > Then I don't understand why this thread seems to be so tense with > frustration. I think getting rid of sha1 and keys < 1024 bits should be really easy. I THOUGHT we had all agreed to get that done and out of the way. In the space of two days we went from "OK, almost done" to "Here's three different visions for how the draft should be written that all say the same thing" or maybe don't bother. That's frustrating. I find the notion that it's not an interoperability problem for signers to sign with keys that receivers will ignore frustrating. > > I have no idea what should be in this draft or if it should even exist > > anymore. > > I really don't think the proposed changes are all that major here. If I knew which of the three approaches to take, then I could pick one and write it: 1. Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MUST NOT rsa-sha1 (my personal preference) 2. Fully replace section 3.3 dropping rsa-sha1 and just giving the new requirements (possibly with an appendix that says MUST NOT rsa-sha1) 3. Make the draft a lot shorter and only state updated requirements. Also don't remove rsa-sha1 [1] As a maintainer of an implementation of RFC 4871 and its updates (e.g. RFC 6376) and its updates, I strongly prefer option #1. That structure makes it very easy to see what needs changing when I update the code. Using the approach in option 2 I need to either mentally diff RFC 6376 and the new document (or if we add it look at the main body of the text and an appendix) to determine what to do. It's less clear. Option 3 makes the entire document a no-op. It both fails to remove rsa-sha1 and offers no guidance on key sizes. The one new thing it says (compared to RFC 6376 is "Verifiers MUST NOT rely on the rsa-sha1 algorithm". What does that even mean? Since rsa-sha1 is not removed from the ABNF, it's still a required part of the protocol. Once we add an ECC algorithm are all three going to be required? I would like to know what the group prefers. I'll do whatever, but I really have no idea what that is. If option 4 is kill the document, my ranking would be: 1 2 4 3 > > I also really don't understand why we have a discussion about if a draft > > should be adopted before a WG adopts it if we just get to re-have the same > > discussion periodically. > > You think working groups should not be allowed to revisit their choices? You think working groups should have a bi-weekly periodic on revisiting choices? Of course choices can be revisited, but if decisions aren't at all sticky, then there's no way to make progress. Scott K [1] https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1/commits/b7815a3b876c5b57f7eff4537ed0c0e9eef497a8 From nobody Mon Jun 12 07:32:56 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC9E128E19 for ; Mon, 12 Jun 2017 07:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 7ox7b0W64PSM for ; Mon, 12 Jun 2017 07:32:53 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4079E128B44 for ; Mon, 12 Jun 2017 07:32:53 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B4B95C40236 for ; Mon, 12 Jun 2017 09:32:51 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497277971; bh=uj2/QZQVLTYduajAJ1oqoLt9oyOyAsdvtjyMinXMo1k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=T+JNaDIBjWnq6X2Ss2mwbn52WsUhePjS2caYC8YtZHBbsAx1wEHLV1p7CIyRRIseZ xPalVyTVKk0Qs9ustYYdPSC9V4i6N6TYBOTYdwXu39rSm3Nxvqa8YxpzvI5uV4OJ4x mazLEvoLsFblV6X3QSUHb1JCIXVsXGzpfoAGPyXQ= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 12 Jun 2017 10:32:51 -0400 Message-ID: <1828951.1dWPTdrTAp@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:32:55 -0000 On Monday, June 12, 2017 08:20:18 AM Martin Thomson wrote: > On 12 June 2017 at 04:25, Murray S. Kucherawy wrote: > > On Sun, Jun 11, 2017 at 1:40 AM, Martin Thomson > > > > wrote: > >> https://github.com/kitterma/draft-ietf-dcrup-dkim-usage/pull/1 > >> > >> I think that I got the essence of your changes there. And it's a lot > >> shorter. > > > > Can you explain what you mean by "rely on"? > > Sure, that's probably a bit of an imprecise way of saying that a > verifier needs to insist on receiving a valid rsa-sha256 signature and > that it can't just fall back to rsa-sha1. The way to do that would be to remove it from the protocol, which you seem to oppose, so I'm confused. > > So by that logic, you can put a 1156-bit key in a record now without > > changing anything. For anything bigger you will need multiple > > character-strings in the TXT field which I believe is one of the things > > John says doesn't fly in current provisioning software. > > 1156 is better, but I was hoping for a bit higher than that. I would > include text that suggests this (explaining the limitations you set > out regarding the whitespace and so forth), but note that the > additional security margin is, well, marginal. 1024 is operationally very common. In the end, if it matters, I don't mind adding this discussion, but I also don't see any reason to set the floor higher than 1024 (I don't think there's enough security advantage in 1156 over 1024 to matter). Scott K From nobody Mon Jun 12 07:41:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A8129411 for ; Mon, 12 Jun 2017 07:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eoeXpliNsZ8C for ; Mon, 12 Jun 2017 07:41:04 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BAE1289B5 for ; Mon, 12 Jun 2017 07:41:04 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id m77so27360167lfe.0 for ; Mon, 12 Jun 2017 07:41:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3dFDNQD9oc/ewRJe4OzAYG0Wd+T2/XyV9d2syzyZZMY=; b=COgoWQqT91tTFMvzkfjHd7mIADeyrUu6zDfh1hnEdHdLV5p8F/6enK+77k0w6y0DUj PmEQGkBRoqM5qUX/mbp/qpeJlkfBnYcwj5LOs9mEvnwkpx5fo9lg2plUQwfsRTPGyGaC HjGsMwxf0i0fV0VwCScmMIicSeC8QRyXwbNBYULCbxBNaqJMu9brl06zEk+3+gOEj6RI zHSeXYWKIfP6Vb9INuvwW/AtyIlg6GHH3+3lfq/2e/U5pj23jFkZssqm4AWC7Et2AA8M 5SKWCuTaWCwLWshl0A1RVZcBB12jMqPKgqYa6+SXvX8dVALLEC2BZg1wik/SEtXYqMih u2hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3dFDNQD9oc/ewRJe4OzAYG0Wd+T2/XyV9d2syzyZZMY=; b=Px7hbZCtztqWLPjOUMZpQMQl/uEigC2L0mLxN7nLhSQY7TJHs7OTFTJ5RAdIaw6M8O Ewz2rg/qNqRySzuHM2KLNVpBfQsFV+wwXh/PxkHb2hxD5cfOJKNimVpjbgh62OhPNVik C2nPjX8OpDCgYoIWVDdwxA2i4fCYy4ud4BGr6tWyPxHFhjnb3rq4P2S3oP0TEUcl70rd aIgk0eDmrmAfU1qTEj8mbTJG/JpfkAcBFYE2+lcwbbcbnJcjVqcmf9RwG4nn2wu22b1H 4T1TwLpLGhEc6Q10SzE6mCwvNKVp/jan2Nl3BLPkww4C8aNtDMV0Buo/Eind3eErS+r7 7+AA== X-Gm-Message-State: AODbwcBRuKxUMuesGWTqXbQtiHYjTC56OSPiLumGLYyp3S4GOZDy5c/9 N7Ike1iW8LvRVoSJVsxsGTaqq9vv3Ce099Q= X-Received: by 10.46.76.1 with SMTP id z1mr16352773lja.128.1497278462232; Mon, 12 Jun 2017 07:41:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Mon, 12 Jun 2017 07:41:01 -0700 (PDT) In-Reply-To: <1828951.1dWPTdrTAp@kitterma-e6430> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <1828951.1dWPTdrTAp@kitterma-e6430> From: Martin Thomson Date: Mon, 12 Jun 2017 15:41:01 +0100 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:41:06 -0000 On 12 June 2017 at 15:32, Scott Kitterman wrote: > The way to do that would be to remove it from the protocol, which you seem to > oppose, so I'm confused. I don't oppose removing it from the protocol in practice, it's just that you can't pretend that the old version doesn't exist, and nor should you care. The point is to not USE it, the definition becomes harmless at that point. > 1024 is operationally very common. In the end, if it matters, I don't mind > adding this discussion, but I also don't see any reason to set the floor > higher than 1024 (I don't think there's enough security advantage in 1156 over > 1024 to matter). This I agree with. The reason I suggested this is that your current draft doesn't *actually* include any new advice about key sizes. 1156 would be advice you could give, but as I said, that's of marginal benefit. From nobody Mon Jun 12 07:57:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 317EE12EB20 for ; Mon, 12 Jun 2017 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 XjwXkO5TanzY for ; Mon, 12 Jun 2017 07:57:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E66C12EB1C for ; Mon, 12 Jun 2017 07:57:41 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CF72DC401D4 for ; Mon, 12 Jun 2017 09:57:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497279460; bh=LaLsKFNQGpQGSn84yUCF1LcKJ/ofmpEkY+koyhwKzco=; h=From:To:Subject:Date:In-Reply-To:References:From; b=EY16ixpxKl3n4XTGU7/d2yZslCz56Urs8b/sOZTTybtXCoxtGqSuMwSdZToZ0QO2e EmHIIKuUg7rYDAoLtobNy5+7QcOicc2X0krcPkXO5lHdvJCQqYS9SYBv2KmRWd/qBb ZNKY7au09SnGHI5a4UYYhrZzi3RnEOkWcc+7LSFo= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 12 Jun 2017 10:57:40 -0400 Message-ID: <2659439.8rBlqZiqLg@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <1828951.1dWPTdrTAp@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 14:57:43 -0000 On Monday, June 12, 2017 03:41:01 PM Martin Thomson wrote: > On 12 June 2017 at 15:32, Scott Kitterman wrote: > > The way to do that would be to remove it from the protocol, which you seem > > to oppose, so I'm confused. > > I don't oppose removing it from the protocol in practice, it's just > that you can't pretend that the old version doesn't exist, and nor > should you care. The point is to not USE it, the definition becomes > harmless at that point. I disagree on that point, but I guess we'll see what others think. I think as long as it's in the protocol, it's problematic. > > 1024 is operationally very common. In the end, if it matters, I don't > > mind > > adding this discussion, but I also don't see any reason to set the floor > > higher than 1024 (I don't think there's enough security advantage in 1156 > > over 1024 to matter). > > This I agree with. > > The reason I suggested this is that your current draft doesn't > *actually* include any new advice about key sizes. 1156 would be > advice you could give, but as I said, that's of marginal benefit. Yes. It's focused on trying to define a secure/interoperable set of requirements that are common between senders and receivers. I didn't see anything that really needed updating about the drivers for choices within those bounds. Scott k From nobody Mon Jun 12 08:05:52 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADC412EB18 for ; Mon, 12 Jun 2017 08:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 fvI40FvBA3jf for ; Mon, 12 Jun 2017 08:05:50 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 F0736126FB3 for ; Mon, 12 Jun 2017 08:05:49 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5CF2YgB018629; Mon, 12 Jun 2017 16:05:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=6WxrxsyaoIxmbJ4Jk5PjmVdxIbF5RbNV3R2+V+AI6jA=; b=T6I356l2/7YKL9iRoeer5Y/Dxm2QWAQ9jzY0395N8dyCRILnEQNnG59V+4F35RvfM3/v vaB7nBrCQ39Txveesj2G3o2MuH9WFQ+pxey2JCK8qDY0EMOovpicm70iVLXM12JOfbA6 hRw6n7iROltlVg6ls2Xozwie73Pfe0egxD55CGO87T0s2JdYrD18R70atQQ/OMYNLNmw JP8lehElqYzfU0bav3MmMvavybwVDgbdAT99z/AJ12gNXuOjUIBDIbkcc4nbNTsxbN2J 7raKHPgf0a83CG6Pnp/nKD07/SGPy/BSJ5qrSLxwVpPLN7ZeXvPmqx8tNd0YWgJR4uBn Pg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2b1vnrr77v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 16:05:46 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5CF0ueD019390; Mon, 12 Jun 2017 11:05:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b0c3uvm37-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 11:05:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 12 Jun 2017 11:05:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 12 Jun 2017 11:05:44 -0400 From: "Salz, Rich" To: Martin Thomson , Scott Kitterman CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt Thread-Index: AQHS4Bqz9gctnLGoiU6X42a/ECKz/aIeHp4AgACUdACAAOxmAIABOosAgABBhQCAAHjbgIAAAkiA///DrkA= Date: Mon, 12 Jun 2017 15:05:43 +0000 Message-ID: <90199bb8f57a4539ad5c6ef506a943ae@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <1828951.1dWPTdrTAp@kitterma-e6430> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.218] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120262 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120262 Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:05:51 -0000 > The reason I suggested this is that your current draft doesn't > *actually* include any new advice about key sizes. Does it have to in order to be useful? I don't think so. From nobody Mon Jun 12 08:07:23 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF0E12EB2D for ; Mon, 12 Jun 2017 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=n78sESB/; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=xNhSAjN3 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 STEBG4axUgYW for ; Mon, 12 Jun 2017 08:07:19 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB40912EB21 for ; Mon, 12 Jun 2017 08:07:06 -0700 (PDT) Received: (qmail 93506 invoked from network); 12 Jun 2017 15:07:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16d40.593eae19.k1705; bh=QlLK3sUqMQzMSshzaVWA0prLdZh6ryLlHHPq3hCEtiQ=; b=n78sESB/TwLspO2TTCbVTN6gf+AoukuMh8gTWaqsw/Z4V/jERzo66yKfuqGXxD/Dr8Edjn5XK/vDleggef2hIfuerAdLcFuP2Mpi42BvzAGPIRnk+vte9tXnuu+B+B/3mJv7ZGyQC7ffmgr7iuBG4LYS8F0BsUoxLLJu67BWx/z8TghX2MXyvkA0dDq1CZurgPdGCgRaUzxOaUpHxHQS3aChm1pMxl/CLcvZAAnmgjFDJn6JqPfecjmFHHvQufx5 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16d40.593eae19.k1705; bh=QlLK3sUqMQzMSshzaVWA0prLdZh6ryLlHHPq3hCEtiQ=; b=xNhSAjN3G5uwblaKZy9HL9hELzVdWDpwssSfjcUOr1fl0Af7pJhfX3Knhy+boq8LaeogpkrBLUz9HLJXv/SC+4RaFDMkIryAQHsylIhmRauhTpscSB/jTeY0syx2xuZ+BXUSWxokpVmjlIfnJqk9wXS83XaBvzRnBeaT4rj4zJ4GGiWzf2e29d61N4IQIfJhK9Oj2dTtUhjhIL4DyGZ6rUm6zi+cWBbum0kilWGIuLfETsyVIDPfaCuU1fWx1p9K Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 12 Jun 2017 15:07:05 -0000 Date: 12 Jun 2017 16:07:05 +0100 Message-ID: From: "John R Levine" To: "Martin Thomson" Cc: dcrup@ietf.org In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] combo update draft-ietf-dcrup-dkim-crypto-01 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 15:07:21 -0000 > Quick comments: > > sig-a-tag-k = "rsa" / "rsafp" / "eddsa" / "eddsafp" x-sig-a-tag-k > > This is missing a '/' for the extension piece. Also, I would instead do: It's supposed to replace the existing sig-a-tag-k and key-k-tag-type rules, not add new ones. The explanatory wording could use some work. > 1. You need to explicitly state that the hash function for the > signature scheme is used to construct the fingerprint. Here's what it says now. This seems reasonably clear. The DNS record contains a sha-256 hash of the public key, stored in base64 in the p= tag. The key type tag MUST be present and contains k=rsafp or k=ecdhfp. I suppose I could change that to say use the hash of the signing algorithm if people think that's a good idea, but if we add algorithms that use hashes other than sha-256, we'll need another update anyway. > 2. You need to explain how to validate a signature. OK. > This description could be made generic so that (for example) PQ > schemes could use this. No, my goal is to make the minimum changes needed. The more options, the more chances not to interoperate. R's, John From nobody Mon Jun 12 09:52:25 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891B91287A0 for ; Mon, 12 Jun 2017 09:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 Y_7PHKRQbE-w for ; Mon, 12 Jun 2017 09:52:21 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 E6819127866 for ; Mon, 12 Jun 2017 09:52:21 -0700 (PDT) Received: from splunge.local ([IPv6:2601:205:8302:79b1:f94e:a05d:edb7:58d1]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5CGqIr2000720 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 12 Jun 2017 09:52:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497286340; bh=Nbgr+1qBGv+ANAUktjnin7dFIwvLBbnd1+6n4/65jMw=; h=Subject:To:References:From:Date:In-Reply-To; b=tvFaAaA6vLXy3CqClndAhav3yUXYyQO8dfOCbHa80x5BsukLRksQGsP4VkyO5gS2D GTyFNakwaP+PE1aEJ6e9svXeKRE+4VtqX/eoGym3mqU0IEU9V3iYxRODXwtmVemhHs fXs8XnN2OJNGrXL8ZPTPjCJBt54ms9uP4EB9SuMY= To: dcrup@ietf.org References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> From: Jim Fenton Message-ID: Date: Mon, 12 Jun 2017 09:52:13 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E9E8940C8E0F5E3573A4D7A3" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 16:52:23 -0000 This is a multi-part message in MIME format. --------------E9E8940C8E0F5E3573A4D7A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/11/17 8:28 PM, Murray S. Kucherawy wrote: > On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson > > wrote: > > I find the construction of this draft strange. Why not simply say > "verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"? > The remainder of the text is largely unchanged, which took me a whi= le > to validate. > > The problem here is that removing the definition of rsa-sha1 is not= > the point. The code point can't be undefined (Section 7 gets that > right), and we don't really benefit from having the definition > removed. What we want is to have rsa-sha256 implemented and deploy= ed. > > So say two things, just to be perfectly clear: > > 1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted. > > 2. DKIM implementations MUST use rsa-sha256. Signers MUST create > signatures using rsa-sha256 and verifiers MUST verify those > signatures. > > > That idea is fine with me. Specifically, I think "MUST NOT rely on" > is better than "MUST NOT implement". The difference between "rely on" and "implement" is not at all clear to m= e. Backing up: For interoperability, ideally we would have some transition time between when rsa-sha1 is no longer an acceptable signing algorithm and when it's no longer an acceptable verification algorithm. RFC 6376 didn't quite close the door on use of rsa-sha1 for signing, so it's premature to say that it's no longer acceptable for verification. Put another way, if a frequent correspondent of a domain signs with rsa-sha1, they're going to want to verify those signatures regardless of what we say here. Yes, rsa-sha1 is busted, but is it busted in a way that is likely to be exploited in this application? There are other weaknesses, most notably spoofing of key records in DNS, that are far more likely to be used; remember that DKIM tries to discourage other uses for keys (e.g., for data encryption) for those reasons. Also, factoring of keys and spoofing of key records are much more scalable than an attack on a particular message's hash. Does anyone have any data on how prevalent use of rsa-sha1 is currently in the field? If nobody is actually using it, I would believe that RFC 6376 closed the door more than I thought. -Jim --------------E9E8940C8E0F5E3573A4D7A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/11/17 8:28 PM, Murray S. Kucherawy wrote:
On Sat, Jun 10, 2017 at 2:42 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
I find the construction of this draft strange.  Why not simply say
"verifiers MUST implement and use rsa-sha256 instead of rsa-sha1"?
The remainder of the text is largely unchanged, which took me a while
to validate.

The problem here is that removing the definition of rsa-sha1 is not
the point.  The code point can't be undefined (Section 7 gets that
right), and we don't really benefit from having the definition
removed.  What we want is to have rsa-sha256 implemented and deployed.

So say two things, just to be perfectly clear:

1. DKIM implementations MUST NOT rely on rsa-sha1, it's busted.

2. DKIM implementations MUST use rsa-sha256.  Signers MUST create
signatures using rsa-sha256 and verifiers MUST verify those
signatures.

That idea is fine with me.  Specifically, I think "MUST NOT rely on" is better than "MUST NOT implement".

The difference between "rely on" and "implement" is not at all clear to me.

Backing up: For interoperability, ideally we would have some transition time between when rsa-sha1 is no longer an acceptable signing algorithm and when it's no longer an acceptable verification algorithm. RFC 6376 didn't quite close the door on use of rsa-sha1 for signing, so it's premature to say that it's no longer acceptable for verification. Put another way, if a frequent correspondent of a domain signs with rsa-sha1, they're going to want to verify those signatures regardless of what we say here.

Yes, rsa-sha1 is busted, but is it busted in a way that is likely to be exploited in this application? There are other weaknesses, most notably spoofing of key records in DNS, that are far more likely to be used; remember that DKIM tries to discourage other uses for keys (e.g., for data encryption) for those reasons. Also, factoring of keys and spoofing of key records are much more scalable than an attack on a particular message's hash.

Does anyone have any data on how prevalent use of rsa-sha1 is currently in the field? If nobody is actually using it, I would believe that RFC 6376 closed the door more than I thought.

-Jim
--------------E9E8940C8E0F5E3573A4D7A3-- From nobody Mon Jun 12 13:55:01 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45500129AB6 for ; Mon, 12 Jun 2017 13:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vjxAgRFmvFel for ; Mon, 12 Jun 2017 13:54:58 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A8A129AA8 for ; Mon, 12 Jun 2017 13:54:58 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q15so63844798uaa.2 for ; Mon, 12 Jun 2017 13:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z0ktLKH0kt4VNyiN0qPsJ5BHJK2XIQDSofg+ts0ziE4=; b=toalFNTMu5lfDuNZXtv+Pz98YsXj6OxvuNYKaMo8aIZeRz8a49w/kXNzjDuLoloSWH zP9uYsmwf7Ktb6LpNfzGdHFiUuOaNzQhiacqN2AqCFINMM9Si4HCrQdrFnarZXrNa/y6 pqm6MLOTcZlBal5rYQnvjebUEbt/vtaPeMbLUM6rmjWdKwaS1yfhskj0WYse67f+UTC/ lYCgfRIEZhIuObTZSRdfuoIqlZSOpj9Oer9bYoSNWno488FS5jY7wNrq4kOfenVRJWnj LhvHo5kMZyQPfz/5C4yRFMButeRFWdhl5b1foRaSZpjuedaF3b+XhIfcgpazVwmtuBRI Zr1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z0ktLKH0kt4VNyiN0qPsJ5BHJK2XIQDSofg+ts0ziE4=; b=tMOw5vkZvx0KDE7p4+SWZ0UfFAFBxlb9xBP/ddW1GaL4bJZZ4TdlRzNJ9SyykzyZrH vOaWYMxj2fAuij43NN4L1+09hwxljgAgSxlzqob9Ooz8hPMJMorEsl6Q/ypLwvf2pEDI oipjB2aKVwgIga7PIEPZB5G7pKUr6ZVFYCJ2rkqmvxb+pOOBc598trlAWpy022JFW6ad 8nP7+eSXCplgGboccOEdpu3nrvbFhBQZOzNKvLzL+60fGVzwrK/FEopfloTSpdMXX7vo 0UmHh3gk38pQzJ5h55iFlRaGkW1qwKJjSTHaV0M9ygMUc6SSGjDwDUSi8jeAK3vko36i Z8fw== X-Gm-Message-State: AKS2vOxkujEPM23iS51qAKxMAIe/bSt9wBXwRPyfESUUpJBpxuvL2CyI e/eryVgHEVAR8l+AgaPsZueJs7dA3g== X-Received: by 10.159.59.210 with SMTP id y18mr542302uah.43.1497300897717; Mon, 12 Jun 2017 13:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Mon, 12 Jun 2017 13:54:57 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <1828951.1dWPTdrTAp@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 12 Jun 2017 13:54:57 -0700 Message-ID: To: Martin Thomson Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a26d62161c20551c988c7" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:55:00 -0000 --94eb2c1a26d62161c20551c988c7 Content-Type: text/plain; charset="UTF-8" Hatless: On Mon, Jun 12, 2017 at 7:41 AM, Martin Thomson wrote: > On 12 June 2017 at 15:32, Scott Kitterman wrote: > > The way to do that would be to remove it from the protocol, which you > seem to > > oppose, so I'm confused. > > I don't oppose removing it from the protocol in practice, it's just > that you can't pretend that the old version doesn't exist, and nor > should you care. The point is to not USE it, the definition becomes > harmless at that point. > +1. -MSK --94eb2c1a26d62161c20551c988c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hatless:

On Mon, Jun 12, 2017 at 7:41 AM, Martin Th= omson <martin.thomson@gmail.com> wrote:
= On 12 June 2017 at 15:32, Scott Kitterman <sklist@kitterman.com> wrote:
> The way to do that would be to remove it from the protocol, which you = seem to
> oppose, so I'm confused.

I don't oppose removing it from the protocol in practice, it'= ;s just
that you can't pretend that the old version doesn't exist, and nor<= br> should you care.=C2=A0 The point is to not USE it, the definition becomes harmless at that point.

+1.

-MS= K
--94eb2c1a26d62161c20551c988c7-- From nobody Mon Jun 12 13:57:36 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAD5129AB6 for ; Mon, 12 Jun 2017 13:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 TFilmGhZQdGb for ; Mon, 12 Jun 2017 13:57:32 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689EA128C81 for ; Mon, 12 Jun 2017 13:57:32 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id p62so54261824vkp.0 for ; Mon, 12 Jun 2017 13:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=77TmSPShDYid+D7muMF0p6xejobzNIuDkoXQtNTf4Rk=; b=nH+z/O1OxLPm76SiNPGSp+n4CZD7wjpeTp/NaKahQsV6WpnNj8iS/4DLs0ChCim1aK msRX8E7/bvJetqIByoO0z2gmzxrp2lCYBRslPQY/NEymA/Ofy3dmrhoJH5TucBE7isa4 9AlsrlQB3o6iIfGC3mlQRnyBMUVoIuhBpX4bndvskqosEQoGTr2q2FLr2MLFrpQSZyCs 2fN/oRrMZDGNW36ykSH47+H+dM8gS7R2buq+VP6DkOykcGzQnxAz4fxGTN3eE/432xFm OQjHtkE51ojt/w9b4EfKT3hQVGvtRmbDmm7lGRsK+nTjntFp1QGrYTTKFkiLuSDirmia F1bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=77TmSPShDYid+D7muMF0p6xejobzNIuDkoXQtNTf4Rk=; b=FxDaKR4HiZz1gZK7PGQE3Mpcnu18qmlaHIljBPhBVdIdPg5jXbF7Uv26oYUu0K7fx4 QC34WdCUjep/43ZTNZqIAJHRq68ROvnrP/tYGmendqw/B1gTI/muFkPTgETI1Lh4gYeX 9IYQfJ2Jm6G0y8o5wSkFISMi7hQ0cHEsecUonLnTHmFBld/ZhF0aejKoZV5LzHnGpUiD ZhJ1mebVYG3CU1w7y23xIjCQjzkS8odXUDwXtXDbtx/eyvmaj0bDpreqiPgGjVRAEmjd iDGhaAzmx5fdL48Oqr7UYkpEw80NIUWBcFoBlZcvNKQfCPDmGtPipT8qZXGsH0YlxvG+ AQ6A== X-Gm-Message-State: AODbwcD9ZKWFl3jbQ+VYh9CVBVR7VhAVAfE0prM5nNxVEnxbc1tYULo4 LHED/Q/YP4gOZLzNNHJfCiCdfPvQPI0+ X-Received: by 10.31.96.150 with SMTP id u144mr20830790vkb.124.1497301051516; Mon, 12 Jun 2017 13:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Mon, 12 Jun 2017 13:57:30 -0700 (PDT) In-Reply-To: <4379310.8G0EpGEsGj@kitterma-e6430> References: <20170610002538.10992.qmail@ary.lan> <2034638.szbv6KSWyz@kitterma-e6430> <4379310.8G0EpGEsGj@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 12 Jun 2017 13:57:30 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114e24a24c2de90551c9915b" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 20:57:34 -0000 --001a114e24a24c2de90551c9915b Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 7:29 AM, Scott Kitterman wrote: > > > I also really don't understand why we have a discussion about if a > draft > > > should be adopted before a WG adopts it if we just get to re-have the > same > > > discussion periodically. > > > > You think working groups should not be allowed to revisit their choices? > > You think working groups should have a bi-weekly periodic on revisiting > choices? We haven't been chartered long enough for that hyperbole to have any basis. I believe this is only the first time such a change has been proposed. If this is going to be the discussion any time someone hints at revisiting a choice we've made about a document, this working group is going to take a really long time to finish. Of course choices can be revisited, but if decisions aren't at all > sticky, then there's no way to make progress. > To be sure, once consensus is reached on something, anyone who wants to change it has the burden to justify the change by doing the work to shift consensus. As a bonus, the weight of that burden generally gets heavier the more time passes. But that's as "sticky" as it gets. The conversation is allowed to happen, and attempts to stifle it are not appropriate. -MSK --001a114e24a24c2de90551c9915b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 12, 2017 at 7:29 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"gmail_quote">
> > I = also really don't understand why we have a discussion about if a draft<= br> > > should be adopted before a WG adopts it if we just get to re-have= the same
> > discussion periodically.
>
> You think working groups should not be allowed to revisit their choice= s?

You think working groups should have a bi-weekly periodic on revisit= ing
choices?

<chair, though having not talke= d to my co-chair about this yet>

We haven't been c= hartered long enough for that hyperbole to have any basis.=C2=A0 I believe = this is only the first time such a change has been proposed.=C2=A0 If this = is going to be the discussion any time someone hints at revisiting a choice= we've made about a document, this working group is going to take a rea= lly long time to finish.

Of cou= rse choices can be revisited, but if decisions aren't at all
sticky, then there's no way to make progress.

=
To be sure, once consensus is reached on something, anyone who w= ants to change it has the burden to justify the change by doing the work to= shift consensus.=C2=A0 As a bonus, the weight of that burden generally get= s heavier the more time passes.

But that's as "sticky"= as it gets.=C2=A0 The conversation is allowed to happen, and attempts to s= tifle it are not appropriate.

</chair>

-MSK
--001a114e24a24c2de90551c9915b-- From nobody Mon Jun 12 14:00:49 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476AF12702E for ; Mon, 12 Jun 2017 14:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com 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 bgYJTKHaXRDZ for ; Mon, 12 Jun 2017 14:00:45 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 5A5FC1296CF for ; Mon, 12 Jun 2017 14:00:45 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 42E521E0FE; Mon, 12 Jun 2017 21:00:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1497301244; bh=JPqOQzjUYQSXMp5K2VXM8ciU3ykLOchW/k40DU6w5vk=; h=From:To:Subject:Date:From; b=WjMYUh90mtjh56NmOkOOZImmaBPGdiW8JKTlxbp02QweKWNocKYjuui9qEbrw+xDo qaG4NfToLfi27Tj66+iPNgjtosqooHHdQkgMnyV/ujQXAmBPKlTmRjWfqMZkWXZ7ny PDJnAhQTKl2ZKs4kXoKRCUC3u4rlcnY7ujs/8DmeL7c2TlYmG/ldTDKXOUwidlBzIp svH9tzbDz9IctWur2il1g5Nsyv9sR4DnND5FAYlVCBWRY8uXUOAGJsZgWLwUnXlY2E 6BhOMCKECBdJgWW0baSHzEjoYxMR+cGp3eLmqyPOhfFUyenFlnTDLcZa+gbD7APA4u 2D26DTN4CFPrw== Received: by carbon.jhcloos.org (Postfix, from userid 500) id B4A66107B7BE1; Mon, 12 Jun 2017 21:00:38 +0000 (UTC) From: James Cloos To: dcrup@ietf.org User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2016 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 12 Jun 2017 17:00:38 -0400 Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170612:dcrup@ietf.org::1eyjAE+8kVcwGCc0:000JAp5 Archived-At: Subject: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:00:48 -0000 I looked at a corpus of email from this year. 3265010 emails, including all of spam, good automated and good from humans. The vast majority of the latter were deliverred via mailing lists. Just under half (1443757) had a dkim sig. The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces to about 6.270:1. So there is a ways to do before sha1 signers disappear. Nonetheless, I still agree that the update should deprecate sha1. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jun 12 14:27:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32887128B51 for ; Mon, 12 Jun 2017 14:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 i5bTkzJRl6Es for ; Mon, 12 Jun 2017 14:27:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487BA128990 for ; Mon, 12 Jun 2017 14:27:40 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DE187C403A4 for ; Mon, 12 Jun 2017 16:27:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497302857; bh=+2V41wZeB4BpzmBo1NwqXxxeVffXsXGW5TxT3uFeZ/s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=LeTNqn0D8ctlIoc9C0fEtbJnPXslNCJfIbalwg3CyFr83Gjiod0fbqD85z9alKBVo 1gKb5EzAJUmRygHarWDBAGKAkUYhQbgHDe2kAyOaRAbZhJajMUx/pb6NL2HvGYFU03 VwS/5P8PXpi2uAj9VGKTM44gP3m6XI7DlAAsytGo= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 12 Jun 2017 17:27:37 -0400 Message-ID: <1963682.inTv7VmKVJ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> <4379310.8G0EpGEsGj@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:27:42 -0000 On Monday, June 12, 2017 01:57:30 PM Murray S. Kucherawy wrote: > On Mon, Jun 12, 2017 at 7:29 AM, Scott Kitterman > > wrote: > > > > I also really don't understand why we have a discussion about if a > > > > draft > > > > > > should be adopted before a WG adopts it if we just get to re-have the > > > > same > > > > > > discussion periodically. > > > > > > You think working groups should not be allowed to revisit their choices? > > > > You think working groups should have a bi-weekly periodic on revisiting > > choices? > > > > We haven't been chartered long enough for that hyperbole to have any > basis. I believe this is only the first time such a change has been > proposed. If this is going to be the discussion any time someone hints at > revisiting a choice we've made about a document, this working group is > going to take a really long time to finish. > > Of course choices can be revisited, but if decisions aren't at all > > > sticky, then there's no way to make progress. > > To be sure, once consensus is reached on something, anyone who wants to > change it has the burden to justify the change by doing the work to shift > consensus. As a bonus, the weight of that burden generally gets heavier > the more time passes. > > But that's as "sticky" as it gets. The conversation is allowed to happen, > and attempts to stifle it are not appropriate. > > OK. Fair enough. I know I get grumpy sometimes. I also get over it. Moving on ... Scott K From nobody Mon Jun 12 14:39:54 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECF12EB58 for ; Mon, 12 Jun 2017 14:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 5RPr5LYDhH-g for ; Mon, 12 Jun 2017 14:39:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C457812EB64 for ; Mon, 12 Jun 2017 14:39:50 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 02A30C403A4 for ; Mon, 12 Jun 2017 16:39:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497303589; bh=jnm8oTPiyKFdNx2EJxnI4XdWTnz8u76Z89N1VlbwpJs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=0hq0kHD+jBW5tWvT87rS+D9OUobYCjLgS/biJ+pPLtrjve3Eq5G1f8Hfvery9Yn89 eJ53VQo9RLyPav+QjUs4P7NnTlHu5nDmeY7BEQfoTCHENc7k1LueJCwciovyJ/oYaa CWTx3uHilhCRZe8ZHrnF6Nped4jcODQtQfb7Qy/s= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 12 Jun 2017 17:39:48 -0400 Message-ID: <17424575.60yUzU31nn@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 21:39:53 -0000 On Monday, June 12, 2017 01:54:57 PM Murray S. Kucherawy wrote: > Hatless: > > On Mon, Jun 12, 2017 at 7:41 AM, Martin Thomson > > wrote: > > On 12 June 2017 at 15:32, Scott Kitterman wrote: > > > The way to do that would be to remove it from the protocol, which you > > > seem to oppose, so I'm confused. > > > > I don't oppose removing it from the protocol in practice, it's just > > that you can't pretend that the old version doesn't exist, and nor > > should you care. The point is to not USE it, the definition becomes > > harmless at that point. > > +1. I've thought about this some more. And the more I think about it, the less I like it. Here are the currently defined DKIM result names from the IANA Email Authentication Result Names registry[1]: > dkim neutral [RFC7601] section 2.7.1 active > dkim none [RFC7601] section 2.7.1 active > dkim pass [RFC7601] section 2.7.1 active > dkim permerror [RFC7601] section 2.7.1 active > dkim policy [RFC7601] section 2.7.1 active > dkim temperror [RFC7601] section 2.7.1 active What's the proper result for a rsa-sha1 signed message that passes DKIM verification? It's not 'none', because it's still a valid signature. I hope it's not 'pass' since there's no way to communicate it should not be relied on. If we really want to approach it this way, there needs to be a new result, something like pass-but-ignore (since downstream consumers will rely on a pass). This seems like a horribly recipe for confused implementation for exactly no benefit. If anyone is sending exclusively rsa-sha1 signed mail (I don't have access to a reasonable corpus to have an opinion on the rarity) they're ignoring a SHOULD NOT that dates back to the very first DKIM RFC a decade ago. I would really appreciate it if someone in favor if keeping rsa-sha1 would describe, in detail, what the authentication-results header field is supposed to look like for this "it's valid DKIM, but don't rely on it" approach. Scott K [1] https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names From nobody Mon Jun 12 16:25:33 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2D128799 for ; Mon, 12 Jun 2017 16:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 Qd_uyNeD0fn7 for ; Mon, 12 Jun 2017 16:25:30 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CF1126DC2 for ; Mon, 12 Jun 2017 16:25:30 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id t31so76507339ota.1 for ; Mon, 12 Jun 2017 16:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uHUePGPeb8uUqgko191a4v120ISGvV6id7g0ROZiu/8=; b=FnIKivaMynKWeHSFVZAXFHeSeNUswOc85vOQIxcITCG2+Lk/H4Dy5MG3jkGPjsAcN1 13sJa3jpuMstg7DUDROqufr5vGD1r9eYCpTxvbxA2+52cKVxn+8LwvQBZQrlpoy65PgG dXfRZXpU7EayDNG3aFLdhflf2XO8yf0eShIKu7MiqFT8gDAmHlLhknH7SnnnCa0CUYAz VLCuP4mX3rdbhiLBq0oO0oT8v3hnugBTo9NUALQDzC85SvZlmvy2J/3FJltJJZegLX/X s/79Y3JDz1MUVrsY+tYJZKJziRe6X7mgU7BT0ESUvGw/SuKRcZGHdMuK6PhB1mCpoTQp 7PdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uHUePGPeb8uUqgko191a4v120ISGvV6id7g0ROZiu/8=; b=M4sRAvx8nUu0oDpMrPNfwymmRaceEOCAI80noW3tle+ejJtgPU/RHXSgM5lk0m+NLI Jx2xBVeeMI3Uf5m2L8nh6C9RJErbd95wbxf8EVoonyZqwOnCW5RhXmgSaeeVhqntgOYw 5xmaYu8pOt86Bk7fw6ScuaDgt7o6QuGXH65VxaxrA64oYf1YWMLwWcBc998AyIs1MqDv LXEOCoTjx1vuRH3dCci2DJ7W1uvo9OY+q6cJDVtpE045EdfkjggAuG69CVRg9fyo7bwE h+O7H+kZElorQBcjGUFqjHt+j9phYEjtWn+ifgcEgnYm77CxeTCSDv8sH2kP+imfcCuB qWhQ== X-Gm-Message-State: AODbwcBpjZGwA+naXjI9Cx3cIgUi4CGqGPgvIY4Lf2Mv4x6ru6H+ZFYU YjnUMSUAVb3Yi0EXUHIMRwxVyPNTlldC X-Received: by 10.157.48.158 with SMTP id s30mr31240389otc.255.1497309929411; Mon, 12 Jun 2017 16:25:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Mon, 12 Jun 2017 16:25:28 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Mon, 12 Jun 2017 16:25:28 -0700 Message-ID: To: James Cloos Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f4030435ae5c7693810551cba2a9" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:25:32 -0000 --f4030435ae5c7693810551cba2a9 Content-Type: text/plain; charset="UTF-8" It would be good to know where the source is, ie if its say the default in opendkim or something, then hopefully a change to that would eventually hit these. We don't currently log the algorithm, guess we can change that to take a look. Brandon On Mon, Jun 12, 2017 at 2:00 PM, James Cloos wrote: > I looked at a corpus of email from this year. 3265010 emails, > including all of spam, good automated and good from humans. > > The vast majority of the latter were deliverred via mailing lists. > > Just under half (1443757) had a dkim sig. > > The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces > to about 6.270:1. > > So there is a ways to do before sha1 signers disappear. > > Nonetheless, I still agree that the update should deprecate sha1. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --f4030435ae5c7693810551cba2a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It would be good to know where the source is, ie if its sa= y the default in opendkim or something, then hopefully a change to that wou= ld eventually hit these.

We don't currently log the = algorithm, guess we can change that to take a look.

Brandon

On Mon, Jun 12, 2017 at 2:00 PM, James Cloos <cloos@jhcloos.com>= ; wrote:
I looked at a corpus of e= mail from this year.=C2=A0 3265010 emails,
including all of spam, good automated and good from humans.

The vast majority of the latter were deliverred via mailing lists.

Just under half (1443757) had a dkim sig.

The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces
to about 6.270:1.

So there is a ways to do before sha1 signers disappear.

Nonetheless, I still agree that the update should deprecate sha1.

-JimC
--
James Cloos <cloos@jhcloos.com&= gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenPGP: 0x997A9F17ED7DAEA6

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--f4030435ae5c7693810551cba2a9-- From nobody Mon Jun 12 16:31:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9ED129AA8 for ; Mon, 12 Jun 2017 16:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 TpGTevlu-7Oq for ; Mon, 12 Jun 2017 16:30:58 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61B5129A9F for ; Mon, 12 Jun 2017 16:30:57 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id k145so52050187oih.3 for ; Mon, 12 Jun 2017 16:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=105PLoFiSHMKL76dU6rJmyjGObYURehTAPttLMtJPnc=; b=PS89tf7ZoWbNGbVr9m6t0h9JIryzSp3YduclZ7eC2qXTB+nOyYUQakm69vyGEaix9b 4lFXZAXYO7kgKJzJAQbWIf1LXlKkSWKSdUotnU/9Iiu0U0oOjoAeR8IuvbSd3nkxuN1L jKv/b9zQyjNGmsk+gAP93cuDss3rdK24X23hK9ZQf8/kaGwsqfgctuL5/V5NpCZvNll7 cGin1Y88H6iyKxccw0UnAEf/X5tnILZFGPtm1QheIYEnh+Qday2rpT8EikBDSxTcjGCV 8MIy6Xd2PYg49XsLgAcHhVkvNQyQzf++qnnUkWNP68zBmyija/0W7Cr/trrFW+DYT/hG k9ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=105PLoFiSHMKL76dU6rJmyjGObYURehTAPttLMtJPnc=; b=c+yDcq3YlJhX+9DZ3J4lSg5Nd7yh58+F8MVyBodEbn3ZiRzB3bjo1UnXUNuzP+1tWw b+EkAXGiUD/XRJyrKudPfubvOU8G41xLQsbZnmgE0vxEXps2ekFCAsmofzvBWK3laJtY 7ymT2oJ4XYTDkaBPleRXPy04XnQSWsCq9J+k+Qn6n/W++dTe5LBhLsm+Js8t8fvQQ0AI KDXtjbzVla1iIa/zleTlhH0N3atMV2gYSCzeboSaCOoKO9IVjnxJm8p2jVxV1oiufqD9 xlCJRYojfuPfDd7P4X5Rx125OiaAvaZWz3XCKwk9vZT/qXWv+odRiG5fI2yLof1Tp6HL GnPA== X-Gm-Message-State: AODbwcCRKmuuL0tDonpAisPwcVu0u0/vo7GsHgcX2krjUNOmT9bnFBEL KAAJ50CRS/z7Boe7TclwYDF64QNJNE3y0c8= X-Received: by 10.202.102.221 with SMTP id m90mr27663168oik.177.1497310257154; Mon, 12 Jun 2017 16:30:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Mon, 12 Jun 2017 16:30:56 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Mon, 12 Jun 2017 16:30:56 -0700 Message-ID: To: James Cloos Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1140fb64ff75380551cbb576" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:31:00 -0000 --001a1140fb64ff75380551cbb576 Content-Type: text/plain; charset="UTF-8" hm, dmarc reports don't report the algorithm either, though I'm not sure if that's generally useful enough to add that. On Mon, Jun 12, 2017 at 4:25 PM, Brandon Long wrote: > It would be good to know where the source is, ie if its say the default in > opendkim or something, then hopefully a change to that would eventually hit > these. > > We don't currently log the algorithm, guess we can change that to take a > look. > > Brandon > > On Mon, Jun 12, 2017 at 2:00 PM, James Cloos wrote: > >> I looked at a corpus of email from this year. 3265010 emails, >> including all of spam, good automated and good from humans. >> >> The vast majority of the latter were deliverred via mailing lists. >> >> Just under half (1443757) had a dkim sig. >> >> The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces >> to about 6.270:1. >> >> So there is a ways to do before sha1 signers disappear. >> >> Nonetheless, I still agree that the update should deprecate sha1. >> >> -JimC >> -- >> James Cloos OpenPGP: 0x997A9F17ED7DAEA6 >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > > --001a1140fb64ff75380551cbb576 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hm, dmarc reports don't report the algorithm either, t= hough I'm not sure if that's generally useful enough to add that.

On Mon, Jun 1= 2, 2017 at 4:25 PM, Brandon Long <blong@google.com> wrote:
It would be good to know w= here the source is, ie if its say the default in opendkim or something, the= n hopefully a change to that would eventually hit these.

We don't currently log the algorithm, guess we can change that to take= a look.

Brandon

On Mon, Jun 1= 2, 2017 at 2:00 PM, James Cloos <cloos@jhcloos.com> wrote:
I looked at a corpus of email from this ye= ar.=C2=A0 3265010 emails,
including all of spam, good automated and good from humans.

The vast majority of the latter were deliverred via mailing lists.

Just under half (1443757) had a dkim sig.

The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces
to about 6.270:1.

So there is a ways to do before sha1 signers disappear.

Nonetheless, I still agree that the update should deprecate sha1.

-JimC
--
James Cloos <cloo= s@jhcloos.com>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenPGP: 0x997A9F17E= D7DAEA6

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a1140fb64ff75380551cbb576-- From nobody Mon Jun 12 16:32:37 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5033912EB84 for ; Mon, 12 Jun 2017 16:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c6NPJUGEL6Ik for ; Mon, 12 Jun 2017 16:32:33 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC87129A9F for ; Mon, 12 Jun 2017 16:32:33 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id y70so17291381vky.3 for ; Mon, 12 Jun 2017 16:32:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3rLDoKI0XgaeQsZXKjXDi4/lK0H/yV/XwyLdu+960pQ=; b=bXVR9p3MvrA7TeQnDMzmJEjzuxYgfFrQYPg45QuKwJkVRagt9xh9Hhn63E/1P7OfMN jVk5lPwNGt13UjVaP9pZ4XzgonL+4bZxa1L/xrGjRqoQceHBAoH50+CYVxuiT4I18p0q X6M0tzFBVMn/jlTTfPRe+dn44LoTdSUkkbI6q647RkQd4Pbt5Cusfx3IfZWho375bs32 +2Yw51t/c3zsTGAXKDyX01HUQGJVgFu40MsrRDScZes9XdolkkqVCkdc1Fy3Sb1mmxzl 2KAJMEHRX96ll18tpNb77ScjLEZid/cb/5p1nkhUPQMK4UPCB88BiKoDko1LAV5euysC 013Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3rLDoKI0XgaeQsZXKjXDi4/lK0H/yV/XwyLdu+960pQ=; b=bwAcgtcGMQOMxLSUh16T+sd4+krK6Zjv1jzOeGLIGWql9d3fSDMuVL0/Qtvth5SZqZ ceV/rOjrs0PR2PrqyFX6ApQp4A/zbOkosQnMk5Z47S4pKJJaDpwzhOUaz6bFgLVxxX0j bi+DI1IkCwTsE49Y+9aI3zQEXLctbTNQ5RhlrfIc+Zj3CDfJsTmr4OWEdJxdU9NTFyK0 g4HKPZcZW037+KrgBFgJL8lcD+iwucAPwwwTlafCcBA9w+C2HbVoalpa8wb5pldjzLPQ IjLhiLAo0eX4a62cj/hZNotVKRIpCj9lZm5q680fy6Go7pCZkjKbPrvHC774VXqM8Me9 RmnQ== X-Gm-Message-State: AODbwcCF7Yw5/T3XaLh5WdJ6BfOomz/Fe2r+Q2GSG3GW4qjSvg39N0TD 8jDcEXx7FtcyZHxTVQwi7fw5RyTgjQ== X-Received: by 10.31.96.150 with SMTP id u144mr21123443vkb.124.1497310352759; Mon, 12 Jun 2017 16:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Mon, 12 Jun 2017 16:32:32 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Mon, 12 Jun 2017 16:32:32 -0700 Message-ID: To: Brandon Long Cc: James Cloos , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114e24a2b1e0360551cbbb2a" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:32:35 -0000 --001a114e24a2b1e0360551cbbb2a Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 4:25 PM, Brandon Long wrote: > It would be good to know where the source is, ie if its say the default in > opendkim or something, then hopefully a change to that would eventually hit > these. > > We don't currently log the algorithm, guess we can change that to take a > look. > If OpenDKIM was compiled against OpenSSL 0.9.8e or later, it supports both rsa-sha1 and rsa-sha256 and defaults to the latter. Otherwise, it only supports rsa-sha1, because that's the only thing it can support with an older OpenSSL. -MSK --001a114e24a2b1e0360551cbbb2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 12, 2017 at 4:25 PM, Brandon Long <blong@googl= e.com> wrote:
It would be good = to know where the source is, ie if its say the default in opendkim or somet= hing, then hopefully a change to that would eventually hit these.

<= /div>
We don't currently log the algorithm, guess we can change tha= t to take a look.

If OpenDKIM w= as compiled against OpenSSL 0.9.8e or later, it supports both rsa-sha1 and = rsa-sha256 and defaults to the latter.=C2=A0 Otherwise, it only supports rs= a-sha1, because that's the only thing it can support with an older Open= SSL.

-MSK
--001a114e24a2b1e0360551cbbb2a-- From nobody Mon Jun 12 16:35:49 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4F8128B8E for ; Mon, 12 Jun 2017 16:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 D4x3s6xR7pUb for ; Mon, 12 Jun 2017 16:35:46 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B82127BA3 for ; Mon, 12 Jun 2017 16:35:46 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id e11so21417304oia.2 for ; Mon, 12 Jun 2017 16:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+BtIOAHSmC653Ys9VxTJkDqBSfb7DeNCszlAADVgs28=; b=iyDdGTw2Nu1y6GW4Ra2dLmeV1+cWAoSDM/ztRAgfICsSYQ5LRHOYCO9/NyYGnhNYal eXT9TxjVcC0F0lUDWz2MpNpdMxahdv2tJ8EMJbu4LQcMrk/U7gQ+nqNDB2UAr0Jh4i5a QJGcvFyy0wfVK1qTBl7LE8adgueoMEGsT4lllxe3YCGnCJcZbxNkoXpRH2sYYVrr7uZq hyZj8iUUEsnTyn0/treU4eoIAPfa+w29ur001RMTYIUB01MYqtUB2RRXUdoHRbx4XmUp IcjStL8sJG3bfaz2ks6PrKHjb3unZKWkV4mQ57BXAkitWgtc2aulxcgv8bFcUtAjl2jG pOqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+BtIOAHSmC653Ys9VxTJkDqBSfb7DeNCszlAADVgs28=; b=c9+6D2x1j2Tuc6cHBNid1tVoRcJ0EVBXiQ47RgrISIfSLnwDrKdepO0X2lydjGJyFi TUMR2xe0rwQB89GQoTMw0MHrIqon5s8gkyRRI/pA7V3aOLKyYBFBffilYzauU+AK7OLG JHMs587Ty26eQIehA3Q6Q14Hq1wL5ywHoaYuZfCiJv1Dzd4OewfQQv9HZbHVI1rCNtse uL9j4hUUKAKPTagxaxme2sDyEXm3Sv7c4fJ6VHNYmx7SUlSNbUpxkkfh019T3zp2TJve pSSKJlvZbl2M+JPtzuhJ2ZUCcX2BGwow8YfkgjrNxIzfBYRsL4UKdw2RcMJNZtrszYI0 16YA== X-Gm-Message-State: AKS2vOxfP1cRTUywnJbYSpPwGia8rxRHB4T1EsTqE4ljaO3HOWqfe/Rv p6KFZYuUG0IqEAExJyDQZHWBg2xc7qfX X-Received: by 10.202.219.134 with SMTP id s128mr42363oig.133.1497310545613; Mon, 12 Jun 2017 16:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Mon, 12 Jun 2017 16:35:45 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Mon, 12 Jun 2017 16:35:45 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: James Cloos , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113d30e030fa670551cbc7d9" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:35:48 -0000 --001a113d30e030fa670551cbc7d9 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 4:32 PM, Murray S. Kucherawy wrote: > On Mon, Jun 12, 2017 at 4:25 PM, Brandon Long wrote: > >> It would be good to know where the source is, ie if its say the default >> in opendkim or something, then hopefully a change to that would eventually >> hit these. >> >> We don't currently log the algorithm, guess we can change that to take a >> look. >> > > If OpenDKIM was compiled against OpenSSL 0.9.8e or later, it supports both > rsa-sha1 and rsa-sha256 and defaults to the latter. Otherwise, it only > supports rsa-sha1, because that's the only thing it can support with an > older OpenSSL. > and if people are still using openssl 0.9.8d or earlier... expectations of updates will be low/slow Brandon --001a113d30e030fa670551cbc7d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 4:32 PM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Mon, Jun 12, 2017 at 4:25 PM, Brandon Long <blong@g= oogle.com> wrote:
It would be good to know where the source is, ie if its say the = default in opendkim or something, then hopefully a change to that would eve= ntually hit these.

We don't currently log the algori= thm, guess we can change that to take a look.
=
If OpenDKIM was compiled against OpenSSL 0.9.8e or la= ter, it supports both rsa-sha1 and rsa-sha256 and defaults to the latter.= =C2=A0 Otherwise, it only supports rsa-sha1, because that's the only th= ing it can support with an older OpenSSL.

and if people are still using openssl 0.9.8d or earl= ier... expectations of updates will be low/slow

Br= andon=C2=A0
--001a113d30e030fa670551cbc7d9-- From nobody Mon Jun 12 16:51:30 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9DF129447 for ; Mon, 12 Jun 2017 16:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 t8eNJE-I3HNL for ; Mon, 12 Jun 2017 16:51:27 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1FCE129426 for ; Mon, 12 Jun 2017 16:51:26 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CA053C403A4; Mon, 12 Jun 2017 18:51:25 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497311485; bh=YRRaTqsa6GvNZ/DS0TcBiiRogAaHDBiLf1ikfQlCb9Y=; h=Date:In-Reply-To:References:Subject:To:From:From; b=a+MsiWq5Hmx3aCBSUKeiCNeVUnS2nyzwDcihpME8+Wg1NjN6frcYV8jyEbLDTuuI+ MQInmCmiPYls2BHS1wn0ZfQhq9Z1XMGYHUDdU1qCy8Ks7eFZkKx7Cy24bUkHqKRB9S ffcW4wzegM07fqwz2MFAS8eAHowksm00OaxbPUcw= Date: Mon, 12 Jun 2017 23:51:24 +0000 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <5B2CFEEC-9A44-4368-A6BE-24CDF69D01C0@kitterman.com> Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 23:51:29 -0000 How are messages that are signed with both rsa-sha1 and rsa-sha256 counted?= For this purpose they should be in the rsa-sha256 pile=2E Scott K On June 12, 2017 7:25:28 PM EDT, Brandon Long wrote: >It would be good to know where the source is, ie if its say the default >in >opendkim or something, then hopefully a change to that would eventually >hit >these=2E > >We don't currently log the algorithm, guess we can change that to take >a >look=2E > >Brandon > >On Mon, Jun 12, 2017 at 2:00 PM, James Cloos wrote: > >> I looked at a corpus of email from this year=2E 3265010 emails, >> including all of spam, good automated and good from humans=2E >> >> The vast majority of the latter were deliverred via mailing lists=2E >> >> Just under half (1443757) had a dkim sig=2E >> >> The ratio of rsa-sha256 to rsa-sha1 was 1244650:198495 which reduces >> to about 6=2E270:1=2E >> >> So there is a ways to do before sha1 signers disappear=2E >> >> Nonetheless, I still agree that the update should deprecate sha1=2E >> >> -JimC >> -- >> James Cloos OpenPGP: 0x997A9F17ED7DAEA6 >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dcrup >> From nobody Mon Jun 12 17:13:08 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD54129407 for ; Mon, 12 Jun 2017 17:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com 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 HHikOfmXfEjM for ; Mon, 12 Jun 2017 17:13:05 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 EB1EA128DF3 for ; Mon, 12 Jun 2017 17:13:04 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id D83021E4FC; Tue, 13 Jun 2017 00:13:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1497312783; bh=z44tDp3QxtVxFqJauXGjVa56cWzNA95HO3tK3k20rNc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=zZgQK69Vk7Qz2aySRwhJLIQy6L68Gc7mRjmJHtrIC24qD89LLNdZbDKnwhjlvg/3n xlc+EYO5ZBqvzdSPKzAuepwDGO0QVpPnIl6aBNEQCP79Pa3rcsf8GG3hchAhnqTDP+ KSD1pCwG4adBDHvevIAAUIIffLIVzE9/6SlaqSXxz2RcC4HX7u2WCYzOrxv/nAdz2a dblxE+/XBh8PojT6Jf2MOXSc7lsQVNHNYPSNC67NsEgJr+lEgfoe/K5uC5NsaS93z3 3ZD/Y+CEEMR14TDqLr+HcjSH83kF17yl4XNoIviPOb+i9ev7aQY2yXjl0+Kgpk1TXT IxwFm0jnIEFnQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7FCD4107AC440; Tue, 13 Jun 2017 00:10:15 +0000 (UTC) From: James Cloos To: Brandon Long Cc: dcrup@ietf.org In-Reply-To: (Brandon Long's message of "Mon, 12 Jun 2017 16:25:28 -0700") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2016 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Mon, 12 Jun 2017 20:10:15 -0400 Message-ID: Lines: 41 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170613:blong@google.com::RAGIV58mmdtOhv0f:5KgnN X-Hashcash: 1:28:170613:dcrup@ietf.org::4qSPHa4IQsPaHobA:00nA3I5 Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 00:13:07 -0000 >>>>> "BL" == Brandon Long writes: BL> It would be good to know where the source is When calculating those, I grep(1)ed for /^DKIM-Signature:/. 195704 sha1 dkims which had their d= on that line. The result of: :; grep sha1 dkim-lines|tr \ \\n|grep ^d=|sort|uniq -c|sort -nr|head is: 55567 d=gcc.gnu.org; 46147 d=github.com; 32100 d=sendgrid.me; 28126 d=sourceware.org; 6865 d= 4560 d=listbox.com; 1980 d=pobox.com; 922 d=zx2c4.com; 891 d=itsqueeze.com; 661 d=travis-ci.org; The gcc.gnu.org ones are from the mailing lists @gcc.gnu.org, including the automated ones like gcc-testresults and gcc-bugs. For github, roughly half were a=rsa-sha1 and half a=rsa-sha256. I found a sha2 example from 2017/02/14 and a sha1 from 2017/02/15. The sha1 included a Received line referencing sendgrid between the ones referencing github itself. Getting those top four fixed would reduce significantly the sha1 cases. In all, there were 4217 distinct d= lines in the a=rsa-sha1 subset. But, again, the counts ignored cases where the a= and/or d= were not on the first line of the DKIM-Signature: header. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Jun 12 23:41:26 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCEA129B4F for ; Mon, 12 Jun 2017 23:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 Fdx1EwJpA_Zc for ; Mon, 12 Jun 2017 23:41:23 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C671129571 for ; Mon, 12 Jun 2017 23:41:23 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id w1so157324308qtg.2 for ; Mon, 12 Jun 2017 23:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=C7bt7UuNEw4I9ShYY4ZRMRphkRwPf6lwcECtGQHQnd8=; b=BKEzc2U4o/XAZV60UmHqvyoDIhucwZslgw7oCW0J7FG5If8K5kU2HYOgp8tq/ZPb7U CGe7oSJBSdq/Q60OuK7HYUCZqwDuXXiQ6+mQa7x+JUMunJzQxuICZlC99FpO4rcfAo83 HzVXL7icP87DWR6Wj6KiIlDRVP2u1YJMCkn02E2MqdWvsjjJMO5YsK+Nv0C9ROFefMSz 2w0FcvmTcgg5KcZ/aojwM71xjavUndAJ7am1spGluu3HokfCv+nD6mYz1iAnmDTAQPLT C5pUodKiuVvqDMu46GXK/eJU0ejzGnxSoWxx4gbs6rVQA2lYMLOTOD/HM+INfsYU2A1t jVlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=C7bt7UuNEw4I9ShYY4ZRMRphkRwPf6lwcECtGQHQnd8=; b=WOm30ri11P9PaPG249WHRQU1vw5XRydqAkeyVoamL5xPKxovhAvvkUxKSN6VkqVIrN x7aSDZqjD0EhvGyglCSOR2NYFOTNf0opj67fSjPZdpufyameRDTsza6Wb1d/I5Kas/Kf jkqyxBY1m203K0Hv2bctOKc52awX6k3KMXqUrv3I/uT4bI/W5UQOVNSn3PA9m7SfXAKJ oChXI/FSgwsWMc4jshBR8XAuQoHVLQfKr/2AeA5pqMU+WBm5ExdogGEcwtuBsM7plwEj zT4NYUB3viYr4/Qdxl4p8ooi7jcFlhMNEYUql/gdwo6HpOusLOKGNacHJR2ELvhTPn4T zmRA== X-Gm-Message-State: AKS2vOwLw4Nbny4xR9dQiilC01587UYL1A+Q8Qr6PPW/D40R93GYphFt FThVnRUoWFNQT4NeS6Hmy8akoMO3IvRaCVzMSQ== X-Received: by 10.55.138.71 with SMTP id m68mr48718935qkd.192.1497336082037; Mon, 12 Jun 2017 23:41:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.165 with HTTP; Mon, 12 Jun 2017 23:41:21 -0700 (PDT) In-Reply-To: References: From: Peter Goldstein Date: Mon, 12 Jun 2017 23:41:21 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0767ee47ed0c0551d1b9f3" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 06:41:26 -0000 --94eb2c0767ee47ed0c0551d1b9f3 Content-Type: text/plain; charset="UTF-8" When looking at the global usage of SHA-1, it's important to note that several of the largest email service providers still use rsa-sha1 signatures. I don't necessarily want to call out any companies on this list, but there are at least 3 large ESPs that in aggregate send billions of messages per day that are DKIM signed with rsa-sha1 (and only rsa-sha1). Getting this small number of ESPs to change to rsa-sha256 will fix this problem for email sent from a very large number of domains. On the referenced corpus I'm pretty sure it would address both the d=github.com and d=travis-ci.org signed messages. And I suspect it would represent a much larger fraction of rsa-sha1 signed email in the average email user's inbox. One of the valuable services that DCRUP can provide is demonstrating to these ESPs that SHA-1 support is actively being deprecated, and that they will need to make the shift to rsa-sha256 to ensure future deliverability. It's M3AAWG this week, and I'm planning on having that conversation with several folks from companies that are using rsa-sha1, to encourage them to make the change sooner rather than later. Similarly, I'd suggest that participants in mailing lists that are signing with rsa-sha1 reach out to the mailing list administrators and encourage them to make this change. Best, Peter On Mon, Jun 12, 2017 at 5:10 PM, James Cloos wrote: > >>>>> "BL" == Brandon Long writes: > > BL> It would be good to know where the source is > > When calculating those, I grep(1)ed for /^DKIM-Signature:/. > > 195704 sha1 dkims which had their d= on that line. The result of: > > :; grep sha1 dkim-lines|tr \ \\n|grep ^d=|sort|uniq -c|sort -nr|head > > is: > > 55567 d=gcc.gnu.org; > 46147 d=github.com; > 32100 d=sendgrid.me; > 28126 d=sourceware.org; > 6865 d= > 4560 d=listbox.com; > 1980 d=pobox.com; > 922 d=zx2c4.com; > 891 d=itsqueeze.com; > 661 d=travis-ci.org; > > The gcc.gnu.org ones are from the mailing lists @gcc.gnu.org, including > the automated ones like gcc-testresults and gcc-bugs. > > For github, roughly half were a=rsa-sha1 and half a=rsa-sha256. > I found a sha2 example from 2017/02/14 and a sha1 from 2017/02/15. > The sha1 included a Received line referencing sendgrid between the > ones referencing github itself. > > Getting those top four fixed would reduce significantly the sha1 cases. > > In all, there were 4217 distinct d= lines in the a=rsa-sha1 subset. > > But, again, the counts ignored cases where the a= and/or d= were not on > the first line of the DKIM-Signature: header. > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 <(415)%20793-5783> --94eb2c0767ee47ed0c0551d1b9f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
When looking at the global usage of SHA-1, it's i= mportant to note that several of the largest email service providers still = use rsa-sha1 signatures.=C2=A0 I don't necessarily want to call out any= companies on this list, but there are at least 3 large ESPs that in aggreg= ate send billions of messages per day that are DKIM signed with rsa-sha1 (a= nd only rsa-sha1).

Getting this small number of ES= Ps to change to rsa-sha256 will fix this problem for email sent from a very= large number of domains.=C2=A0 On the referenced corpus I'm pretty sur= e it would address both the d=3Dgithub.com and d=3Dtravis-ci.org signed message= s.=C2=A0 And I suspect it would represent a much larger fraction of rsa-sha= 1 signed email in the average email user's inbox.
One of the valuable services that DCRUP can provide is d= emonstrating to these ESPs that SHA-1 support is actively being deprecated,= and that they will need to make the shift to rsa-sha256 to ensure future d= eliverability.=C2=A0 It's M3AAWG this week, and I'm planning on hav= ing that conversation with several folks from companies that are using rsa-= sha1, to encourage them to make the change sooner rather than later.=C2=A0<= /div>

Similarly, I'd suggest that participants in ma= iling lists that are signing with rsa-sha1 reach out to the mailing list ad= ministrators and encourage them to make this change. =C2=A0

<= /div>
Best,

Peter

On Mon, Jun 12, 2017 at 5:10 PM, Jam= es Cloos <cloos@jhcloos.com> wrote:
>>>>> "BL" =3D=3D Br= andon Long <blong@= google.com> writes:

BL> It would be good to know where the source is

When calculating those, I grep(1)ed for /^DKIM-Signature:/.

195704 sha1 dkims which had their d=3D on that line.=C2=A0 The result of:
:; grep sha1 dkim-lines|tr \=C2=A0 \\n|grep ^d=3D|sort|uniq -c|sort -nr|hea= d

is:

=C2=A0 55567 d=3Dgcc.gnu.org;
=C2=A0 46147 d=3Dgithub.com;
=C2=A0 32100 d=3Dsendgrid.me;
=C2=A0 28126 d=3Dsourceware.org;
=C2=A0 =C2=A06865 d=3D
=C2=A0 =C2=A04560 d=3Dlistbox.com;
=C2=A0 =C2=A01980 d=3Dpobox.com;
=C2=A0 =C2=A0 922 d=3Dzx2c4.com;
=C2=A0 =C2=A0 891 d=3Ditsqueeze.com;
=C2=A0 =C2=A0 661 d=3Dtravis-ci.org;

The gcc= .gnu.org ones are from the mailing lists @gcc.gnu.org, including
the automated ones like gcc-testresults and gcc-bugs.

For github, roughly half were a=3Drsa-sha1 and half a=3Drsa-sha256.
I found a sha2 example from 2017/02/14 and a sha1 from 2017/02/15.
The sha1 included a Received line referencing sendgrid between the
ones referencing github itself.

Getting those top four fixed would reduce significantly the sha1 cases.

In all, there were 4217 distinct d=3D lines in the a=3Drsa-sha1 subset.

But, again, the counts ignored cases where the a=3D and/or d=3D were not on=
the first line of the DKIM-Signature: header.

-JimC
--
James Cloos <cloo= s@jhcloos.com>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenPGP: 0x997A9F17E= D7DAEA6

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup



--
=
=


=

<= img src=3D"https://lh5.googleusercontent.com/2H5o4IUaWTQg0CyrwoJc9mFj0TcbJM= MCWaIZWc5tSI-3Y7NtaSXWVY5jyaxa8eEuXkbx_liH2_QV_IcQWNAs2nN07sRNDvA5OSd06XWJi= IcMKW24c8dRvUh4xr33iC_CMgHzgODr" width=3D"239" height=3D"61" style=3D"borde= r: none;" alt=3D"logo for sig file.png">

Bringing Trust to Email

Peter Goldstein | CTO & Co-Fou= nder

peter@valimail.com

+1.415.793.5783<= br>
=
--94eb2c0767ee47ed0c0551d1b9f3-- From nobody Tue Jun 13 00:50:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A84129BA8 for ; Tue, 13 Jun 2017 00:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 f0HyEIqm3-Jb for ; Tue, 13 Jun 2017 00:50:10 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52281129B98 for ; Tue, 13 Jun 2017 00:50:10 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id c10so159815648qtd.1 for ; Tue, 13 Jun 2017 00:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=qxnmqvX0OLNDJH++c//HGWJFooL+m9Qmy+GbZfkkzuc=; b=fWh7uYmdE79v9I0g43IPByI2z8Ya1nxUvUfUNPj415L8HjiJZm9pwzNl4E0M0TD25p hEERAnBhcW/OGvaAGH1lNE/FEPXl2E+c6SzzHN8Pm1MLBXaC9QJgf1BPD/o9wR20mezR KH0uvehgFMYZNaPQ3WWBx3d8PlPQBx+YfrIMQOV7gAJQT7x5Fs0/njrFO8iuoI2T73Kw XvX5lxyMhFZcQ2k8SeeUOkoTdg53lFu6TSSPBNaeVGqvEZfZdHPAnca4K0YTNk/t9wOH ne5MZKFnCo23fYuCHWMqb2zYdUcn66JRgn4tZhlfFJfbpneu7S+oovnsjwKO9AfDqKmf U7HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=qxnmqvX0OLNDJH++c//HGWJFooL+m9Qmy+GbZfkkzuc=; b=L48VnqhE3sKAnbnF8RemfdO0gaWtJvfcf7bNNaDL13P7n4rgOobYQWExcp5zOrmYdX O+jnfKR9/ZziqGQ3g2poFQ+ANfY1Xdox+5DTkMHKljVt41wiG+8XAOQDbocPKLWWA2NK CZaMwbKcyULUNXlq7FbsLsbc0FjyXPw0rYWLZxGfrstAYhYzhk6hNYLpTMRf78f0Gu/a chjoETG1skzqHYxUg3xwtjhebO5s7yALr+5tVbfQzz2inOc8LrglbDTl2vuGNgMmPHKd ic/GQdsvCoFJwSX1XHqyOZaYlM8KK8IvLjOBvgL3gaY3mWrRKxPEuVZ0gk4H4G6eQFjb 4eWA== X-Gm-Message-State: AODbwcAEi/aMvONEdQvY+0HghkAdRheZuPyPB2qTy2ASxdYKMf/L2jPJ +iHKqj9Nm+DW51J9guzqNd0QiLPFMT6VBHU= X-Received: by 10.200.55.148 with SMTP id d20mr53103468qtc.94.1497340209303; Tue, 13 Jun 2017 00:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.43.27 with HTTP; Tue, 13 Jun 2017 00:49:48 -0700 (PDT) In-Reply-To: <4379310.8G0EpGEsGj@kitterma-e6430> References: <20170610002538.10992.qmail@ary.lan> <2034638.szbv6KSWyz@kitterma-e6430> <4379310.8G0EpGEsGj@kitterma-e6430> From: Seth Blank Date: Tue, 13 Jun 2017 08:49:48 +0100 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1146449c48a3ca0551d2af0c" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 07:50:17 -0000 --001a1146449c48a3ca0551d2af0c Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 3:29 PM, Scott Kitterman wrote: > If I knew which of the three approaches to take, then I could pick one and > write it: > > 1. Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MUST > NOT > rsa-sha1 (my personal preference) > > 2. Fully replace section 3.3 dropping rsa-sha1 and just giving the new > requirements (possibly with an appendix that says MUST NOT rsa-sha1) > > 3. Make the draft a lot shorter and only state updated requirements. Also > don't remove rsa-sha1 [1] > I think #2 is the cleanest for a lot of reasons, but I'm sympathetic to the argument about the RFC making it clear what has changed to an implementer reading it and this has persuaded me, If the point of this document is to get implementers who have been using sha-1 and weak keys to throw them out - #1's language accomplishes this explicitly. So I'm voting for #1. --001a1146449c48a3ca0551d2af0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jun 12, 2017 at 3:29 PM, Scott Kitterman <sklist@kitterman.com= > wrote:
If I knew which of the= three approaches to take, then I could=C2=A0 pick one and
write it:

1.=C2=A0 Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MU= ST NOT
rsa-sha1 (my personal preference)

2.=C2=A0 Fully replace section 3.3 dropping rsa-sha1 and just giving the ne= w
requirements (possibly with an appendix that says MUST NOT rsa-sha1)

3.=C2=A0 Make the draft a lot shorter and only state updated requirements.= =C2=A0 Also
don't remove rsa-sha1 [1]

I think #2 is the cleanest for a lot of reasons, but I'm = sympathetic to the argument about the RFC making it clear what has changed = to an implementer reading it and this has persuaded me, If the point of thi= s document is to get implementers who have been using sha-1 and weak keys t= o throw them out - #1's language accomplishes this explicitly.

So I'm vot= ing for #1.

--001a1146449c48a3ca0551d2af0c-- From nobody Tue Jun 13 03:10:19 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E8D12F4B2 for ; Tue, 13 Jun 2017 03:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 ZkhPoxx1VBZL for ; Tue, 13 Jun 2017 03:10:13 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABA41314C9 for ; Tue, 13 Jun 2017 02:53:23 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 68so54633170uas.0 for ; Tue, 13 Jun 2017 02:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3GWXK9k8FyVJHF4zy44x520AGYzx0cxwKDFHEQ+Ym7I=; b=MqP9hkUh41nScsGWQIvvcQLphh0GsemlQ1UojMxG2K+0JvM4uSc90+B3obrIzTATAm H8+3xFCx7gYKddos18hVFjGic6wY4uAKOEISkYHLGQSju5uTlm272VTupF6ruXzy6fDb Ueq6mo40HtF8klV+88m2RLNawxqyDy6q9ek1s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3GWXK9k8FyVJHF4zy44x520AGYzx0cxwKDFHEQ+Ym7I=; b=ARdT4BgK2i1X/XNt2+0gxtj2XjKhru6H3Mk3Y8SnbNalbpeQCXgjQM1q6WT8yebApJ eEw9BPyF+quc0vmxUFu3sb/fioHUYZz6Gy477CV4hnOm58r8QkqNxVRcnRGH1OzpeEVO y6WnkeYgt9x8lTd/1EzXcLuIyIqNBKDcIaPYEQGUQHCp3YCL17qWmRylbE2U3mIVtW8v gyNLSKXicOHVAyc02LVDA+WUt4ONESQ3MC9QDkCRwy6128dKORgFpnxNFh/dY/20Kn8A 10SREcfpB08td4UEyY/gWshpLFUhz03u6OI1Wk0IPDQ8j/KzchgoNvb9mKmOJ5/xnh97 LvJw== X-Gm-Message-State: AKS2vOy+Cjp0ul4lK3qy6IzeKZ1RTzxLhXOktKvIIV8I/RakMtVE/FDm BQHVZi2Wx/yE3UZom7hgikTJtySye5CSI3s= X-Received: by 10.176.82.26 with SMTP id i26mr2108300uaa.1.1497347602425; Tue, 13 Jun 2017 02:53:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.75.153 with HTTP; Tue, 13 Jun 2017 02:53:21 -0700 (PDT) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> <2034638.szbv6KSWyz@kitterma-e6430> <4379310.8G0EpGEsGj@kitterma-e6430> From: Kurt Andersen Date: Tue, 13 Jun 2017 10:53:21 +0100 Message-ID: To: Seth Blank Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18ff88f2c0300551d467d4" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 10:10:18 -0000 --94eb2c18ff88f2c0300551d467d4 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 8:49 AM, Seth Blank wrote: > On Mon, Jun 12, 2017 at 3:29 PM, Scott Kitterman > wrote: > >> If I knew which of the three approaches to take, then I could pick one >> and >> write it: >> >> 1. Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MUST >> NOT >> rsa-sha1 (my personal preference) >> >> 2. Fully replace section 3.3 dropping rsa-sha1 and just giving the new >> requirements (possibly with an appendix that says MUST NOT rsa-sha1) >> >> 3. Make the draft a lot shorter and only state updated requirements. >> Also >> don't remove rsa-sha1 [1] >> > > I think #2 is the cleanest for a lot of reasons, but I'm sympathetic to > the argument about the RFC making it clear what has changed to an > implementer reading it and this has persuaded me, If the point of this > document is to get implementers who have been using sha-1 and weak keys to > throw them out - #1's language accomplishes this explicitly. > > So I'm voting for #1. > I'd much prefer approach #2, but rather than "replace in place", the replacement should point to a registry with the details in the registry subject to expert review for future updates. The initial population of registry entries should designate sha1 and rsa keys <1024bits as either "not supported" or "deprecated" or whatever other terminology conveys the same message in registry-speak. --Kurt --94eb2c18ff88f2c0300551d467d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 8:49 AM, Seth Blank <seth@valimail.com> = wrote:
On Mon, Jun 12, 2017 = at 3:29 PM, Scott Kitterman <sklist@kitterman.com> wrote:=
If I knew which of the three approaches = to take, then I could=C2=A0 pick one and
write it:

1.=C2=A0 Fully replace section 3.3 explicitly saying MUST rsa-sha256 and MU= ST NOT
rsa-sha1 (my personal preference)

2.=C2=A0 Fully replace section 3.3 dropping rsa-sha1 and just giving the ne= w
requirements (possibly with an appendix that says MUST NOT rsa-sha1)

3.=C2=A0 Make the draft a lot shorter and only state updated requirements.= =C2=A0 Also
don't remove rsa-sha1 [1]

I think #2 is the cleanest for a lot of reasons, but I= 'm sympathetic to the argument about the RFC making it clear what has c= hanged to an implementer reading it and this has persuaded me, If the point= of this document is to get implementers who have been using sha-1 and weak= keys to throw them out - #1's language accomplishes this explicitly.

So I= 9;m voting for #1.

I'd much= prefer approach #2, but rather than "replace in place", the repl= acement should point to a registry with the details in the registry subject= to expert review for future updates. The initial population of registry en= tries should designate sha1 and rsa keys <1024bits as either "not s= upported" or "deprecated" or whatever other terminology conv= eys the same message in registry-speak.

--Kurt=C2= =A0
--94eb2c18ff88f2c0300551d467d4-- From nobody Tue Jun 13 03:55:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF14129BC5 for ; Tue, 13 Jun 2017 03:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ufOp5nT6m94N for ; Tue, 13 Jun 2017 03:55:38 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615821315D0 for ; Tue, 13 Jun 2017 03:50:45 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id m77so42923455lfe.0 for ; Tue, 13 Jun 2017 03:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JqdeLs+hZoaKAs+tMaQSDscY8Dk7KW/3sK1O+jXdqfo=; b=QDxkm5CWSidM5OkE+R1LcSWrI8HqoBAVhObI2naycSG/H+Ey1Z3GLdGSPgdTdzdYrY G/MWyiQWT0gd/sBGVG59Npeb/9lAFKTdxSmWrT3nQp1jeB9pwuCU2oMvGwRkFVHWyBdC nVrfFKMVT2OjmXk1YqfmJQSzsN5L0gbE1CdMtV8Re2CMlCJfC0DXm+Bj/kBPpiEHFdjZ n3AanVxHd4tFrGy48SZ9tbbCauJycR2ZGhnsYU3VtanaJO8DnE5YIkjlQod2u5cia2AS Oag5H2SqCTadYDIZkAt5Qu8e+zZd2LUsZZDjfluSk4HuAg56Yb+y2nPWVrutMfg4Hxes DtJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JqdeLs+hZoaKAs+tMaQSDscY8Dk7KW/3sK1O+jXdqfo=; b=gfRwAKMqvfCIcM3QEzRVK8KXezGohjfmJACdQAr7owr/fHgZsokdCRKjk1Gl8W+HuY SfJrhRGsCQWsY2qO47E+v71r5/V/5duhABnMWyrlsIqUz01WtKor3T4+aBolCS9wC89k zZlyuk/ZBDMI/9iFUxQZYw1Xxu/rPg6C4ZccrOMI91hAnVYkWUFiZtJM861zn0S9nPiS fXVeILleVFVGV2aorF6ezJyaI7vept2sIDBMYXtgmhtxpTfd6XRTVW1v66XamSQFNeRw /529wY2R0jWUaDWnmHYPwWiUNzvvrci4vqqTOOlxNMV1o1mZ30+jmECfDve3iFY2GN0/ pTRw== X-Gm-Message-State: AKS2vOzMffVsPh5aDiWuObtu10R7aZLRwUvPQN1qhtu+ppvYFCXvGvJ9 lc7WrT2WvjqbLGvYsYX3oecyEL0XEw== X-Received: by 10.25.145.19 with SMTP id t19mr1996282lfd.130.1497351043657; Tue, 13 Jun 2017 03:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 13 Jun 2017 03:50:42 -0700 (PDT) In-Reply-To: <90199bb8f57a4539ad5c6ef506a943ae@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <1828951.1dWPTdrTAp@kitterma-e6430> <90199bb8f57a4539ad5c6ef506a943ae@usma1ex-dag1mb1.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 13 Jun 2017 11:50:42 +0100 Message-ID: To: "Salz, Rich" Cc: Scott Kitterman , "dcrup@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 10:55:39 -0000 On 12 June 2017 at 16:05, Salz, Rich wrote: >> The reason I suggested this is that your current draft doesn't >> *actually* include any new advice about key sizes. > > Does it have to in order to be useful? I don't think so. The introduction implies that there is advice (see the last paragraph). There is text on key sizes, but it is copied verbatim from 6376 as far as I can see, that is why the question arose. From nobody Tue Jun 13 03:57:42 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A454313162E for ; Tue, 13 Jun 2017 03:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wbimoGC49XZv for ; Tue, 13 Jun 2017 03:57:37 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9135E130A94 for ; Tue, 13 Jun 2017 03:52:44 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id m77so42961058lfe.0 for ; Tue, 13 Jun 2017 03:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lASmMSZvUHtXs7fv5AG1oXEISrEL/sTVLMmmeseiplg=; b=o0WezCM6vjbdl4Srtc0LjoRLuNuXajtA9+rbrr/cHtoME39BdOLwY4+uAdoJuCh7qB Jl2wOBkci94c3KzMIVv4z5unTaV2jPUNtnUaI5SNOdyl7Ls/D3k7M6OqiLq/+dg4J6WG aTItbcM6r1tPF2VR5++Gu1WCwUHqFhDnlH4jPjR+eCpwwEXYfJ3KA1MVbGQpjdH7mbQZ yZghgwzKYLWJ7UhXIxdXOb94XlcMKpwM0pZrCvITJe6gaKgP0JH016qO2yGMLzPlqcjy Ghd1xlR5CAqq+9Td2v5IWB2TwFLda7SatOMJgXi5GL/fL1XVSjFtQfXetkI3U+FSDAIl R2Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lASmMSZvUHtXs7fv5AG1oXEISrEL/sTVLMmmeseiplg=; b=E4zX49g6fVkwGVNbOO7wrgwEIQVmDQ1+mTjSpqlHgL0/S9VzQ+EaT+SxIXIC1DjLsB tl88PkQn28I4C8FaQDze2xNbR7oiu3qSrliJyL3kfGsnc4gbg2rJAl8TfSTICfZhVucF wD8aJ9qXmk5Wdsq900EzmL/NLpyf8jzCE3q8GDlhOhjt2kiTjJslfVeMMGXk/xXHNtH8 K3GR/L6KKN5eEI/H9s7iWCu7F0bsuhaYsxL0J22c1Pv9fse5kPkJy0iOufejO+1H7z7a BjlDLFVB7zd9qqs9brML5umTvNRv0KarduDl5+vwCUuVNY/lniMynD8NWZ+aswLsXjX7 Lrng== X-Gm-Message-State: AKS2vOxw1yt7RW4zPpMtov/k+KK53nC8v4RTcnmfv0Gtle4TwSZe88W5 migszkz+EnLRwomvyhZ4bhvoqjAD46xb X-Received: by 10.25.196.17 with SMTP id u17mr2712168lff.19.1497351162810; Tue, 13 Jun 2017 03:52:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 13 Jun 2017 03:52:42 -0700 (PDT) In-Reply-To: <17424575.60yUzU31nn@kitterma-e6430> References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <17424575.60yUzU31nn@kitterma-e6430> From: Martin Thomson Date: Tue, 13 Jun 2017 11:52:42 +0100 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 10:57:42 -0000 On 12 June 2017 at 22:39, Scott Kitterman wrote: > What's the proper result for a rsa-sha1 signed message that passes DKIM > verification? Oh, I see where you are coming from. I think that you need text that says "an rsa-sha1 signature MUST be ignored by a verifier". I think that answers the questions about "rely on" more clearly. From nobody Tue Jun 13 04:01:33 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F718131621 for ; Tue, 13 Jun 2017 04:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Od3myUXJTcLl for ; Tue, 13 Jun 2017 04:01:30 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FAD1316B8 for ; Tue, 13 Jun 2017 03:57:12 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id v20so67889679lfa.1 for ; Tue, 13 Jun 2017 03:57:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9xoTIKRPMI4807X+vBFaQhCDq/hKwYErSX8RAlkA/+M=; b=M1ekgfsOt48Ot6T1lNAqr4SHsCUuN9pxFFK+ttA5ogaM3W8fl3kTmIgiJ5cxJT3hN/ 518gU+TVP4Uddt6eLnsZBSncaw1hxJtDC9ud/SRzw0vyPQDRmiX5F/n0UXFiaBdBvMXL 8yjUiOV6l2XoVI8/4lfIOvyTKD4nncsvYXJl3HBIYvNMv1bt58Gto3sMRTytVUVupoJI /5a3sLpKZG1mwRYDJ+XMG7CvWI3iA7uuUMQMf0RzPLgu5uIfMcm7/B4TCHfk+Run5ELD f0BQCL6RStGQwBTsA+iQSHTq0YxiwCnYTsVtGL0yWXOHRLi/Pl8UXkliD1srEO5tMhHL SvyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9xoTIKRPMI4807X+vBFaQhCDq/hKwYErSX8RAlkA/+M=; b=iHVzojO7POpKdBAw6QrwzuQKk3GTZPw3Gf2Xb0nsvXgiGqj4fEUG9qCsQRTkWubVhN RDkGVvAoe+PCAf8RPpNBRe1XBjDBvSSuxvsTpdZrgVG+VRGLM1o5Xncx4yoIC6b7f+i9 DfJ7ESlImZ5HWxCNUld2P9C8HCz1M/CLQpqGKKGWyvIL6fdZjQvBP10xwqI3DTHKS9x8 2Gd1Bu9U0NKTKwxQc2D1W5xxGs3phHmoUKwYr1Zmfzhzf9tstfA6bExEBMi8j2Y8WMcU NE+qQLwzxrPpGSVp9aJLTX8mNJBQFHZRMZ7savZC+k8MCiivT/3JiwRFXJHxisTYHMCh iKJQ== X-Gm-Message-State: AODbwcCDW834N05Ly6el/BNCg5uHdhlsdCZ8Wy6vhr/2WQIHhMQMMORb nTyw5VKZZXVSzHbWdRLt7726Rz9tCg== X-Received: by 10.46.81.89 with SMTP id b25mr17704173lje.33.1497351431342; Tue, 13 Jun 2017 03:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 13 Jun 2017 03:57:10 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 13 Jun 2017 11:57:10 +0100 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] combo update draft-ietf-dcrup-dkim-crypto-01 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:01:32 -0000 On 12 June 2017 at 16:07, John R Levine wrote: >> This description could be made generic so that (for example) PQ >> schemes could use this. > > No, my goal is to make the minimum changes needed. The more options, the > more chances not to interoperate. That's fine with me. From nobody Tue Jun 13 04:30:55 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D29131688 for ; Tue, 13 Jun 2017 04:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 GKzh1ssgqkDx for ; Tue, 13 Jun 2017 04:30:48 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E6AF1315EB for ; Tue, 13 Jun 2017 04:30:48 -0700 (PDT) Received: (qmail 58520 invoked from network); 13 Jun 2017 11:30:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Jun 2017 11:30:47 -0000 Date: 13 Jun 2017 00:21:17 -0000 Message-ID: <20170613002117.1367.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: kurta@drkurt.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-crypto-02 and registries X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 11:30:54 -0000 In article you write: >I'd much prefer approach #2, but rather than "replace in place", the >replacement should point to a registry with the details in the registry >subject to expert review for future updates. The initial population of >registry entries should designate sha1 and rsa keys <1024bits as either >"not supported" or "deprecated" or whatever other terminology conveys the >same message in registry-speak. Take a look at my draft. There already is a registry for hash algorithms, and mine moves sha1 to historic. There's no registry for key sizes, and creating one would be tough. For RSA, you can create a key with as many bits as you want. You want a 1775 bit key, you can use a 1775 bit key. I'd rather keep the advice about key size in the text since the alternative would seem to be to list every key size from 512 to whatever and mark them individually good or bad. For the elliptic algorithms, there's no choice of key size so nothing to put in a registry. R's, John From nobody Tue Jun 13 05:05:33 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723F51317E7 for ; Tue, 13 Jun 2017 05:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 gldjkkPZUGRN for ; Tue, 13 Jun 2017 05:05:30 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 902E01317A1 for ; Tue, 13 Jun 2017 05:05:30 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DC32xt019180; Tue, 13 Jun 2017 13:05:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lHPoDRIjbv5eIOUECngDUwJiP9CWrd3GnrpkVymMsrg=; b=o3rU3JZwhH8vJ4G/O0T47QS6mVrHxKPuYqBUvFIBvYcorIMBHaga6cDQgO+8RehQ0Y+t PunvkE/RZoI1G6st9Qgh/X/AQsnpPu54FI+HRB1Qy5I2ijB5k96f4rOQZFUmGG9UOeON 8XM8JxQ2eS5w2ChhLyfytdGVU2b1Nh8H7eMr0gDgajC46EGksDZFW+oQfm7EabBW4sUk gnGohPeC/s5YXnyxpOiqFxoUQDjJjKyq6TOvG4OFhRgbhZbOKblv53CyQbFDCN/4UwTL S63nbMblf7jnNkaZ1qsw6LKJNEDQOspQ1/t3zr/tZf0PHAOMx+3tokANAVpfcJ6ihZZW Ww== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b1vnrwpmq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 13:05:27 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DC1KX0001145; Tue, 13 Jun 2017 08:05:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3uhy3q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 08:05:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 13 Jun 2017 08:05:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 13 Jun 2017 08:05:26 -0400 From: "Salz, Rich" To: Peter Goldstein , "dcrup@ietf.org" Thread-Topic: [Dcrup] rsa-sha1 usage Thread-Index: AQHS4779Tb5v0bLckEm+niEmYG2uC6IiIeoA///KSQ2AAK9/gIAAFrbg Date: Tue, 13 Jun 2017 12:05:25 +0000 Message-ID: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.130] Content-Type: multipart/alternative; boundary="_000_5bf52517591d4950aec335d31bcf3631usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130213 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130213 Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 12:05:32 -0000 --_000_5bf52517591d4950aec335d31bcf3631usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYSBuZXdjb21lciB0byBES0lNIChJIGNvbWUgZnJvbSB0aGUgY3J5cHRvIHNpZGUgb2YgdGhp bmdzKSBJIGFtIGEgYml0IGNvbmZ1c2VkLg0KDQpDZXJ0aWZpY2F0ZXMgbGFzdCBmb3IgYSBjb3Vw bGUgb2YgeWVhcnMsIGFuZCBzbyB0aGVyZSB3YXMgYSBzdHJvbmcgbW90aXZhdGlvbiB0byBtb3Zl IG9mZiBNRDUgYW5kIHRoZW4gU0hBMSwgYmVjYXVzZSBvZiB0aGUgY29uY2VybiB0aGF0IHNvbWVv bmUgd291bGQgZmluZCBhIGNvbGxpc2lvbiBhbmQgY3JlYXRlIGEgYm9ndXMgY2VydGlmaWNhdGUg ZHVyaW5nIHRoZSBvcmlnaW5hbCBjZXJ04oCZcyBsaWZldGltZS4NCg0KQnV0IEnigJl2ZSBoZWFy ZCB0aGF0IERLSU0g4oCcdHJ1c3QgbGlmZXRpbWXigJ0gaXMgbXVjaCBzaG9ydGVyLiAgSXMgaXQ/ ICBXaGF0IGlzIHRoZSBleHBlY3RlZCBsaWZldGltZSBmb3IgcmVseWluZyBvbiBhIERLSU0gc2ln bmF0dXJlPw0K --_000_5bf52517591d4950aec335d31bcf3631usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgYSBuZXdjb21lciB0byBES0lN IChJIGNvbWUgZnJvbSB0aGUgY3J5cHRvIHNpZGUgb2YgdGhpbmdzKSBJIGFtIGEgYml0IGNvbmZ1 c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5DZXJ0aWZpY2F0ZXMgbGFzdCBmb3IgYSBjb3VwbGUgb2YgeWVh cnMsIGFuZCBzbyB0aGVyZSB3YXMgYSBzdHJvbmcgbW90aXZhdGlvbiB0byBtb3ZlIG9mZiBNRDUg YW5kIHRoZW4gU0hBMSwgYmVjYXVzZSBvZiB0aGUgY29uY2VybiB0aGF0IHNvbWVvbmUgd291bGQg ZmluZCBhIGNvbGxpc2lvbiBhbmQNCiBjcmVhdGUgYSBib2d1cyBjZXJ0aWZpY2F0ZSBkdXJpbmcg dGhlIG9yaWdpbmFsIGNlcnTigJlzIGxpZmV0aW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CdXQgSeKAmXZl IGhlYXJkIHRoYXQgREtJTSDigJx0cnVzdCBsaWZldGltZeKAnSBpcyBtdWNoIHNob3J0ZXIuJm5i c3A7IElzIGl0PyZuYnNwOyBXaGF0IGlzIHRoZSBleHBlY3RlZCBsaWZldGltZSBmb3IgcmVseWlu ZyBvbiBhIERLSU0gc2lnbmF0dXJlPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_5bf52517591d4950aec335d31bcf3631usma1exdag1mb1msgcorpak_-- From nobody Tue Jun 13 06:13:29 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9412EAA4 for ; Tue, 13 Jun 2017 06:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9L0DYkkZDC1h for ; Tue, 13 Jun 2017 06:13:25 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CAE1129503 for ; Tue, 13 Jun 2017 06:13:25 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id y70so25230315vky.3 for ; Tue, 13 Jun 2017 06:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SwoY+UVYKaOuDqHlXmT7JGflg5rWkXTxQskaErY/4n4=; b=rbVPjFbwnM1yLcDlNqMptjnXWia6AvZSquH6BAA1w1wfKjQTKlKI/J0+w58hJSAjXs tVzp2X3QCtYWAYN0x+iHk0rFFM2e3+DDFlWtAitHYUiIT82Pfdb0nPPXj0Tn5c77hXJ0 dH+gorfVgNLHFvtf6qgp9sBH67qywD57K2622QShxoQzGoFgTc8EYRsTfHOkxtTQ3lyW 4UjPNRmLUieRVmo1sNJHEfKrkhyArpFJoe3esv3bVcFeH5RgQfXF61mfHKmWIP1qJ945 ZcxGm71CmmlJSLf4lf9CTy6gxEBw8XeUCJz3OXRSbyaMRJxD0qZ+G6bJhcBclfCacXUI pLNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SwoY+UVYKaOuDqHlXmT7JGflg5rWkXTxQskaErY/4n4=; b=ana9z+cpEVB15jHdL8japORhEmerTI6oEYbF5aFI7agRLt78Ye/OR6CRa5CF/GwCwl rAN25LTtei9DbmGRIgy8egegdJ93FkYlZ8kwilOtW5vvmdQ6ZiCNArvCqYw3R0ys0A8p QO01MYqD8u3O2lFC29dB9YaA5k4JIO63SGz+w7T2Jgtqcfxoa6BODLJgBMNcQqx6xAIC CDSCWTFp7h4ICbv8eyDTKGsdGiGsqV1xS07y4OQ5NwYo/9Vtd9C5S738MyWY0DTddhvB DLwAmjJQr6Mrtb3sWYJT8U3p167wB9cYRQ41zpDlhGQthKJC96HytbEkNu6He38NKxGF pHuw== X-Gm-Message-State: AODbwcD7P3oBvlH1CiWPhSyY/6ouzrjgYCYn6j1lV+4/Di6DpQjeV4cs iSe6gwh79oDUNoc6QWhEAV1QEr7/HGE68sM= X-Received: by 10.31.173.134 with SMTP id w128mr19344273vke.125.1497359604432; Tue, 13 Jun 2017 06:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Tue, 13 Jun 2017 06:13:23 -0700 (PDT) In-Reply-To: References: <20170610002538.10992.qmail@ary.lan> <2034638.szbv6KSWyz@kitterma-e6430> <4379310.8G0EpGEsGj@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 06:13:23 -0700 Message-ID: To: Kurt Andersen Cc: Seth Blank , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1143f0ce52c61d0551d7333e" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage and document shepherds X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:13:27 -0000 --001a1143f0ce52c61d0551d7333e Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 2:53 AM, Kurt Andersen wrote: > I'd much prefer approach #2, but rather than "replace in place", the > replacement should point to a registry with the details in the registry > subject to expert review for future updates. The initial population of > registry entries should designate sha1 and rsa keys <1024bits as either > "not supported" or "deprecated" or whatever other terminology conveys the > same message in registry-speak. > We have such a registry, here: https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml Look for "DKIM Hash Algorithms". We just need to mark "sha1" as "deprecated" or some such. This doesn't cover key sizes, but that was discussed elsewhere. I still don't think that belongs in a registry as a bare parameter. -MSK --001a1143f0ce52c61d0551d7333e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 2:53 AM, Kurt Andersen <kurta@dr= kurt.com> wrote:
I'= d much prefer approach #2, but rather than "replace in place", th= e replacement should point to a registry with the details in the registry s= ubject to expert review for future updates. The initial population of regis= try entries should designate sha1 and rsa keys <1024bits as either "= ;not supported" or "deprecated" or whatever other terminolog= y conveys the same message in registry-speak.
=

--001a1143f0ce52c61d0551d7333e-- From nobody Tue Jun 13 06:21:13 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B579F131857 for ; Tue, 13 Jun 2017 06:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CCZmnMbZlfPl for ; Tue, 13 Jun 2017 06:21:10 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 477471314F8 for ; Tue, 13 Jun 2017 06:21:10 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 68so57709648uas.0 for ; Tue, 13 Jun 2017 06:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9/FF9vgo/AkyX+5sCEwFemY0JxliItxqi9f/EGx9uKg=; b=kbpqlKjv0FGkFmlVjNCcrpdFsDe71MQDOUEoOt90xktHEuvJQwn6v3xsLmo7kVIdMW BvC72KHeM/HrwxbKg7eKfJPW/W0+06P/4i0tJsOYIG5jsYu4pKAnZRzYLXdLMbvCC6WY haZiitD5EvGp7MAb5BB/G5YsYyIltXGmeMgwD1Tsj2FEkAZ+frTfkSPmi0QV3tEfoAyo AuWDv8lyj7d4i0TVws8c9kfda85p4MnGn1mpSXKJZJ1xQ5laEaV6Foa0lBVpC5h5f3YU Bvwr1bVUoR38EZiEqf+hLdN8aOSo+u8JkZKKBQvfE0yn+H6oF7TZaejTxb9IfQsQIdaq b2/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9/FF9vgo/AkyX+5sCEwFemY0JxliItxqi9f/EGx9uKg=; b=n0O/vJN+geA6DvQ+CH9/sF3cpDCfT/OeHM5bTgBE+Obug3Oq9MwB8HP/CeyLEaNJqU nvQv9Kh0VBBaOmLCP65cm21qfb3RAI6WqKVQ6dqVN/vDRA+nytKWVonAseni3xLzqDay y/cRi/lsHKGQdGhdiDicaKHlvcDPhffX94ihvu26L16FCBc6eG7+QiLeJetz0Elc3bDn vE8YFS/2S6UkciU8pEhUWwUkqke1AY8giamxUaayiPLT4UGyI0c1PbDUzQPy7ZWYF4rc kiK7pdwolMYsMRLXThiliQVub0HWH+wOGyW/ohq7wwxsuqBYiZKmLBtYeiuwBcTr86J6 TpkQ== X-Gm-Message-State: AKS2vOwtaCkLRdQgGYYw0qPAc+he+XB3DEHCoDzBfGnIbXlOslMwmlgI L+lfXshp2T2BihyHPxb4jiPRmgJV/LXC X-Received: by 10.176.0.248 with SMTP id 111mr2093083uaj.133.1497360069353; Tue, 13 Jun 2017 06:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Tue, 13 Jun 2017 06:21:08 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 06:21:08 -0700 Message-ID: To: Peter Goldstein Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113ac2d40928590551d74f76" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:21:12 -0000 --001a113ac2d40928590551d74f76 Content-Type: text/plain; charset="UTF-8" Hi Peter, On Mon, Jun 12, 2017 at 11:41 PM, Peter Goldstein wrote: > One of the valuable services that DCRUP can provide is demonstrating to > these ESPs that SHA-1 support is actively being deprecated, and that they > will need to make the shift to rsa-sha256 to ensure future deliverability. > It's M3AAWG this week, and I'm planning on having that conversation with > several folks from companies that are using rsa-sha1, to encourage them to > make the change sooner rather than later. > I think we should be careful not to assume that us issuing RFCs or updating IANA registries will compel the long tail to do anything. What will get them to change is receivers no longer accepting their signatures and affecting their mail's delivery, but our work here won't necessarily compel that either. We should say the right things in the right ways, and stop. -MSK --001a113ac2d40928590551d74f76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

On Mon, Jun 12, 2017 at 11:41 PM, Peter G= oldstein <peter@valimail.com> wrote:
One of the valuable services that DCRUP can provide is demons= trating to these ESPs that SHA-1 support is actively being deprecated, and = that they will need to make the shift to rsa-sha256 to ensure future delive= rability.=C2=A0 It's M3AAWG this week, and I'm planning on having t= hat conversation with several folks from companies that are using rsa-sha1,= to encourage them to make the change sooner rather than later.
<= /div>

I think we should be careful not to assume= that us issuing RFCs or updating IANA registries will compel the long tail= to do anything.=C2=A0 What will get them to change is receivers no longer = accepting their signatures and affecting their mail's delivery, but our= work here won't necessarily compel that either.

We should say the right things in the right ways, and sto= p.

-MSK
--001a113ac2d40928590551d74f76-- From nobody Tue Jun 13 06:32:17 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82B7128CDB for ; Tue, 13 Jun 2017 06:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c2mhO_1YAwdd for ; Tue, 13 Jun 2017 06:32:14 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B66212EAB1 for ; Tue, 13 Jun 2017 06:32:10 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id q15so75384889uaa.2 for ; Tue, 13 Jun 2017 06:32:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ziT//0n9Hyl3E+VOV3Al5b7F8HIPwigmyHOwreu0dfE=; b=eGbS++VBMmboffzGbfXysv8lN95GIz38kdhsVpdAdE0YCN0ozWYSKEvNAjc7+TS4G7 WaA+mYsiA1HoeVKajOXMo4b5M1w87OX7AcAeFicW52lY2Nba9qnbFbmSQ+QBGrUYEMKU kJVBq2AQuVIoEYATqnzeS0Rw00xJyeTv7dsoIpjxzDzZYPXw5OplbrdcNCuX+2Oa5BMs 9v5OpQ6mwVoewgD81360zz7BthwgHSnvGm1u33tYQQUEdMXW7qftBSAsYKGRF+Sx4Mdm WOs4o9alMJHTPY9HBIXC3KRM6jxVf5BLJUxzBl0B1UTi2ztLyKCfENEsrNUbjKb0i+sl Bqxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ziT//0n9Hyl3E+VOV3Al5b7F8HIPwigmyHOwreu0dfE=; b=lUsOFDAwfXZgzkfGD24VUlhVD2dIT1VulM+XEtno58DK3J7AGdcRZwbkGVJhjjjZ3p 5MDYJsx62i5Z3bdnKPam9OQoHoHy3i+eTakImqpuy4fn5S0qLdfPaqSDTjqkCnWRcVv2 38KnahBBNg9bMUyZ9wWHQMdpBvgJ+D8cSsdLX7L4/qr2UZGpMZAYeBvzlE9aGfhVfonF sML6K8PxuzllRFTTeJL0qv578ch6ZOWeedjM4Idu3+ySCYd1+GycR+yK5pU+NGOA0pGY yoFb6UITJcOXxYUytxtcfolfX9HyOQ+hgTz3kGVUXZLq2JAJL7AtlLEp+j53J6nbR0b0 5SOg== X-Gm-Message-State: AKS2vOwj9/IrG0sQc8xSJYEhGR5eQQRewwDN4uQpvfM7XkDotwBmiupX CNDt8v2GwzZI30RNL42vOEoG/CzaRA== X-Received: by 10.159.59.210 with SMTP id y18mr2557279uah.43.1497360729683; Tue, 13 Jun 2017 06:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Tue, 13 Jun 2017 06:32:08 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <17424575.60yUzU31nn@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 06:32:08 -0700 Message-ID: To: Martin Thomson Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a26d664bd460551d776e9" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:32:15 -0000 --94eb2c1a26d664bd460551d776e9 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 3:52 AM, Martin Thomson wrote: > Oh, I see where you are coming from. I think that you need text that > says "an rsa-sha1 signature MUST be ignored by a verifier". I think > that answers the questions about "rely on" more clearly. > If we really need to say something like this, I'd prefer to drop the MUSTard for previously given reasons. Suggest something like: "Since SHA1 is a deprecated hash algorithm generally, DKIM's 'rsa-sha1' algorithm is as well (see [John's draft] which changes its status in the IANA registry), and thus verifiers therefore ignore signatures that use this algorithm." -MSK --94eb2c1a26d664bd460551d776e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 3:52 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
Oh, I see where you are coming from.=C2=A0 I think that you need t= ext that
says "an rsa-sha1 signature MUST be ignored by a verifier".=C2=A0= I think
that answers the questions about "rely on" more clearly.

If we really need to say something like this, I= 'd prefer to drop the MUSTard for previously given reasons.=C2=A0 Sugge= st something like:

"Since SHA1 is a deprecated hash = algorithm generally, DKIM's 'rsa-sha1' algorithm is as well (se= e [John's draft] which changes its status in the IANA registry), and th= us verifiers therefore ignore signatures that use this algorithm."
=
-MSK
--94eb2c1a26d664bd460551d776e9-- From nobody Tue Jun 13 06:45:56 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A533D13150D for ; Tue, 13 Jun 2017 06:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DeV-ec9gLAC5 for ; Tue, 13 Jun 2017 06:45:53 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84031316D7 for ; Tue, 13 Jun 2017 06:45:51 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id p62so64384275vkp.0 for ; Tue, 13 Jun 2017 06:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xzktYTEybvr8ofBm5JiMEiE0H5G0Df6FW/vhODoU/Dc=; b=GBkNdAS+/MmrAWUVHJS2UwvtNLj0z14zSRLEkCZyCJNW0ilqjzmM9FVz/o+/g9WqBO llE2kNUQRvjHZCkV5ytniR5es4D235neX4I+AV+WtQNIqPGZWGZCFCfqgTvCPb4gA3XB hcRk7ojoQSo/9extE+Xk+DnU4FoKUA3GHsU3Ndp5frAbYd4lFzII4O+1piHP9DA0dxug wBbkeWGguIcReoGUknJX0UwxMRyAEqEFL6SREZw5LWBNhwTkhM3ZEm9hdtQl494ulycD HmPnaMV8S5iSNdybFD655MoVLXFUnOkR2LS3PCqdlgTQnoSGte37kMD2elyfZFOWv/Ad mB0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xzktYTEybvr8ofBm5JiMEiE0H5G0Df6FW/vhODoU/Dc=; b=dDlqRnUHUQYUjauGWwWSnWK+cBEAXJLTdmP7N8/8pUoc8LAtlta9zcRfdeFOQ574ZO SLPxlugY/8Q0f2YqTRWm7qOOjndh8Gjyf0V6vX2fkS9sKbrVfSUxT80cyox3CRRMcJm0 fuGJRWOWC9RYMt47EycRjodcPq8JFtQAnqL/4qsGPk4AZUGKlQXvoxNEcIToiKPs1Soj v3eDU3N7v6WITKRrLfpZ5E5LkW9sw5saEWbG4cXuxf11djXyBX2VZBZqeBMdjOjj7wf4 6YFW3ruZPrQxc9x8Uct1pLP2bG9afRBkV+7CM66f6vvMl8OPPTxmoKuEsJ6CMyCjpaPV 3aWg== X-Gm-Message-State: AODbwcARwrPWsFG7q39MSqwxtLGEEKSa7+J6e5Sedafs32c2+zv+hJj+ LVcjqLMOfYCK+xi2vAebpyrfwJND54Kc X-Received: by 10.31.3.100 with SMTP id 97mr27789577vkd.80.1497361550575; Tue, 13 Jun 2017 06:45:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Tue, 13 Jun 2017 06:45:50 -0700 (PDT) From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 06:45:50 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11428ab2528c750551d7a744" Archived-At: Subject: [Dcrup] Deprecating algorithms X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:45:54 -0000 --001a11428ab2528c750551d7a744 Content-Type: text/plain; charset="UTF-8" As a procedural matter, I looked at our charter and discovered that it doesn't explicitly allow us to deprecate "rsa-sha1". It only allows us to make new algorithms or ways to transport larger keys, and give revised advice about key sizes. For the sake of dotting and crossing everything I talked to Alexey and Eric and they don't imagine there would be a problem here, nor would it be a problem to adjust the charter accordingly. I'd prefer to have the charter tweaked so we're covered, and since doing so wouldn't interrupt our work flow, unless anyone objects I'm going to ask Alexey to start that process for us. -MSK --001a11428ab2528c750551d7a744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<chair>

As a procedural matter= , I looked at our charter and discovered that it doesn't explicitly all= ow us to deprecate "rsa-sha1".=C2=A0 It only allows us to make ne= w algorithms or ways to transport larger keys, and give revised advice abou= t key sizes.

For the sake of dotting and crossing everything I= talked to Alexey and Eric and they don't imagine there would be a prob= lem here, nor would it be a problem to adjust the charter accordingly.=C2= =A0 I'd prefer to have the charter tweaked so we're covered, and si= nce doing so wouldn't interrupt our work flow, unless anyone objects I&= #39;m going to ask Alexey to start that process for us.

</c= hair>

-MSK
--001a11428ab2528c750551d7a744-- From nobody Tue Jun 13 06:47:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540F413150D for ; Tue, 13 Jun 2017 06:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 uIvNwWxoZI_d for ; Tue, 13 Jun 2017 06:46:59 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0023126CBF for ; Tue, 13 Jun 2017 06:46:58 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id y70so25791684vky.3 for ; Tue, 13 Jun 2017 06:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qjzOP/TRGhXaXk3f5rFHZN1aUYTr+dA8mpUAgjSZaMs=; b=jxAX/8ZjxvyV4ZVppLRUINcDWJWWTv2HrJhaDZQqFdqwyTDRzPI1B0+XIhxTdr9m5e ZZNqZvzWTrToSG9PxI5rC3abTKFhGZPbpIuykCOGj3S+nlWJ252bov1xUE16L1S6llco O3K250P6UmROcNRS51Am2/s0cseCAdfWtgtl34dFx9umLnfmIuXidPILBxzQrf4y0oVg qRTmT9GmqDBg+UERawTO/IwIWP9iFUWtqmoGC1kMwSXInu5xPzLnDw3LbrSWmTt+dU83 UDURh7M1g9i097gd91PNN2nihDyu/pg9RVmH6YFik6vfRrCob/8nQz0UWzPEsG7G6J2G UCOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qjzOP/TRGhXaXk3f5rFHZN1aUYTr+dA8mpUAgjSZaMs=; b=Yoj92GZjaMhYCg0cI8swu5rzSuvQNuOtmRHI9T1y9VvdN22x/21ImTvQmhkVa3szRt yR9pIvZJOknogSYLjAT2PVHwxW7hzgRPy6/zzGrK4kVcO5PbX2yBBG0smKTbGTIbwuBO 8iAvVymverWW1Z2y9wFrq9dVyj1L7iG/GWVJ1/IOpA7/NlyhcUQdakXURAdne3Q5eMFv DNBEZwBp3NdkTQzFiRqsE1df6oQUV+CZvhJ+JbmdMO1w98SlfyocoZt5Q6F3YJdu3VCs 1bxpvH93jfi8CJIRP4rONCVPdfgohZ8QGD9hVdpEmIqwX9k40d2OP4OH7bH+slKy9oKl G/8g== X-Gm-Message-State: AKS2vOzOxBaVZDe8WzJLiWA3vn6gN8gnDitvgxwaG5DM0LVFue7Eqc2w 3y1WKAdrwmyytVJiVtfhNTbCs/lvDw== X-Received: by 10.31.190.145 with SMTP id o139mr3688927vkf.35.1497361618005; Tue, 13 Jun 2017 06:46:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.138.3 with HTTP; Tue, 13 Jun 2017 06:46:57 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <17424575.60yUzU31nn@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 06:46:57 -0700 Message-ID: To: Martin Thomson Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114399105772f00551d7aba8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 13:47:00 -0000 --001a114399105772f00551d7aba8 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 6:32 AM, Murray S. Kucherawy wrote: > "Since SHA1 is a deprecated hash algorithm generally, DKIM's 'rsa-sha1' > algorithm is as well (see [John's draft] which changes its status in the > IANA registry), and thus verifiers therefore ignore signatures that use > this algorithm." > Uh... we can vote on "thus" or "therefore". (*shame*) -MSK --001a114399105772f00551d7aba8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 6:32 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
"Since SHA1 is a deprecated hash algorithm general= ly, DKIM's 'rsa-sha1' algorithm is as well (see [John's dra= ft] which changes its status in the IANA registry), and thus verifiers ther= efore ignore signatures that use this algorithm."

Uh... we can vote on "thus" or "theref= ore".=C2=A0 (*shame*)

-MSK
--001a114399105772f00551d7aba8-- From nobody Tue Jun 13 07:32:25 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E131318B9 for ; Tue, 13 Jun 2017 07:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 phiShEeiVMg2 for ; Tue, 13 Jun 2017 07:32:22 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 2B9F512EAF5 for ; Tue, 13 Jun 2017 07:30:50 -0700 (PDT) Received: from splunge.local ([IPv6:2601:205:8302:79b1:dcef:c2d0:5748:b88a]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5DEUl8R013956 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 13 Jun 2017 07:30:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497364249; bh=ibnJ3/DRl0iZ5U0jjg4J2n+Mv8J34/6XKPS4KXC1QcM=; h=Subject:To:References:From:Date:In-Reply-To; b=rgFWogx2+H5hJhkwOrTzgoX45kpdXtd4N0tzXqhHV9MVwGCSrXD0oxAVOLfTdcTgQ GOC6AUmN2q4Dchf3WEuDrvktJFua+ekS1UySka1QPu6E9p242r8K1Q+exq2PX+YJr/ 3K0EAjtF5dAz6764o+E+DMZKtNAXCZjRKZyPwOyc= To: dcrup@ietf.org References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <17424575.60yUzU31nn@kitterma-e6430> From: Jim Fenton Message-ID: Date: Tue, 13 Jun 2017 07:30:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------131FFC37E66BD73F324423F0" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:32:24 -0000 This is a multi-part message in MIME format. --------------131FFC37E66BD73F324423F0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/13/17 6:46 AM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 6:32 AM, Murray S. Kucherawy > > wrote: > > "Since SHA1 is a deprecated hash algorithm generally, DKIM's > 'rsa-sha1' algorithm is as well (see [John's draft] which changes > its status in the IANA registry), and thus verifiers therefore > ignore signatures that use this algorithm." > > > Uh... we can vote on "thus" or "therefore". (*shame*) :) But "verifiers ignore signatures" doesn't seem like very good normative language. Are they required to (MUST) or is it a strong (SHOULD) or weaker (MAY) suggestion? Since we have seen that there are still a lot of rsa-sha1 signers out there, encouraging verifiers to ignore those signatures (and implementers not to provide rsa-sha1 verification), in the absence of something that is likely to be exploitable, flies in the face of interoperability. Cutting off verification is a lever that should be used only after having said that they SHALL not sign with rsa-sha1, and the current spec doesn't say that. -Jim --------------131FFC37E66BD73F324423F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/13/17 6:46 AM, Murray S. Kucherawy wrote:
On Tue, Jun 13, 2017 at 6:32 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
"Since SHA1 is a deprecated hash algorithm generally, DKIM's 'rsa-sha1' algorithm is as well (see [John's draft] which changes its status in the IANA registry), and thus verifiers therefore ignore signatures that use this algorithm."

Uh... we can vote on "thus" or "therefore".  (*shame*)

:)

But "verifiers ignore signatures" doesn't seem like very good normative language. Are they required to (MUST) or is it a strong (SHOULD) or weaker (MAY) suggestion?

Since we have seen that there are still a lot of rsa-sha1 signers out there, encouraging verifiers to ignore those signatures (and implementers not to provide rsa-sha1 verification), in the absence of something that is likely to be exploitable, flies in the face of interoperability. Cutting off verification is a lever that should be used only after having said that they SHALL not sign with rsa-sha1, and the current spec doesn't say that.

-Jim
--------------131FFC37E66BD73F324423F0-- From nobody Tue Jun 13 07:50:53 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B9813194B for ; Tue, 13 Jun 2017 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 zSO525yUrC1T for ; Tue, 13 Jun 2017 07:50:50 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 8AEA913194F for ; Tue, 13 Jun 2017 07:41:50 -0700 (PDT) Received: from splunge.local ([IPv6:2601:205:8302:79b1:dcef:c2d0:5748:b88a]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5DEfm6L014146 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 13 Jun 2017 07:41:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497364910; bh=ImdGLSJ9WHMmmv0QYr2CzUpycGwEz9Qtj/n7B3Ku/8U=; h=Subject:To:References:From:Date:In-Reply-To; b=ATh7GQBUBM5J3BPuSCUy+fZw4N9QxEj7y6HRLzJEHPdK8bSFpdjlqykNQO7I9L2LO Bf2LTYN722OlQ91OwB/7unjMnv22FnFXckEipUxe0T2janXAbHQGi/4Q/YmPwvz10H /hZczZw0r79Y8mBVPxGT88kB/eCMp/Q+kt5svGmY= To: dcrup@ietf.org References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jim Fenton Message-ID: Date: Tue, 13 Jun 2017 07:41:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------04FE1894F6A0F5978E32D881" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 14:50:52 -0000 This is a multi-part message in MIME format. --------------04FE1894F6A0F5978E32D881 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/13/17 5:05 AM, Salz, Rich wrote: > > As a newcomer to DKIM (I come from the crypto side of things) I am a > bit confused. > > =20 > > Certificates last for a couple of years, and so there was a strong > motivation to move off MD5 and then SHA1, because of the concern that > someone would find a collision and create a bogus certificate during > the original cert=E2=80=99s lifetime. > > =20 > > But I=E2=80=99ve heard that DKIM =E2=80=9Ctrust lifetime=E2=80=9D is mu= ch shorter. Is it?=20 > What is the expected lifetime for relying on a DKIM signature? > The expected lifetime is on the order of a week (message delivery timeout). But the signature doesn't have an expiration time, so if someone can construct a second message with the same hash, they could replay the signature, potentially much later if the public key is still in DNS. IMO it seems very unlikely, even with the known weaknesses in SHA-1, that in the near future someone would be able to construct such a message that would be exploitable by an attacker (e.g., spam or a phishing attack). That will likely change in the future, so we should tell signers to stop using SHA-1 ASAP and tell verifiers to stop accepting those signatures sometime later. If anyone knows something yet more serious about exploitability of rsa-sha1, please set me straight. -Jim --------------04FE1894F6A0F5978E32D881 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/13/17 5:05 AM, Salz, Rich wrote:

As a newcomer to DKIM (I come from the crypto side of things) I am a bit confused.

 

Certificates last for a couple of years, and so there was a strong motivation to move off MD5 and then SHA1, because of the concern that someone would find a collision and create a bogus certificate during the original cert’s lifetime.

 

But I’ve heard that DKIM “trust lifetime” is much shorter.  Is it?  What is the expected lifetime for relying on a DKIM signature?


The expected lifetime is on the order of a week (message delivery timeout). But the signature doesn't have an expiration time, so if someone can construct a second message with the same hash, they could replay the signature, potentially much later if the public key is still in DNS.

IMO it seems very unlikely, even with the known weaknesses in SHA-1, that in the near future someone would be able to construct such a message that would be exploitable by an attacker (e.g., spam or a phishing attack). That will likely change in the future, so we should tell signers to stop using SHA-1 ASAP and tell verifiers to stop accepting those signatures sometime later.

If anyone knows something yet more serious about exploitability of rsa-sha1, please set me straight.

-Jim
--------------04FE1894F6A0F5978E32D881-- From nobody Tue Jun 13 08:06:58 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEC5131A54 for ; Tue, 13 Jun 2017 08:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RZ_bBdXl3jEd for ; Tue, 13 Jun 2017 08:06:54 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF798131BB5 for ; Tue, 13 Jun 2017 07:52:24 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id p189so73721365lfe.2 for ; Tue, 13 Jun 2017 07:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dL1xyusLheZmdve8gWR/SAVG4GJr10ubLCrWSjJHJMs=; b=MTOmcs9Q6fRuY0uWNppI8KrivX8rYl9l9yBail47STu7gveSurKMbRjp/fkdBrozKv JxgBD6OuKvZG+DeyhT0iNOSIiVNLzHY9xOynt3TutZIRvvtiBldhSFDdPSIbZ9CfxO66 NYr2u7P8wsleA1dgg3xt9itRMUmCjANJLhbizCNWXXKMSGrisdz9X9NQSVpMe/NCDicB yJ5nvbChZtbWKTft+gls7pgppnkZ+0yeRLAKJbFK8OvLtmC63g/j6ySZ7HSEdJ0bKIYK 9mJQqky7AMwKKNMTWuH/xNYBZPPuTyBMKEFHn95PsWtTdW6YtPF5u12EmofWWPnrSY5G eNhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dL1xyusLheZmdve8gWR/SAVG4GJr10ubLCrWSjJHJMs=; b=OJ7LFkTMUznR68ABZlixVhYe0Jt+FhOBzH7OMau2AyVU5okDU2r7eg2JvquDsidiub NfyYMJMzysIpaugjdJu/X2Y00u/oqMw/Ep+wS1CxESVvfCV6alPLcJwGeMxiFE1B0xqZ bv1IEQo3uIDGCRBbqsaXDOVvmOyFzyYuBvyzTvcpFa4yanFTQZGffechpoO0zYrOHEV/ w5HmEeN96iLKRUU27zRnmRg+41WC2r1dlDZ5JTmtKWeCUUAYH5WXRRIMl2u6pcmzY5xH 49rJPnXIgHe6DjVbfxoaINxsWzjMXGFfFTfINUHJ6r+ZzRgOnY2qFyscIUlSV3tcEqM3 q7Lg== X-Gm-Message-State: AKS2vOxazTDD5brgZm0dvqQexxvZhXlUVSn8eQlZzqMkBZYODN0fP4jB QFZyg41onmP0d+c6X4idhXjNo0837A== X-Received: by 10.46.87.85 with SMTP id r21mr112706ljd.22.1497365543202; Tue, 13 Jun 2017 07:52:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Tue, 13 Jun 2017 07:52:22 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 13 Jun 2017 15:52:22 +0100 Message-ID: To: "Murray S. Kucherawy" Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Deprecating algorithms X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:06:57 -0000 This is a fine thing. Do you want to propose text for the charter? On 13 June 2017 at 14:45, Murray S. Kucherawy wrote: > > > As a procedural matter, I looked at our charter and discovered that it > doesn't explicitly allow us to deprecate "rsa-sha1". It only allows us to > make new algorithms or ways to transport larger keys, and give revised > advice about key sizes. > > For the sake of dotting and crossing everything I talked to Alexey and Eric > and they don't imagine there would be a problem here, nor would it be a > problem to adjust the charter accordingly. I'd prefer to have the charter > tweaked so we're covered, and since doing so wouldn't interrupt our work > flow, unless anyone objects I'm going to ask Alexey to start that process > for us. > > > > -MSK > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > From nobody Tue Jun 13 08:09:27 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDA4131A9E for ; Tue, 13 Jun 2017 08:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 MgrUkp4NSw7N for ; Tue, 13 Jun 2017 08:09:23 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F06131975 for ; Tue, 13 Jun 2017 07:54:23 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id e142so43240065ywa.1 for ; Tue, 13 Jun 2017 07:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TpdN3FC6IIxYJr4ixo0ZtjzQpHXlfQpsomvLWzZknis=; b=wtN/x80mVUf8szAgB22awnPc1fbd5LRBlnFVxM6XctyXUR3ewRISvGQpyHcEgjfrtk Z6q2UG0xM/maxcqdCQBXzMvJEIQjdbJ5H2gDqaclb29jnXq0a/XDOelv+JzQ3PFl8tJW miX9M5RacaUTphtI0iqxJJtwNtRC2DagtvTGxrMPmQd+M81yUr7nQaObLjhtLlj/ft+B r4Ifan12//wQI+oWBQN3vpkEk7NqZrdIU8YrlpD6Xv0+kubt+BMk3AWZk8WWNPhatiLe pwPZKMOd5VPu6Tf4CZMhJ258HCRbbaRKavLvjaROJcsPsKeEwmzeyaAM3WUCcW8dONLn 1UqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TpdN3FC6IIxYJr4ixo0ZtjzQpHXlfQpsomvLWzZknis=; b=GVH4uUsom7+Y0KgiHdCzI9jqQvC0OBv/dvPUhAvZg2coQf5d1Mi4y0qiM1iTUYTHsj 7XztqOCyZPo7QON9FXTMqL10Qi5purlk/b3Bh5OdB6TU1tnt3GcL+GQ78VOAFGGBv9E7 TZs5SSEZ5+M1lkaFxn+1DHvJJt7O+5e/EZr2076HVVpZMN58K2LJEuWhWcoOUGq3A5tp CF4XQfTencOZhacihh16UwrMtHP/ipPdb5O9hXe9JcBb7wSmB7VI0nrcL9uj7XJX3a9t 7dFK1P74kIv6q2q4Bl747krUZRRDjmNU8W3pVBH2DU586PXr+aXHQ5tRNVvuNxku9Tzg 6ObA== X-Gm-Message-State: AKS2vOxSrUUM/7Z8oExGLShBcH0EuzyO37HsBPKa3tMl9DNg5lOne+SB Zd1Xw7UIkZNArXH0508nnuqepxjptVbzBSY= X-Received: by 10.129.109.4 with SMTP id i4mr3665656ywc.3.1497365662664; Tue, 13 Jun 2017 07:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Tue, 13 Jun 2017 07:53:42 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 13 Jun 2017 15:53:42 +0100 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dd1846c37ba0551d89c48" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:09:26 -0000 --001a114dd1846c37ba0551d89c48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, this would require a second preimage. My sense is that nobody is close to that at all with SHA-1.... -Ekr On Tue, Jun 13, 2017 at 3:41 PM, Jim Fenton wrote: > On 6/13/17 5:05 AM, Salz, Rich wrote: > > As a newcomer to DKIM (I come from the crypto side of things) I am a bit > confused. > > > > Certificates last for a couple of years, and so there was a strong > motivation to move off MD5 and then SHA1, because of the concern that > someone would find a collision and create a bogus certificate during the > original cert=E2=80=99s lifetime. > > > > But I=E2=80=99ve heard that DKIM =E2=80=9Ctrust lifetime=E2=80=9D is much= shorter. Is it? What > is the expected lifetime for relying on a DKIM signature? > > > The expected lifetime is on the order of a week (message delivery > timeout). But the signature doesn't have an expiration time, so if someon= e > can construct a second message with the same hash, they could replay the > signature, potentially much later if the public key is still in DNS. > > IMO it seems very unlikely, even with the known weaknesses in SHA-1, that > in the near future someone would be able to construct such a message that > would be exploitable by an attacker (e.g., spam or a phishing attack). Th= at > will likely change in the future, so we should tell signers to stop using > SHA-1 ASAP and tell verifiers to stop accepting those signatures sometime > later. > > If anyone knows something yet more serious about exploitability of > rsa-sha1, please set me straight. > > -Jim > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a114dd1846c37ba0551d89c48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, this would require a second preimage. My sense is th= at nobody is close to that at all with SHA-1....

-Ekr


On Tue, Jun 13, 2017 at 3:41 PM, Jim Fenton <fenton@bluepopcor= n.net> wrote:
=20 =20 =20
On 6/13/17 5:05 AM= , Salz, Rich wrote:
=20 =20 =20

As a newcomer to DKIM (I come from the crypto side of things) I am a bit confused.

=C2=A0

Certificates last for a couple of years, and so there was a strong motivation to move off MD5 and then SHA1, because of the concern that someone would find a collision and create a bogus certificate during the original cert=E2=80=99s lifetime.<= u>

=C2=A0

But I=E2=80=99ve heard that DKIM =E2=80=9Ctrust lifetime=E2=80=9D i= s much shorter.=C2=A0 Is it?=C2=A0 What is the expected lifetime for relying on a DKIM signature?


The expected lifetime is on the order of a week (message delivery timeout). But the signature doesn't have an expiration time, so if someone can construct a second message with the same hash, they could replay the signature, potentially much later if the public key is still in DNS.

IMO it seems very unlikely, even with the known weaknesses in SHA-1, that in the near future someone would be able to construct such a message that would be exploitable by an attacker (e.g., spam or a phishing attack). That will likely change in the future, so we should tell signers to stop using SHA-1 ASAP and tell verifiers to stop accepting those signatures sometime later.

If anyone knows something yet more serious about exploitability of rsa-sha1, please set me straight.

-Jim

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a114dd1846c37ba0551d89c48-- From nobody Tue Jun 13 08:28:19 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97BDD131915 for ; Tue, 13 Jun 2017 08:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3mpvsOMm7iXE for ; Tue, 13 Jun 2017 08:28:16 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89314131924 for ; Tue, 13 Jun 2017 08:14:22 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id e11so32064796oia.2 for ; Tue, 13 Jun 2017 08:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3AdUvRpITEeImWsjC9MxFFgWWJPWUgJ/xogc15swICY=; b=LHzpwRw3eqRXQZNxihRjWCGgimpLx4H3ewtPmrlE5Ur0DUM98QVwOQS2n5hZqKhJdl ++zwXukdEJKBNE2meEBqU3+TrQsijICS5e0wiNu2xSd9AC7/f/L2tWhpTUlpSjLZEHfh 3FRjK32A+xktXMD49ZFLbBqghQF1yt72jEAC9SMv0tBmw7m8g7c0sSZJEQ+HSPuToafz Q7XQPKs5VSo0hSktvlHIEVMDUxcKmRSCi5QPzinY/5mZEQSbsqVvpLx/jJTjzjUOHLUO nktNQndHQUAE8ytSmIZiOpaNkW5OT5uL3BjKn1ZrE6ZDw/RWKY6G9FN/n28PEODoYVz+ 1scA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3AdUvRpITEeImWsjC9MxFFgWWJPWUgJ/xogc15swICY=; b=WT2LubpwpQA3SYVzDhIM/wnLumkPd99lBFZ7Es9DiQXDSWtgl/Jp1ya1PwEN3XRuUQ 66p5fdaLh+rUVfbyN24RDxiE9WwBlKNW+lVCyQVNERwMAmnuDZuwrZUBXGvxqPB2dZDd lRfF9kxSZEHbjT8qe0VHcpo6vpQAhOVRFGeuCt72kFNOsWFAgJJuaXPB+0CyB8su2JJ/ lmpAnDQE1l/PSQ7cP0UguQOEfjCMhOV0nAKjqUZiZ92QCD2vYQLX6S1IkSvUAxS0MjPW wdQJ8P21AFlDa8PzTEImdfhDkptzBFxqB4wOlJ5er5hmhNA1zIUhbbeeU1cfaQvzXSnc r8bA== X-Gm-Message-State: AKS2vOw4Y8sE2DpcJ5vpjvqJ+cq1i1kLeKBg2LvgZOm3AVLp03XTxmFr 1MXzhx/mqZnwXAsv4Mt4LeVf4RLhHA5O X-Received: by 10.202.236.20 with SMTP id k20mr248876oih.20.1497366861840; Tue, 13 Jun 2017 08:14:21 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.225 with HTTP; Tue, 13 Jun 2017 08:14:19 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 11:14:19 -0400 X-Google-Sender-Auth: S19orQK_ugk6ROZF1YhYmKIXUQY Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:28:18 -0000 The issue of trust lifetime is now very problematic due to the use DKIM signatures are being put to. In particular the verification of purported leaks from the DNC and other places. The DNC material was verified by means of the DKIM signatures. Other material has been exposed as fake by the lack of signatures. And please, let us not get into idiot discussions of whether people who hack into politicians email might redact, suppress or forge material, of course they would. People who use dishonest tactics are going to do anything they can get away with and no, nobody is going to be able to guarantee the material is genuine without a mechanism such as DKIM. As it stands, the break in SHA-1 is not sufficient to introduce a forgery but could certainly be used for mischief (if you can't see how, you lack imagination). Remember that in this campaign, the opponent is hacking into infrastructure because simply planting a seed of doubt serves their malignant ends. So the SHA-1 issue is very clearly a security issue. It is in fact a critical national security issue. The question is what to do about it. I suggest the following: Signers MUST NOT use SHA-1 or RSA 1024. Verifiers MAY accept SHA-1 or RSA 1024. The rationale here is that you do not get better security from introducing a new algorithm. You only improve security by withdrawing an insecure algorithm. From nobody Tue Jun 13 08:54:34 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E1A131C2E for ; Tue, 13 Jun 2017 08:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 vbqLcVd_kg90 for ; Tue, 13 Jun 2017 08:54:30 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD37713192E for ; Tue, 13 Jun 2017 08:43:29 -0700 (PDT) Received: from [10.220.112.173] (mobile-166-171-56-130.mycingular.net [166.171.56.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4C63BC40349; Tue, 13 Jun 2017 10:43:28 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497368608; bh=p6Mnf/XUMLfzo8tPAYmXz+JK4PAsNFx32y9L5UzHEBY=; h=Date:In-Reply-To:References:Subject:To:From:From; b=woLgCIPR9iaGL5P3m0I7MpQLnBcEe7aJSIlPsxfNtAmbFm0j9tXDSCrzwAV1W4QYL BKdXLecllQIRM0H+oschNOHlISfw7cy7wmRTLLbHq9zuImsdeU6ULbC9c/E31LSCOk ZJR4Cgz2YEgow9eRyzEE0uF+PFeq/EWJ6THLa25k= Date: Tue, 13 Jun 2017 15:43:25 +0000 In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 15:54:33 -0000 On June 13, 2017 10:41:42 AM EDT, Jim Fenton wr= ote: >On 6/13/17 5:05 AM, Salz, Rich wrote: >> >> As a newcomer to DKIM (I come from the crypto side of things) I am a >> bit confused=2E >> >> =20 >> >> Certificates last for a couple of years, and so there was a strong >> motivation to move off MD5 and then SHA1, because of the concern that >> someone would find a collision and create a bogus certificate during >> the original cert=E2=80=99s lifetime=2E >> >> =20 >> >> But I=E2=80=99ve heard that DKIM =E2=80=9Ctrust lifetime=E2=80=9D is mu= ch shorter=2E Is it?=20 >> What is the expected lifetime for relying on a DKIM signature? >> > >The expected lifetime is on the order of a week (message delivery >timeout)=2E But the signature doesn't have an expiration time, so if >someone can construct a second message with the same hash, they could >replay the signature, potentially much later if the public key is still >in DNS=2E > >IMO it seems very unlikely, even with the known weaknesses in SHA-1, >that in the near future someone would be able to construct such a >message that would be exploitable by an attacker (e=2Eg=2E, spam or a >phishing attack)=2E That will likely change in the future, so we should >tell signers to stop using SHA-1 ASAP and tell verifiers to stop >accepting those signatures sometime later=2E > >If anyone knows something yet more serious about exploitability of >rsa-sha1, please set me straight=2E > >-Jim I'm not an expert at all, but at least to the degree I understand it, I th= ink your understanding of the rsa-sha1 situation is correct=2E I think your proposed remedy is too mild though=2E Given the degree to wh= ich the SHOULD NOT sign rsa-sha1 has been ignored for the last decade, I do= n't believe anything other than MUST NOT sign/MUST NOT verify rsa-sha1 is v= ery useful=2E The thing about weaknesses=E2=80=8B in cryptographic algorithms is that th= e timeline for their discovery isn't predictable=2E I believe that most cr= yptographic experts anticipate that such weaknesses exist and will be found= , we just don't know when=2E Given that we have rsa-sha256 available, I think it would be irresponsible= not to remove rsa-sha1 from the DKIM protocol=2E Operational practice=E2= =80=8B isn't closely coupled with standards changes=2E Killing off rsa-sha= 1 now is the best thing we can do to minimize=E2=80=8Bthe panic when a prob= lem does become known=2E To the extent standards changes matter, engineering resources don't get as= signed beyond the minimum needed=2E I imagine a manager dropping our RFC o= n the (metaphorical) desk of one=E2=80=8B of their engineers and asking wha= t's the minimum change required by the RFC=2E If the answer leaves rsa-sha= 1 in use, I think it's a mistake=2E Scott K From nobody Tue Jun 13 13:37:16 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3BE1243F3 for ; Tue, 13 Jun 2017 13:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com 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 32x8m25nxigQ for ; Tue, 13 Jun 2017 13:37:13 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 CD3E9126E3A for ; Tue, 13 Jun 2017 13:37:13 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id B2E661E105; Tue, 13 Jun 2017 20:37:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1497386231; bh=GJaIB4KlYmJ8MRaXSgcIXZr9687ZTi5K/iYWQ5UQp/8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=egQHlVxhrzzgI4lJyLAQ4OeLIw1c0j9EGfalrAQtMk7t+jdSX7ILNeXxr2zOQK7Wy fPaNMXZnSeKwBrfYjwnt5WzSZYlI6cJbGttrsPWpyNFUV6B3yH3JcOciRJBGnWNqlr kVeGuVQvarNN4Pf8b0G16bz7akCMOGvQHjm0vB+iYZ0WrXwTQrN6vRK/DH2CNW3ghK Vb2z7vXE1tPDEXh/mzOKUTg6XWs0WNFMH3HyK9hF8R/nQqEqnVSQNeK7Y7RLL6vyii M3afxR47LKnXm1e9No129RaL5zcSuPUrMt1p4E3FP/Xa3o6TOTdUstTCntVVVRPKUp 7NQUg1I7oQT/A== Received: by carbon.jhcloos.org (Postfix, from userid 500) id D2BA5107AC446; Tue, 13 Jun 2017 20:35:26 +0000 (UTC) From: James Cloos To: Scott Kitterman Cc: dcrup@ietf.org In-Reply-To: <5B2CFEEC-9A44-4368-A6BE-24CDF69D01C0@kitterman.com> (Scott Kitterman's message of "Mon, 12 Jun 2017 23:51:24 +0000") References: <5B2CFEEC-9A44-4368-A6BE-24CDF69D01C0@kitterman.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2016 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Tue, 13 Jun 2017 16:35:26 -0400 Message-ID: Lines: 23 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170613:sklist@kitterman.com::gPIC8n/jNIFstZWA:0000000000000000000000000000000000000000BrErm X-Hashcash: 1:28:170613:dcrup@ietf.org::KoiMfl+cwuOBvVE4:00KCM20 Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jun 2017 20:37:15 -0000 >>>>> "SK" == Scott Kitterman writes: SK> How are messages that are signed with both rsa-sha1 and rsa-sha256 SK> counted? For this purpose they should be in the rsa-sha256 pile. Indeed they should. But my earlier report counted ^DKIM lines separately. Rechecking on them, I found that one spam had 500 DKIM-Signature: blocks. (All from the same sha256 signer. :) I just checked by splitting them into sha1 files and sha256 files, running: ;: diff -U999 .sha*|egrep '^ ' reported 5821 lines. Many are from mailing lists, where the list signed with 256 and the sender with 1. Or similar, but via something like mandrill. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Tue Jun 13 18:37:14 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8029131AE4 for ; Tue, 13 Jun 2017 18:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jhqoouuVU35A for ; Tue, 13 Jun 2017 18:37:12 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D76F12947F for ; Tue, 13 Jun 2017 18:37:12 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id q15so86177445uaa.2 for ; Tue, 13 Jun 2017 18:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j1e4IFcEBlykdEBNHT+fL+JxqJGLXDt4JBWngnQ8GRc=; b=lC8CpwmvztqOszJCQQQaudZhluk4B18JYFrb74OJgpsgTAU0HB7/aiwsg6R6BZ1/Sm XzkK3UwMbeL7UqlK4oMn1F8Rj8J08lRw0SVBArQVCTNwgo2YWUkG26EcicbwElK8/DUh nxoZ4f2LFnKTtchj/TuHAHVO4w4d29F1TwQh2XPLcnz1zjnAytcaz1XOc9IWHUjwCAqQ BvOt/sClmmp8vN70HZrJ0m17qgCOqeHGnjyxNhliQ425LJVzhtOXtOZR5You+DwEtReH Ajus2vMScWPjQEgX1L8OkT1UEjFMpB1ldc8FR/cIbQB/Ms36WhqmNVV3a5WCxy3bGh13 GCJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j1e4IFcEBlykdEBNHT+fL+JxqJGLXDt4JBWngnQ8GRc=; b=pFClRQXRBuZbs/vwVN2ysVMgEBEMXDhw9NxzSGW7/8H4wVFN+vRMZcNfMHbWP+BHh2 ID7d9hRfjdJRi3wXuk7v7i9e5H0eGH2cJ4wWHbbjBto4ggat4U18WUeUz6ByyCBHOZQh nEHW4q/j2HVBSmKLAy08MPSx9SF2gHOY/Ki8FvSQIh/fKIjrZMywijh9SmBt1E/dL2yQ 8oy253Th2tcySZ/5QsmkoLyhCkhcxqLPIO/hvzGJSE8Q8MhKXHdVY60jrMaCuGEhFO20 t5vdvK/YwV4dVLjm34e7UFoddH41Xy3Qk/hdTTd6v/wfQaWjG5FxTbQeDqAnCElfMYNM jdqg== X-Gm-Message-State: AKS2vOwgbbrC+t4qaXsAu0HM2R8c8hhJUyupKUDtAXKmfS4tClWbdVa0 +sCDo4WBRlzLw5/LUmFOg8kcrq5P78sR X-Received: by 10.176.0.248 with SMTP id 111mr3798228uaj.133.1497404231162; Tue, 13 Jun 2017 18:37:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Tue, 13 Jun 2017 18:37:10 -0700 (PDT) In-Reply-To: References: <149690083334.25644.8501543904193079634@ietfa.amsl.com> <17424575.60yUzU31nn@kitterma-e6430> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 18:37:10 -0700 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113ac2d448d0960551e197b4" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:37:14 -0000 --001a113ac2d448d0960551e197b4 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 7:30 AM, Jim Fenton wrote: > But "verifiers ignore signatures" doesn't seem like very good normative > language. Are they required to (MUST) or is it a strong (SHOULD) or weaker > (MAY) suggestion? > Get Pete Resnick in here! You don't need any of those things. "Verifiers ignore SHA1 signatures" means that's what they do if they comply with this update. Sticking a MUST in there doesn't change anything; anyone that wants to comply will, and anyone who has no idea about any of this won't. Alternatively, we could load this up with a sentence or two describing why it's a grand idea to ignore such signatures. -MSK --001a113ac2d448d0960551e197b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 7:30 AM, Jim Fenton <fenton@= bluepopcorn.net> wrote:
=20 =20 =20
But &qu= ot;verifiers ignore signatures" doesn't seem like very good normative language. Are they required to (MUST) or is it a strong (SHOULD) or weaker (MAY) suggestion?

Get Pete Resnick in here!

You don't need any = of those things.=C2=A0 "Verifiers ignore SHA1 signatures" means t= hat's what they do if they comply with this update.=C2=A0 Sticking a MU= ST in there doesn't change anything; anyone that wants to comply will, = and anyone who has no idea about any of this won't.

Alternativel= y, we could load this up with a sentence or two describing why it's a g= rand idea to ignore such signatures.

-MSK
=
--001a113ac2d448d0960551e197b4-- From nobody Tue Jun 13 18:38:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C485131AE3 for ; Tue, 13 Jun 2017 18:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Sls1bRJ2z4qM for ; Tue, 13 Jun 2017 18:38:00 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB4AD131AD7 for ; Tue, 13 Jun 2017 18:38:00 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 68so68718730uas.0 for ; Tue, 13 Jun 2017 18:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FPFSN7P4kYHtHFTwJCbgTHF5+RDSuioxqyGtT9DcHyk=; b=uOFeEdgwxDsTQQ4btEFMeqjIBcj5DtC4YHUu/ww2+u0SWUYeqwj1QZCH32ChPVYLjH uarMlT6VurZ1hisTQYU2bbqTePMmBfpO3OKAqkD29xSD6YfsjXFWNoVntt+5MjliTABC RBk9nkqw4lq4yoy/20I5YkG+Ta1UZ0m65GiSp4tL0reTJo9UfDFHzqYBybYyHPurBhn3 bOQOwcCjprcYOZZmE3FkENOzcysxzBXdLjuLWsa+ds3uaheYFIi+QMLFB9rr9IdY//wb elJhXiqAZi25vSAiymTiDCf8fncUpdBg0nfkWH4I5gPveJM6Q1HxXVAHCdvLBSSK/6Jw yuNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FPFSN7P4kYHtHFTwJCbgTHF5+RDSuioxqyGtT9DcHyk=; b=V7zIpY/5hjaig5SCVGrREldBjIW17Tr+OBhpEYbp/nptorWHhZGnnm8O2pEBdVjL12 Nyzf2G5qjOqV2JS8ywQRRIPFOOl11kXtu/xDA+zYukVAYve2OYgoqaBzoX7UMMlYHtWc tj5Xy5EFspk3tmnMaupxEsnguDnFuDENquh4XZKJ/2zwad5m4tA3vkqtKGPcD2XOFvps Bx1+lT9lEpagmJ/NIvZfNHyaHClCGe0APdLfsfnaimLHEveLrUptUPAedtcNwJHqXUS8 mS2+lAn6CDnG9Bgr2T2sYAYUrMfIz+mMty6Mn86a5EYhRM9BUlTfPbZDlg7x5fdHzAsf /3yw== X-Gm-Message-State: AKS2vOx5+TLzSgjunyURx46qbjKaOp08Az/PTYVZig9zlowL7DErqlTW cdKPmLnEREeDs3NqLZEMEDoWNAc1WA== X-Received: by 10.159.59.210 with SMTP id y18mr4506302uah.43.1497404279880; Tue, 13 Jun 2017 18:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Tue, 13 Jun 2017 18:37:59 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 18:37:59 -0700 Message-ID: To: Martin Thomson Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1a26d63004df0551e19a6e" Archived-At: Subject: Re: [Dcrup] Deprecating algorithms X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:38:02 -0000 --94eb2c1a26d63004df0551e19a6e Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 7:52 AM, Martin Thomson wrote: > This is a fine thing. Do you want to propose text for the charter? > The diff to the current charter is going to be mighty small, so sure, I'll do it this week sometime. -MSK --94eb2c1a26d63004df0551e19a6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 7:52 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
This is a fine = thing.=C2=A0 Do you want to propose text for the charter?

The diff to the current charter is going t= o be mighty small, so sure, I'll do it this week sometime.

-MSK
--94eb2c1a26d63004df0551e19a6e-- From nobody Tue Jun 13 18:40:10 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8865A131AE5 for ; Tue, 13 Jun 2017 18:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3sBdPrvbuGpp for ; Tue, 13 Jun 2017 18:40:07 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D332C1205F0 for ; Tue, 13 Jun 2017 18:40:06 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id 191so73396528vko.2 for ; Tue, 13 Jun 2017 18:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HbRat+ZdftA5bS3mKW3aJ8SHacEo6LKh7h1MuTFRJPU=; b=uN/TXKysMOBGwfoKf/FnJi99hD+e51ZSTCeqvqXC+2bCOc+CQnUJSKi05W5pr9Zzw4 j2OzdkndffmQFW3kAUQj+E/vtBMHmwZcZQ4YJBxuRh+5Zvmh+aG4xwSaUvP85wV1pPD/ 5fr9oh9pqIb9WIA1JwKgDKXTEL9zKCGPN+dN4TBWcvh/aTph3cIwYynxpqiJwAbXVzwa IGwe552sXwFQtZvQAbNYDKjNQkZTKkkAmOhUIUgYGWyw8r1ifqu/MMhRPRBn01UIoMlt JTZ6SO+xG4HIJR31hPWCJabUm2yiCB1Zq9/SF7sTLP4JW5Cv5OTps73lQT1mdateRZDN 6K2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HbRat+ZdftA5bS3mKW3aJ8SHacEo6LKh7h1MuTFRJPU=; b=ppH03OdTcibVQgXAMntK0vCZGCAh+UvJgIwuBwCjH8O1eUbEbnWjAlL+FBooex2zWP GVu2k7/ItHVEVVdO7luih6hLjCOFUlnYYrEiBUJwyqn7y0n42uZgwk1saVgt75xS87Bi oiCMcoAmtzhRDLrqvFVe16iHYNbDtIhdp9Lfzw28eUQ0S8UwEDnNGc1xo/jScjE04tZH xLOiZ5LhnbC5bMwWq8KOW9EgK5skGBXRNGiYKbUNmzGJAFFgEuwcJwiJMPYQw7RKmxRa qAVsS7PRmiJvDy9zHjj6PUW9vPXEFvwwCjYnXHhXS83WH4myKalxwBoamqlSsjggU7eE DLhA== X-Gm-Message-State: AKS2vOzSYM4ywUVqTT8ZO+nukiCVDIoNKdPxOjnNZ8mKfJg8xxuyyiD/ AVY8j2gVlID3OwgdYwNYUVPm5l9zbRLs X-Received: by 10.31.97.197 with SMTP id v188mr1651609vkb.132.1497404405979; Tue, 13 Jun 2017 18:40:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Tue, 13 Jun 2017 18:40:05 -0700 (PDT) In-Reply-To: <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 18:40:05 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0944a4b41e580551e1a1d9" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:40:08 -0000 --94eb2c0944a4b41e580551e1a1d9 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman wrote: > I think your proposed remedy is too mild though. Given the degree to > which the SHOULD NOT sign rsa-sha1 has been ignored for the last decade, I > don't believe anything other than MUST NOT sign/MUST NOT verify rsa-sha1 is > very useful. > That being the case, why do we think people will pay attention to a MUST NOT today? -MSK --94eb2c0944a4b41e580551e1a1d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
I think your proposed r= emedy is too mild though.=C2=A0 Given the degree to which the SHOULD NOT si= gn rsa-sha1 has been ignored for the last decade, I don't believe anyth= ing other than MUST NOT sign/MUST NOT verify rsa-sha1 is very useful.

That being the case, why do we think people = will pay attention to a MUST NOT today?

-MSK
--94eb2c0944a4b41e580551e1a1d9-- From nobody Tue Jun 13 18:56:01 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C1A12957B for ; Tue, 13 Jun 2017 18:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 t2U2uNlUTMyu for ; Tue, 13 Jun 2017 18:55:58 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 CB5FE126DCA for ; Tue, 13 Jun 2017 18:55:58 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:90f4:2421:52d:e0c9]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5E1tqfD021648 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 13 Jun 2017 18:55:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497405358; bh=mgPPXOe+hCECP4nqIsKU3JiApaX7MygJgyspW7OYz2s=; h=Subject:To:References:From:Date:In-Reply-To; b=G3SRPuCpIls40GrxXbEPQUSy/JgznkDNJbz+bPTiLw1/iKueYksQzz9N3R5iom80C CoocpmsW4bWAtfGOpDo7T9rfOTpk+/zD8egq3NyRskJwga1mWV7UndF+xUa4dom+fn uHCPdSjwcyINSdd8aitAlDZM9uxBGlUR+9Y+8CtQ= To: dcrup@ietf.org References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> From: Jim Fenton Message-ID: <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> Date: Tue, 13 Jun 2017 18:55:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C65B212E04DCF1FE0E40FAA4" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 01:56:00 -0000 This is a multi-part message in MIME format. --------------C65B212E04DCF1FE0E40FAA4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/13/17 6:40 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman > wrote: > > I think your proposed remedy is too mild though. Given the degree > to which the SHOULD NOT sign rsa-sha1 has been ignored for the > last decade, I don't believe anything other than MUST NOT > sign/MUST NOT verify rsa-sha1 is very useful. > But it isn't a simple SHOULD NOT, because it's followed by: INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some senders might prefer to use rsa-sha1 when balancing security strength against performance, complexity, or other needs. In general, however, rsa-sha256 should always be used whenever possible. Basically this seems to be giving signers an out to use rsa-sha1 because performance of rsa-sha256 is worse (although I doubt that it is significantly so). Granted, I'm probably reading a lot more nuance into the specification than many readers are. > > That being the case, why do we think people will pay attention to a > MUST NOT today? Because implementations will stop supporting rsa-sha1, forcing the issue for any who upgrade. I'm all for having them stop supporting signing with rsa-sha1, but they should continue to support verification for a whi= le. -Jim --------------C65B212E04DCF1FE0E40FAA4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/13/17 6:40 PM, Murray S. Kucherawy wrote:
On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman <sklist@kitterman.com> wrote:
I think your proposed remedy is too mild though.  Given the degree to which the SHOULD NOT sign rsa-sha1 has been ignored for the last decade, I don't believe anything other than MUST NOT sign/MUST NOT verify rsa-sha1 is very useful.
But it isn't a simple SHOULD NOT, because it's followed by:

INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
      senders might prefer to use rsa-sha1 when balancing security
      strength against performance, complexity, or other needs.  In
      general, however, rsa-sha256 should always be used whenever
      possible.

Basically this seems to be giving signers an out to use rsa-sha1 because performance of rsa-sha256 is worse (although I doubt that it is significantly so). Granted, I'm probably reading a lot more nuance into the specification than many readers are.

That being the case, why do we think people will pay attention to a MUST NOT today?

Because implementations will stop supporting rsa-sha1, forcing the issue for any who upgrade. I'm all for having them stop supporting signing with rsa-sha1, but they should continue to support verification for a while.

-Jim

--------------C65B212E04DCF1FE0E40FAA4-- From nobody Tue Jun 13 19:11:38 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419461274D0 for ; Tue, 13 Jun 2017 19:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bff78ssLeNsF for ; Tue, 13 Jun 2017 19:11:36 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBAF81275AB for ; Tue, 13 Jun 2017 19:11:35 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id k145so11628356oih.0 for ; Tue, 13 Jun 2017 19:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fnnggE0NDB/DBjdIlNHOomtInqYDWbkg/eze497fDMM=; b=tTbtI8ijHzFf6GHzK0rp2xw0eC3ru2NOd+JR5gmZRLQ8/qQX9zPtiRNnmHPAR/6rll WOysK3QxWAoUE84dsg8jjNS5ZxNCcwMd6tV4cjTuYLdpuBLOrTBtVMyV03+Zwf4kLZ4Z 3Y9QirW/wQlQSqbMw4uahSpKqv+xeNL6VIOQiS4X3/2cc8vj3+duRO/Yj8k2go53hj+2 8ZCjjmjskwBGmlrjMrji/jSPKFOYb/uVc4/H5u789eaW+VHr4uRG2643hy8gPS8rIVLe 0oe9F1BS6KazA+CX1N4Z1p7E5aifNn7PNwXV536eJLHMIR2zo003rXMDNLaXMsiP/uOl E+7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fnnggE0NDB/DBjdIlNHOomtInqYDWbkg/eze497fDMM=; b=sjYsszwyxUlkzC4XXGuqFPFrcvx6eDCl5Bp5S4rF+9hTtt/5mneJgAjxJiuQSb8Hwq QKbbl1pr92W278bhpHZyQt2q+vKvQV0biX/vxv44z99pguwV5vvdVUL8a8luTdgWZHf3 bz1bAG9G/vs48zUUXkDVtwaA8zlNc2OXYgSs8xppWea6fQ505P+eRABw7/xEA2yz+bqX 0zYl2eZ5KgGeY9rBy/tp7TFp3/4YjiujyhNxcutK3ar0LOAFzcNStWPmCvxEbRCwSl+C 6ONjiFk8rwHkm/KoRWa3Z+BonEdhvTYx/Ok4L9Z5CohyHd+1Ia4k375MKMHB5p5R5xH1 15aw== X-Gm-Message-State: AKS2vOxX/z321aB5XrL+OSPYWNxVYFkpS4rv2N3DqtXwh+f9UFxUu+a1 5Sjo4A5BLdgBKVEPq2sT3IsatHGywA== X-Received: by 10.202.212.73 with SMTP id l70mr1965387oig.4.1497406295150; Tue, 13 Jun 2017 19:11:35 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 19:11:34 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 22:11:34 -0400 X-Google-Sender-Auth: rrHn1KFlpg8CIbo0WChl4CQS5QE Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 02:11:37 -0000 On Tue, Jun 13, 2017 at 9:40 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman > wrote: >> >> I think your proposed remedy is too mild though. Given the degree to >> which the SHOULD NOT sign rsa-sha1 has been ignored for the last decade, I >> don't believe anything other than MUST NOT sign/MUST NOT verify rsa-sha1 is >> very useful. > > > That being the case, why do we think people will pay attention to a MUST NOT > today? MUST NOT sign is perfectly viable and proper and will be followed by anything that has the right to call itself compliant with the new spec. MUST NOT verify is not supported by the state of the crypto and is guaranteed to be ignored. It is an utterly illogical criteria since there is no requirement to sign at all. From nobody Tue Jun 13 19:41:34 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA625129AF6 for ; Tue, 13 Jun 2017 19:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nV4jVk0Om7yq for ; Tue, 13 Jun 2017 19:41:31 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85024129AE9 for ; Tue, 13 Jun 2017 19:41:31 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id c10so194706209qtd.1 for ; Tue, 13 Jun 2017 19:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=93j7L85JEVIdEX9nrmngWfMeDil+ysoQQBu4i2RvfoY=; b=RhEIaoPt+GSvt/J/AZ9BuAJG/Vq8XWUOGprdcUmp8ipBkEi+hPIWemcXC3ML5ksBkB DoRZFxz/reTpBZQlf1jIZWY8EfG1fswmfP5DFg2kR091kI6PMzTYZr9JSzAg32US41g0 4dbUUGoOv8t/+IKZS9O11pJ5ib5HRDI2AGVqy/U5/vhb5xwGcQPXLXgqNiIIxkwr/JLP 3Qz6xEe2WgzoshamBMGCvhd4ubJ9jL2+tKioB0eJyG81zPJgtfIbWH/oC49jIEjS8Mdl 17DpN+eOPZ9/zHwjQ/nEwKjQSwvIMZZxA/J6ZT5UQi/r0b9u9SorpnV8MqKUVx/VnekE V/dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=93j7L85JEVIdEX9nrmngWfMeDil+ysoQQBu4i2RvfoY=; b=dvGD9Op2Wypxx+TqeTvZYnOdDSRAerKtW3Wr1H8k3P5WOUm+Flyc2uJ0+XpK1lLwUd Cd+WlJ+bIbqta0EboVQl4GesxMMkBdvs9co1uZIKFfNtcW+1yFFV5jv3dAH7U4tHd0tA qu2+6xyueBN99HTTcyf5eq+UaaxhDYlw7TvHHRuLxozvwyvCL9rEyTjyM1UqWCfIilzv cLoZDdbTCda/Wjti1xUcEDU8fUFH5EM1u3LClGgRccm6YPUkLjHbNXXXQffrbpqOAOMl raaLS28Iq3G/uWu1LaGU4rGjjN4fjI0IECJ+3mFwmN0SnxX15EP/K5QYxMAqAcnLOwHz NOqw== X-Gm-Message-State: AKS2vOwACx1LeKKtr7I+PHPgh6PhjN1Kh6PMXUnOdeboDszY85VDJNfU t/Px9ZHd6rpadUkOHIUXcv3+fDKXTg== X-Received: by 10.200.2.79 with SMTP id o15mr4286333qtg.26.1497408090776; Tue, 13 Jun 2017 19:41:30 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.140.19.200 with HTTP; Tue, 13 Jun 2017 19:41:29 -0700 (PDT) In-Reply-To: References: <20170611231340.17586.qmail@ary.lan> From: Phillip Hallam-Baker Date: Tue, 13 Jun 2017 22:41:29 -0400 X-Google-Sender-Auth: pFS6-TX0HDAVoQ8JYbJsuTV2TtM Message-ID: To: Eric Rescorla Cc: John R Levine , dcrup@ietf.org, Martin Thomson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] stronger crypto, I-D Action: draft-ietf-dcrup-dkim-usage-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 02:41:33 -0000 On Mon, Jun 12, 2017 at 5:49 AM, Eric Rescorla wrote: > You can bikeshed on anything, but I don't see how this is actually a > particular problem, > given that you can pin the hash to the signature algorithm, as we do with > elliptic curves. As a process matter. Could we not use the term 'bikeshed' when referring to contributions? I am completely serious about this. I have seen the term used by certain individuals to essentially trash someone's contribution and then gaslight them. It really does get used as a form of harassment in IETF. Basically what I hear is, 'this is an unimportant issue so we are going to do it my way and I can't be bothered to enter into discussions on the topic because your work on the issue is utterly insignificant'. Choice of identifiers is an important consideration in any protocol. In fact it is pretty much the only decision to make most of the time. Wanting to do a job properly is not 'bikeshedding'. From nobody Tue Jun 13 20:16:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870E712957B for ; Tue, 13 Jun 2017 20:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cmq9nPYl676T for ; Tue, 13 Jun 2017 20:16:14 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47D61294A4 for ; Tue, 13 Jun 2017 20:16:12 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 68so69571335uas.0 for ; Tue, 13 Jun 2017 20:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=osywVqNXsADDQvs1s4EBeQGYo+gUKiUpVaQNhLqw+N8=; b=B4lPjk0vmwHVgw6GhtZ2pl+6MXnT6fafmfsA4ePD6CQ6dOO23gbURm8aEzXuNJIfFR ydwVEE9pFNRIyjzRi1hi1sUW4uPxnG7rqvV8M4q4gTaYk21Aqg2oCkCnnoJBYef7VTiQ vOK7Nd9G4TIVZLMM4Jq0veY7BOD/zWMSMnsPqSNEOWvueAosHSUjyj90fVRhgbcngJIA eWyO1Jzh8pW0EhXRtoarVBlLE0uIBrhP66rp0BwMeW/FHIPUHzp3kKKtdliFjIgME89V ux7WYRv02TsRX7Xw07FHhrpx6PYLVGeInc8+z8p6HSuSUfcP/jdTwVDGKs8givPAYST2 cIww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=osywVqNXsADDQvs1s4EBeQGYo+gUKiUpVaQNhLqw+N8=; b=KjWGRIQhEtBMnMNZgtFJOoEF612Uezu99oMbInPdwaAwLBBmiZJU1WfkP6tu6ScmrP GZ87wK5AACteSv41ChjsKppFK6BYdd5eRWtGjOcjhNBiz2Zd6bqD1kiApP3l/dCjeau6 cPIwTESUPc9uEu1EOo3QhVfZTeUFl6gOrrQUaG+p/25Q882DLt3ehVDZCqFK5XfwYgjs R8pRkZ8g27D/g3YXOhsZD0DQoUqovqz8Ml7FUkUNfCqX3bbEglI51Uj31mZSILh0uP/b 4Zz95E9G2sP/jQvw6890OU0+87qiriOYHKFNb0szpZcX22nyM1bDxTOFB6CeDX20nx4D rCLw== X-Gm-Message-State: AKS2vOzZ6mn4IkKNd7yjpgXs0m2AFXyObEZv68/YZ1b+LAQsfsJS2a/Q NdQZoS7zEPnhOhiAz31jirPxAK7pRTGYqvY= X-Received: by 10.159.60.162 with SMTP id s34mr4592639uai.89.1497410172086; Tue, 13 Jun 2017 20:16:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Tue, 13 Jun 2017 20:16:11 -0700 (PDT) In-Reply-To: <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 20:16:11 -0700 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403043641f063edc30551e2f914" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:16:16 -0000 --f403043641f063edc30551e2f914 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton wrote: > That being the case, why do we think people will pay attention to a MUST > NOT today? > > > Because implementations will stop supporting rsa-sha1, forcing the issue > for any who upgrade. I'm all for having them stop supporting signing with > rsa-sha1, but they should continue to support verification for a while. > We can't have this logic both ways. Scott claimed nobody pays attention to the advice in RFCs ("Operational practice=E2=80=8B isn't closely coupled wi= th standards changes"). If that's true, then there's no meat to a MUST NOT anyway, and it really only matters what people will implement. And if that's true, then saying current implementations neither sign with nor verify "rsa-sha1" because it's deprecated suffices, and we're done. -MSK --f403043641f063edc30551e2f914 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton <fenton@= bluepopcorn.net> wrote:
That being the case, why do we think people will pay attention to a MUST NOT today?
=20

Because implementations will stop supporting rsa-sha1, forcing the issue for any who upgrade. I'm all for having them stop supporting signing with rsa-sha1, but they should continue to support verification for a while.

We can&= #39;t have this logic both ways.=C2=A0 Scott claimed nobody pays attention = to the advice in RFCs ("Operational practice=E2=80=8B isn't closel= y coupled with standards changes").=C2=A0 If that's true, then the= re's no meat to a MUST NOT anyway, and it really only matters what peop= le will implement.=C2=A0 And if that's true, then saying current implem= entations neither sign with nor verify "rsa-sha1" because it'= s deprecated suffices, and we're done.

-MSK
=
--f403043641f063edc30551e2f914-- From nobody Tue Jun 13 20:20:51 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37ACC12948B for ; Tue, 13 Jun 2017 20:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 YUWYFSqjm8Ec for ; Tue, 13 Jun 2017 20:20:48 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 9AB6F129473 for ; Tue, 13 Jun 2017 20:20:48 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:3d46:df10:69e2:448]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5E3Kkif022622 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 13 Jun 2017 20:20:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497410448; bh=qcXbMigaHBCg8tRN4Nh3ISiDJoazTVuRAm1HQR0bPxo=; h=Subject:To:References:From:Date:In-Reply-To; b=Mh4CjGqtDsnMkAR6/2ROu2dOgwgSjVBL8W2VidsEqdOMdY+Q5IptnU2s8fP0bdcbr /Rzg70PVBydfkbGA+iwQzrmEGVXbzsVW5MkkaXWKt1PcPHQBq5SOTNblTedIa4+7ql LuhzIEq1eKW6b7HCoIDdL/B0HZXahiSfrQOYwTgc= To: dcrup@ietf.org References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> From: Jim Fenton Message-ID: <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> Date: Tue, 13 Jun 2017 20:20:42 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E9F0D02D1619807CED60CBBC" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:20:50 -0000 This is a multi-part message in MIME format. --------------E9F0D02D1619807CED60CBBC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 6/13/17 8:16 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton > wrote: > >> That being the case, why do we think people will pay attention to >> a MUST NOT today? > > Because implementations will stop supporting rsa-sha1, forcing the > issue for any who upgrade. I'm all for having them stop supporting > signing with rsa-sha1, but they should continue to support > verification for a while. > > > We can't have this logic both ways. Scott claimed nobody pays > attention to the advice in RFCs ("Operational practice​ isn't closely > coupled with standards changes"). If that's true, then there's no > meat to a MUST NOT anyway, and it really only matters what people will > implement. And if that's true, then saying current implementations > neither sign with nor verify "rsa-sha1" because it's deprecated > suffices, and we're done. Based on no supporting data whatsoever, my conjecture is that implementers pay a lot more attention to what RFCs say than people who are deploying others' implementations. Which basically boils down to MUSTs having a significant effect and SHOULDs having little. Which is why I favor making signing with rsa-sha1 a MUST NOT prior to making verification of rsa-sha1 signatures a MUST NOT. -Jim --------------E9F0D02D1619807CED60CBBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/13/17 8:16 PM, Murray S. Kucherawy wrote:
On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:
That being the case, why do we think people will pay attention to a MUST NOT today?

 Because implementations will stop supporting rsa-sha1, forcing the issue for any who upgrade. I'm all for having them stop supporting signing with rsa-sha1, but they should continue to support verification for a while.

We can't have this logic both ways.  Scott claimed nobody pays attention to the advice in RFCs ("Operational practice​ isn't closely coupled with standards changes").  If that's true, then there's no meat to a MUST NOT anyway, and it really only matters what people will implement.  And if that's true, then saying current implementations neither sign with nor verify "rsa-sha1" because it's deprecated suffices, and we're done.

Based on no supporting data whatsoever, my conjecture is that implementers pay a lot more attention to what RFCs say than people who are deploying others' implementations. Which basically boils down to MUSTs having a significant effect and SHOULDs having little. Which is why I favor making signing with rsa-sha1 a MUST NOT prior to making verification of rsa-sha1 signatures a MUST NOT.

-Jim
--------------E9F0D02D1619807CED60CBBC-- From nobody Tue Jun 13 20:28:36 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3F3129AEA for ; Tue, 13 Jun 2017 20:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 Uy4_rmmAXChV for ; Tue, 13 Jun 2017 20:28:32 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA6212957B for ; Tue, 13 Jun 2017 20:28:32 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 6A7E5C40593; Tue, 13 Jun 2017 22:28:30 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497410910; bh=DOhQJTAAzupb1p/AcrElGhaXsVxdZL3Nwq4W9GTIOc8=; h=Date:In-Reply-To:References:Subject:To:From:From; b=0/TqOXozeKoz8lRYRKi9CPy7/NLAPBcdD3oh3f+ziRq/AvTgeanc1DutYBhwi/LyG CPwm21usy5a1i8Zo7RdyerwMEdeFBcqUImC2vsaR4q3B2CwvSchrEV+Ama3E1O+0rZ ZWWzwFwudGGKRjAG+ab7vFg9T/gGyrzWGmDjP2Sk= Date: Wed, 14 Jun 2017 03:28:29 +0000 In-Reply-To: <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:28:34 -0000 On June 13, 2017 11:20:42 PM EDT, Jim Fenton wr= ote: >On 6/13/17 8:16 PM, Murray S=2E Kucherawy wrote: >> On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton > > wrote: >> >>> That being the case, why do we think people will pay attention >to >>> a MUST NOT today? >> >> Because implementations will stop supporting rsa-sha1, forcing >the >> issue for any who upgrade=2E I'm all for having them stop >supporting >> signing with rsa-sha1, but they should continue to support >> verification for a while=2E >> >> >> We can't have this logic both ways=2E Scott claimed nobody pays >> attention to the advice in RFCs ("Operational practice=E2=80=8B isn't c= losely >> coupled with standards changes")=2E If that's true, then there's no >> meat to a MUST NOT anyway, and it really only matters what people >will >> implement=2E And if that's true, then saying current implementations >> neither sign with nor verify "rsa-sha1" because it's deprecated >> suffices, and we're done=2E > >Based on no supporting data whatsoever, my conjecture is that >implementers pay a lot more attention to what RFCs say than people who >are deploying others' implementations=2E Which basically boils down to >MUSTs having a significant effect and SHOULDs having little=2E Which is >why I favor making signing with rsa-sha1 a MUST NOT prior to making >verification of rsa-sha1 signatures a MUST NOT=2E > >-Jim I agree on the importance of MUST versus SHOULD to implementors=2E In gen= eral terms, MUST tells me what I have to implement and SHOULD tells me the = defaults=2E I still think we should MUST NOT both signing and verification for rsa-sha= 1 if for no other reason than to not require implementations to support thr= ee algorithms, but I am starting to get the sense I'm in the rough on that= =2E Scott K From nobody Tue Jun 13 20:29:06 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B5A129AEA for ; Tue, 13 Jun 2017 20:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M7Aw4P7Ti-P0 for ; Tue, 13 Jun 2017 20:29:02 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 520F012957B for ; Tue, 13 Jun 2017 20:29:02 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id q15so87142816uaa.2 for ; Tue, 13 Jun 2017 20:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3kF7HqY/S5zy7mX19L95ZlEeL6aqtjf7yLAuWZVzlz0=; b=U5UssZr+Nsv7vDYfhtiDM2EHeIUh/jdzcEbSktnOrQ1TUT3sLcl4eLusanpgAl299L g/f5mJNUu3BWBgb1LNc4JwcqRfskKW+wbRVmYPAsHWxAomPvmfo9iE4p5tUhz2BewLR9 VfG4g8pos2c33cMEovFNBY2cL+OR1JEjbEa6cTpXHg9gaeBMXv52SYOquSO55BzX4r35 NquyFO8rqQa3RHB1HTBYtNMrW3BtwieaD5BEfuvXyQUqLBtkAgQ7WRjGkQ7vU2zgam9C ipc3/QbPgySq7qK4YoYvlyf1bGS2S2GKJ3LCTdR+Kuc6NyVv2KKMuL/KzvtiURd32hz2 Ar/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3kF7HqY/S5zy7mX19L95ZlEeL6aqtjf7yLAuWZVzlz0=; b=Sdr0gQMxp4LCxyHwTyi99gbZI0tobx9zWxvrTp1frzArqw0tkdn5SSCLRM1kgqERXK Zs85ExUQzXcstAYKiDwTWVpz8wBGadISea92/04D9CAbm0UZ3w6puLvV3YsCULx42Xd0 ttd75SiOVWElK8ZS7mguTNtNDvEYffh9rbwy1FUROLCTYC4CaVpr2GRMKOaL623NIzgN q+LbHSeLkB9oVs1y9GYO9JxvohiDsZgss/o9K30ngkuWOK7M+jxih+72Soa9IJvcH6Y1 QT4sI1dz411gzMLGFWVP7bzZX47FQrlBOF7/BOlNuEeHP3YRAb27keA3EhKrL/LlzYug bCQA== X-Gm-Message-State: AKS2vOxaUGAjKb+vtg3FqGqy6UHPRZEsBkjiJkTlN6shZ0A1b1KAI5Uh nBjkYcYmxC4wTF9+/u+WFwcUu6bQUNtH5Hc= X-Received: by 10.159.59.94 with SMTP id j30mr4071178uah.72.1497410941466; Tue, 13 Jun 2017 20:29:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Tue, 13 Jun 2017 20:29:00 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Tue, 13 Jun 2017 20:29:00 -0700 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403043ed9e83fbee10551e3279a" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:29:04 -0000 --f403043ed9e83fbee10551e3279a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton > wrote: > > That being the case, why do we think people will pay attention to a MUST >> NOT today? >> >> >> Because implementations will stop supporting rsa-sha1, forcing the issue >> for any who upgrade. I'm all for having them stop supporting signing wit= h >> rsa-sha1, but they should continue to support verification for a while. >> > > We can't have this logic both ways. Scott claimed nobody pays attention > to the advice in RFCs ("Operational practice=E2=80=8B isn't closely coupl= ed with > standards changes"). If that's true, then there's no meat to a MUST NOT > anyway, and it really only matters what people will implement. And if > that's true, then saying current implementations neither sign with nor > verify "rsa-sha1" because it's deprecated suffices, and we're done. > As Pete Resnick loves to point out, RFC prose can be normative without using RFC2119 words. The text of RFC2119 counsels against unnecessary use of the words it defines. It also contains this language: "...actually required for interoperation" (which use of rsa-sha1 clearly does not impede) "or to limit behavior which has potential for causing harm". I suppose this latter is the key issue. Still, I don't find it necessary or appropriate with respect to deprecating rsa-sha1, for reasons previously given. -MSK --f403043ed9e83fbee10551e3279a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
On Tue, Jun 13, 2017 at 6:55 PM, Jim = Fenton <fenton@bluepopcorn.net> wrote:

<= div bgcolor=3D"#FFFFFF">=
That being the case, why do we think people will pay attention to a MUST NOT today?
=20

Because implementations will stop supporting rsa-sha1, forcing the issue for any who upgrade. I'm all for having them stop supporting signing with rsa-sha1, but they should continue to support verification for a while.

= We can't have this logic both ways.=C2=A0 Scott claimed nobody pays att= ention to the advice in RFCs ("Operational practice=E2=80=8B isn't= closely coupled with standards changes").=C2=A0 If that's true, t= hen there's no meat to a MUST NOT anyway, and it really only matters wh= at people will implement.=C2=A0 And if that's true, then saying current= implementations neither sign with nor verify "rsa-sha1" because = it's deprecated suffices, and we're done.

As Pete = Resnick loves to point out, RFC prose can be normative without using RFC211= 9 words.

The text of RFC2119 counsels against unnecessary use of the= words it defines.=C2=A0 It also contains this language: "...actually = required for interoperation" (which use of rsa-sha1 clearly does not i= mpede) "or to limit behavior which has potential for causing harm"= ;.=C2=A0 I suppose this latter is the key issue.

Still, I= don't find it necessary or appropriate with respect to deprecating rsa= -sha1, for reasons previously given.

-MSK
=
--f403043ed9e83fbee10551e3279a-- From nobody Tue Jun 13 20:35:51 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5B12948B for ; Tue, 13 Jun 2017 20:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 bI6wUKFvacVn for ; Tue, 13 Jun 2017 20:35:48 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53AA12946C for ; Tue, 13 Jun 2017 20:35:48 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CCBBAC40593; Tue, 13 Jun 2017 22:35:46 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497411346; bh=/12iL8mdNFrzXhsZ+cngrtrUKoD1zbGiQj8LHRTZUUQ=; h=Date:In-Reply-To:References:Subject:To:From:From; b=SSdwBG7cgJfU0IALXP8ggILxfh2FmNrZeaE48t0ex7jzsWGn77nIaI03xI+Hr5Kke gjQHEplE6hZGDr2sroTgyKnAgnB1keslp2MUFfD5QGNkpYhYK2emIvA+K0yqKyP6jn CzTh9RX/YHJ8XxHQtaNqt5dMQ1sxgQYGPqkPYgKY= Date: Wed, 14 Jun 2017 03:35:35 +0000 In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <182B1730-A277-4E7F-ACFF-F51E766173BB@kitterman.com> Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 03:35:50 -0000 On June 13, 2017 11:16:11 PM EDT, "Murray S=2E Kucherawy" wrote: >On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton >wrote: > >> That being the case, why do we think people will pay attention to a >MUST >> NOT today? >> >> >> Because implementations will stop supporting rsa-sha1, forcing the >issue >> for any who upgrade=2E I'm all for having them stop supporting signing >with >> rsa-sha1, but they should continue to support verification for a >while=2E >> > >We can't have this logic both ways=2E Scott claimed nobody pays >attention to >the advice in RFCs ("Operational practice=E2=80=8B isn't closely coupled = with >standards changes")=2E If that's true, then there's no meat to a MUST >NOT >anyway, and it really only matters what people will implement=2E And if >that's true, then saying current implementations neither sign with nor >verify "rsa-sha1" because it's deprecated suffices, and we're done=2E What I should have said is sometimes standards lead and sometimes they fol= low=2E Bumping up the minimum RSA key size is the standards community catc= hing up to what the operational community did half a decade ago=2E OTOH, I= think rsa-sha1 usage will decline once there is strong MUST NOT guidance p= ublished=2E Not immediately, but considering the mail system development, = deployment, upgrade life cycle it's much better to give things a good push = in that direction now, before its time to panic=2E=2E Scott K From nobody Tue Jun 13 21:18:19 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044BE1319B2 for ; Tue, 13 Jun 2017 21:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 pAsCOtRdnkUs for ; Tue, 13 Jun 2017 21:18:16 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 E9587129AF4 for ; Tue, 13 Jun 2017 21:18:15 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:3d46:df10:69e2:448]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5E4IDRu023244 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 13 Jun 2017 21:18:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497413895; bh=Qtn04ibY+pmLJnfPJVva0mu3SLuk894i6ynvHdcNYno=; h=Subject:To:References:From:Date:In-Reply-To; b=TA/gPwtCQimfsDKoEx8kGU4bSP8msMBtnpZ5fBfWqunT9XeNQxoOu8lqbtpkhCuY1 Piw7Ps2RZbZd3fI9Zeknn5IJoPACMx6Wzz8obsxmffbNbPbxH5sRuq7EmXVhV2OTVR vHAhTZPiTDYS67tVIGMrj4wSG+fPqoO8X/6ERy+c= To: dcrup@ietf.org References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> From: Jim Fenton Message-ID: <58b8da69-353a-fadb-76bc-649def47a618@bluepopcorn.net> Date: Tue, 13 Jun 2017 21:18:09 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EDC562051EBDD9093CCB7373" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 04:18:18 -0000 This is a multi-part message in MIME format. --------------EDC562051EBDD9093CCB7373 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/13/17 8:29 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy > > wrote: > > On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton > > wrote: > >> That being the case, why do we think people will pay >> attention to a MUST NOT today? > > Because implementations will stop supporting rsa-sha1, forcing > the issue for any who upgrade. I'm all for having them stop > supporting signing with rsa-sha1, but they should continue to > support verification for a while. > > > We can't have this logic both ways. Scott claimed nobody pays > attention to the advice in RFCs ("Operational practice=E2=80=8B isn= 't > closely coupled with standards changes"). If that's true, then > there's no meat to a MUST NOT anyway, and it really only matters > what people will implement. And if that's true, then saying > current implementations neither sign with nor verify "rsa-sha1" > because it's deprecated suffices, and we're done. > > > As Pete Resnick loves to point out, RFC prose can be normative without > using RFC2119 words. > > The text of RFC2119 counsels against unnecessary use of the words it > defines. It also contains this language: "...actually required for > interoperation" (which use of rsa-sha1 clearly does not impede) "or to > limit behavior which has potential for causing harm". I suppose this > latter is the key issue. With respect to whether you need to include the MUST NOT (a point you made earlier), I'll defer to whatever the accepted practices are on the wording. But WRT the potential to cause harm, I refer to ekr's comment: > Well, this would require a second preimage. My sense is that nobody is > close to that at all with SHA-1.... > which I interpret as little potential for causing harm in the near future= =2E -Jim P.S. It would be helpful for you to identify which of your comments are made as chair and which are made hats-off. --------------EDC562051EBDD9093CCB7373 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/13/17 8:29 PM, Murray S. Kucherawy wrote:
On Tue, Jun 13, 2017 at 8:16 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Jun 13, 2017 at 6:55 PM, Jim Fenton <fenton@bluepopcorn.net> wrote:

That being the case, why do we think people will pay attention to a MUST NOT today?

 Because implementations will stop supporting rsa-sha1, forcing the issue for any who upgrade. I'm all for having them stop supporting signing with rsa-sha1, but they should continue to support verification for a while.
We can't have this logic both ways.  Scott claimed nobody pays attention to the advice in RFCs ("Operational practice​ isn't closely coupled with standards changes").  If that's true, then there's no meat to a MUST NOT anyway, and it really only matters what people will implement.  And if that's true, then saying current implementations neither sign with nor verify "rsa-sha1" because it's deprecated suffices, and we're done.

As Pete Resnick loves to point out, RFC prose can be normative without using RFC2119 words.

The text of RFC2119 counsels against unnecessary use of the words it defines.  It also contains this language: "...actually required for interoperation" (which use of rsa-sha1 clearly does not impede) "or to limit behavior which has potential for causing harm".  I suppose this latter is the key issue.

With respect to whether you need to include the MUST NOT (a point you made earlier), I'll defer to whatever the accepted practices are on the wording.

But WRT the potential to cause harm, I refer to ekr's comment:

Well, this would require a second preimage. My sense is that nobody is close to that at all with SHA-1....

which I interpret as little potential for causing harm in the near future.

-Jim

P.S. It would be helpful for you to identify which of your comments are made as chair and which are made hats-off.


--------------EDC562051EBDD9093CCB7373-- From nobody Tue Jun 13 21:24:53 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D605129B19 for ; Tue, 13 Jun 2017 21:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mNtg-MYZcRGm for ; Tue, 13 Jun 2017 21:24:49 -0700 (PDT) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42EB5131AF4 for ; Tue, 13 Jun 2017 21:24:49 -0700 (PDT) Received: by mail-ot0-x22a.google.com with SMTP id k4so102061118otd.0 for ; Tue, 13 Jun 2017 21:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rDtXtRWk3/OXrTEa0ZdssxLTURhCtvVwgSWVGlF9uuQ=; b=NEGYEzf95+sSkE6t9CPCqNU5Ge/a/zZx/VK4isq7qkw0G7oXl5NrESMqybv0rsXkM8 /8YajyJoqMnsgJdd0eWln3JaM/kfPWpFR22TJUfZO9kPzZDilmzJjyrWaXWbDSgh3qYM pH291vPSQK4ykvqCN5/v1HmJiDuKX18N0iR0c2bUY0JxQtGMUSsKKq9BFiO9op1z1Gtb OyElpax1Ggen8qWK4Pr07WVD0bZC517vot4QorUvL69RHoclkg1/dnikm4axBtWORxO4 MsmW2r25iOIyUqLWL5E/xrI4f9cn7FgYI3T1Gg23FClH+89osGf7moDKga4bbwIC02Na M1Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rDtXtRWk3/OXrTEa0ZdssxLTURhCtvVwgSWVGlF9uuQ=; b=FoOcNThiz8dkCpGdm+/uJb/TjaKrtMCQVqCW6eNJZRjKkEfQoYLXaI4g3OW70qChlu ew7bsz2TMRiAkxieu1LD8BlRmA8YOs+Uv8VAbbv7DMRHYbGMbKVeQwR+W3kJQnaH2xkk 0/xBsw9Ozi89jxAE9jOdREj92zga8nXIACwaoyIYJj/wJM0hZDTHJVUAINQfzwAKn7lG 8/LOpW1G9lRlpFtJiK4XtyIlFYshd5JUApsWul8uLaMxYw6IixhvlIO6AI6zJkqgW6wU gW1IeKnKVWGne24J2T24uiynbCsjKRNfv9dmk4/o//aXhvKvyiUVJqySTxAvYx3IT4Rv noWg== X-Gm-Message-State: AKS2vOzpDNyqqV884fwN02kEeFSF2aIXCzbnpg5eLXCA0bthr4TCZhof t1dVuuS5+QENGOZEaEUnFduFuva3VSt8 X-Received: by 10.157.44.102 with SMTP id f93mr2271088otb.199.1497414288685; Tue, 13 Jun 2017 21:24:48 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Tue, 13 Jun 2017 21:24:47 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> From: Phillip Hallam-Baker Date: Wed, 14 Jun 2017 00:24:47 -0400 X-Google-Sender-Auth: 8wjVND8LXV8qtusnb20P_UIhMP0 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 04:24:52 -0000 On Tue, Jun 13, 2017 at 11:28 PM, Scott Kitterman wrote: > > > On June 13, 2017 11:20:42 PM EDT, Jim Fenton wrote: >>Based on no supporting data whatsoever, my conjecture is that >>implementers pay a lot more attention to what RFCs say than people who >>are deploying others' implementations. Which basically boils down to >>MUSTs having a significant effect and SHOULDs having little. Which is >>why I favor making signing with rsa-sha1 a MUST NOT prior to making >>verification of rsa-sha1 signatures a MUST NOT. >> >>-Jim > > I agree on the importance of MUST versus SHOULD to implementors. In general terms, MUST tells me what I have to implement and SHOULD tells me the defaults. > > I still think we should MUST NOT both signing and verification for rsa-sha1 if for no other reason than to not require implementations to support three algorithms, but I am starting to get the sense I'm in the rough on that. It is a two step process in my view. First you rip out the generate, then once the transition is complete, you rip out the accept. SHA-1 is causing lots of issues as folk find 'funny' japes such as bjorking GIT repos by uploading the pdf from the shattering. H(A1) = H(A2) but H(Zip {A1, B, D, E, F}) <> H(Zip {A1, B, D, E, F}) Getting rid of SHA1 is the long term plan. But not in one go. From nobody Wed Jun 14 01:32:05 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFFC129468 for ; Wed, 14 Jun 2017 01:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9thJhHDnqYU4 for ; Wed, 14 Jun 2017 01:32:01 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26AD128B37 for ; Wed, 14 Jun 2017 01:31:59 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id 63so61846731ywr.0 for ; Wed, 14 Jun 2017 01:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=91qv5GMObSJDfAQamrS7dRVHGVktY75faoD9C7Jc0bg=; b=SeujxM4BDiO754Wh5ohueK3TZtw5HWVUgVLNSG+H4ya15W8oY8BTludW1quegbxDDz xonHg+1pgeS26wnxcWjoivgvjEbAoe3cTp/SbPaEnsMBn6A0FVOEac49hYxk4vPdIc0d 5InDUQRJkPJsuwAK1tkVROqY6aziEMz8izIqTb4EeonSWjBdc5SyFb/XH6RsfK40fpM5 rGZ3/wiTiKxUCK4czzyvvFSBkeyBFuubuOm87/Eum9JXQJqqit3aU4WbeYsRR+7LYNFo KiEsCNk8fHXqfCqJNm9mqE1tRlD80bzKhQnqLn68ZQJBrN6eeyHxVTKG6sSgoDBZLjz1 iRwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=91qv5GMObSJDfAQamrS7dRVHGVktY75faoD9C7Jc0bg=; b=W1mEJKJC+a077yNwHVvWVC2h4InuznXW3uCzLC8FzURcha6x0jtEXUwxyts+jNQeCo +6h3+0L3X1eTZ/J7hRTLMA1pOZMKljy4i28CzESQlpY+jNyzqOLvdT3Wj1ETn5097dPZ mSlt/b8CPpHth6cCUXwUVrffIRNgqqnYWyIenBbOlTFPS6WNZwcya0LqhNJTMESg9SWj HwvDCXZw7cKuM9xbBAHVLhmXEIA9Z9etUrziEzo2KMM4Nxch2P+IH0grA/eHsMjB9meS AsqjImEoegURP4YCFza1jeTwT9OUPzeoBueKNIChrsgM/rCAEdlm4F2WCqOLea9ybPuE 1RNw== X-Gm-Message-State: AKS2vOxpq2Tq38MIRnqvG7RTmdsYs9gNBbA5YTr6H4048oPRLza9CMb7 347gx2ddDQO6A7nicLaPyd+Nc4n1Sw== X-Received: by 10.129.40.149 with SMTP id o143mr6295871ywo.154.1497429118975; Wed, 14 Jun 2017 01:31:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.45.2 with HTTP; Wed, 14 Jun 2017 01:31:58 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> From: denis bider Date: Wed, 14 Jun 2017 02:31:58 -0600 Message-ID: To: Phillip Hallam-Baker Cc: "Murray S. Kucherawy" , dcrup@ietf.org, Scott Kitterman Content-Type: multipart/alternative; boundary="001a1140865ab687780551e76226" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 08:32:03 -0000 --001a1140865ab687780551e76226 Content-Type: text/plain; charset="UTF-8" Overall, I think there is currently too much being said on this list, and too little substance in it. However, to the extent that a decision is to be made, I support Phillip's below reasoning. +1. On Tue, Jun 13, 2017 at 8:11 PM, Phillip Hallam-Baker wrote: > On Tue, Jun 13, 2017 at 9:40 PM, Murray S. Kucherawy > wrote: > > On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman > > wrote: > >> > >> I think your proposed remedy is too mild though. Given the degree to > >> which the SHOULD NOT sign rsa-sha1 has been ignored for the last > decade, I > >> don't believe anything other than MUST NOT sign/MUST NOT verify > rsa-sha1 is > >> very useful. > > > > > > That being the case, why do we think people will pay attention to a MUST > NOT > > today? > > MUST NOT sign is perfectly viable and proper and will be followed by > anything that has the right to call itself compliant with the new > spec. > > MUST NOT verify is not supported by the state of the crypto and is > guaranteed to be ignored. It is an utterly illogical criteria since > there is no requirement to sign at all. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a1140865ab687780551e76226 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Overall, I think there is currently too much being said on= this list, and too little substance in it. However, to the extent that a d= ecision is to be made, I support Phillip's below reasoning.

+1.


On Tue, Jun 13, 2017 at 8:11 PM, Phillip Hallam-Baker <phill@ha= llambaker.com> wrote:
On Tue, Jun 13, 2017 at 9:40 PM, Murray S. Kucherawy
<superuser@gmail.com> wrot= e:
> On Tue, Jun 13, 2017 at 8:43 AM, Scott Kitterman <sklist@kitterman.com>
> wrote:
>>
>> I think your proposed remedy is too mild though.=C2=A0 Given the d= egree to
>> which the SHOULD NOT sign rsa-sha1 has been ignored for the last d= ecade, I
>> don't believe anything other than MUST NOT sign/MUST NOT verif= y rsa-sha1 is
>> very useful.
>
>
> That being the case, why do we think people will pay attention to a MU= ST NOT
> today?

MUST NOT sign is perfectly viable and proper and will be followed by=
anything that has the right to call itself compliant with the new
spec.

MUST NOT verify is not supported by the state of the crypto and is
guaranteed to be ignored. It is an utterly illogical criteria since
there is no requirement to sign at all.

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a1140865ab687780551e76226-- From nobody Wed Jun 14 03:02:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724DB1271FD for ; Wed, 14 Jun 2017 03:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 kpbBhugZ_1dy for ; Wed, 14 Jun 2017 03:02:39 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F36B6129B55 for ; Wed, 14 Jun 2017 03:02:38 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id g83so22925663qkb.3 for ; Wed, 14 Jun 2017 03:02:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2RzzrsTlX9IwbJNlBPEvkQItX/m9W3iJh946WR+cEUI=; b=EJS7Q6f+gZzh7Fj0fgo/K71cRI+anYpZU0UQ3qQm5VNzbt3+p7P2feguZpPS/pOzw2 p6WFbO5FJxiiyob6FW6/vt9ZeNuGAUEEaASr5rhtn9HxGMoixPiXyD/T+/bYvAwpT4EI k4e6fN/e2ywENI8nleNSr90S61NbfjL74Zp76cW4NCs85CO+CvJ4Jnx851jEst9ZZpuM qtRGIDDxgSE2+6w0fSoun/QpGeCnJ4ec6LWcftt2L0OdNNJobWePRdJ2oj7+chxun54k 5zodDHcKVZJjJSxotNBUET1OGXEcY5OPWwuG3vIzhy+emkGWU/8aXBzEUEL/beYETdwT 2irQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=2RzzrsTlX9IwbJNlBPEvkQItX/m9W3iJh946WR+cEUI=; b=LG/kHI0mBCORNiyfSCN5erqc4N+KnTHx8U6iv02bWm+W2lskoOIyZSKkCYTueL5PeL jBYTti1iSMf8E/TDIX5d8yuoeI37rrT95zttXi7HtxZTOJM+Nw4uoDVDxYk4i47Ox8eo kxvwmBjHPJm9dIbJUaxXFpV/HFLilpD2MpeNRQteZCcP455AIh+qMjxM7K1HoBOLn7A3 rgO9eTaXZXBcrcIMxUfmkYrfQbv10X62Xi0JKElwF12921VUe22/UoJeu8EGbY7A2F6Q RiZ6tZFPTKrm+Q6xKrsTlGIWjgcon8hYzekGr8KkCQ6+Dl2DBWMA2ZluPL4NHhlxOphD oINg== X-Gm-Message-State: AKS2vOxMcDWt+pqDWiSFxbXB4Udb+Kxgn9aeAgSAznAxcvkhvnSXLSpa Z/o0rP4YteWxeFN9vQEUneiZqfqTzCK2oo4= X-Received: by 10.55.44.129 with SMTP id s123mr4820409qkh.137.1497434557765; Wed, 14 Jun 2017 03:02:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.43.27 with HTTP; Wed, 14 Jun 2017 03:02:17 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> From: Seth Blank Date: Wed, 14 Jun 2017 11:02:17 +0100 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114f4440e3eb120551e8a6ef" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 10:02:41 -0000 --001a114f4440e3eb120551e8a6ef Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker wrote: > > It is a two step process in my view. First you rip out the generate, > then once the transition is complete, you rip out the accept. > I disagree. SHA-1 has been deprecated for far too long, but is still in wide use by major players. I'd argue step 1 was taken ages ago (with a SHOULD, not a MUST, but still...) and we're at step 2 *now* because senders aren't complying with up-to-date crypto standards on their own. While a large number of senders may not pay attention to language in an RFC, in my experience the verifiers have a strong incentive to follow the RFC language to a tee whenever possible to maximize interoperability. And the senders don't change unless the receivers make them. At this point, why don't we call a spade a spade, and say that the only way to kill SHA-1 in the wild dead is by saying verifiers MUST NOT verify SHA-1. Then the verifiers will do what they always do, and reach out to those not playing by standards and say "upgrade your implementation or it'll start being rejected in 90 days" and letting the problem solve itself. I believe this is exactly what draft-01 accomplishes. --001a114f4440e3eb120551e8a6ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker <phill@hallambaker.c= om> wrote:
It is a two step pro= cess in my view. First you rip out the generate,
then once the transition is complete, you rip out the accept.

I disagree. SHA-1 has been deprecated for f= ar too long, but is still in wide use by major players. I'd argue step = 1 was taken ages ago (with a SHOULD, not a MUST, but still...) and we'r= e at step 2 *now* because senders aren't complying with up-to-date cryp= to standards on their own.

While a large number of= senders may not pay attention to language in an RFC, in my experience the = verifiers have a strong incentive to follow the RFC language to a tee whene= ver possible to maximize interoperability. And the senders don't change= unless the receivers make them.

At this point, wh= y don't we call a spade a spade, and say that the only way to kill SHA-= 1 in the wild dead is by saying verifiers MUST NOT verify SHA-1. Then the v= erifiers will do what they always do, and reach out to those not playing by= standards and say "upgrade your implementation or it'll start bei= ng rejected in 90 days" and letting the problem solve itself.

I believe this is exactly what draft-01 accomplishes.
--001a114f4440e3eb120551e8a6ef-- From nobody Wed Jun 14 04:53:42 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF77C129C58 for ; Wed, 14 Jun 2017 04:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eGmgw7BZeNIz for ; Wed, 14 Jun 2017 04:53:39 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDB61200B9 for ; Wed, 14 Jun 2017 04:53:38 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id g66so79292644vki.1 for ; Wed, 14 Jun 2017 04:53:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nlBrunUbho8cBa4s4HiTwMdp4Qrekqgh+5wVprCDj90=; b=qkzf3uVRhhrFwRY8B0KmjgjC1TXtCr+YVAsnU4p1sh5ML5h/Fvh1qT5w6VDMd2yKjF Hgx9zGUCGPNBj1T/8apY/zGlgHn8/h3Xz9fvUr+KSZ6xrHMFWt05xn9cbOAwbjdB2utp Z5xC/8UB2Gc2tu2yom8AuFC+2N7CQUlf/9dKn63tIDjUDiyJc6AZaJCZDapvRBzdq2cO /jDjQpz/hxilBzosvzswoyRkgqjAbzoNu0oU9vW2unfUlfYqTcwRE/5RYCEyxToeZ/BJ yTBoyrA4hUAYrdLE2psFrX3DtLf/V/dPABJT3oO/RNPTZrU7VEJu1IICMyLAFXjLb022 h1Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nlBrunUbho8cBa4s4HiTwMdp4Qrekqgh+5wVprCDj90=; b=pk9VKEcj0x2+Hmzr/YpdO7D7aaWWip82s3PndiZObr6eTw5kjMW13kePvaP03qimq4 mKYM8OujHHT/LT+C57NZRdYQTSElU2TY98TXEezp3EW5Ge5lgj45Uah1eDm6LtW4uMOS lz0rGW7zViFadjZqLJo5qKX92pArWlX5GM7oaUpUNLX2148ys3iM2Pmuhhne1GyMuCZO qxub3kRZMW8WyIy5aZBwEmFNNAHMfJLo1HiCQIg98/Gf/f/LhRifS8v5L8iZqWVxhUyf b+C2I1++4nV1MC8pR8CBSnxCtKfUm68N0f95ZXAL+ffWoMp3IWsOsAfks40XbY/59niK Gw8A== X-Gm-Message-State: AKS2vOxbWLTH753F7TmNa8rwcB5YoTmxOvrqh6dJ7AAhHtGkVO2RK1pT zHfEo5LAM8e11J+UwtoUCLNjGSaTcTdl X-Received: by 10.31.3.100 with SMTP id 97mr120046vkd.80.1497441218127; Wed, 14 Jun 2017 04:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Wed, 14 Jun 2017 04:53:37 -0700 (PDT) In-Reply-To: <58b8da69-353a-fadb-76bc-649def47a618@bluepopcorn.net> References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <58b8da69-353a-fadb-76bc-649def47a618@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Wed, 14 Jun 2017 04:53:37 -0700 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11428ab2e0eb660551ea33ec" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:53:41 -0000 --001a11428ab2e0eb660551ea33ec Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 9:18 PM, Jim Fenton wrote: > As Pete Resnick loves to point out, RFC prose can be normative without > using RFC2119 words. > > The text of RFC2119 counsels against unnecessary use of the words it > defines. It also contains this language: "...actually required for > interoperation" (which use of rsa-sha1 clearly does not impede) "or to > limit behavior which has potential for causing harm". I suppose this > latter is the key issue. > > > With respect to whether you need to include the MUST NOT (a point you made > earlier), I'll defer to whatever the accepted practices are on the wording. > > But WRT the potential to cause harm, I refer to ekr's comment: > > Well, this would require a second preimage. My sense is that nobody is > close to that at all with SHA-1.... > > which I interpret as little potential for causing harm in the near future. > This actually leads me to believe that there's no urgency to deprecate rsa-sha1 at all. > P.S. It would be helpful for you to identify which of your comments are > made as chair and which are made hats-off. > Unless you see me explicitly saying the hat is on, especially in a technical discussion, the hat is always off. I'm participating. I don't think it's ever appropriate for a chair to make hatted assertions about technical topics unless being called on to make a decision when the WG is deadlocked, and that should be exceptional. In the chair role, we just run the process. -MSK --001a11428ab2e0eb660551ea33ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 9:18 PM, Jim Fenton <fenton@= bluepopcorn.net> wrote:
=20 =20 =20
As Pete Resnick loves to point out, RFC prose can be normative without using RFC2119 words.

The text of RFC2119 counsels against unnecessary use of the words it defines.=C2=A0 It also contains this language: "...actually required for interoperation" (which us= e of rsa-sha1 clearly does not impede) "or to limit behavior which has potential for causing harm".=C2=A0 I suppose t= his latter is the key issue.

With respect to whether you need to include the MUST NOT (a point you made earlier), I'll defer to whatever the accepted practices ar= e on the wording.

But WRT the potential to cause harm, I refer to ekr's comment:

Well, this would require a second preimage. My sense is that nobody is close to that at all with SHA-1....

which I interpret as little potential for causing harm in the near future.

This actually leads me to= believe that there's no urgency to deprecate rsa-sha1 at all.
=C2= =A0
P.S. It would be helpful for you= to identify which of your comments are made as chair and which are made hats-off.

Unless you see me explicitly saying the hat is on, especi= ally in a technical discussion, the hat is always off.=C2=A0 I'm partic= ipating.

I don't think it's ever appropriate for = a chair to make hatted assertions about technical topics unless being calle= d on to make a decision when the WG is deadlocked, and that should be excep= tional.=C2=A0 In the chair role, we just run the process.
-MSK
--001a11428ab2e0eb660551ea33ec-- From nobody Wed Jun 14 04:59:39 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD1612EBCD for ; Wed, 14 Jun 2017 04:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KrIhZyVaBtyJ for ; Wed, 14 Jun 2017 04:59:35 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A866212EBCC for ; Wed, 14 Jun 2017 04:59:35 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id g66so79374436vki.1 for ; Wed, 14 Jun 2017 04:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fA3VBAcilRdAMMVeV4FANHCN+RoDAF5GUvwboLqDk3U=; b=Fo+wEC/TtYMo8mGyQZIo4tY3GQFfbVAWoDlxqJFM42NxorJKc3YKTnfIo6I+5Q/Vbt nyKOzf0coRhEl1lxEfgIocw26DHlJ+8M/Gs65NknvNHpKNV5mnlYIw7eixnw9B6FQyYH VUetgTZes6fTiTKPRLSwxUS0H27OhLKf5Ozuz5mL4u38OHPsD7LrQQfwiWDOF1jBMDNF qGGC4yJwYzNqeDsPAOegoaK8aXgR2GRDz3RXqu9R+UA1gGpJDGEU8FUi/8K43PHpAYQr KN5KWwyx4C/i/4Watchf2sAbcgOZbg0uoGbdeZuEjztBjYoWy7U/iILSOloxPU3i0ilj 2/Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fA3VBAcilRdAMMVeV4FANHCN+RoDAF5GUvwboLqDk3U=; b=qneLHoaRymn6ZXaLpN6Rs3zrqmJg+cJBb1QghKAogwn3PhpnPz+sScA16LDFnZ8LhH CSY/CK0hTBp9aZRFo9/h1ZUduIJgKkZ5pFjfoifj9sYB6OQ4oWDoWgMM4W/fpdjOStbU HdVeYaIEn8MrBmqoqqEI9Pq7WBoSKDLhx6jizHq4BDDPvLDmLqrrc3qOUnUoteJndM5r lo5wiad6dIPl13dgqserUpUrqaWjmIW2GHf+OzcVbuocghe+BkKtE9w0VffXfjdttFR7 jxGQRjAS5p2yoFVohITS58dQttSke06hCDUFg2D70dmht3W0WQ1ExY50xe2cddZW71Yr ikpw== X-Gm-Message-State: AKS2vOzML2uw0sDMaWO+9h11I8vsvnpMXJOOfZ5/oIzcl+OuJVdGov4q 82TXItwZyDsWwSl36xTnPk8/8zFYwQ== X-Received: by 10.31.190.145 with SMTP id o139mr113124vkf.35.1497441574832; Wed, 14 Jun 2017 04:59:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Wed, 14 Jun 2017 04:59:34 -0700 (PDT) In-Reply-To: References: From: "Murray S. Kucherawy" Date: Wed, 14 Jun 2017 04:59:34 -0700 Message-ID: To: Martin Thomson Cc: dcrup@ietf.org, Alexey Melnikov Content-Type: multipart/alternative; boundary="001a1143991023cf6d0551ea491f" Archived-At: Subject: Re: [Dcrup] Deprecating algorithms X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 11:59:38 -0000 --001a1143991023cf6d0551ea491f Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 6:37 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 7:52 AM, Martin Thomson > wrote: > > This is a fine thing. Do you want to propose text for the charter? >> > > The diff to the current charter is going to be mighty small, so sure, I'll > do it this week sometime. > Proposed revised charter text. A crypto person should review it to make sure it's not nonsense since I only know enough about crypto to be dangerous. Apologies for the silly wrapping; I fought with the gmail interface to make it pretty and failed. -- snip -- The DKIM Crypto Update (DCRUP) Working Group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records. DKIM also currently supports use of SHA1 coupled with RSA. SHA1 has been formally deprecated due to weakness especially when used in the context transport security, though the risk of a successful preimage attack is less severe. Still, the community wishes to discourage its continued use in the DKIM context. DCRUP will consider four types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, changes to key strength advice and requirements, deprecating the use of SHA1, and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records. It will limit itself to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. --001a1143991023cf6d0551ea491f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 13, 2017 at 6:37 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
On Tue, Jun 13, 2017 at 7:52 AM, Mart= in Thomson <martin.thomson@gmail.com> wrote:

This is a fine th= ing.=C2=A0 Do you want to propose text for the charter?

The diff to the current charter is = going to be mighty small, so sure, I'll do it this week sometime.

Proposed revised charter tex= t.=C2=A0 A crypto person should review it to make sure it's not nonsens= e since I only know enough about crypto to be dangerous.=C2=A0 Apologies fo= r the silly wrapping; I fought with the gmail interface to make it pretty a= nd failed.

-- snip --

The DKIM Crypto Update (DCRUP= ) Working Group is chartered to update
DomainKeys Identified Mail (DKIM,= RFC 6376) to handle more modern
cryptographic algorithms and key sizes= . DKIM (RFC 6376) signatures
include a tag that identifies the hash alg= orithm and signing algorithm
used in the signature. The only current al= gorithm is RSA, with advice
that signing keys should be between 1024 an= d 2048 bits. While 1024 bit
signatures are common, longer signatures ar= e not because bugs in DNS
provisioning software prevent publishing long= er keys as DNS TXT records.

DKIM also currently supports use of SHA1 = coupled with RSA.=C2=A0 SHA1 has been formally deprecated due to weakness e= specially when used in the context transport security, though the risk of a= successful preimage attack is less severe.=C2=A0 Still, the community wish= es to discourage its continued use in the DKIM context.

DCRUP will consider four types of changes to DKIM: additional signingalgorithms such as those based on elliptic curves, changes to key
stren= gth advice and requirements, deprecating the use of SHA1, and new public ke= y forms, such as
putting the public key in the signature and a hash of t= he key in the
DNS to bypass bugs in DNS provisioning software that preve= nt publishing
longer keys as DNS TXT records. It will limit itself to e= xisting
implemented algorithms and key forms. Other changes to DKIM, suc= h as new
message canonicalization schemes, are out of scope. The WG wil= l as far
as possible avoid changes incompatible with deployed DKIM sign= ers and
verifiers.


--001a1143991023cf6d0551ea491f-- From nobody Wed Jun 14 05:15:28 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C6C12EBD0 for ; Wed, 14 Jun 2017 05:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 fQgiDOE2UqWy for ; Wed, 14 Jun 2017 05:15:25 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B8C129B35 for ; Wed, 14 Jun 2017 05:15:25 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 27A0EC402AE for ; Wed, 14 Jun 2017 07:15:24 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497442524; bh=XTrwhwYBdh5ZilJ3mWZpq4OoiNH03O+js8dcynyVDXA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qnkxsYoswyKbddp8Gr9PvrATTkHQvLhVf1pR3jsqDgajL1eoJSa7NKDNZ6qDoPb9g L2HtDRc8ticZzjTXeie69WLKvDTXmG5qdj332OARzQJrZVzG1FXXHRvQW5CAWu/j5K +bAMHrd8OT5Ya/UZUD3ZpNLP9RlZuPvtssOSxC2I= From: Scott Kitterman To: dcrup@ietf.org Date: Wed, 14 Jun 2017 08:15:23 -0400 Message-ID: <4405396.8sPtXljfs2@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <58b8da69-353a-fadb-76bc-649def47a618@bluepopcorn.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 12:15:27 -0000 On Wednesday, June 14, 2017 04:53:37 AM Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 9:18 PM, Jim Fenton wrote: > > As Pete Resnick loves to point out, RFC prose can be normative without > > using RFC2119 words. > > > > The text of RFC2119 counsels against unnecessary use of the words it > > defines. It also contains this language: "...actually required for > > interoperation" (which use of rsa-sha1 clearly does not impede) "or to > > limit behavior which has potential for causing harm". I suppose this > > latter is the key issue. > > > > > > With respect to whether you need to include the MUST NOT (a point you made > > earlier), I'll defer to whatever the accepted practices are on the > > wording. > > > > But WRT the potential to cause harm, I refer to ekr's comment: > > > > Well, this would require a second preimage. My sense is that nobody is > > close to that at all with SHA-1.... > > > > which I interpret as little potential for causing harm in the near future. > > This actually leads me to believe that there's no urgency to deprecate > rsa-sha1 at all. The thing about surprises is that they don't show up when expected. Given we have rsa-sha256 and want to add another algorithm, taking the MUST NOT sign step now for rsa-sha1 so it's a short putt to remove it entirely when such a weakness is unearthed is a prudent step forward. Scott K From nobody Wed Jun 14 05:34:47 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F6212EBDF for ; Wed, 14 Jun 2017 05:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7JRG9qHgwGgt for ; Wed, 14 Jun 2017 05:34:43 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDA912E04F for ; Wed, 14 Jun 2017 05:34:43 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id y70so41579246vky.3 for ; Wed, 14 Jun 2017 05:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T/BGRHJuG6BP3NpAPZ1Z8uv4xpitpndg1QphPIowrk0=; b=eJVxEuI2EPgIgyXW2S1R6HOM9dbC95zHQjLkB/xz0mj063s6NAUmIehEBW1Z1brJ8t yO5dZBK1i1gLWohdC88gjVTcJTwLKy/QcetE8BbAg4+Jr+xxv9GbScYfhealFDrRWLjc 2Iw9NcdBwp6IhlMF27a3rBL7MSrk8K6RLfetGEjd2iZWc7uM22yLQ87As1t9gHn9Jx6e oNnp1fSG+3D8CtOXipbvQTnbYqjSxw2EkKnt3QUI2P7UNM6mPRJhSgN2OAOpBiGKRF/N sv6DOZf9QCUPh1M9kZrsOioNjW1UVDGneRqCO83KrpXlnY/HioGpxhkp35/+di8AiKj+ 48Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T/BGRHJuG6BP3NpAPZ1Z8uv4xpitpndg1QphPIowrk0=; b=bwQmz76aBg2xyfGsaRw0StX/xE/+5CkwSBR4R2EfyUOzpAWRtF6rTea1A1Qz2P2Lle 5mUqdcFfvK1EsvlXY1kidu0yGwo10QfWB2j6DG65zgh3MjqTap/uFd7SsIjmh+kO1ZnP Ia5c6/m3YqANomipgjShwZ302H+LSBeRaMpmBfmNXirlfrkNKi/q0fzydRrFVGIM9SZ2 MVf6ba2aB6GrsMd9nXUeDJRyvrfOobXm1iu4qL0L3d+GlwzJOO18iyCWxHL0bznspR79 ToDepJUs+QplsxJtY1tYQdNT9QEcHKM4/FVcwuyS/Tjrj/xB7YVVl8ERjcPqO1osrYtv /wRg== X-Gm-Message-State: AKS2vOzgdlrjizfr/7eAgjyh+GGAYehbmbsheEe5xeRmOglh1Q0aoAz8 3CfwD66H0xsn6+u2HFWND/GWWWF6wzeR X-Received: by 10.31.2.204 with SMTP id 195mr205287vkc.65.1497443682590; Wed, 14 Jun 2017 05:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.6 with HTTP; Wed, 14 Jun 2017 05:34:41 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> From: "Murray S. Kucherawy" Date: Wed, 14 Jun 2017 05:34:41 -0700 Message-ID: To: Seth Blank Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113da7f4c5b0dc0551eac610" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 12:34:45 -0000 --001a113da7f4c5b0dc0551eac610 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 3:02 AM, Seth Blank wrote: > On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: >> >> It is a two step process in my view. First you rip out the generate, >> then once the transition is complete, you rip out the accept. >> > > I disagree. SHA-1 has been deprecated for far too long, but is still in > wide use by major players. I'd argue step 1 was taken ages ago (with a > SHOULD, not a MUST, but still...) and we're at step 2 *now* because senders > aren't complying with up-to-date crypto standards on their own. > [...] > I think that's an interesting perspective, specifically that step 1 was taken a while ago, and I agree. What we're discussing is the right way to "rip out the accept". I don't believe that either actor will be compelled to do anything more by "MUST NOT" than by simply "We don't use that anymore because $REASONS." I've been a medium-sized receiver before, and I work for a large sender now. If I decide I'm going to comply with the update, either prose is compelling to me. Am I exceptional in that regard? Maybe I'm atypical because I'm an IETF participant, but to me the general issue here plain old operational inertia rather than the absence of an RFC telling them what to do. If a receiver says "update within 90 days or else", it will happen no matter what the text says. It could happen today even without us publishing anything at all. I would even posit that it's more likely for M3AAWG to trigger that action than the IETF. Please note that I'm not only being sticky on this point because I think it's wrong. Unnecessary use of RFC2119 language is a topic that's come up with nearly every email-related standards track RFC where I've been a contributor and has resulted in DISCUSSes during IESG Evaluation. I'm hoping to head off some of that back-and-forth later by getting it sorted out now. -MSK --001a113da7f4c5b0dc0551eac610 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 14, 2017 at 3:02 AM, Seth Blank <seth@valimai= l.com> wrote:
On Wed, Jun 14, 2017 = at 5:24 AM, Phillip Hallam-Baker <phill@hallambaker.com>= wrote:
It is a two step process in my view. = First you rip out the generate,
then once the transition is complete, you rip out the accept.

I disagree. SHA-1 has been deprecate= d for far too long, but is still in wide use by major players. I'd argu= e step 1 was taken ages ago (with a SHOULD, not a MUST, but still...) and w= e're at step 2 *now* because senders aren't complying with up-to-da= te crypto standards on their own.
[...]

I think that's an interesting perspective, specif= ically that step 1 was taken a while ago, and I agree.=C2=A0 What we're= discussing is the right way to "rip out the accept".

I don't believe that either actor will be compelled to do anythi= ng more by "MUST NOT" than by simply "We don't use that = anymore because $REASONS."=C2=A0 I've been a medium-sized receiver= before, and I work for a large sender now.=C2=A0 If I decide I'm going= to comply with the update, either prose is compelling to me.=C2=A0 Am I ex= ceptional in that regard?=C2=A0 Maybe I'm atypical because I'm an I= ETF participant, but to me the general issue here plain old operational ine= rtia rather than the absence of an RFC telling them what to do.

If a receiver says "update within 90 days or else", it wil= l happen no matter what the text says.=C2=A0 It could happen today even wit= hout us publishing anything at all.=C2=A0 I would even posit that it's = more likely for M3AAWG to trigger that action than the IETF.

<= div>Please note that I'm not only being sticky on this point because I = think it's wrong.=C2=A0 Unnecessary use of RFC2119 language is a topic = that's come up with nearly every email-related standards track RFC wher= e I've been a contributor and has resulted in DISCUSSes during IESG Eva= luation.=C2=A0 I'm hoping to head off some of that back-and-forth later= by getting it sorted out now.

-MSK
--001a113da7f4c5b0dc0551eac610-- From nobody Wed Jun 14 06:00:12 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3824129B3C for ; Wed, 14 Jun 2017 06:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 nooHIKuvPlUV for ; Wed, 14 Jun 2017 06:00:09 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 5E2771294F8 for ; Wed, 14 Jun 2017 06:00:09 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5ECvMbU006737; Wed, 14 Jun 2017 14:00:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=LGdQFeHEgLk3EE+uq6KgOCwG4l+jjf0+ddrcCpLOyb4=; b=Ur6zzASSYfdBbG0YCUv8vvZRqbM+UM64R9QHagD0ox6oTdYmSA5v7fPzF62mC4yBTeco SMGTH42GjxdLfRfegKIphDduvRrQoxYJuqTQhvK6q2bD+X1EmcBiuDXbrlsGCyYOTft+ 19Iuqc/Orhzgn2dvZXWqIeFUOEK4/pRLRu3B6uZc+ksI9BhOmMyP/UHQ3ox8E3Fl6UI+ czRAnT/JA7rNxF5NWRX0x1JKTNpR1bqjaBMSkUiRUOxKkE01Ro83VxuOXcZe3pHkfj/b ZNRQ0RMSzTabLOyhbMRwRQ5bepRzDxE9Dw9TGW7y6Q3/7/oZu5djx2A0hGmafMCvyLJA eA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2b33q98syd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 14:00:07 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5ECuBVe008159; Wed, 14 Jun 2017 09:00:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3udns0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 09:00:05 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 09:00:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 14 Jun 2017 09:00:04 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 14 Jun 2017 09:00:04 -0400 From: "Salz, Rich" To: Scott Kitterman , "dcrup@ietf.org" Thread-Topic: [Dcrup] rsa-sha1 usage Thread-Index: AQHS4779Tb5v0bLckEm+niEmYG2uC6IiIeoA///KSQ2AAK9/gIAAFrbggABvgACAABE+gIAAprWAgAAEY4CAABZ3gIAAA5QAgAANvICAAH9BgIAABhWA///JCxA= Date: Wed, 14 Jun 2017 13:00:03 +0000 Message-ID: <9dfe775844dc465b9765bd9fe65883b6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <58b8da69-353a-fadb-76bc-649def47a618@bluepopcorn.net> <4405396.8sPtXljfs2@kitterma-e6430> In-Reply-To: <4405396.8sPtXljfs2@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.194] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140218 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140218 Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 13:00:11 -0000 As an indvidiual, I first thought there was no urgency given how DKIM is us= ed. But PHB's message (the one that included the phrase national security)= convinced me otherwise. We do/could have nation-state agencies involved h= ere. Time to move off SHA1=20 From nobody Wed Jun 14 07:06:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A0A12E872 for ; Wed, 14 Jun 2017 07:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JBT6-RNsA5LK for ; Wed, 14 Jun 2017 07:06:03 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D922F1294B7 for ; Wed, 14 Jun 2017 07:06:02 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id s3so1083313oia.0 for ; Wed, 14 Jun 2017 07:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=VdPPcvIWakc0zo5Yw/NYbyO610CASgVoqgdCaDkah4I=; b=ZsDH9X08Hsjrzy+d1ls3IjClR64xtA8B03lEJ7+K+KAiv1zf9RCjRxAtOmXfaI+F53 Jxn7fpfffcN9QA2MjZ1i63Pp86l+5dLDzrQxh7s5zjhTYBrdUlDqpEWopnEC1Nhi9BR1 2d+6S6anqZqdvVBktU7zjeBQRrh6rIWit7YM4ZwuwlnROuuDOuooSePKCIEaxxO3b5EW Oyf44HDGxzQ3unW6kLpUazn6bUhHW+l23kaG4V8NdaRYNFEE/RHjpbhMjFQUozmtz/Xy jbkrgcv3E0QWyaiCVMaN5Dx5c01+zYUX1QPxBB/Widf+aR9hBbEY/VrFRS092/xk7ueu l7rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=VdPPcvIWakc0zo5Yw/NYbyO610CASgVoqgdCaDkah4I=; b=r/g3sFAHOT7qoociQYS+t/PRRsOItwSgHA9CwWahyIV4b8PSpoKboB0LrghOK6IZbf bq2fw1WtgSq9VfNYDmxSqsqiKNO/Fq0HnOFyJm7yP4g0grqhlQK63lE4D7Ipr7vILjOo z+eb7i0RbbgL1F3VpVtfZXnl/A9jHhlFqZ///YfR70FkVItyhLnr/Ii7ucnd0OjUojpW A/IC8ZKKt/r25Q3fspOB+LSQ6F/sUbNmXf1ePHRpFikA/w+I/bnQUXTV58c/13Qt5WqD ZD8zG7wUV+IdBCQbPsEGUE3do7z4AbQkRADvOUfmwWXxy+cmQf9HjIdjtFlgRvLx25h5 ScCg== X-Gm-Message-State: AKS2vOyviHaVvVgohXDkhF2kSxOqgRWjeGz/yHo9nZJt5pkZPtQB8cKR 1TqAE2DxgL6mMKlObE2n4PyW8QiNgg== X-Received: by 10.202.102.142 with SMTP id m14mr186522oik.154.1497449162103; Wed, 14 Jun 2017 07:06:02 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.23.5 with HTTP; Wed, 14 Jun 2017 07:06:01 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> From: Phillip Hallam-Baker Date: Wed, 14 Jun 2017 10:06:01 -0400 X-Google-Sender-Auth: tWaOpz20FKJaiFWdwxXLHLswU-Y Message-ID: To: "Murray S. Kucherawy" Cc: Seth Blank , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 14:06:05 -0000 On Wed, Jun 14, 2017 at 8:34 AM, Murray S. Kucherawy wrote: > On Wed, Jun 14, 2017 at 3:02 AM, Seth Blank wrote: >> >> On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker >> wrote: >>> >>> It is a two step process in my view. First you rip out the generate, >>> then once the transition is complete, you rip out the accept. >> >> >> I disagree. SHA-1 has been deprecated for far too long, but is still in >> wide use by major players. I'd argue step 1 was taken ages ago (with a >> SHOULD, not a MUST, but still...) and we're at step 2 *now* because senders >> aren't complying with up-to-date crypto standards on their own. >> [...] > > > I think that's an interesting perspective, specifically that step 1 was > taken a while ago, and I agree. What we're discussing is the right way to > "rip out the accept". > > I don't believe that either actor will be compelled to do anything more by > "MUST NOT" than by simply "We don't use that anymore because $REASONS." > I've been a medium-sized receiver before, and I work for a large sender now. > If I decide I'm going to comply with the update, either prose is compelling > to me. Am I exceptional in that regard? Maybe I'm atypical because I'm an > IETF participant, but to me the general issue here plain old operational > inertia rather than the absence of an RFC telling them what to do. I don't understand your line of reasoning. I certainly disagree with it. DKIM is an IETF specification. If IETF makes a change then M3AAWG will almost certainly follow suit. But I do not think it at all likely M3AAWG would start making suggestions on technical matters like this in preference to IETF action. People ignore standards all the time. But there are consequences. Getting people to upgrade their crypto is actually one of the easier things to persuade people to do. The only circumstance when it becomes hard is when the new crypto is not widely understood by the applications that must receive the messages and there is no way to negotiate an upgrade. That is why S/MIME was stuck doing 3DES for a decade. Any transition has to be driven by the state of the deployed infrastructure. The sequence of facts that need to be gathered are as follows: X = proportion of implementations that accept RSA/SHA-2-256 signatures. Y = proportion of implementations that accept Ed25519 signatures >From these facts we then build a state machine that guarantees that 95-99% of all messages will be correctly processed by the deployed infrastructure. Phase 1) Dual sign with RSA/SHA-1 and RSA/SHA-2-256 Phase 2) Sign with RSA/SHA-2-256 Phase 3) Sign with Ed25519 The decision to use MUST, MUST NOT, etc. is then driven by math. M3AAWG does not make the decision but they are probably best placed to collect the data. From nobody Wed Jun 14 09:25:47 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9143128C83 for ; Wed, 14 Jun 2017 09:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 EIJt03fYVbUa for ; Wed, 14 Jun 2017 09:25:44 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BB1128B4E for ; Wed, 14 Jun 2017 09:25:43 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id c10so5814897qtd.1 for ; Wed, 14 Jun 2017 09:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=UcBoSHyjBRjE8FVyfL9ERbJX1yzzgVbwF5ih6Aahheo=; b=ZX/DrN06fyRXAIFvM90qS/zw2ewyXE4YkH/F45T/shPTeGq5msY5pHLb1M5kTHVkgS SdIGyTmgQFdDqtVZ4+mKyKyGkmG25KIEJEJGg9A1tTQPOd3gLdPmTnhUJ+pZW5oQZrKb owzWSfTFR+nU/HFbaXBvzn94URMUxWcHjQ+5iVeObVzZFuQVu3lJ20tar9QQDAKcUZKo UtiH1nPIBpl6CVe//usM8xLKeXO1SJd0+WbEw2InQwjDz9fUkeHEFXtOWNDnb1aksRH4 2p06q/NT6qcNSJXoEtrtigpPf3dLBoqQY4ZEQJeHPDOh0pBSmX6HojDAW08kdMJYCUDa Wftw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=UcBoSHyjBRjE8FVyfL9ERbJX1yzzgVbwF5ih6Aahheo=; b=b+N5qIi885l4D6RyDnIV3xbsB62dm1mfj5oszBrOC27pGqAvIaAE8LcY0Fo/2RFovD 6VtpAq9SPDIt29Q9eA0db+yZvEbu/Ln1lieJ+QiqDqY4G4q18CgKopuyc5jfB6MJpfWq MtaVNvSVshqu0PdN6RxMB3mrVxc9zMySzH9TNE+tdajrV6hOHl7aSU4peWBR7ODswujM WiSlR9UfgfvNPrT6HvnCKnd6PwcxXDggwof3WCMgtY8ANc7NUjCbonSNGrRSBV7mC6FM eL4hmP2pYh5iIhsmnB1uFDvf9+P3UzQ2LCzFdKy86+s7zuBSHKZIqc092UG0QAhV2yO+ KbkQ== X-Gm-Message-State: AKS2vOw+fOE29QjhdA+JqBHYJTcsYLb4VhGStRmuDwBRtAeNSAfZdQtW 8UPTa2TagFMf4/ZdoxA6Dd30FWF6hFizqwo= X-Received: by 10.55.59.10 with SMTP id i10mr1057287qka.15.1497457543031; Wed, 14 Jun 2017 09:25:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.183 with HTTP; Wed, 14 Jun 2017 09:25:42 -0700 (PDT) In-Reply-To: References: <5bf52517591d4950aec335d31bcf3631@usma1ex-dag1mb1.msg.corp.akamai.com> <29B74569-6BB3-43F8-9549-566DA405B1FF@kitterman.com> <57fda1d5-b0b7-f226-60db-7f4c47233fc7@bluepopcorn.net> <87dfdc8c-5acc-e51e-a6d3-1e35611419b7@bluepopcorn.net> From: Peter Goldstein Date: Wed, 14 Jun 2017 09:25:42 -0700 Message-ID: To: Phillip Hallam-Baker , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1148c6b8eb49610551ee0097" Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:25:47 -0000 --001a1148c6b8eb49610551ee0097 Content-Type: text/plain; charset="UTF-8" > Any transition has to be driven by the state of the deployed > infrastructure. The sequence of facts that need to be gathered are as > follows: > X = proportion of implementations that accept RSA/SHA-2-256 signatures. > Y = proportion of implementations that accept Ed25519 signatures > > >From these facts we then build a state machine that guarantees that > 95-99% of all messages will be correctly processed by the deployed > infrastructure. > Phase 1) Dual sign with RSA/SHA-1 and RSA/SHA-2-256 > Phase 2) Sign with RSA/SHA-2-256 > Phase 3) Sign with Ed25519 > The decision to use MUST, MUST NOT, etc. is then driven by math. > M3AAWG does not make the decision but they are probably best placed to > collect the data. The phases as described here do not fit the situation at hand. As written they mix two separate questions - rsa-sha1 vs rsa-256 and RSA vs Ed25519. Those need to be considered separately. Moreover, for the rsa-sha1/rsa-sha256 the phases are also inappropriate because X is already ~100% Verifiers were required to support rsa-sha256 by RFC 6376 - https://tools.ietf.org/html/rfc6376#section-3.3 - and I'm unaware of any verifier who does not support rsa-sha256. Combine that with the fact that a large number of systems (easily the majority of DKIM signers) currently sign with rsa-sha256 (G Suite, Office365, Facebook, Twitter, etc.) and see no need to dual sign with rsa-sha1, there's no reason to believe that there is any significant non-zero population of receivers that validate DKIM for rsa-sha1 but not for rsa-sha256. Dual signing with rsa-sha1 and rsa-sha256 is not a necessary step in the rsa-sha1 deprecation process. Rolling out Ed25519 signing support is a separate question, and it should not be mixed with the rsa-sha1 deprecation question, even if they are rolled into one document. There is, as far as I know, no intention to deprecate RSA in favor of Ed25519. Rather the intention is to add Ed25519 as a more modern option for senders that supports shorter keys with better resistance to attacks. The current question before the working group is basically a procedural one - Should we use the RFC2119 MUST NOT language for verifiers and their acceptance of rsa-sha1 (transitioning from the affirmative SHOULD in RFC 6376) or avoid the use of such language? Best, Peter -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 <(415)%20793-5783> --001a1148c6b8eb49610551ee0097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Any transition has to be driven by the state of the deployed
infr= astructure. The sequence of facts that need to be gathered are as
follow= s:
X =3D proportion of implementations that accept RSA/SHA-2-256 signatu= res.
Y =3D proportion of implementations that accept Ed25519 signatures<= br>
>From these facts we then build a state machine that guarantees t= hat
95-99% of all messages will be correctly processed by the deployedinfrastructure.
Phase 1) Dual sign with RSA/SHA-1 and RSA/SHA-2-256Phase 2) Sign with RSA/SHA-2-256
Phase 3) Sign with Ed25519
The deci= sion to use MUST, MUST NOT, etc. is then driven by math.
M3AAWG does not= make the decision but they are probably best placed to
collect the data= .

The phases as described here do not fit t= he situation at hand.=C2=A0 As written they mix two separate questions - rs= a-sha1 vs rsa-256 and RSA vs Ed25519.=C2=A0 Those need to be considered sep= arately.=C2=A0 Moreover, for the rsa-sha1/rsa-sha256 the phases are also in= appropriate because X is already ~100%

Verifiers w= ere required to support rsa-sha256 by RFC 6376 -=C2=A0https://tools.ietf= .org/html/rfc6376#section-3.3 - and I'm unaware of any verifie= r who does not support rsa-sha256.=C2=A0 Combine that with the fact that a = large number of systems (easily the majority of DKIM signers) currently sig= n with rsa-sha256 (G Suite, Office365, Facebook, Twitter, etc.) and see no = need to dual sign with rsa-sha1, there's no reason to believe that ther= e is any significant non-zero population of receivers that validate DKIM fo= r rsa-sha1 but not for rsa-sha256.=C2=A0 Dual signing with rsa-sha1 and rsa= -sha256 is not a necessary step in the rsa-sha1 deprecation process.
<= div>
Rolling out Ed25519 sign= ing support is a separate question, and it should not be mixed with the rsa= -sha1 deprecation question, even if they are rolled into one document.=C2= =A0 There is, as far as I know, no intention to deprecate RSA in favor of E= d25519.=C2=A0 Rather the intention is to add Ed25519 as a more modern optio= n for senders that supports shorter keys with better resistance to attacks.=

The current question before the working group is = basically a procedural one - Should we use the=C2=A0RFC2119=C2=A0MUST = NOT language for verifiers and their acceptance of rsa-sha1 (transitioning = from the affirmative SHOULD in RFC 6376) or avoid the use of such language?=

Best,

Peter

--
=


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783
<= /div>
--001a1148c6b8eb49610551ee0097-- From nobody Wed Jun 14 09:45:50 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6AB129C00 for ; Wed, 14 Jun 2017 09:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 aD4F4ApwSMXa for ; Wed, 14 Jun 2017 09:45:46 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9615128B4E for ; Wed, 14 Jun 2017 09:45:45 -0700 (PDT) Received: (qmail 96876 invoked from network); 14 Jun 2017 16:45:44 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2017 16:45:44 -0000 Date: 14 Jun 2017 13:51:23 -0000 Message-ID: <20170614135123.4861.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: phill@hallambaker.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 16:45:48 -0000 In article you write: >DKIM is an IETF specification. If IETF makes a change then M3AAWG will >almost certainly follow suit. But I do not think it at all likely >M3AAWG would start making suggestions on technical matters like this >in preference to IETF action. Hi from the M3AAWG meeting in Lisbon. M3 publishes the occasional BCP, not standards. There's been a fair amount of hall conversations about how to get the signers still using sha-1 to switch. R's, John From nobody Thu Jun 15 04:59:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAEC129BCE for ; Thu, 15 Jun 2017 04:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 o8IrQT-vNFBE for ; Thu, 15 Jun 2017 04:59:04 -0700 (PDT) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF593129BCC for ; Thu, 15 Jun 2017 04:59:03 -0700 (PDT) Received: by mail-vk0-x243.google.com with SMTP id y70so692508vky.3 for ; Thu, 15 Jun 2017 04:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=suRyDpnOiL+SsC9CdUIYmdFYYrH5rBAW2o9sRpub634=; b=O11Vnjo3G1/o1xpSqumsBhhrlySuKH7b0r1c55/fKWbEHhT05StNOnWomwccHineAs VFT1TLbVbHBV5V8YTRih3LNM7t8ONVNcitf9j4lRwja7j8AriyZpPDbipDn9z2R7ddUS h+zu7oF8tcfau+PmbVFlf32Q52/gL1OkxuXGo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=suRyDpnOiL+SsC9CdUIYmdFYYrH5rBAW2o9sRpub634=; b=lSosY8XFXbUJidO+8ii7UdIlaQoxeCkUXtHoTLduLS0a4aVPwGQf3SaoYjxch+08nQ ukex3a8rbhSCsVbWzPPzBKNbfzOK4McdT2ijiaw0z8g9u7vHAYrHkw80lPqgIuYCQSit G+FpxApmOwkTvCt7bIN1PShp7LzxDKJnLPTWkN/jfRHH8PuU9c22cu8SutfmK9e1X1cw n8qZKcmLP3q2WNozNduH70W+Lj3ECnKdg8QW0tnILpxuQUaw5OCNLHNv2X+6FjgMyoih FpaO2xdalB3N5f0YOvEhxVF9WsNjGWP7uHULgdY2O7ljAWAF2G/0R7meNdmPNcehOecl /ITw== X-Gm-Message-State: AKS2vOwNAPE4VQc5UcSylhh8S2O0gN0wXLcoCP1BFbYtL/GqUNkClfPT qndPWf9HH70py6IwmPagEVSCtNXBDDRL X-Received: by 10.31.178.215 with SMTP id b206mr2859896vkf.79.1497527942835; Thu, 15 Jun 2017 04:59:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.75.153 with HTTP; Thu, 15 Jun 2017 04:59:02 -0700 (PDT) In-Reply-To: References: From: Kurt Andersen Date: Thu, 15 Jun 2017 12:59:02 +0100 Message-ID: To: "Murray S. Kucherawy" Cc: Martin Thomson , Alexey Melnikov , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11438352130ee00551fe65fd" Archived-At: Subject: Re: [Dcrup] Deprecating algorithms X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 11:59:06 -0000 --001a11438352130ee00551fe65fd Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 12:59 PM, Murray S. Kucherawy wrote: > On Tue, Jun 13, 2017 at 6:37 PM, Murray S. Kucherawy > wrote: > >> On Tue, Jun 13, 2017 at 7:52 AM, Martin Thomson > > wrote: >> >> This is a fine thing. Do you want to propose text for the charter? >>> >> >> The diff to the current charter is going to be mighty small, so sure, >> I'll do it this week sometime. >> > > Proposed revised charter text. . . . > > DKIM also currently supports use of SHA1 coupled with RSA. SHA1 has been > formally deprecated due to weakness especially when used in the context > transport security, though the risk of a successful preimage attack is less > severe. Still, the community wishes to discourage its continued use in the > DKIM context. > I don't think that we need this editorializing paragraph. What you have below should be sufficient (delta changes highlighted): > DCRUP will consider > - three + four > types of changes to DKIM: additional signing > algorithms such as those based on elliptic curves, changes to key > strength advice and requirements, > +deprecating the use of SHA1, > and new public key forms, such as. . . > --Kurt --001a11438352130ee00551fe65fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 14, 2017 at 12:59 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Jun 13, 2017 at 6:37 PM, Murray S. Kucherawy <supe= ruser@gmail.com> wrote:
=
On Tue, Jun 13, 2017 at 7:52 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

=
This is a fine thing.=C2=A0 D= o you want to propose text for the charter?

The diff to the current charter is = going to be mighty small, so sure, I'll do it this week sometime.

= Proposed revised charter text. =C2=A0. . .

DKIM also curre= ntly supports use of SHA1 coupled with RSA.=C2=A0 SHA1 has been formally de= precated due to weakness especially when used in the context transport secu= rity, though the risk of a successful preimage attack is less severe.=C2=A0= Still, the community wishes to discourage its continued use in the DKIM co= ntext.

I don't think t= hat we need this editorializing paragraph. What you have below should be su= fficient (delta changes highlighted):=C2=A0

DCRUP will consider

- thre= e
+ four=C2=A0

types of c= hanges to DKIM: additional signing

=
=

algorithms such as those based on ellipt= ic curves, changes to key
strength advice and requirements,

=C2=A0+deprecating the use of SHA1,
=
=

and new public key forms, such as. . .

--Kurt=C2=A0
--001a11438352130ee00551fe65fd-- From nobody Sun Jun 18 07:03:51 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2D1241FC for ; Sun, 18 Jun 2017 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.334 X-Spam-Level: * X-Spam-Status: No, score=1.334 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_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=LJcJ7Ljv; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=tNeJgxHo 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 znRNmhh_bJxL for ; Sun, 18 Jun 2017 07:03:48 -0700 (PDT) Received: from secure.winserver.com (winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id D6D201271DF for ; Sun, 18 Jun 2017 07:03:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=907; t=1497794623; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=KUb3R8BSHIauwSJ6bOoBn/ft1SQ=; b=LJcJ7Ljv8GVijQvPiqLJigCEEMtzliH1l3xVFxyeEH8Q83Z00V47cwTiwOHUrf 9KluSgA8zjXP3e9vGZi5Imhc+8smEi0H0G9k6fijy44qRNr2tLttffPXbt88I9Ix iHSndz93gtQ1MN4BJ+NSa4fn6ohvlRgkCVqwK4Qw4b3zE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Sun, 18 Jun 2017 10:03:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2153504420.1.3252; Sun, 18 Jun 2017 10:03:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=907; t=1497794424; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zVTit5q bJYgt9qedz2hye37HPh00W+v5QY5dy8RB5Rs=; b=tNeJgxHo88wXnxLzyzSDPXk HWueXmC6Q9q0EnI/c8CBIPEKGeLAF0jkU0wtHCd4cEKjjKox0P9nv6u54ySsN/tB CxsVfuBxyzv2B7n4NfNXyhO3Qg89TSqj9FL+LmRVmBUnBVQMbfDlbJH91r3/sC4n uxkZU6o37a8ehic/u5UE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Sun, 18 Jun 2017 10:00:23 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2696060986.9.607068; Sun, 18 Jun 2017 10:00:22 -0400 Message-ID: <59468839.7030003@isdg.net> Date: Sun, 18 Jun 2017 10:03:37 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <20170614135123.4861.qmail@ary.lan> In-Reply-To: <20170614135123.4861.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 14:03:50 -0000 On 6/14/2017 9:51 AM, John Levine wrote: > In article you write: >> DKIM is an IETF specification. If IETF makes a change then M3AAWG will >> almost certainly follow suit. But I do not think it at all likely >> M3AAWG would start making suggestions on technical matters like this >> in preference to IETF action. > > Hi from the M3AAWG meeting in Lisbon. > > M3 publishes the occasional BCP, not standards. There's been a fair > amount of hall conversations about how to get the signers still using > sha-1 to switch. Are we having a "serious" security issue, yet? We haven't even finished on figuring out how to trust signatures. Will bad guys "switch?" I continue to believe its about "author domain policy" so when we look an organization up, they tell us what to expect. That would be a first step, imo. -- HLS From nobody Mon Jun 19 13:53:35 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07D8131841 for ; Mon, 19 Jun 2017 13:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 knWXrtx3tfYx for ; Mon, 19 Jun 2017 13:53:32 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814991250B8 for ; Mon, 19 Jun 2017 13:53:32 -0700 (PDT) Received: (qmail 56993 invoked from network); 19 Jun 2017 20:53:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2017 20:53:31 -0000 Date: 19 Jun 2017 20:53:09 -0000 Message-ID: <20170619205309.10839.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: johnl@taugh.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 20:53:34 -0000 Not to nag or anything, but I think this draft addresses everything in the WG's charter, assuming the charter is adjusted to deprecate SHA-1. Could people take a look and see if you agree? If so we could move it to last call and be within hailing distance of wrapping things up. >* new algorithm is now EdDSA, tags updated appropriately > >* sha1 hash is moved to historic > >* place marker to splice in deprecation text from Scott's draft if we want >to. > >My draft has always provided updated text for section 3.3 of RFC 6376. >It says which algorithms signers and verifiers are supposed to use. From nobody Mon Jun 19 13:54:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26B126C22 for ; Mon, 19 Jun 2017 13:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MkvluuAYDmiL for ; Mon, 19 Jun 2017 13:54:39 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2521F1250B8 for ; Mon, 19 Jun 2017 13:54:39 -0700 (PDT) Received: (qmail 57102 invoked from network); 19 Jun 2017 20:54:38 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2017 20:54:38 -0000 Date: 19 Jun 2017 20:54:16 -0000 Message-ID: <20170619205416.10860.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 20:54:40 -0000 If I wanted to work on, say, updating the python or perl DKIM libraries to do eddsa, which crypto code should I use? As far as I can tell it isn't in openssl yet. R's, John From nobody Mon Jun 19 16:27:03 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A9129566 for ; Mon, 19 Jun 2017 16:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 ZbLHPLeruk3t for ; Mon, 19 Jun 2017 16:26:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA8B1289B5 for ; Mon, 19 Jun 2017 16:26:59 -0700 (PDT) Received: from [10.152.151.131] (mobile-166-171-59-241.mycingular.net [166.171.59.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 17745C40320; Mon, 19 Jun 2017 18:26:58 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497914818; bh=uQWQ8Qzt4lJQzjXeTUgT7blmwGHvl1IbIm3vNnUoGMY=; h=Date:In-Reply-To:References:Subject:To:From:From; b=DN5k3u36RxeKzM8pEVfl4AHvovUX+j1OdKdF4L/FSugbR6h908tok5EHB2q6WOl9M dIZf6XGRkdrwYkSVqX81q36fFbbjvjJh63FcOTBApNQzC61nWsIQJ2YA/wjC3TiLcW j4APQeoUqwqfKzkiqDyN9sD1nL4QvnGfsFEBT+eY= Date: Mon, 19 Jun 2017 23:26:56 +0000 In-Reply-To: <20170619205416.10860.qmail@ary.lan> References: <20170619205416.10860.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <7807DE08-7107-4598-BC4F-0B8D73CFE75C@kitterman.com> Archived-At: Subject: Re: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 23:27:01 -0000 On June 19, 2017 4:54:16 PM EDT, John Levine wrote: >If I wanted to work on, say, updating the python or perl DKIM >libraries to do eddsa, which crypto code should I use? As far as I >can tell it isn't in openssl yet=2E It looks like python-nacl has what's needed (quick look only, didn't inves= tigate thoroughly)=2E Scott K From nobody Mon Jun 19 18:41:14 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3C0131882 for ; Mon, 19 Jun 2017 18:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 pXpAfIjlqo_R for ; Mon, 19 Jun 2017 18:41:10 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A80F131834 for ; Mon, 19 Jun 2017 18:41:10 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id u12so123758157qth.0 for ; Mon, 19 Jun 2017 18:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uyDGmeUESSrAXB8z+cFc4FxKYt1+vIQGXUkZBBFr6bs=; b=V6xmfaF4HyPaEuiwNu/A51HkLBp6YJx46Tv6xslbfHO7gGOUE5I0NNBeW5j/KvDTaS BdssHyysaroyYzW8Jiyt25UtCe8CHudVvguw2OyqbAhnYehXqT9s3Q9pzYW79W6sXTub f4dNWIf8+0xCe0/JCk+utUJPzgf/2TQkxmFBXNikXnAJ/e8SzN/ACL67zJeYs2rF322j 6h81G6fw+BLQGWBFqo/xdRUh+iJ7otX3W6aCALTUr6J2Vkz2xe6hZ2zA14sjSWzEvE5o ABC21KDm1nuKHt4A7Hu4gguNn8ToCMPwOx82QN6dmIBSVRAromSXZIdV9xia+r+Y/h3F QWkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uyDGmeUESSrAXB8z+cFc4FxKYt1+vIQGXUkZBBFr6bs=; b=kwetKBq88m86oxHh+/PPKNIB0O+gpsfmfUQ3Sl2WlmJaIx2Wx5TCqCEpjKhjoPJn43 AqiQSsIRfsENkAxvm9HvAPEv93tfigXbLgFti5wI2wRZqtH0HtpEzF6yBeWDt5pukAVW 8zwfNoc63V/oYMSFJeqeZBqRbZ4dLLdVy4CEKDbSV4TyVmslvywCmeQy+cbATUqRGMxO 0uLosVFdHo47YH3ddYoY+7xXs9Iho485G4n85YiqlqSCzqWETf9YfMqYx0Jp6AuqIdjA P+He0XM9Hq5wGeICzPM7uzPmoOSBdHwsxoFmQP6QvaH4rDLLdytcEMndrLB2nZQDzUPE 563g== X-Gm-Message-State: AKS2vOxypCerFgnvgJ3URoZAxThMnp/pM2wOHSRiPUZldM1wHeKYCYag hIgLNlsxFcbauxUusIxM6fLmH29LAlFZAtAMiw== X-Received: by 10.237.51.35 with SMTP id u32mr32392247qtd.181.1497922869318; Mon, 19 Jun 2017 18:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.183 with HTTP; Mon, 19 Jun 2017 18:41:08 -0700 (PDT) In-Reply-To: <7807DE08-7107-4598-BC4F-0B8D73CFE75C@kitterman.com> References: <20170619205416.10860.qmail@ary.lan> <7807DE08-7107-4598-BC4F-0B8D73CFE75C@kitterman.com> From: Peter Goldstein Date: Mon, 19 Jun 2017 18:41:08 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c124ac286ed0505525a580f" Archived-At: Subject: Re: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 01:41:13 -0000 --94eb2c124ac286ed0505525a580f Content-Type: text/plain; charset="UTF-8" It also looks basic support is close in OpenSSL - https://github.com/openssl/openssl/pull/3503 . This has been merged for release in OpenSSL 1.1.1 Best, Peter On Mon, Jun 19, 2017 at 4:26 PM, Scott Kitterman wrote: > > > On June 19, 2017 4:54:16 PM EDT, John Levine wrote: > >If I wanted to work on, say, updating the python or perl DKIM > >libraries to do eddsa, which crypto code should I use? As far as I > >can tell it isn't in openssl yet. > > It looks like python-nacl has what's needed (quick look only, didn't > investigate thoroughly). > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --94eb2c124ac286ed0505525a580f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It also looks basic support is close in OpenSSL -=C2=A0https://github.com/op= enssl/openssl/pull/3503 .=C2=A0 This has been merged for release in Ope= nSSL 1.1.1
Best,

Peter<= /font>

On Mon, Jun 19, 2017 at 4:26 PM, Scott Kitterman <sklist@kitterman.com= > wrote:
<= br>
On June 19, 2017 4:54:16 PM EDT, John Levine <johnl@taugh.com> wrote:
>If I wanted to work on, say, updating the python or perl DKIM
>libraries to do eddsa, which crypto code should I use?=C2=A0 As far as = I
>can tell it isn't in openssl yet.

It looks like python-nacl has what's needed (quick look only, di= dn't investigate thoroughly).

Scott K

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--94eb2c124ac286ed0505525a580f-- From nobody Mon Jun 19 18:42:58 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BD31318C0 for ; Mon, 19 Jun 2017 18:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 r0VsepuIyHCz for ; Mon, 19 Jun 2017 18:42:54 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFC21318BB for ; Mon, 19 Jun 2017 18:42:54 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id s7so80095852otb.3 for ; Mon, 19 Jun 2017 18:42:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=+Y/JVonWks7V6Gp5tj5NFDUlrDPoVOFh5o9newbDw0Q=; b=XU1Gcfl58KuBlaDOIx3JaEyAL2so8mUj4VxAOdcUAbaGLEOqkYnp5SkM3wyLjEm6Km g8qyJUWa802wsmSRc9fF9HDZSuDz+dzpt2gOV+LJPgxb6uWz2em2HyvpnLh0S4hHVj5l tiiuK+oNOudFkNxLj7gd8HqjdssAZX1OM0BF/gKF77DKTc88B5G6ayiWaaaOBCzz+cdI C+x1/9jb58tOOD242JXefhKPnEOw9F12IEbi0jzxEkav6j/CD+sd9STE0r1HtzGQNVzI YK3z4t9ZuFJvpBf9Z6RF4GO8tKRh95tXYT79oMEqQOtoW2HeHpkGnGfnY0ruHY1HE/qB 2Wxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=+Y/JVonWks7V6Gp5tj5NFDUlrDPoVOFh5o9newbDw0Q=; b=gCOqVPNSAdo8qJfvKxR2mfG84io7aVRdsh/5+NmSZkQhEnFA1SmNY8qfrJPpFq6GDE yz/iGjOwwu/IKsKcmhD2/q5yLWycQE/NvOB4adMzb0G/jIiAhxiQ/JvZndnVJFS6QETz cMimv6O8GG4G7B/jOnJJde0Tpro7B6uAWn/mJ156a4tBDbNQSfvwMR7OlWLA9cOqIu0U r0uRSmNCt9/Ch/d8gMuqS62fKJXYQCQg2h7qqYgGp3Akj1/Fd49KiWYDtPvUfMSfL3CC 1qm23MBEPVeTNdQiub8+Hx87vljnubvk6i+1jHgOad+C91rUaRDOvDL2LXv5KKPxN0s5 OGyw== X-Gm-Message-State: AKS2vOy8aakiKFgkb68UFgPpqnz/410c9qtgwRjenH68KFYPaz9d9o0k eyV4Z6A5P8YPJMJLIDNPFsIywip5xg== X-Received: by 10.157.9.210 with SMTP id 18mr15441819otz.245.1497922974078; Mon, 19 Jun 2017 18:42:54 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.206 with HTTP; Mon, 19 Jun 2017 18:42:53 -0700 (PDT) In-Reply-To: <20170619205416.10860.qmail@ary.lan> References: <20170619205416.10860.qmail@ary.lan> From: Phillip Hallam-Baker Date: Mon, 19 Jun 2017 21:42:53 -0400 X-Google-Sender-Auth: 5IFQU-9D1APyMwLjqmNFytGjm-A Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113d0e16c55c0905525a5efa" Archived-At: Subject: Re: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 01:42:56 -0000 --001a113d0e16c55c0905525a5efa Content-Type: text/plain; charset="UTF-8" The reference code in the RFC is python. On Mon, Jun 19, 2017 at 4:54 PM, John Levine wrote: > If I wanted to work on, say, updating the python or perl DKIM > libraries to do eddsa, which crypto code should I use? As far as I > can tell it isn't in openssl yet. > > R's, > John > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a113d0e16c55c0905525a5efa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= reference code in the RFC is python.

On Mon, Jun 19, 2017 at 4:54 PM, John Levin= e <johnl@taugh.com> wrote:
I= f I wanted to work on, say, updating the python or perl DKIM
libraries to do eddsa, which crypto code should I use?=C2=A0 As far as I can tell it isn't in openssl yet.

R's,
John


_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a113d0e16c55c0905525a5efa-- From nobody Mon Jun 19 18:47:12 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB061318BE for ; Mon, 19 Jun 2017 18:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xJzQqFEa3QjX for ; Mon, 19 Jun 2017 18:47:08 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702BC131537 for ; Mon, 19 Jun 2017 18:47:08 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id o83so65274833lff.3 for ; Mon, 19 Jun 2017 18:47:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Swn1eZqWGgFHufyerNwDnoM/Oo0d/oI8cqn70kI6aWw=; b=I14p9okJc/eNW2ldMQKC0ObXd38Og0Vay8WTXtq4dWqfAiX5JCkfgBH51eMFnvfv6c 5bzITj7ie9+lK2+zIjwifqlaKIVuxHWtaDXqGG2Ib1/HdyHKEyPFgaicTLut+agoN0fW 12OZrxH60vl3pM2w6B6a2LCZ2d2bBNw1y7t1XeV6wvLjDz+MGyTaEnmmRGWiHY8XtBMj zbvecCvmh9Z6fZaH0C7uHH4MBlKSZyPTW95RfRk6F2Qo3hTkbhkNZtkWa7Ua66nxyy/x kdGBKzVpAI8klPRs925wLDxFcgV/eVjUNhOF+5BWtGWcjjpgKYx3dpEug3SJCjinHHsr ldww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Swn1eZqWGgFHufyerNwDnoM/Oo0d/oI8cqn70kI6aWw=; b=kqFGqJJTis+mKBHOasdMmolhcCDve/qFXnHeJXtGUBHIZFpSRPhRANAJ37DLBwHgHP MdLAEmytF2KEp4DPDdwgMT9zrI5Z+iUCTCCrFBXgjgYWv80UsHo5LyRijB3sVYmqGqZT U1he5yh/IqzsbCN9R2MQbBHSsZ+iEvmI0w1PwgRpQrtq2VSysR7MGTNI6o1eLy9dO9u/ yNU+0p+IthPox9+7iP2Ma2h0x3NOXrHkOiKLDIMHGZQW+5H+4eqMECMegQvUrrCw/aRK uUWD6YTfpAIiJTb/BPSv15LKxAHWTztBKjNYvX1XFpqd5Xb4u4uh5THHyQRQ2mLLlsvm XpBw== X-Gm-Message-State: AKS2vOxgV8DjqdpvjiSVVZuB3G5T97EHeCHwkMciuQWyVNn8UigPeU2d HekX5J8KLVffoMEZi2Bm8UYr7wMsl/Z0y/8= X-Received: by 10.25.201.18 with SMTP id z18mr8678988lff.172.1497923226738; Mon, 19 Jun 2017 18:47:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Mon, 19 Jun 2017 18:47:06 -0700 (PDT) In-Reply-To: References: <20170619205416.10860.qmail@ary.lan> From: Martin Thomson Date: Tue, 20 Jun 2017 11:47:06 +1000 Message-ID: To: Phillip Hallam-Baker Cc: John Levine , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 01:47:11 -0000 It's not clear that the code in the RFC is free of side channels, so it's probably not fit for use other than for verifying correctness of outputs. Note: This code is not intended for production. Although it should produce correct results for every input, it is slow and makes no attempt to avoid side-channel attacks. On 20 June 2017 at 11:42, Phillip Hallam-Baker wrote: > The reference code in the RFC is python. > > On Mon, Jun 19, 2017 at 4:54 PM, John Levine wrote: >> >> If I wanted to work on, say, updating the python or perl DKIM >> libraries to do eddsa, which crypto code should I use? As far as I >> can tell it isn't in openssl yet. >> >> R's, >> John >> >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > From nobody Mon Jun 19 19:31:32 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23581318EF for ; Mon, 19 Jun 2017 19:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 deLL75lokfKu for ; Mon, 19 Jun 2017 19:31:29 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 4AFF71318EC for ; Mon, 19 Jun 2017 19:31:29 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5K2QkRU020139; Tue, 20 Jun 2017 03:31:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3vsRJK19s1E/aJtzk82hFNxr01yUSLrzyCfhrr/NE3c=; b=hEXtVXoU8NQTGyc8RB0h+5kscX4xpJx9JHGxQZ3Szi24sE/v0wTajJM+nTxuAke89M5S /lEQ8Upca4UamfeH1/Lauczxv5RJKQueMmLtq+uIQ7M/21aPIrIiYz4YSYNhVPY5xAzs KexXMbWr+suwAFsPcSXaJ2C6V6jJ6RVVZofTTvrz0upwvR+QH7oX8A99tvvDl0eQf+Ue w9WKa+82d7OeajZQGs3TSmRi3KkfpsTzWe81RBZRTGHeKHR5yiomnU0BIGq4t43MPg6C u78lSD+ROkd3P5rd8VzuOnQe6VMqX/2/FGeLAbTcl/f4btaw+y1e9RZCdu163NeAAYsT eg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2b6dkrd5k5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 03:31:26 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5K2VODk017099; Mon, 19 Jun 2017 22:31:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b4yrv8rb9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Jun 2017 22:31:24 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Jun 2017 19:31:22 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Jun 2017 22:31:22 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 19 Jun 2017 22:31:22 -0400 From: "Salz, Rich" To: Martin Thomson , Phillip Hallam-Baker CC: "dcrup@ietf.org" , John Levine Thread-Topic: [Dcrup] EDDSA implementation question Thread-Index: AQHS6T5Im1dzakh5PEi+LeE0la84+KItPaKAgAABLQD//8k1MA== Date: Tue, 20 Jun 2017 02:31:21 +0000 Message-ID: References: <20170619205416.10860.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.26] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200047 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-19_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200046 Archived-At: Subject: Re: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 02:31:31 -0000 I am biased, but I would like at pycrypto and ask them to wrap the openssl = eddsa code. From nobody Mon Jun 19 20:08:01 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E990C13192E for ; Mon, 19 Jun 2017 20:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 NXdUZzWNq5td for ; Mon, 19 Jun 2017 20:07:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100D813192B for ; Mon, 19 Jun 2017 20:07:59 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8CB79C4037F; Mon, 19 Jun 2017 22:07:57 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497928077; bh=Ueo8uFEAlaTTCQUUrR1hsBIVnnmEy7CrMkfecXnw2DE=; h=Date:In-Reply-To:References:Subject:To:From:From; b=YB7DkDxer54GLXGGDUQkUY8QytFXELBYcp9TqA3y65XkgKW22yokLa04T5gejthrR FOBs7lMeJv/aXXOoL8cTZJlMROGYAe2mrpQE61LX/v+QAHepoFNXdvQI6MnNg0W+Hl f4OnWkHrP0Nwhaz0/4gWXq0vV/zwp673s1JT4A28= Date: Tue, 20 Jun 2017 03:07:56 +0000 In-Reply-To: References: <20170619205416.10860.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <8CDE9BE5-3D3E-42AE-81EC-6B805B73EE5E@kitterman.com> Archived-At: Subject: Re: [Dcrup] EDDSA implementation question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 03:08:01 -0000 On June 19, 2017 10:31:21 PM EDT, "Salz, Rich" wrote: >I am biased, but I would like at pycrypto and ask them to wrap the >openssl eddsa code=2E The python-nacl code has the advantage of being available=2E It depends o= n how long you want to wait=2E Also the API is high level enough to avoid = having to get your hands into the low level guts of it all=2E Speaking as a maintainer of a DKIM library (dkimpy), those are both very a= ppealing properties=2E =20 Scott K From nobody Tue Jun 20 05:39:12 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F1E12EB37 for ; Tue, 20 Jun 2017 05:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 HQ-6JDz695Dv for ; Tue, 20 Jun 2017 05:39:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 7F24112EB0E for ; Tue, 20 Jun 2017 05:38:51 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5KCb1uA027112; Tue, 20 Jun 2017 13:38:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=le3vBpqE00Cd8dB55v6CMlPVv1ZAjKSyrgCRfEc+ZSM=; b=cjJ9eohjuV/siXM+6M8RbMtG4xGzDpt1odYiPIhJJkndinQAbPenEz4OxU6SlmLnCfZm YmEVIehOMPqj2JnKsWGGknWNk7JrWn5B0OAJBP4G7b2kqaVaPzdajI/gyCm6kCDZVbr7 d2JARllCMb/XQRkoT4zIjzOmPOUhl+Yq+q9yIhCsoxIYL/KESo0W4HNSmCoHfMEdN6Q+ k6iI2lSxRQY1MxMi/Y8aX3DbUql+lBdZD75oESArcTX/oHPYsP2PGVXsz4l26S+OItb5 dRcRL+mGcsEL0ahosRV1NNLnWG5dQwI76TCDQv/gyILRBjyoqdowepPPb6DfmObqOQmA gg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2b6dkrg0mh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 13:38:47 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5KCZNSh007290; Tue, 20 Jun 2017 08:38:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yrujcqf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 08:38:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 20 Jun 2017 08:38:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 20 Jun 2017 08:38:45 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" Thread-Topic: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? Thread-Index: AQHS6T4iaOBh+kldWkWZYHkqviWKd6ItsaNg Date: Tue, 20 Jun 2017 12:38:45 +0000 Message-ID: References: <20170619205309.10839.qmail@ary.lan> In-Reply-To: <20170619205309.10839.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.30] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200224 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200225 Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:39:11 -0000 > Not to nag or anything, but I think this draft addresses everything in th= e WG's > charter, assuming the charter is adjusted to deprecate SHA-1. >=20 > Could people take a look and see if you agree? If so we could move it to= last > call and be within hailing distance of wrapping things up. Let me be more "official" Once the charter change is approved (Murray is working on that with Alexsey= ), I'd like to put this into WGLC. Any concerns? From nobody Tue Jun 20 05:57:09 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD8D12EB5D for ; Tue, 20 Jun 2017 05:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 JNMU3EIuhT0A for ; Tue, 20 Jun 2017 05:57:05 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1EB512EB20 for ; Tue, 20 Jun 2017 05:57:01 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 63so51771027ywr.0 for ; Tue, 20 Jun 2017 05:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P2JsAPB7y2dlk7zqhKB5kx+i/HiwyGXOa/dVofGTNgA=; b=tdGoM4o5GLMwdf8NvBK5EsE+8m5rcCKZh8oDEf50ia5vHvDPEb/8kbO+WDKWPMeuJE yyKFCvM8sVIIFw60ECCthNRspJLPXxCnUhuSnZVsZQLChqz1HAAdX6ITie3Iam2Kl3MO bSOy5ukzGdhWVX0QoGKRc/tHUBzgYBFSc5dj0PgIY6Gf7FmagwULU+fB3KOPiBnTUyH6 gqgNGcfMIbdm4yiYKJfFVcevXbwU/SidX2SVAEYeA2T8/qKu5Dzd50W8TiDue5IhDYdY mIEDbrXhx+Bv84aqstmwfSX/duwEr4pOwGHCPTuVO6mOHH12e3ObOyEolefCmEyUEKZF Ghlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P2JsAPB7y2dlk7zqhKB5kx+i/HiwyGXOa/dVofGTNgA=; b=ndr/ugrv+BIkWagQphJBlWtzgzLBAktFeS7nWqd28Z4FblXDUZLQBjmO/vRiL2a3cy rRweyTXG9P71aYU7D8y9KE9AbP3Cd6kEcjY5j0UJlpvKwAfVs7C5ZO7RprySNsH/pPxj Y0VJw7JbLWRLwJBom1yYJUPc84rsaiUF4SjEp8lmk13LXu4GJEHAhUa++D5bg1c7SODR 6MrKyOCvIb0QB+/iRTWzf8FpCAKx0cYTMA/K8jh/hjd3TdOmLFXwhfFHpmZd3p1dWui2 G+xbJKdDYOxPpq+VvoP9rmjRR8QM7PnU+yGU4/HGFGXrU2AhZOrayg+z4gi/Py94jWNv 8mLA== X-Gm-Message-State: AKS2vOzxJEi6BjwrRM/Jcrpws3AYEbbTUvXRRJAQdHPL0tPWPlTSyTPe Nzjm27es44D2+SGiVkdvGDAuzwlogVAU X-Received: by 10.129.183.24 with SMTP id v24mr11403972ywh.312.1497963420825; Tue, 20 Jun 2017 05:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 20 Jun 2017 05:56:20 -0700 (PDT) In-Reply-To: References: <20170619205309.10839.qmail@ary.lan> From: Eric Rescorla Date: Tue, 20 Jun 2017 05:56:20 -0700 Message-ID: To: "Salz, Rich" Cc: John Levine , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cbd0495d5e7055263c9ad" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 12:57:08 -0000 --94eb2c1cbd0495d5e7055263c9ad Content-Type: text/plain; charset="UTF-8" Giving this document a quick read I see several things I would change. 1. You say you are using EdDSA with SHA-256? Does this mean you intend to use the HashEdDSA variant see ( https://tools.ietf.org/rfcmarkup?doc=8032#section-4)? If so you should say so. 2. I wouldn't specific generic EdDSA but rather EdDSA with a specific curve. This is both for practical reasons (I don't want to have to distinguish keys by len()) and for algorithmic reasons (you want to use a stronger digest algorithm than SHA-256 with X448) 3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp) These keys are not intended for use with key exchange but rather signature. The document actually seems kinda confused on this point with the text saying one thing and the table saying another. -Ekr On Tue, Jun 20, 2017 at 5:38 AM, Salz, Rich wrote: > > Not to nag or anything, but I think this draft addresses everything in > the WG's > > charter, assuming the charter is adjusted to deprecate SHA-1. > > > > Could people take a look and see if you agree? If so we could move it > to last > > call and be within hailing distance of wrapping things up. > > Let me be more "official" > > Once the charter change is approved (Murray is working on that with > Alexsey), I'd like to put this into WGLC. Any concerns? > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c1cbd0495d5e7055263c9ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Giving this document a quick read I see several thing= s I would change.


1. You say you ar= e using EdDSA with SHA-256? Does this mean you intend to use
the = HashEdDSA variant see (https://tools.ietf.org/rfcmarkup?doc=3D8032#section-4)?
If so you should say so.

2. I wouldn'= t specific generic EdDSA but rather EdDSA with a specific curve. This
=
is both for practical reasons (I don't want to have to distinguish= keys by len())
and for algorithmic reasons (you want to use a st= ronger digest algorithm than
SHA-256 with X448)

3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp) = =C2=A0These keys are not
intended for use with key exchange but r= ather signature. The document actually
seems kinda confused on th= is point with the text saying one thing and the
table saying anot= her.

-Ekr


=


On Tue, Jun 20, 2017 at 5:38 AM, Salz, Rich <rsalz@akamai.com= > wrote:
&= gt; Not to nag or anything, but I think this draft addresses everything in = the WG's
> charter, assuming the charter is adjusted to deprecate SHA-1.
>
> Could people take a look and see if you agree?=C2=A0 If so we could mo= ve it to last
> call and be within hailing distance of wrapping things up.

Let me be more "official"

Once the charter change is approved (Murray is working on that with Alexsey= ), I'd like to put this into WGLC.=C2=A0 Any concerns?

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--94eb2c1cbd0495d5e7055263c9ad-- From nobody Tue Jun 20 08:43:47 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFC813148E for ; Tue, 20 Jun 2017 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 w-YNwjX3-cSC for ; Tue, 20 Jun 2017 08:43:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F206131BAB for ; Tue, 20 Jun 2017 08:39:36 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 336A1C400DA for ; Tue, 20 Jun 2017 10:39:35 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497973175; bh=w1IqPAFfmypPQ4lKLVYdliTh0dYYQNfJ6+pkOwe0gCg=; h=From:To:Subject:Date:From; b=gqipgV4Oya12i64wcwQiG4QR1Zw/YxI8notEDCyidsADpf6ar2TaDgpDQSIAADqHn gsFrIvYlpHOE17lcm1NwuRRSZ1g6c/QwFB9ZUnm7f8d2V7n42t69Odthwo0iUBKNFS TibxJWscmxEjnvxHDtZuZjUGQ7iP/6TZb1TUWMd0= From: Scott Kitterman To: "dcrup@ietf.org" Date: Tue, 20 Jun 2017 11:39:34 -0400 Message-ID: <1642300.47WuTbIWPP@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 15:43:45 -0000 I think we still have some different opinions on what to do with rsa-sha1, so I thought I'd attempt to summarize the different options (as best I can, I have an opinion, so I'm sure my bias will leak in) in the hopes it will help drive this part of the WG discussion to closure. Note: I'm not talking about RSA key sizes because it seems to me we're largely converged on that topic. I think there are roughly three options that have been discussed: Status quo: > Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST > implement both rsa-sha1 and rsa-sha256. Deprecate rsa-sha1: > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST > implement both rsa-sha1 and rsa-sha256. Remove rsa-sha1: > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST > implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. Note: This option also removes rsa-sha1 from the ABNF. Pro/Con for each: Status quo: There is no immediate known security threat to rsa-sha1 that would indicate its imminent demise as a useful algorithm in this application and rsa-sha1 signatures are still in significant use. RSA key sizes are the current security issue and that can be fixed without doing anything about rsa-sha1. There are a number of known shortcomings with rsa-sha1 and given that rsa- sha256 is available and does not share the same issues, raising the bar to require rsa-sha256 is easy and a prudent step to take in advance of issues being published. Let's not wait until we have to panic. Retaining rsa-sha1 means DKIM implementers will have to deal with three algorithms rather than two and this raises implementation complexity and the risk of things going wrong. Deprecate rsa-sha1: There is no immediate known security threat to rsa-sha1 that would indicate its imminent demise as a useful algorithm in this application and rsa-sha1 signatures are still in significant use. RSA key sizes are the current security issue and that can be fixed without doing anything about rsa-sha1, but if we move to a more aggressive stance against rsa-sha1 now, it should be easier to remove it when needed. There are a number of known shortcomings with rsa-sha1 and given that rsa- sha256 is available and does not share the same issues, raising the bar to require rsa-sha256 is easy and a prudent step to take in advance of issues being published. Let's not wait until we have to panic. Retaining rsa-sha1 means DKIM implementers will have to deal with three algorithms rather than two and this raises implementation complexity and the risk of things going wrong. Remove rsa-sha1: This option eliminates (to the extent it is adopted) the potential of security risks with rsa-sha1. If a relevant issue with rsa-sha1 is made public, there will be no further standards work that needs to be done. This option also keeps the number of algorithms at two, eliminating the additional complexity associated with having more algorithms to sort through in implementation. While this might be considered somewhat abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade. Maybe this will create some momentum for operators to move off of it. It is abrupt to remove something without a formal deprecation period. Thoughts? Scott K From nobody Tue Jun 20 09:19:22 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8124D131526 for ; Tue, 20 Jun 2017 09:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 9qVNq62a4Wyo for ; Tue, 20 Jun 2017 09:19:18 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A18B128C83 for ; Tue, 20 Jun 2017 09:19:18 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id u12so137536956qth.0 for ; Tue, 20 Jun 2017 09:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=aI52nlbq3FOqYfkrPNSGBTezvisVktuuD97fq2dtvqA=; b=O3xWVC7a2iXOI8WWg5hOiSvmyL1nHh+6bgrKlu5FKdAHm8kt+Q+s++N8vqDgD5DZDR 9m252tsptIhIiTyB3OEGcOqZDJ8Pb+l119xU4SDTvfdelvNT6FQRXW0K2vsl92qQrCyC mUO97KBaq0AHCh+J2Yz3GdbPMP+BhfMDOteKACpv92B/EU0wMgJHtpp6AuWA+EOxNO1K yieKh3mwzE6p9VNKxMscc1o5+i3tV62MWKvom0jNhD1QnxoPFFbSc/DjY7lXoNzUgFHx YTlz2hDB4ONeE3VM2VJMTWFssZJdSROAwvF+UPr148AGe1mDeOcSsVK3Jz0oGjIT/Gab +QaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=aI52nlbq3FOqYfkrPNSGBTezvisVktuuD97fq2dtvqA=; b=M39culL/SIvMsdnbYv474Iza1kZQxG8uP5u0YGRBOZsgT9ywuc+M8CJnpDKF64HAZK L9pqiMGut/Bnvr0woIZoTye55VvVMzD8Akyar/ToWEkPDgV44yfB/InTBJdvuJfzOrtQ jp06tGh6FTeP/oPG/iafHYyZcd0AmeIQqnUTxlH726mGBiKXZEwdibZUIyCZk9Ra64Ms CjniB8YHIL+5qyPrIPJ8N1QXDe+7foUXB66c/Efq7J0M3sfkHKSeSJc+H6pykg8o9lY9 kykyAQCpYOQ6vt7KI6yICCzIqd066i+lOeE9yJb8zda8032+kRZB34LmXn6j9TiRGQoO cilg== X-Gm-Message-State: AKS2vOzJs3SjWxlKYV4DLHYe+JyhWTQwq9wgxjqJeEW/zuhWso5Kgtqz /d9HWRQYR/WPmHE4I40MLBss1H83VemLSPg= X-Received: by 10.237.45.103 with SMTP id h94mr35878491qtd.204.1497975557068; Tue, 20 Jun 2017 09:19:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.43.27 with HTTP; Tue, 20 Jun 2017 09:18:56 -0700 (PDT) In-Reply-To: <1642300.47WuTbIWPP@kitterma-e6430> References: <1642300.47WuTbIWPP@kitterma-e6430> From: Seth Blank Date: Tue, 20 Jun 2017 09:18:56 -0700 Message-ID: To: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c124a6ef6316b0552669c61" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:19:20 -0000 --94eb2c124a6ef6316b0552669c61 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman wrote: > Remove rsa-sha1: > This option eliminates (to the extent it is adopted) the potential of > security > risks with rsa-sha1. If a relevant issue with rsa-sha1 is made public, > there > will be no further standards work that needs to be done. This option also > keeps the number of algorithms at two, eliminating the additional > complexity > associated with having more algorithms to sort through in implementation. > While this might be considered somewhat abrupt, rsa-sha1 signing has been > effectively SHOULD NOT for a decade. Maybe this will create some momentum > for > operators to move off of it. > > It is abrupt to remove something without a formal deprecation period. > I strongly vote to remove SHA1 as proposed here; I do not believe any other approach will incentivize senders or receivers to make the change. I do not believe this qualifies as an "abrupt" deprecation, as you said, it has been SHOULD NOT for over a decade. > Thoughts? > > Scott K > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c124a6ef6316b0552669c61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman <sklist@kitterman.com= > wrote:
Remove rsa-sha1: This option eliminates (to the extent it is adopted) the potential of secur= ity
risks with rsa-sha1.=C2=A0 If a relevant issue with rsa-sha1 is made public= , there
will be no further standards work that needs to be done.=C2=A0 This option = also
keeps the number of algorithms at two, eliminating the additional complexit= y
associated with having more algorithms to sort through in implementation. While this might be considered somewhat abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade.=C2=A0 Maybe this will create some mome= ntum for
operators to move off of it.

It is abrupt to remove something without a formal deprecation period.

I strongly vote to remove SHA1 as proposed h= ere; I do not believe any other approach will incentivize senders or receiv= ers to make the change.

I do not believe this qual= ifies as an "abrupt" deprecation, as you said, it has been SHOULD= NOT for over a decade.

=C2=A0
Thoughts?

Scott K


_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

=
--94eb2c124a6ef6316b0552669c61-- From nobody Tue Jun 20 09:40:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689F7131BC1 for ; Tue, 20 Jun 2017 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 7w3uJiQAjesA for ; Tue, 20 Jun 2017 09:40:41 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2B6131BD4 for ; Tue, 20 Jun 2017 09:40:27 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0CC57C40021 for ; Tue, 20 Jun 2017 11:40:25 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497976825; bh=TQSCV5fO+iHxVNv5r+bFCT6l0w7hMyH2j237iS+4IzU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=UJeDQ2ipQOk0BJz96z0PnZKchmoRCC2rZVnU4TmRcLCKXGInUZJaaP3EQJiRlBdKm ZnTBl0aZyf1qmngCeSy6/mG4DJjvLptca+9/OiR6UAumhkCHy80/XQ2daQJiTaB6ZV H8dDdopC/jYtAxHHwMMbo+lCPnppiF0jF9nraWYg= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 20 Jun 2017 12:36:35 -0400 Message-ID: <1555197.Rcy4aD9AYe@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <1642300.47WuTbIWPP@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:40:43 -0000 On Tuesday, June 20, 2017 09:18:56 AM Seth Blank wrote: > On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman > > wrote: > > Remove rsa-sha1: > > This option eliminates (to the extent it is adopted) the potential of > > security > > risks with rsa-sha1. If a relevant issue with rsa-sha1 is made public, > > there > > will be no further standards work that needs to be done. This option also > > keeps the number of algorithms at two, eliminating the additional > > complexity > > associated with having more algorithms to sort through in implementation. > > While this might be considered somewhat abrupt, rsa-sha1 signing has been > > effectively SHOULD NOT for a decade. Maybe this will create some momentum > > for > > operators to move off of it. > > > > It is abrupt to remove something without a formal deprecation period. > > I strongly vote to remove SHA1 as proposed here; I do not believe any other > approach will incentivize senders or receivers to make the change. > > I do not believe this qualifies as an "abrupt" deprecation, as you said, it > has been SHOULD NOT for over a decade. Modulo the IETF doesn't vote, I agree, but then you knew that already. Hopefully the responses give enough information for the chairs to develop an opinion about where the consensus is on this issue. Thanks, Scott K From nobody Tue Jun 20 09:43:16 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB072131B9D for ; Tue, 20 Jun 2017 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 Mb2EdXuKjxEN for ; Tue, 20 Jun 2017 09:43:13 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 75C42131BC0 for ; Tue, 20 Jun 2017 09:43:13 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5KGba2w028512; Tue, 20 Jun 2017 17:43:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dPXCDDDCMJJgf7xEHb8InfJFtFI5Er5Ar1d+bAPJLVI=; b=QOAzCNLmB0vmMZ6r9hpspgq8LgVt4xiaL4bSaQQzYYTOW5xz1TRV9ZlP2jyc1ihyKyCF LSIWVbwfNVq4dziIS4wYaXWEY2LJ0xbD8wLRQmKnYbk/L+ya5PvNms2IXArrieLQChke JoXCn7dZcyWWIyBN6OgWKXeXfJAZk/bsm5GjnIx6FcskosdYMSiivys1FzCjK0661e5b k0UlOmOcjYV0q7m13n5fmi0FnG7mdPMUXBaj0KuXOPuwptsqkAEeqzTWYoZ8nfXl50hJ 3e+w+MdYJMiYrTXpAArO946Yhq+ix+vsNpEe9GMbp4zowfbMy4rULiii57K6Nn1n6rVd zA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b6gbq7rev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 17:43:11 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5KGfGlU022373; Tue, 20 Jun 2017 12:43:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yruk8qr-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 12:43:10 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 20 Jun 2017 12:43:09 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 20 Jun 2017 12:43:09 -0400 From: "Salz, Rich" To: Scott Kitterman , "dcrup@ietf.org" Thread-Topic: [Dcrup] rsa-sha1 proposals Thread-Index: AQHS6dwEx6Qzh7qeKkuelYoLg0TlfaIuMSoAgAAE74D//76jsA== Date: Tue, 20 Jun 2017 16:43:09 +0000 Message-ID: <9392addb39da47db8a472b4962731b3b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1642300.47WuTbIWPP@kitterma-e6430> <1555197.Rcy4aD9AYe@kitterma-e6430> In-Reply-To: <1555197.Rcy4aD9AYe@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.30] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200288 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706200288 Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:43:15 -0000 I don't think an RFC is ever abrupt deprecation; instances are free to not = implement. From nobody Tue Jun 20 09:50:36 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D7013151E for ; Tue, 20 Jun 2017 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=XpGtRkU2; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=LIpE0coz 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 Ae2tNZiw0yCZ for ; Tue, 20 Jun 2017 09:50:29 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A56D120725 for ; Tue, 20 Jun 2017 09:50:09 -0700 (PDT) Received: (qmail 24418 invoked from network); 20 Jun 2017 16:50:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5f60.59495240.k1705; bh=uqHhd8LmjRQoQ9jfWv/sPZqUcanOqKUl6mwtM3uzPkk=; b=XpGtRkU2KPyS9i8as8jJdYcevB6JqdAjChKhhlxidaAynvnoS2fBQqlySpOHkNRecbR93WQ5Z8gLWwvGPgV38GcwE31N7s6rJa0OrJCnebG2O+dSxW8gIXkIh+qCEXzJD7/prgf0q7wdIiMjmHiRjL9oeZ+8jgvlycHojCQ8W3D9qeVJ7SlP8hXwfvpFs+o7YFlWWTF6VoWu9gTik1G2dM+GopCvIOOEV9xQYZSJ7B+uU/vZ867nvlKwGfaXONQm DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=5f60.59495240.k1705; bh=uqHhd8LmjRQoQ9jfWv/sPZqUcanOqKUl6mwtM3uzPkk=; b=LIpE0cozy93EnHJd+g7+gsdMMjWVD5dNroq+A/+bKZUG2jgEi6Jb56CyrqPrGLnekA/rJbyPLHDLhMrIVNJh6bH2EVYphTrIwgYI+LddydZkzIlv7NrtuLep/ERhIKOj5gvu1C7L3TBvJEZGAVGpymYWejGvyMlCIrSJ9sF/oaDUevY+cS2zQNb6jL5MqFUPSn4YZtRseRl21h2JJ+F1JeJxlNSw3OcCtexnhN5b6Nn0aReuAoMd3ldSIeLE7VXt Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jun 2017 16:50:08 -0000 Date: 20 Jun 2017 12:50:07 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: "dcrup@ietf.org" In-Reply-To: References: <20170619205309.10839.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:50:33 -0000 > Giving this document a quick read I see several things I would change. In case it's not clear, I do not purport to be any sort of crypto expert, so I'm hoping that you, r$, et al. help us to be sure that what I say makes sense. > 1. You say you are using EdDSA with SHA-256? Does this mean you intend > to use the HashEdDSA variant see ( > https://tools.ietf.org/rfcmarkup?doc=8032#section-4)? If so you > should say so. I think the answer is no. DKIM signatures use two chained hashes. First it hashes a canonicalized version of the message body, and inserts the base64 hash into the DKIM-Signature header. Then it hashes a canonicalized version of the headers, signs that hash, and inserts the base64 signature of the second hash into the DKIM-Signatuer header. To avoid infinite regress, the verification step pretends the signature wasn't in the header when verifying. As far as I can tell, feeding the canonicalized header text into HashEdDSA gives the same result as feeding the hash into PureEdDSA. Since the hashing in DKIM has been defined for a decade and we're not planning to change it (other than to deprecate SHA-1) I'd rather say this is a PureEdDSA signature of the existing hash. > 2. I wouldn't specific generic EdDSA but rather EdDSA with a specific > curve. This is both for practical reasons (I don't want to have to > distinguish keys by len()) and for algorithmic reasons (you want to > use a stronger digest algorithm than SHA-256 with X448) OK. Looking at 8032, it appears I want to use Ed25519, right? > 3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp) These keys > are not intended for use with key exchange but rather signature. The > document actually seems kinda confused on this point with the text > saying one thing and the table saying another. OK. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jun 20 10:38:21 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766601315C7 for ; Tue, 20 Jun 2017 10:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 1nhyWcvY5Sne for ; Tue, 20 Jun 2017 10:38:09 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30EE51315B8 for ; Tue, 20 Jun 2017 10:38:09 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 63so55186201ywr.0 for ; Tue, 20 Jun 2017 10:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8wSxAJ+gHi0g98hDB1dbU7MZgAdNdntUI/snG/7ca/4=; b=lFmO/1V2o4iKJCw2F3DfXx7sLy+mxDF/l3zqZhGV/wHQFXAJLaA10y3CWuy7A8HkuQ QkcC5CyxuF1QuElPEsvgq/pkMPWERPyMG1ncL04lWb8eA7e2PrzBoxRu4LQwVWtxKT0+ rrZZ5MmEYZ2ewOqbt8hXT4kSPPO+SLqth+znOOqSGjhcymKqHu2Q4nAQQwMQNPJeluil LIopxxtk5w7nxDu54ieCObA18Pb/y030l8mBqjy43Mmyg4vUQOQ3H6agYsh3YaHskThv UYcWtHE+0+9HdNHDgdboF5OBzYjOLTFverzGHRPN6fE/ZierjOMpqGab/enJIwZ3Tu1Y mnzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8wSxAJ+gHi0g98hDB1dbU7MZgAdNdntUI/snG/7ca/4=; b=WsINHZrxZ4dBxU8H11lH1jzw249vlDHHsSAcg/isrUlk4DOgdf1NzJN9e315PYfJDe W06NYExQErVLyZ8ZwmjZajquSAX3kNeMEBc/alfwctI1qlgo2EfuOODpMoHFK/HIzVbI EwoRelmk62tbM7gwwEbft1qUaZwcC7XyDDEbJ9+hTT8417abJTJhmK5ieHgCMHwrtMWR 9WNUzCfTdaDTSPT6/Q46DPfVKJ50bREj+TI8jnm3olCfpDT0/aR/RpkSs8+Mj+3CQCgD EbrIl39KA0OgFAvRlgweOXvTnI0OaW5VhJM5b4ux3UHj8PK6K/g34b+gpBQu/jLvqMo3 lUyw== X-Gm-Message-State: AKS2vOzWYACFLldkZAICLgq+o4fmmgFcCuTBNV5QEjiWcJJTXQIACilQ G6ce7odDOghbiS4eHz+LO8AqxeyMbgApjDA= X-Received: by 10.129.109.4 with SMTP id i4mr24872562ywc.3.1497980288328; Tue, 20 Jun 2017 10:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 20 Jun 2017 10:37:27 -0700 (PDT) In-Reply-To: References: <20170619205309.10839.qmail@ary.lan> From: Eric Rescorla Date: Tue, 20 Jun 2017 10:37:27 -0700 Message-ID: To: John R Levine Cc: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd184f7aedc055267b617" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:38:11 -0000 --001a114dd184f7aedc055267b617 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 9:50 AM, John R Levine wrote: > Giving this document a quick read I see several things I would change. >> > > In case it's not clear, I do not purport to be any sort of crypto expert, > so I'm hoping that you, r$, et al. help us to be sure that what I say makes > sense. > > 1. You say you are using EdDSA with SHA-256? Does this mean you intend >> to use the HashEdDSA variant see ( >> https://tools.ietf.org/rfcmarkup?doc=8032#section-4)? If so you >> should say so. >> > > I think the answer is no. DKIM signatures use two chained hashes. First > it hashes a canonicalized version of the message body, and inserts the > base64 hash into the DKIM-Signature header. Then it hashes a canonicalized > version of the headers, signs that hash, and inserts the base64 signature > of the second hash into the DKIM-Signatuer header. To avoid infinite > regress, the verification step pretends the signature wasn't in the header > when verifying. > > As far as I can tell, feeding the canonicalized header text into HashEdDSA > gives the same result as feeding the hash into PureEdDSA. Since the > hashing in DKIM has been defined for a decade and we're not planning to > change it (other than to deprecate SHA-1) I'd rather say this is a > PureEdDSA signature of the existing hash. OK, I think this probably needs to be clearer in the document. 2. I wouldn't specific generic EdDSA but rather EdDSA with a specific >> curve. This is both for practical reasons (I don't want to have to >> distinguish keys by len()) and for algorithmic reasons (you want to >> use a stronger digest algorithm than SHA-256 with X448) >> > > OK. Looking at 8032, it appears I want to use Ed25519, right? Yes, I think so. -Ekr 3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp) These keys >> are not intended for use with key exchange but rather signature. The >> document actually seems kinda confused on this point with the text >> saying one thing and the table saying another. >> > > OK. > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --001a114dd184f7aedc055267b617 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 20, 2017 at 9:50 AM, John R Levine <johnl@taugh.com><= /span> wrote:
Giving this document a quick read I see several things I would change.

 In case it's not clear, I do not purport to be any sort of crypto exper= t, so I'm hoping that you, r$, et al. help us to be sure that what I sa= y makes sense.

1. You say you are using EdDSA with SHA-256? Does this mean you intend
=C2=A0 =C2=A0to use the HashEdDSA variant see (
=C2=A0 =C2=A0https://tools.ietf.org/rfcmar= kup?doc=3D8032#section-4)?=C2=A0 If so you
=C2=A0 =C2=A0should say so.

 I think the answer is no.=C2=A0 DKIM signatures use two chained hashes.=C2= =A0 First it hashes a canonicalized version of the message body, and insert= s the base64 hash into the DKIM-Signature header.=C2=A0 Then it hashes a ca= nonicalized version of the headers, signs that hash, and inserts the base64= signature of the second hash into the DKIM-Signatuer header.=C2=A0 To avoi= d infinite regress, the verification step pretends the signature wasn't= in the header when verifying.

As far as I can tell, feeding the canonicalized header text into HashEdDSA = gives the same result as feeding the hash into PureEdDSA.=C2=A0 Since the h= ashing in DKIM has been defined for a decade and we're not planning to = change it (other than to deprecate SHA-1) I'd rather say this is a Pure= EdDSA signature of the existing hash.

OK, I= think this probably needs to be clearer in the document.


2. I wouldn't specific generic EdDSA but rather EdDSA with a specific =C2=A0 =C2=A0curve. This is both for practical reasons (I don't want to= have to
=C2=A0 =C2=A0distinguish keys by len())=C2=A0 and for algorithmic reasons (= you want to
=C2=A0 =C2=A0use a stronger digest algorithm than SHA-256 with X448)

 OK.=C2=A0 Looking at 8032, it appears I want to use Ed25519, right?


Yes, I think so.

-Ekr



3. You shouldn't name the keys ecdh(fp) but rather eddsa(fp)=C2=A0 Thes= e keys
=C2=A0 =C2=A0are not intended for use with key exchange but rather signatur= e. The
=C2=A0 =C2=A0document actually seems kinda confused on this point with the = text
=C2=A0 =C2=A0saying one thing and the table saying another.

 OK.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

--001a114dd184f7aedc055267b617-- From nobody Tue Jun 20 10:52:53 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8BA12F3D3 for ; Tue, 20 Jun 2017 10:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 VUz6-_QnnxU7 for ; Tue, 20 Jun 2017 10:52:49 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 62B27129493 for ; Tue, 20 Jun 2017 10:52:49 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:fd7a:2368:ef63:6afe]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5KHqjsN027436 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 20 Jun 2017 10:52:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1497981168; bh=M46C7X8N0hZAXRUeiAc0f7KALphdXTSOiqbY3m46Tws=; h=Subject:To:References:From:Date:In-Reply-To; b=q1uhJYfgS8TPA9eax1+9cHCYVorBwESnhMBIUiKRH03MP5JaWNXGDugR+aPDvcASx 55eXrCIDSFvdoNA0jBaQh/aRwV8OM0ZQ6B4Q3Pd3ssUfKrfBdV3fqpi12wRU18NawH sPJW7AzVZmn3e/MAe4njPtATg0QHRRTBlBoF4bTc= To: dcrup@ietf.org References: <1642300.47WuTbIWPP@kitterma-e6430> From: Jim Fenton Message-ID: <33f087e3-ca27-f425-6d36-4ad11dd16799@bluepopcorn.net> Date: Tue, 20 Jun 2017 10:52:40 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <1642300.47WuTbIWPP@kitterma-e6430> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:52:52 -0000 If it isn't obvious from my previous comments, I favor the "Deprecate rsa-sha1" option. I might even suggest we soften it to say that verifiers MUST implement rsa-sha256 and SHOULD implement rsa-sha1; it's ultimately up to the verifier to decide what signatures they trust and they might decide not to implement rsa-sha1 if they know they will never accept one of those signatures anyway. Having been away from this stuff for a while, I was startled that the hash algorithms were named directly in the ABNF rather than by reference to the registry, but that's what we do apparently. The description of the rsa-sha1 algorithm (3.3.1 in RFC 6376) can be removed as well when rsa-sha1 is removed entirely, of course. -Jim On 6/20/17 8:39 AM, Scott Kitterman wrote: > I think we still have some different opinions on what to do with rsa-sh= a1, so=20 > I thought I'd attempt to summarize the different options (as best I can= , I=20 > have an opinion, so I'm sure my bias will leak in) in the hopes it will= help=20 > drive this part of the WG discussion to closure. Note: I'm not talking= about=20 > RSA key sizes because it seems to me we're largely converged on that to= pic. > > I think there are roughly three options that have been discussed: > > Status quo: > >> Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MU= ST >> implement both rsa-sha1 and rsa-sha256. > Deprecate rsa-sha1: > >> Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST= >> implement both rsa-sha1 and rsa-sha256. > Remove rsa-sha1: > >> Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST= >> implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. > Note: This option also removes rsa-sha1 from the ABNF. > > Pro/Con for each: > > Status quo: > There is no immediate known security threat to rsa-sha1 that would indi= cate=20 > its imminent demise as a useful algorithm in this application and rsa-s= ha1=20 > signatures are still in significant use. RSA key sizes are the current= =20 > security issue and that can be fixed without doing anything about rsa-s= ha1. > > There are a number of known shortcomings with rsa-sha1 and given that r= sa- > sha256 is available and does not share the same issues, raising the bar= to=20 > require rsa-sha256 is easy and a prudent step to take in advance of iss= ues=20 > being published. Let's not wait until we have to panic. > > Retaining rsa-sha1 means DKIM implementers will have to deal with three= =20 > algorithms rather than two and this raises implementation complexity an= d the=20 > risk of things going wrong. > > > Deprecate rsa-sha1: > There is no immediate known security threat to rsa-sha1 that would indi= cate=20 > its imminent demise as a useful algorithm in this application and rsa-s= ha1=20 > signatures are still in significant use. RSA key sizes are the current= =20 > security issue and that can be fixed without doing anything about rsa-s= ha1,=20 > but if we move to a more aggressive stance against rsa-sha1 now, it sho= uld be=20 > easier to remove it when needed. > > There are a number of known shortcomings with rsa-sha1 and given that r= sa- > sha256 is available and does not share the same issues, raising the bar= to=20 > require rsa-sha256 is easy and a prudent step to take in advance of iss= ues=20 > being published. Let's not wait until we have to panic. > > Retaining rsa-sha1 means DKIM implementers will have to deal with three= =20 > algorithms rather than two and this raises implementation complexity an= d the=20 > risk of things going wrong. > > Remove rsa-sha1: > This option eliminates (to the extent it is adopted) the potential of s= ecurity=20 > risks with rsa-sha1. If a relevant issue with rsa-sha1 is made public,= there=20 > will be no further standards work that needs to be done. This option a= lso=20 > keeps the number of algorithms at two, eliminating the additional compl= exity=20 > associated with having more algorithms to sort through in implementatio= n. =20 > While this might be considered somewhat abrupt, rsa-sha1 signing has be= en=20 > effectively SHOULD NOT for a decade. Maybe this will create some momen= tum for=20 > operators to move off of it. > > It is abrupt to remove something without a formal deprecation period. > > Thoughts? > > Scott K > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Tue Jun 20 11:56:15 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531612714F for ; Tue, 20 Jun 2017 11:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oM2rGlc_Li52 for ; Tue, 20 Jun 2017 11:56:12 -0700 (PDT) Received: from smtp64.iad3a.emailsrvr.com (smtp64.iad3a.emailsrvr.com [173.203.187.64]) (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 4FB75129412 for ; Tue, 20 Jun 2017 11:56:12 -0700 (PDT) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 660C525458; Tue, 20 Jun 2017 14:56:07 -0400 (EDT) X-Auth-ID: jon@merrymeet.com Received: by smtp25.relay.iad3a.emailsrvr.com (Authenticated sender: jon-AT-merrymeet.com) with ESMTPSA id BA79725362; Tue, 20 Jun 2017 14:56:06 -0400 (EDT) X-Sender-Id: jon@merrymeet.com Received: from [172.16.138.17] ([TEMPUNAVAIL]. [65.199.22.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 20 Jun 2017 14:56:07 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jon Callas In-Reply-To: Date: Tue, 20 Jun 2017 11:56:04 -0700 Cc: Jon Callas , John Levine , "dcrup@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170619205309.10839.qmail@ary.lan> To: "Salz, Rich" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 18:56:14 -0000 > On Jun 20, 2017, at 5:38 AM, Salz, Rich wrote: >=20 > Once the charter change is approved (Murray is working on that with = Alexsey), I'd like to put this into WGLC. Any concerns? My biggest concern is about key rollover. I could, should, say more, but = every time I write a page I get rantier than I wanted to be. Suffice it to say that removing and retiring keys (which is easy because = they're just in DNS, and there's no revocation etc.) is really important = for privacy and downstream issues. Jon From nobody Tue Jun 20 12:00:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E541315FB for ; Tue, 20 Jun 2017 12:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com 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 SmsZaDwrtYzg for ; Tue, 20 Jun 2017 12:00:11 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F2C11315F5 for ; Tue, 20 Jun 2017 12:00:07 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 70so25573478uau.0 for ; Tue, 20 Jun 2017 12:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FdQL+K5ya+h50C7fRvrKGyaIF9/HdLsDFzxy4AT7u2I=; b=e/MeVJhtCiLH0AZZAkEhFTr3/OacQdEwkRGqqjWQtZCsr/gQTBB7tizhVSqpzmDE8o VMfyIiGiUJmo+Jmq/lLfLb+xkzl064Q4ReU2gxiELuUcpxQ02leHLVU/Doa0iuHlGUIY 2U9rjLCFYkYVrtu9VJyZGJqg/AfMUYnkbtWkc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FdQL+K5ya+h50C7fRvrKGyaIF9/HdLsDFzxy4AT7u2I=; b=iwGSlQIYdhdqRVLGnR2rgrSwNPSPa+i3MxeTG+lUUhoQaotaILAR3Wo0FRcC/lhE91 D+dM5ifxH5X76KRw8PojLr5nZy5ee13otG+edhnSXjVyQ/5+a7aZ+4ws/jBgV61XJ6qT /3mvq06rmZr1dqTs0iWTSTFBA/cas+/YFVvMDLCbciXHxch9+6PiAjinK85JK6wP2HHR ZumSGVRj2SXSJGZcjTeIChrdmAocss63gd0VawGxbGOCMl1EN8vheINaUyAShGYBGpHX N1WdpDb8n6SUvLLNZVoXUJzuCSWdlNfqDHkKnyHkwGIPaKSDQBjQmLwYDO+y2wKSPULt qFfQ== X-Gm-Message-State: AKS2vOzjWNGPQUyIh1x0tK0KO97T4+6YAJWLwtvyz0oH5Ccel0cF8ruj giECRYarKVsAS8T/+ukjincD6i3EdjGAYUE= X-Received: by 10.159.52.77 with SMTP id s13mr13430972uab.8.1497985206192; Tue, 20 Jun 2017 12:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.75.153 with HTTP; Tue, 20 Jun 2017 12:00:05 -0700 (PDT) In-Reply-To: <1642300.47WuTbIWPP@kitterma-e6430> References: <1642300.47WuTbIWPP@kitterma-e6430> From: Kurt Andersen Date: Tue, 20 Jun 2017 12:00:05 -0700 Message-ID: To: Scott Kitterman Cc: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="f403043eb7a4187df0055268dcf1" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:00:13 -0000 --f403043eb7a4187df0055268dcf1 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman wrote: > > I think there are roughly three options that have been discussed: > > Status quo: > > > Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST > > implement both rsa-sha1 and rsa-sha256. > > Deprecate rsa-sha1: > > > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST > > implement both rsa-sha1 and rsa-sha256. > > Remove rsa-sha1: > > > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST > > implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. > Note: This option also removes rsa-sha1 from the ABNF. > [elided] Remove rsa-sha1: > This option eliminates (to the extent it is adopted) the potential of > security > risks with rsa-sha1. . . > While this might be considered somewhat abrupt, rsa-sha1 signing has been > effectively SHOULD NOT for a decade. Maybe this will create some momentum > for > operators to move off of it. > > It is abrupt to remove something without a formal deprecation period. > I'm in favor of moving strongly and clearly to kill sha1, but what about moving it out to the registry with a dated "MUST NOT". That provides for a deprecation period without the need for further intervention. The other advantage is that it provides a stronger historical record that people can point to when explaining brain-deadness to people who have not updated :-) I would suggest a "drop dead" date of something like mid-2018 to allow the rest of this work to reach completion. --Kurt --f403043eb7a4187df0055268dcf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman <= sklist@kitterman.= com> wrote:

I think there are roughly three options that have been discussed:

Status quo:

> Signers MUST implement and SHOULD sign using rsa-sha256.=C2=A0 Verifie= rs MUST
> implement both rsa-sha1 and rsa-sha256.

Deprecate rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.=C2=A0 Verifiers= MUST
> implement both rsa-sha1 and rsa-sha256.

Remove rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.=C2=A0 Verifiers= MUST
> implement rsa-sha256.=C2=A0 rsa-sha1 is obsolete and MUST not be used.=
Note: This option also removes rsa-sha1 from the ABNF.

[elided]=C2=A0

Remove rsa-sha1:
This option eliminates (to the extent it is adopted) the potential of secur= ity
risks with rsa-sha1. =C2=A0. =C2=A0.
While this might be considered somewhat abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade.=C2=A0 Maybe this will create some mome= ntum for
operators to move off of it.

It is abrupt to remove something without a formal deprecation period.

I'm in favor of moving strongly and clea= rly to kill sha1, but what about moving it out to the registry with a dated= "MUST NOT". That provides for a deprecation period without the n= eed for further intervention. The other advantage is that it provides a str= onger historical record that people can point to when explaining brain-dead= ness to people who have not updated :-)
I would suggest a "d= rop dead" date of something like mid-2018 to allow the rest of this wo= rk to reach completion.

--Kurt
--f403043eb7a4187df0055268dcf1-- From nobody Tue Jun 20 12:15:20 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C2B128D2E for ; Tue, 20 Jun 2017 12:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=JeY/vFwg; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=nyknc3Dk 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 gfWoy5My2AbA for ; Tue, 20 Jun 2017 12:15:17 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2DD1241FC for ; Tue, 20 Jun 2017 12:15:17 -0700 (PDT) Received: (qmail 48489 invoked from network); 20 Jun 2017 19:15:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=bd67.59497444.k1705; bh=45eiRF0Cp/wFxk92vhvYIHpOOCQldCOtWAil/kbKBP4=; b=JeY/vFwg/24lKgsak0tPKs14B57qGEodCuUauDR1CZ2hAuFYvv4uHjE8nxZcb8IdaC+mJUWsKjC6S7lrRLL4piWyuuOkneARaOaN5h7n1hQ8RY4+PbY8tIc75NmUyBfwB96GwPD/+v6VYtNlTIFJdCGPnV7ig8Y0H2T/Jhbl/vGt7jonvaBFQN31Q9/u1pibcpTRCD7k+7n/d0zJh35GO+7t+6FT8fPBxXbd7n+ZSaVrsttQuoPFntHQnz3+lwv3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=bd67.59497444.k1705; bh=45eiRF0Cp/wFxk92vhvYIHpOOCQldCOtWAil/kbKBP4=; b=nyknc3DkILIZiDzsA9D7cMCd1wqFXtRqzWv44BZxHineDTOTQuHT9qo2OXNU+FNu0JLp5Eib2CkL7vbgYa2UnIWfu5hk7tWJYNsNv+3p2rQsddojToMYuno9PfZVMetg26GXJIT+f++fbSmHwbI2XIUnIrxrCEJnvw6osnSEPsL29rD/t1M7tFJJ/2a2xmNjIgw/a1ZBh6iolaY4Hqo/m7bKPjvdwf6XEhRNIV7IzRTb5mO/h6GPL7UlrUO6XtSW Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jun 2017 19:15:16 -0000 Date: 20 Jun 2017 15:15:16 -0400 Message-ID: From: "John R Levine" To: "Jon Callas" Cc: "dcrup@ietf.org" In-Reply-To: References: <20170619205309.10839.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] key rotation, was Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:15:19 -0000 On Tue, 20 Jun 2017, Jon Callas wrote: > My biggest concern is about key rollover. I could, should, say more, but every time I write a page I get rantier than I wanted to be. > > Suffice it to say that removing and retiring keys (which is easy because > they're just in DNS, ... We talked about this at the M3AAWG meeting. The main reason that mail systems don't rotate keys is that rotating is hard because they're in the DNS. In many organizations, the people who run the DNS are far awy from the people who run the mail, and the two groups are not friends. A proposed hack is to publish two or three key records as CNAMEs that point at a DNS server the mail people control, and rotate the target records a few times a year. In large organizations there's also the issue of updating all of the mail servers at roughly the same time, but the DNS management is apparently the hard part. In any event, key rotation is a security issue rather than an interopration issue. If you want I can ask the guy who proposed the CNAMEs if he'd like to write it up as an information draft. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jun 20 12:24:16 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5094A131608 for ; Tue, 20 Jun 2017 12:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 zdrT6UTkAt8M for ; Tue, 20 Jun 2017 12:24:13 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A5913160D for ; Tue, 20 Jun 2017 12:24:13 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7381CC400E6 for ; Tue, 20 Jun 2017 14:24:12 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497986652; bh=TfJgUgR3QhrX4oqWB8CeHd0tjMKyR4Z2I2yBTYHDR6o=; h=From:To:Subject:Date:In-Reply-To:References:From; b=h6DGYtLV6iijO0Eb0aY321+cIGwQR3+5e87jUFa90i1KW7IciQlneSNNzUu5tiLva 0v2KMUGXbp15Cqp8QbGCH1Q++wcQvTIvazfbUusYhPjx4pFozw3Dai6urJUjFIuh6v EyMpWd/bvKj6ZHth1jx6kYVzjOAlX/EiPHSl4Lvo= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 20 Jun 2017 15:24:11 -0400 Message-ID: <10416754.S7IJN86VGL@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170619205309.10839.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:24:15 -0000 On Tuesday, June 20, 2017 12:38:45 PM Salz, Rich wrote: > > Not to nag or anything, but I think this draft addresses everything in the > > WG's charter, assuming the charter is adjusted to deprecate SHA-1. > > > > Could people take a look and see if you agree? If so we could move it to > > last call and be within hailing distance of wrapping things up. > > Let me be more "official" > > Once the charter change is approved (Murray is working on that with > Alexsey), I'd like to put this into WGLC. Any concerns? This is no doubt reasonably obvious, but for clarity: I think it's still not clear where the group lies on how dead we should kill rsa-sha1. I think the WG chairs are going to have to evaluate the consensus and let us know. Once that's done, converging on the correct wording should be ~easy (whether it ends up in my draft or John's). Scott K From nobody Tue Jun 20 12:28:25 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9EF131613 for ; Tue, 20 Jun 2017 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 gQF6scRUHy6m for ; Tue, 20 Jun 2017 12:28:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8A813160B for ; Tue, 20 Jun 2017 12:28:21 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B61A7C400E6 for ; Tue, 20 Jun 2017 14:28:20 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497986900; bh=RyuvnOmN0iKFD30wWMy76K5EDeKEHQA+FsspJ26mbyE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Hb/xGz3PJa98A9C0JpHlT+pw0//KlRdi39vLMDAullB3oc3a0x8cJ5t/AQj181rvl aK2P94/Edpsqx4wb6EKxr5AR6sGNcqssUN0ltmM/XF7rpHy5nZpmsyGZsGT0fa0N10 i1RvHF64BZnCtQQWN0balawkFUTdrJ5TgRgRgRAc= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 20 Jun 2017 15:28:19 -0400 Message-ID: <10345013.0xW9ERPpmE@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20170619205309.10839.qmail@ary.lan> References: <20170619205309.10839.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:28:23 -0000 On Monday, June 19, 2017 08:53:09 PM John Levine wrote: > Not to nag or anything, but I think this draft addresses everything in the > WG's charter, assuming the charter is adjusted to deprecate SHA-1. > > Could people take a look and see if you agree? If so we could move it to > last call and be within hailing distance of wrapping things up. > > >* new algorithm is now EdDSA, tags updated appropriately > > > >* sha1 hash is moved to historic > > > >* place marker to splice in deprecation text from Scott's draft if we want > >to. > > > >My draft has always provided updated text for section 3.3 of RFC 6376. > >It says which algorithms signers and verifiers are supposed to use. As another non-crypto expert, it's not clear to me what the DNS record for the new algorithm are supposed to look like? If it's reasonably clear from what's in the exisitng RFCs, perhaps an example? Scott K From nobody Tue Jun 20 12:38:10 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C67131292CE; Tue, 20 Jun 2017 12:38:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149798748868.25039.9965936692099258736@ietfa.amsl.com> Date: Tue, 20 Jun 2017 12:38:08 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:38:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update of the IETF. Title : Cryptographic Update to DKIM Author : John Levine Filename : draft-ietf-dcrup-dkim-crypto-02.txt Pages : 7 Date : 2017-06-20 Abstract: DKIM was designed to allow new cryptographic algorithms to be added. This document adds a new signing algorithm and a new way to represent signature validation keys, and deprecates an obsolete signing algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-02 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 20 12:40:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A6F13160E for ; Tue, 20 Jun 2017 12:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=qE4azGML; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=fWHZFurq 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 HVBG32o4iWTW for ; Tue, 20 Jun 2017 12:40:35 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FA6131620 for ; Tue, 20 Jun 2017 12:40:23 -0700 (PDT) Received: (qmail 52161 invoked from network); 20 Jun 2017 19:40:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cbbf.59497a26.k1705; bh=gqvL+qh3thRxY9hLa0atRkXrfkmP5H6wsU7MW7sNgpc=; b=qE4azGMLOhh4q6RfoUrdaJwbIi09MPefA9w52L21+rPS83ofN9f/Xfm8glD3SVH8RYWr6KJCxCSdBgHO9WqgmELMY7VyeHIPoCJv/cfxUph57z3l6EASfhCh1+4UI98s0K2cRKa/tzNtHgRSK/T61LKd+ufXCiDfpra+L3kouFYzontsqB31wdauXwTaTAVaXO3VfcF3YFDTtjmk6StFRIbTC7gTgebNUpyQsLKeDhR+vPfDWQ1rb6S136Op2iyN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cbbf.59497a26.k1705; bh=gqvL+qh3thRxY9hLa0atRkXrfkmP5H6wsU7MW7sNgpc=; b=fWHZFurqJOXP+RfBLV5jUe3BLz2AipEVQiVYj7j1PjM8hGN6PaNk/NgbC6XbRx9zwrHDCnPIlZ5dmUAU8m1kHu86yOWI/Oizy6D91aw/CA/cdDGTmyOPSCgDPuhGg8CV6KbLNwzflNgrAiTkZJc7ephLSsgKXZux1Jo7TXYCtSq0pVyJXojgOGrnbE+muzXXOX3VV5Jpv1HuXPhWrHxtlNcwPPYpN4rG5StTCayouL4RGcSQtoYq+bik49MCSqmX Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jun 2017 19:40:22 -0000 Date: 20 Jun 2017 15:40:22 -0400 Message-ID: From: "John R Levine" To: dcrup@ietf.org In-Reply-To: <149798748868.25039.9965936692099258736@ietfa.amsl.com> References: <149798748868.25039.9965936692099258736@ietfa.amsl.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-02.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:40:37 -0000 This is intended to address the recent concerns by ekr and others. On Tue, 20 Jun 2017, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the DKIM Crypto Update of the IETF. > > Title : Cryptographic Update to DKIM > Author : John Levine > Filename : draft-ietf-dcrup-dkim-crypto-02.txt > Pages : 7 > Date : 2017-06-20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ From nobody Tue Jun 20 12:44:30 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC8F131622 for ; Tue, 20 Jun 2017 12:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com 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 LHrNy4VS2OVj for ; Tue, 20 Jun 2017 12:44:26 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411A3131618 for ; Tue, 20 Jun 2017 12:44:26 -0700 (PDT) Received: (qmail 52662 invoked from network); 20 Jun 2017 19:44:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=cdb4.59497b19.k1705; bh=+yDrrs9SjlwikF+vAktZngWV8i3tTo/6Eto30lMyvhk=; b=Xwz+H/35cpd0wrzw42dQHHlSvdSo1OaEtZY9CutEKonITW3T2vP9Tnj05LN7MX4wC8W172tfYUor10q8wPQ6s/jt77lwiqO6EUQc3K62i9QB9mwHgyCfFaNai/GpLIgtg3rBALSmxduBsXu/jdXTeiESNCWMxx1ugxftAaTRi1goqssS4orZPzyY87jEIeJVTIXV6WMakvfNbvwtbGcCaUQOy7MVqE1Di1fUPyFV6VCk01SCljicUSYZSyPtJiiY Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jun 2017 19:44:25 -0000 Date: 20 Jun 2017 15:44:24 -0400 Message-ID: From: "John R. Levine" To: "Scott Kitterman" Cc: dcrup@ietf.org In-Reply-To: <10345013.0xW9ERPpmE@kitterma-e6430> References: <20170619205309.10839.qmail@ary.lan> <10345013.0xW9ERPpmE@kitterma-e6430> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 19:44:28 -0000 > As another non-crypto expert, it's not clear to me what the DNS record for the > new algorithm are supposed to look like? If it's reasonably clear from what's > in the exisitng RFCs, perhaps an example? I think the new -02 is clearer. The format of the key records hasn't changed at all other than to add the new algorithms as key tags. For EdDSA, the p= is the base64 version of the key, just like RSA. For the fingerprint versions, the p= is the base64 version of the sha-256 hash of the key. New text says that you get the key out of the signature header, hash it, check that the hash matches the one in the DNS, and then use the key as usual. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jun 20 13:01:23 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4155A13160E for ; Tue, 20 Jun 2017 13:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com 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 pnhoj7T9ZUj9 for ; Tue, 20 Jun 2017 13:01:19 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926DF13153E for ; Tue, 20 Jun 2017 13:01:19 -0700 (PDT) Received: (qmail 54944 invoked from network); 20 Jun 2017 20:01:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d69e.59497f0e.k1705; bh=RUyjy19utmgdBbcRaeYdMzVgWwktFml/yCFrbxFnl64=; b=QNslhNobc5C3I2c1kGtvvcY2o6myx5Z8ikQg87mZsiU8kt7eCno0j765By4vc3S4CLo9k3CHssA0Q7fXWwIioQPow/5cbOVvhr5iiYcsib25RqrBXbGo5OWMFYuY/8gXd8J1D/U26xdEHjn0pmleukxhLtLoDG56gdT8EQOfwKaX2tJMg8l644fViei6hJNTGnXNbuLwJgrxnm2kBdaGr1VKVHJlY2RxmqRzJWMvO7m9uqsDpYP9FiX8NGUApyXZ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jun 2017 20:01:18 -0000 Date: 20 Jun 2017 16:01:18 -0400 Message-ID: From: "John R. Levine" To: "Scott Kitterman" Cc: dcrup@ietf.org In-Reply-To: <10416754.S7IJN86VGL@kitterma-e6430> References: <20170619205309.10839.qmail@ary.lan> <10416754.S7IJN86VGL@kitterma-e6430> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 20:01:21 -0000 > I think it's still not clear where the group lies on how dead we should kill > rsa-sha1. I think the WG chairs are going to have to evaluate the consensus > and let us know. Once that's done, converging on the correct wording should > be ~easy (whether it ends up in my draft or John's). Given that we are not the Network Police, I don't see this as a very meaningful questions We can tell people not to sign with sha-1 or to verify sha-1 signatures, but we can't threaten them with penalties if they ignore us. In practice, the known problems with sha-1 aren't yet very relevant to short lived signatures like DKIM's since the cost of finding a collision remains high, so signers can't be bothered to upgrade their signers. I looked at the last 1000 signed messages I got from non-spam bulkish mailers, and 354 of them still had sha1 signatures. They can't be bothered to upgrade, and the IETF has no leverage. At some point I expect one of the big gorillas will decide to stop accepting sha-1 and after a week of panic in the bulk mail community, they'll all patch their signers and we'll never see another sha-1 signature again. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly PS: Hall of shame: 67 d=patreon.com; 37 d=bookbub.com; 32 d=gbp.co.uk; 20 d=email.powells.com; 18 d=audiencerewards.com; 17 d=astorwines.com; 16 d=aaas.sciencepubs.org; 12 d=e.avis.com; 10 d=email.airbnb.com; 7 d=mail125.wdc01.mcdlv.net; 6 d=ebay.com; 5 d=rocketmiles.com; 4 d=sendgrid.me; 4 d=rel1.aeroplan.com; 4 d=mail63.us4.mcsv.net; 4 d=e-vanguard.com; 3 d=subscription.theatlantic.com; 3 d=emessaging.us.hsbc.com; 3 d=emails.hertz.com; 3 d=cmail19.com; 2 d=your.lufthansa-group.com; 2 d=ted.com; 2 d=notify.transunion.com; 2 d=newsletter.milesandmore.com; 2 d=mg.expediamail.com; 2 d=mail70.atl11.rsgsv.net; 2 d=mail215.atl171.mcdlv.net; 2 d=mail103.atl161.mcsv.net; 2 d=kickstarter.com; From nobody Tue Jun 20 13:11:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7908213162C for ; Tue, 20 Jun 2017 13:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 lsxyZG2u17rm for ; Tue, 20 Jun 2017 13:11:40 -0700 (PDT) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2D2131561 for ; Tue, 20 Jun 2017 13:11:38 -0700 (PDT) Received: by mail-ot0-x232.google.com with SMTP id y47so75768020oty.0 for ; Tue, 20 Jun 2017 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=uHQyHWK9mZptnq63jdz1+W+GjTSi0C74+NRmWZT6Hqw=; b=OVWExejeu6e2EhQ34oxNeNCN3U75mdPVE1Qh/6re+sE6ndjwH++a8wBevmVV8A8+av RTBbAFxBp+PaqGZ8A70+8a5VxL5JWqoKM4+ZzR2lR3Rer+JzZxhrmOLjHDBF80leuuaA MXMLvF2QGqPX7MsYYHFf557vrcBpefIZnPloFaMKuALq+e1O82K+5zMEJqXzTx1XhPq0 ZItIxeJo649roTL5MbaTMOdrudx7uS+pVdplnqzHJjXYiLY6Y2n8Bso+y8GbLx7AemwA /2GXcgpgzfKIfeO3BDjw467EW/3+9W84P2d9Jj7zh0ePJ5vruH8tcozf/FdnZrxS1SxV mZyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uHQyHWK9mZptnq63jdz1+W+GjTSi0C74+NRmWZT6Hqw=; b=uNhWgoquRGZgmRSVbGRNnntKzDv6hWGjnkW3DuZ7JsP1oyg4zHhUMipNZTEJw44Gt6 h1Nx4fGH04HmzPanMjJDvcJkmmrqfDHXx4jU/6n3yFCxsyiMrh5PtCSD9EKLwQBuLNK0 CUIVV2cDMoe8kFR/YHrNoOGvjggU+8hZSmAhobajHAcjD9zr1lEnkU475KF3x9+dFMVz yLCVk/D+EY7nQH52lLUiBon2Xr56Kr1h6Yaed+nfglDjF0IRyqEyv1aG+DeGq8u+n8Go rDug/lFswFHXgMnOhoj8l/X6XLSQEhEQNEuBwCbZLwJzZR1F4NdkXl9UFxZi4fOoSmKk 2enw== X-Gm-Message-State: AKS2vOw4v6YtHToMs/TwgS49efr61DBlqjV7IN8L6Svp+idKzPa3GNLh TkOwmpTlT0cGnYF03VYtx7ZMP2gJxTTjlj4= X-Received: by 10.157.40.238 with SMTP id s101mr20194129ota.88.1497989497564; Tue, 20 Jun 2017 13:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Tue, 20 Jun 2017 13:11:37 -0700 (PDT) In-Reply-To: References: <1642300.47WuTbIWPP@kitterma-e6430> From: Brandon Long Date: Tue, 20 Jun 2017 13:11:37 -0700 Message-ID: To: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a113edb94e1a603055269db10" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 20:11:42 -0000 --001a113edb94e1a603055269db10 Content-Type: text/plain; charset="UTF-8" I think we should go for removal. I don't think implementation wise for receivers who have a choice, that removal vs deprecation is going to have a big short-term impact, I doubt most receivers would remove rsa-sha1 at the publish date or on the deprecation date in the registry. They'll assess the damage between keeping it or removing it based on the current timeframes. The larger question will be if implementations that others depend on start removing it, ie if you upgrade your version of opendkim and rsa-sha1 is no longer supported, you'll likely have unexpected changes to your receiving. That said, I think that deprecation doesn't change the status quo enough. Brandon On Tue, Jun 20, 2017 at 12:00 PM, Kurt Andersen wrote: > > > On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitterman > wrote: > >> >> I think there are roughly three options that have been discussed: >> >> Status quo: >> >> > Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST >> > implement both rsa-sha1 and rsa-sha256. >> >> Deprecate rsa-sha1: >> >> > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST >> > implement both rsa-sha1 and rsa-sha256. >> >> Remove rsa-sha1: >> >> > Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST >> > implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. >> Note: This option also removes rsa-sha1 from the ABNF. >> > > [elided] > > Remove rsa-sha1: >> This option eliminates (to the extent it is adopted) the potential of >> security >> risks with rsa-sha1. . . >> While this might be considered somewhat abrupt, rsa-sha1 signing has been >> effectively SHOULD NOT for a decade. Maybe this will create some >> momentum for >> operators to move off of it. >> >> It is abrupt to remove something without a formal deprecation period. >> > > I'm in favor of moving strongly and clearly to kill sha1, but what about > moving it out to the registry with a dated "MUST NOT". That provides for a > deprecation period without the need for further intervention. The other > advantage is that it provides a stronger historical record that people can > point to when explaining brain-deadness to people who have not updated :-) > I would suggest a "drop dead" date of something like mid-2018 to allow the > rest of this work to reach completion. > > --Kurt > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a113edb94e1a603055269db10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think we should go for removal.

I don= 't think implementation wise for receivers who have a choice, that remo= val vs deprecation is going to have a big short-term impact, I doubt most r= eceivers would remove rsa-sha1 at the publish date or on the deprecation da= te in the registry.=C2=A0 They'll assess the damage between keeping it = or removing it based on the current timeframes.

Th= e larger question will be if implementations that others depend on start re= moving it, ie if you upgrade your version of opendkim and rsa-sha1 is no lo= nger supported, you'll likely have unexpected changes to your receiving= .=C2=A0 That said, I think that deprecation doesn't change the status q= uo enough.

Brandon

On Tue, Jun 20, 2017 at 12:00 PM, Kur= t Andersen <kurta@drkurt.com> wrote:


On Tue, Jun 20, 2017 at 8:39 AM, Scott Kitte= rman <sklist@kitterman.com> wrote:

I think there are roughly three options that have been discussed:

Status quo:

> Signers MUST implement and SHOULD sign using rsa-sha256.=C2=A0 Verifie= rs MUST
> implement both rsa-sha1 and rsa-sha256.

Deprecate rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.=C2=A0 Verifiers= MUST
> implement both rsa-sha1 and rsa-sha256.

Remove rsa-sha1:

> Signers MUST implement and sign using rsa-sha256 only.=C2=A0 Verifiers= MUST
> implement rsa-sha256.=C2=A0 rsa-sha1 is obsolete and MUST not be used.=
Note: This option also removes rsa-sha1 from the ABNF.

[elided]=C2=A0

Remove rsa-sha1:
This option eliminates (to the extent it is adopted) the potential of secur= ity
 risks with rsa-sha1. =C2=A0. =C2=A0.
While this might be considered somewhat abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade.=C2=A0 Maybe this will create some mome= ntum for
operators to move off of it.

It is abrupt to remove something without a formal deprecation period.

I'm in favor of moving strongly a= nd clearly to kill sha1, but what about moving it out to the registry with = a dated "MUST NOT". That provides for a deprecation period withou= t the need for further intervention. The other advantage is that it provide= s a stronger historical record that people can point to when explaining bra= in-deadness to people who have not updated :-)
I would suggest a = "drop dead" date of something like mid-2018 to allow the rest of = this work to reach completion.

--Kurt

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a113edb94e1a603055269db10-- From nobody Tue Jun 20 13:13:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8651315C5 for ; Tue, 20 Jun 2017 13:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 630hqkbmLR3S for ; Tue, 20 Jun 2017 13:13:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A894129BA2 for ; Tue, 20 Jun 2017 13:13:40 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C9C12C400E6 for ; Tue, 20 Jun 2017 15:13:37 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497989617; bh=oaT4jH2LGqh60hPI38WuPMVDRNC01rcqsx7qnto3law=; h=From:To:Subject:Date:In-Reply-To:References:From; b=zze5tD4NUPBN7qyDvKDybRKIC0Pg0E50eN9XdVCirRKJpAtO1gaivd1HVXJgEpqTm lkiSq8p37Ha+JuqyzGPloXXRzv/jQVYBqVepcg56UIJFJNRjAVRyRzMWd2IR8TqJKv SIbHy76RY9rdTiaOW8DtoiVx8qPLGzZnmL+wWdlE= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 20 Jun 2017 16:13:37 -0400 Message-ID: <1669306.WDH1r8A93p@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <10416754.S7IJN86VGL@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 20:13:42 -0000 On Tuesday, June 20, 2017 04:01:18 PM John R. Levine wrote: > > I think it's still not clear where the group lies on how dead we should > > kill rsa-sha1. I think the WG chairs are going to have to evaluate the > > consensus and let us know. Once that's done, converging on the correct > > wording should be ~easy (whether it ends up in my draft or John's). > > Given that we are not the Network Police, I don't see this as a very > meaningful questions We can tell people not to sign with sha-1 or to > verify sha-1 signatures, but we can't threaten them with penalties if they > ignore us. > > In practice, the known problems with sha-1 aren't yet very relevant to > short lived signatures like DKIM's since the cost of finding a collision > remains high, so signers can't be bothered to upgrade their signers. I > looked at the last 1000 signed messages I got from non-spam bulkish > mailers, and 354 of them still had sha1 signatures. They can't be > bothered to upgrade, and the IETF has no leverage. > > At some point I expect one of the big gorillas will decide to stop > accepting sha-1 and after a week of panic in the bulk mail community, > they'll all patch their signers and we'll never see another sha-1 > signature again. Right, and when the panic happens (which is, I agree, when this will change for real) I'd like for the engineer getting beat up by his boss to be able to say in response to the "Argh! What should be do" question from the PHB [1] "We need to upgrade our DKIM like it says in RFC XXXX" [2]. I think what you've proposed covers that. Scott K [1] The pointy haired boss (see Dilbert), not the other one. [2] Followed by a mostly silent "Like I've been telling you for a year." From nobody Tue Jun 20 14:01:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEA01294DC for ; Tue, 20 Jun 2017 14:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 ld2Ic9MVGMsQ for ; Tue, 20 Jun 2017 14:01:38 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E9A126D73 for ; Tue, 20 Jun 2017 14:01:38 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id u19so143289880qta.3 for ; Tue, 20 Jun 2017 14:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=/rJP2ncG+igQrS84pBw/UpPX7162scmbNUIrOAqVXvA=; b=LIJ5NkbregZtqI5lj066MiNOIocbxU7+2uXKWMMqkhbjzJQzQpVpAb16niYEGiMH9H CB6TfNVKMXdXtZw4xFd4AxBWn5n8JOlvej7JNTzUAVvSG7w7POHnadRO7hT8nDveN/H3 8NP0FumIpqfr8j70jMWasbDaiU38dcFB4AUYAwaEHnMvRZ/GQaeSEp1ds83iFvC+k+FO +ssmCJHTGK8Cgqnx24uU+e4pLktElmZEAxaKAsat7yaq5Lq+uyxhiYl6N7h5kYdMKjFw Veat6tebUjXrdD1SqGF5RIymWA45D/J05k3so5KlmKf2VlwZbtRJAFOdWoDSIqUiFTPI MsjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=/rJP2ncG+igQrS84pBw/UpPX7162scmbNUIrOAqVXvA=; b=lp32zhG9s6nJJiCYhplLFsbIFbkOfMTSK5MfvFr09zw4yu2OoKxPCXU774+HMteZl6 9um7OIKM8UBr42cnMtbkmf34jkIqAB3qrYRWET2rRiBnlyn78iBkWcwva0D6UdhjQHJI v6eskiU5oOH7GrFA2RXaz8Cw0JCNFr2hBD664eeGiMdKVnv4Qu2JIwcvcSU0i0lB7kQl ZqSaxDRWKFwuhJnX5l1511I5eAuAr1HUJ0WdubmfrEOSFWbj+M32U1iQx3WrocOhuaYa chqxK6eVBgbE33t5TN5zhAc72pX+HdHbXH0m0bf1as9prcCQU4dpLpIqe8daKt9fzFFb EQCA== X-Gm-Message-State: AKS2vOyei99navHS3Rj1SSNUlDJspeAdRfXpnI1ynSJuX7U5hepTvIQa F8KqIxxfKqmXLFTQc21C6NgRiqdKLXl5EjU= X-Received: by 10.200.55.233 with SMTP id e38mr35421253qtc.198.1497992497277; Tue, 20 Jun 2017 14:01:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.183 with HTTP; Tue, 20 Jun 2017 14:01:36 -0700 (PDT) In-Reply-To: <1669306.WDH1r8A93p@kitterma-e6430> References: <10416754.S7IJN86VGL@kitterma-e6430> <1669306.WDH1r8A93p@kitterma-e6430> From: Peter Goldstein Date: Tue, 20 Jun 2017 14:01:36 -0700 Message-ID: To: Scott Kitterman , dcrup@ietf.org, "John R. Levine" Content-Type: multipart/alternative; boundary="001a113e4180ad3cff05526a8eef" Archived-At: Subject: Re: [Dcrup] Is there anything this WG wants to do not yet in draft-ietf-dcrup-dkim-crypto-01 ? X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 21:01:41 -0000 --001a113e4180ad3cff05526a8eef Content-Type: text/plain; charset="UTF-8" The -02 document looks basically good to me. The new EdDSA and fingerprinting behavior seems well-defined and unambiguous. And the guidance on minimum key length seems fine. And the SHA-1 language is clear and unambiguous. My only question is whether there's any need or desire to support larger RSA key sizes (e.g. 4096)? I don't know of a use case that requires such support that couldn't be met by the use of EdDSA, but I wanted to make sure the question was considered by the WG. Best, Peter On Tue, Jun 20, 2017 at 1:13 PM, Scott Kitterman wrote: > On Tuesday, June 20, 2017 04:01:18 PM John R. Levine wrote: > > > I think it's still not clear where the group lies on how dead we should > > > kill rsa-sha1. I think the WG chairs are going to have to evaluate the > > > consensus and let us know. Once that's done, converging on the correct > > > wording should be ~easy (whether it ends up in my draft or John's). > > > > Given that we are not the Network Police, I don't see this as a very > > meaningful questions We can tell people not to sign with sha-1 or to > > verify sha-1 signatures, but we can't threaten them with penalties if > they > > ignore us. > > > > In practice, the known problems with sha-1 aren't yet very relevant to > > short lived signatures like DKIM's since the cost of finding a collision > > remains high, so signers can't be bothered to upgrade their signers. I > > looked at the last 1000 signed messages I got from non-spam bulkish > > mailers, and 354 of them still had sha1 signatures. They can't be > > bothered to upgrade, and the IETF has no leverage. > > > > At some point I expect one of the big gorillas will decide to stop > > accepting sha-1 and after a week of panic in the bulk mail community, > > they'll all patch their signers and we'll never see another sha-1 > > signature again. > > Right, and when the panic happens (which is, I agree, when this will change > for real) I'd like for the engineer getting beat up by his boss to be able > to > say in response to the "Argh! What should be do" question from the PHB [1] > "We > need to upgrade our DKIM like it says in RFC XXXX" [2]. I think what > you've > proposed covers that. > > Scott K > > > [1] The pointy haired boss (see Dilbert), not the other one. > [2] Followed by a mostly silent "Like I've been telling you for a year." > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --001a113e4180ad3cff05526a8eef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The -02 document looks basically good to me.

The new EdDSA and fingerprinting behavior seems well-defin= ed and unambiguous.=C2=A0 And the guidance on minimum key length seems fine= .=C2=A0 And the SHA-1 language is clear and unambiguous.

My only question is whether there's any need or desire to suppor= t larger RSA key sizes (e.g. 4096)?=C2=A0 I don't know of a use case th= at requires such support that couldn't be met by the use of EdDSA, but = I wanted to make sure the question was considered by the WG.

=
Best,

Peter

On Tue, Jun 20, 2017 at 1:1= 3 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On Tuesday, June 20, 2017 04:= 01:18 PM John R. Levine wrote:
> > I think it's still not clear where the group lies on how dead= we should
> > kill rsa-sha1.=C2=A0 I think the WG chairs are going to have to e= valuate the
> > consensus and let us know.=C2=A0 Once that's done, converging= on the correct
> > wording should be ~easy (whether it ends up in my draft or John&#= 39;s).
>
> Given that we are not the Network Police, I don't see this as a ve= ry
> meaningful questions We can tell people not to sign with sha-1 or to > verify sha-1 signatures, but we can't threaten them with penalties= if they
> ignore us.
>
> In practice, the known problems with sha-1 aren't yet very relevan= t to
> short lived signatures like DKIM's since the cost of finding a col= lision
> remains high, so signers can't be bothered to upgrade their signer= s.=C2=A0 I
> looked at the last 1000 signed messages I got from non-spam bulkish > mailers, and 354 of them still had sha1 signatures.=C2=A0 They can'= ;t be
> bothered to upgrade, and the IETF has no leverage.
>
> At some point I expect one of the big gorillas will decide to stop
> accepting sha-1 and after a week of panic in the bulk mail community,<= br> > they'll all patch their signers and we'll never see another sh= a-1
> signature again.

Right, and when the panic happens (which is, I agree, when this will= change
for real) I'd like for the engineer getting beat up by his boss to be a= ble to
say in response to the "Argh! What should be do" question from th= e PHB [1] "We
need to upgrade our DKIM like it says in RFC XXXX" [2].=C2=A0 I think = what you've
proposed covers that.

Scott K


[1] The pointy haired boss (see Dilbert), not the other one.
[2] Followed by a mostly silent "Like I've been telling you for a = year."

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--001a113e4180ad3cff05526a8eef-- From nobody Tue Jun 20 15:47:46 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB378127275 for ; Tue, 20 Jun 2017 15:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=isdg.net header.b=k7+t5ioh; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=KV/yRCCq 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 BplNrGlVXTRf for ; Tue, 20 Jun 2017 15:47:42 -0700 (PDT) Received: from listserv.winserver.com (catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 62940126C0F for ; Tue, 20 Jun 2017 15:47:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=926; t=1497998853; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=EwXCZsmt2rySdMS4Tz66qcJdgyY=; b=k7+t5iohodKK0rT3qB5H9nFUANJLzPwTbcKloYVCg6oricxAw2TGpIDhsaHbP9 tsxqH5Ycv7J2dHA0Rl/Hjfl13szo4mJQIkZoygr0l2kTSEy/NAw1orJA8RjoZCLV PC977AoL4CiDYPhmzAt7OVURX5tejmeOHJsnTgsDiaWhg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 18:47:33 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2357732489.1.1944; Tue, 20 Jun 2017 18:47:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=926; t=1497998649; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=zLE5K1+ ch8niuPcKTelpaYmKODjHDuHmI487OXdtbJU=; b=KV/yRCCq1+L9Sge3OWXfOUo i8h21drO9J+BEwkSm/wMmVQSJ00TgfehGlWYXH5ZlCVMC3rKvYpE9VxsILJUYR4b xriXmVsuJ7X+VQ9QV7JJhfiOWy/PkHwgtxg79mcaz1zAue/m6ps6ECMxHScGtPs7 WxgaYBROXjCwtKqXyQwk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 18:44:09 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2900287345.9.622460; Tue, 20 Jun 2017 18:44:08 -0400 Message-ID: <5949A603.5080408@isdg.net> Date: Tue, 20 Jun 2017 18:47:31 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <1642300.47WuTbIWPP@kitterma-e6430> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 22:47:45 -0000 On 6/20/2017 3:00 PM, Kurt Andersen wrote: > > I'm in favor of moving strongly and clearly to kill sha1, but what > about moving it out to the registry with a dated "MUST NOT". That > provides for a deprecation period without the need for further > intervention. The other advantage is that it provides a stronger > historical record that people can point to when explaining > brain-deadness to people who have not updated :-) > I would suggest a "drop dead" date of something like mid-2018 to allow > the rest of this work to reach completion. > -1. I'm not going to stop supporting SHA1 and invaliding signatures based on a drop dead date. I would prefer a "hint" from the already existing overhead DNS lookups being down, i.e. either the key lookup or author domain policy. If the "Author Domain" says "we only do SHA256, then that should allow for a supportive verifier to act accordingly. -- HLS From nobody Tue Jun 20 15:50:34 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751211293EC for ; Tue, 20 Jun 2017 15:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=isdg.net header.b=VjvIC/vE; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=njc9wC7o 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 M5v_dWDrmafO for ; Tue, 20 Jun 2017 15:50:30 -0700 (PDT) Received: from listserv.winserver.com (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 47EBD126C0F for ; Tue, 20 Jun 2017 15:50:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3939; t=1497999023; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=hLIQO7VPbF1W4qrdKhTtRJ+YRGs=; b=VjvIC/vETowgYPwiLyUqlaC2kpfZKWYuxP46+BQIye8MTbBmwudegk+LRDQK0Z 140NOPFYzAn+MNwri5wLt1CZ9bqGZE/qkrqEWTeM75SY4N0nULcyyUq3us9PwZ5F /2FNEFwClJjLUuTMAoOJWHPZArq6pAdPjHMNCBiC6q8mI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 18:50:23 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2357902577.1.2296; Tue, 20 Jun 2017 18:50:22 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3939; t=1497998817; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9bsxAP5 qV/IgCDxY5Yx4fqcqQcsM6i1V6wZXy8/BoFA=; b=njc9wC7oM1+rPetrvFXDXrr A1TVDqX5P4giG+aW2BQD+dRjIvuZWmuGqPnUbSnDTsvpQNLMJboQF3MO6KRNC4Gu +5rTOHpE37Gc/A9igFFUi7ejevWVc6aS4rX1VmkLyv09VwgAkr+4GgMegtXjHape EsKdnm5bnqq4SJdF6LSc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 18:46:57 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2900455283.9.622560; Tue, 20 Jun 2017 18:46:56 -0400 Message-ID: <5949A6AB.9020402@isdg.net> Date: Tue, 20 Jun 2017 18:50:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dcrup@ietf.org" References: <1642300.47WuTbIWPP@kitterma-e6430> In-Reply-To: <1642300.47WuTbIWPP@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 22:50:33 -0000 I would prefer if a "Author Domain Policy" said what is supported. We can add that hint to the DKIM or DMARC lookup that is already being done. We should leverage that overhead lookup. I don't see stopping supporting SHA1 (pulling existing code). -- HLS On 6/20/2017 11:39 AM, Scott Kitterman wrote: > I think we still have some different opinions on what to do with rsa-sha1, so > I thought I'd attempt to summarize the different options (as best I can, I > have an opinion, so I'm sure my bias will leak in) in the hopes it will help > drive this part of the WG discussion to closure. Note: I'm not talking about > RSA key sizes because it seems to me we're largely converged on that topic. > > I think there are roughly three options that have been discussed: > > Status quo: > >> Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST >> implement both rsa-sha1 and rsa-sha256. > > Deprecate rsa-sha1: > >> Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST >> implement both rsa-sha1 and rsa-sha256. > > Remove rsa-sha1: > >> Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST >> implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. > Note: This option also removes rsa-sha1 from the ABNF. > > Pro/Con for each: > > Status quo: > There is no immediate known security threat to rsa-sha1 that would indicate > its imminent demise as a useful algorithm in this application and rsa-sha1 > signatures are still in significant use. RSA key sizes are the current > security issue and that can be fixed without doing anything about rsa-sha1. > > There are a number of known shortcomings with rsa-sha1 and given that rsa- > sha256 is available and does not share the same issues, raising the bar to > require rsa-sha256 is easy and a prudent step to take in advance of issues > being published. Let's not wait until we have to panic. > > Retaining rsa-sha1 means DKIM implementers will have to deal with three > algorithms rather than two and this raises implementation complexity and the > risk of things going wrong. > > > Deprecate rsa-sha1: > There is no immediate known security threat to rsa-sha1 that would indicate > its imminent demise as a useful algorithm in this application and rsa-sha1 > signatures are still in significant use. RSA key sizes are the current > security issue and that can be fixed without doing anything about rsa-sha1, > but if we move to a more aggressive stance against rsa-sha1 now, it should be > easier to remove it when needed. > > There are a number of known shortcomings with rsa-sha1 and given that rsa- > sha256 is available and does not share the same issues, raising the bar to > require rsa-sha256 is easy and a prudent step to take in advance of issues > being published. Let's not wait until we have to panic. > > Retaining rsa-sha1 means DKIM implementers will have to deal with three > algorithms rather than two and this raises implementation complexity and the > risk of things going wrong. > > Remove rsa-sha1: > This option eliminates (to the extent it is adopted) the potential of security > risks with rsa-sha1. If a relevant issue with rsa-sha1 is made public, there > will be no further standards work that needs to be done. This option also > keeps the number of algorithms at two, eliminating the additional complexity > associated with having more algorithms to sort through in implementation. > While this might be considered somewhat abrupt, rsa-sha1 signing has been > effectively SHOULD NOT for a decade. Maybe this will create some momentum for > operators to move off of it. > > It is abrupt to remove something without a formal deprecation period. > > Thoughts? > > Scott K > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > From nobody Tue Jun 20 15:58:27 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADDF1200C1 for ; Tue, 20 Jun 2017 15:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=kitterman.com 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 wkwKrI3kLhm9 for ; Tue, 20 Jun 2017 15:58:16 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05941294FF for ; Tue, 20 Jun 2017 15:58:15 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 07D6EC40021 for ; Tue, 20 Jun 2017 17:58:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1497999494; bh=Q6EJUmtg1+33T0vw/YW+A9VD7J4j58NYGks3wOI+Sb8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AoJvmvRIBdrzgtK5cTFvjA60BOw6nUBJna3ctIv77Wg10kEJ33dnLkU7t/yFhDzTo Em9NV+NSmF1BXIiOZrsenuu5UfhvYfKNJGw468+TZCTfkjq+IF+tz+WrDv1yGhlgZ1 ZS2ijX+BDraj/FW8aQS6ZeXfhiRCJ31iyGZVgmZk= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 20 Jun 2017 18:58:13 -0400 Message-ID: <136195841.6zUymZVACD@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5949A6AB.9020402@isdg.net> References: <1642300.47WuTbIWPP@kitterma-e6430> <5949A6AB.9020402@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 22:58:18 -0000 You are describing the existing optional h= tag for DKIM records. Nothing new is needed to specify the acceptable algorithm for the key. Since there are no Internet police, no one will make you delete your rsa-sha1 code no matter what we write here. Scott K On Tuesday, June 20, 2017 06:50:19 PM Hector Santos wrote: > I would prefer if a "Author Domain Policy" said what is supported. We > can add that hint to the DKIM or DMARC lookup that is already being > done. We should leverage that overhead lookup. I don't see stopping > supporting SHA1 (pulling existing code). > > > I think we still have some different opinions on what to do with rsa-sha1, > > so I thought I'd attempt to summarize the different options (as best I > > can, I have an opinion, so I'm sure my bias will leak in) in the hopes it > > will help drive this part of the WG discussion to closure. Note: I'm not > > talking about RSA key sizes because it seems to me we're largely > > converged on that topic. > > > > I think there are roughly three options that have been discussed: > > > > Status quo: > >> Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST > >> implement both rsa-sha1 and rsa-sha256. > > > > Deprecate rsa-sha1: > >> Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST > >> implement both rsa-sha1 and rsa-sha256. > > > > Remove rsa-sha1: > >> Signers MUST implement and sign using rsa-sha256 only. Verifiers MUST > >> implement rsa-sha256. rsa-sha1 is obsolete and MUST not be used. > > > > Note: This option also removes rsa-sha1 from the ABNF. > > > > Pro/Con for each: > > > > Status quo: > > There is no immediate known security threat to rsa-sha1 that would > > indicate > > its imminent demise as a useful algorithm in this application and rsa-sha1 > > signatures are still in significant use. RSA key sizes are the current > > security issue and that can be fixed without doing anything about > > rsa-sha1. > > > > There are a number of known shortcomings with rsa-sha1 and given that rsa- > > sha256 is available and does not share the same issues, raising the bar to > > require rsa-sha256 is easy and a prudent step to take in advance of issues > > being published. Let's not wait until we have to panic. > > > > Retaining rsa-sha1 means DKIM implementers will have to deal with three > > algorithms rather than two and this raises implementation complexity and > > the risk of things going wrong. > > > > > > Deprecate rsa-sha1: > > There is no immediate known security threat to rsa-sha1 that would > > indicate > > its imminent demise as a useful algorithm in this application and rsa-sha1 > > signatures are still in significant use. RSA key sizes are the current > > security issue and that can be fixed without doing anything about > > rsa-sha1, > > but if we move to a more aggressive stance against rsa-sha1 now, it should > > be easier to remove it when needed. > > > > There are a number of known shortcomings with rsa-sha1 and given that rsa- > > sha256 is available and does not share the same issues, raising the bar to > > require rsa-sha256 is easy and a prudent step to take in advance of issues > > being published. Let's not wait until we have to panic. > > > > Retaining rsa-sha1 means DKIM implementers will have to deal with three > > algorithms rather than two and this raises implementation complexity and > > the risk of things going wrong. > > > > Remove rsa-sha1: > > This option eliminates (to the extent it is adopted) the potential of > > security risks with rsa-sha1. If a relevant issue with rsa-sha1 is made > > public, there will be no further standards work that needs to be done. > > This option also keeps the number of algorithms at two, eliminating the > > additional complexity associated with having more algorithms to sort > > through in implementation. While this might be considered somewhat > > abrupt, rsa-sha1 signing has been effectively SHOULD NOT for a decade. > > Maybe this will create some momentum for operators to move off of it. > > > > It is abrupt to remove something without a formal deprecation period. > > > > Thoughts? > > > > Scott K > > > > > > _______________________________________________ > > Dcrup mailing list > > Dcrup@ietf.org > > https://www.ietf.org/mailman/listinfo/dcrup > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Tue Jun 20 16:07:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5AB1294E2 for ; Tue, 20 Jun 2017 16:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 CpZCTnAWVreb for ; Tue, 20 Jun 2017 16:07:04 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705641294C8 for ; Tue, 20 Jun 2017 16:07:04 -0700 (PDT) Received: (qmail 80884 invoked from network); 20 Jun 2017 23:07:03 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2017 23:07:03 -0000 Date: 20 Jun 2017 23:06:41 -0000 Message-ID: <20170620230641.18814.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: kurta@drkurt.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 23:07:06 -0000 In article you write: >I'm in favor of moving strongly and clearly to kill sha1, but what about >moving it out to the registry with a dated "MUST NOT". Back in 2007 RFC 4871 said "In general, sha256 should always be used whenever possible." I think people have had enough warning, and if we want to kill it, we should just kill it. >The other >advantage is that it provides a stronger historical record that people can >point to when explaining brain-deadness to people who have not updated :-) Having known too many of those people, a document that says anything less than "do not use SHA-1 for any reason, ever" will be interpreted as see, we don't have to change. R's, John From nobody Tue Jun 20 16:14:14 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBA1129329 for ; Tue, 20 Jun 2017 16:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=isdg.net header.b=S/A/Ui4j; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=v1IhE+nc 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 JGRKOFmb2Km2 for ; Tue, 20 Jun 2017 16:14:10 -0700 (PDT) Received: from listserv.winserver.com (catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69C12783A for ; Tue, 20 Jun 2017 16:14:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2222; t=1498000443; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=yk4/UDCY2vojyuLTm5AEwliqhhE=; b=S/A/Ui4jQiu0UtQmmwEbSwobUZfLKBtbNcH32ek3DkmS2p6icMApk7rzk4dPwJ xQD6ikq7FxVbPl1rf0mElZGwxeNXSjc6OhY0SVzaB/IQu1bqSnifakmZdEajuMSU sy1lXYGAjU4vr2uytBWvsRZkVdc9a4dip5MZjdDmr43Bk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 19:14:03 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2359322779.1.6020; Tue, 20 Jun 2017 19:14:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2222; t=1498000237; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+3SrYNZ H6GMJR7Fg/VwRkoMIVqlen+7l4NQbAdjBVeQ=; b=v1IhE+ncRtfYSyAoVDuOVRq TmFlpIiq2ZxrsBUr8E0B4Wjg/ciIyOwj9GLl5ZErdae/A0nVFUtPQ6SctebploMT vlD4/Voz/MQSz1N0wM3jKjiv2WZ3A5H+zA9b9n82X+X48xYk2Uh0zasxz+qqOSYK eL7DStq2l0mRPQp+4m5A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 19:10:37 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2901875704.9.622148; Tue, 20 Jun 2017 19:10:37 -0400 Message-ID: <5949AC38.4000700@isdg.net> Date: Tue, 20 Jun 2017 19:14:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <1642300.47WuTbIWPP@kitterma-e6430> <5949A6AB.9020402@isdg.net> <136195841.6zUymZVACD@kitterma-e6430> In-Reply-To: <136195841.6zUymZVACD@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 23:14:12 -0000 On 6/20/2017 6:58 PM, Scott Kitterman wrote: > You are describing the existing optional h= tag for DKIM records. Nothing new > is needed to specify the acceptable algorithm for the key. > > Since there are no Internet police, no one will make you delete your rsa-sha1 > code no matter what we write here. Understood, but it shouldn't be expected signer/verifiers would just "turn it off" either in established and legacy setups, small to larger. It would be helpful, if an automated protocol logic hint was provided. I've been out of the loop for this DCRUP (and ARC), but has "h=" update proposal been made? It currently says: h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Unrecognized algorithms MUST be ignored. Refer to Section 3.3 for a discussion of the hash algorithms implemented by Signers and Verifiers. The set of algorithms listed in this tag in each record is an operational choice made by the Signer. ABNF: key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg *( [FWS] ":" [FWS] key-h-tag-alg ) key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg x-key-h-tag-alg = hyphenated-word ; for future extension Maybe the "extension" can be used to automate protocol? Section 3.3 says: 3.3. Signing and Verification Algorithms DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. Signers MUST implement and SHOULD sign using rsa-sha256. Verifiers MUST implement both rsa-sha1 and rsa-sha256. INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some senders might prefer to use rsa-sha1 when balancing security strength against performance, complexity, or other needs. In general, however, rsa-sha256 should always be used whenever possible. and I think it will apply to the shift to stronger (& more overhead) hashes. I just don't want to invalid a perfectly good SHA1 hash UNLESS the author says so. What is the SHA1 considered "bad?" or "hacked?" What if its a trusted Domain? Does it apply, with SHA1 at a minimum? -- HLS From nobody Tue Jun 20 16:20:19 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9129A1293F2 for ; Tue, 20 Jun 2017 16:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=isdg.net header.b=Uid0S6az; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=GrJ90YqL 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 JAr_xzbPXhZD for ; Tue, 20 Jun 2017 16:20:16 -0700 (PDT) Received: from listserv.winserver.com (catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id B0A391200CF for ; Tue, 20 Jun 2017 16:20:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=713; t=1498000804; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=PuyH4FK0mPXuRqmWjGfGfpx0uk8=; b=Uid0S6azifFllIrQhQVMN7HgGIrSkyCD5olvguKzZO6RUsALcnaU8Dz1YqWVv/ gcJFAGKJI+vAzN/xtA32vysa2yLhGPP7JaDoIpZap3krawHraMmpcwhwe8ejdaKy FjeNfGbKkRkO6jI9rE+Y6hoLKfe3b1/1GeDwghokEXFkg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 19:20:04 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2359682782.1.3708; Tue, 20 Jun 2017 19:20:03 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=713; t=1498000597; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=N64Ua2j zRLdZYxTz84mcaTyQ8TL3EBgarJXPeFALDAw=; b=GrJ90YqLpydM9BcguB9NnQV YnWaXlHf5OnWkDW1FnER4fBWhjGVuPiu1S9WTinPUoXk7cCwGu1iCSlGOO+7a3/n XrJLjNdM2IED6P1Z1iTkFWwwgSQb5pxCVnR9J6yTALdovzQJI6L585kipSUPw+M5 F/6sADFJ6kCnlDnn8ir4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 19:16:37 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2902235923.9.622312; Tue, 20 Jun 2017 19:16:37 -0400 Message-ID: <5949ADA0.3050702@isdg.net> Date: Tue, 20 Jun 2017 19:20:00 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <20170620230641.18814.qmail@ary.lan> In-Reply-To: <20170620230641.18814.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 23:20:17 -0000 On 6/20/2017 7:06 PM, John Levine wrote: > In article you write: >> I'm in favor of moving strongly and clearly to kill sha1, but what about >> moving it out to the registry with a dated "MUST NOT". > > Back in 2007 RFC 4871 said "In general, sha256 should always be used > whenever possible." I think people have had enough warning, and if we > want to kill it, we should just kill it. Unless whitelisted, this will create invalid SHA1 signatures from perfectly good domains. New systems who initially avoid SHA1 legacy support will quickly learn not all systems use SHA256. i.e a quick support problem. No thanks. -- HLS From nobody Tue Jun 20 16:39:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2B0129471 for ; Tue, 20 Jun 2017 16:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com 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 g4q3RGV3PnD5 for ; Tue, 20 Jun 2017 16:38:58 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9AC127869 for ; Tue, 20 Jun 2017 16:38:57 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d14so70160857qkb.1 for ; Tue, 20 Jun 2017 16:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=PPiH7EdZNCvufvmwAeqUnxdK7K6l9a/S3fHcGcBDaMo=; b=R8orbkS2rp4ku3653tpv3CX60Hd+TnJWNZ6WatUnyN+EQFaJkK8MZKu/I75JDjToNo gL6zDkWKfBhEdFFRhNS5lTU7yA4oFYH1TL5OyHAANQcfeple/H9/PDCttfm8p7/S5ELx h2RBWoIG4riNwMXJ5OANjKouXTgSOBCcEMlsoBGqdbXIFiUuqCuOAVHHXE9RIX4dA58t N4AhizLhlzuZx99KBm4gQVgnil8JIg6v6JsWdzINP+2W6l04ow3+1ceXZpDRiI/q/SAg F07WDdQ+z6otTBgeb9rcpKz2C0JCCwI1yswPUvAVd15Ku4GWmBQ44Jrm8zYZHY2z2z7m /dIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=PPiH7EdZNCvufvmwAeqUnxdK7K6l9a/S3fHcGcBDaMo=; b=LJIfa0IEUrbfKXN1ZKm2845hxWPxxqSBBdLX+SnLHJgUSqnxJO8xyPxAYtEUN4ZzbS K0pUlaUcvXj6LegDpWY0I3YfWrYLJNHFk21eq4r61CedoDihfvj6faLHAN7lfnJBvTJl vViBk8re38F+c0BXnPw3ows9iTG+9POM+BsqIPFcL0drqluory8Jkmma6z/OzZB6aHTU a6yG3DjFIp/xirJp6PxpRNfH56N7qYXGdIIGgJMOEmSNEhULpsKs1orJIyOqWoHBrYyM EZJNInHdKNQ/gMBCOZ4euD7Or1BgOyVWGRbdPxuuoYfGHaWjn+HXywAE0MHgr4DV3kZ+ YbDg== X-Gm-Message-State: AKS2vOxcPr/8fCxCnA7KE89ByqlxBnn2iw22uTQXiq4vV0jUwfLwSr3D pkEkkJ71oQN2pcjw9AEL2MKDXpgFE41U3jM= X-Received: by 10.55.44.129 with SMTP id s123mr34968427qkh.137.1498001936848; Tue, 20 Jun 2017 16:38:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.43.27 with HTTP; Tue, 20 Jun 2017 16:38:36 -0700 (PDT) In-Reply-To: <5949ADA0.3050702@isdg.net> References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> From: Seth Blank Date: Tue, 20 Jun 2017 16:38:36 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114f444051b9dd05526cc19a" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 23:39:01 -0000 --001a114f444051b9dd05526cc19a Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos wrote: > Back in 2007 RFC 4871 said "In general, sha256 should always be used >> whenever possible." I think people have had enough warning, and if we >> want to kill it, we should just kill it. >> > > Unless whitelisted, this will create invalid SHA1 signatures from > perfectly good domains. New systems who initially avoid SHA1 legacy > support will quickly learn not all systems use SHA256. i.e a quick support > problem. > To me, this is exactly the point. People have had ten years to switch to SHA-256. At this point, people will only move if the threat of breakage is upon them. And this isn't breakage, this is a document that says using SHA-1 is no longer acceptable, and you MUST use SHA-256. If it's the right security recommendation, we should say it explicitly. --001a114f444051b9dd05526cc19a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 20, 2017 at 4:20 PM, Hector Santos <hsantos@isdg.net>= wrote:
Back in 2007 RFC 4871 said "In general, sha256 should a= lways be used
whenever possible."=C2=A0 I think people have had enough warning, and = if we
want to kill it, we should just kill it.

 Unless whitelisted, this will create invalid SHA1 signatures from perfectly= good domains.=C2=A0 New systems who initially avoid SHA1 legacy support wi= ll quickly learn not all systems use SHA256. i.e a quick support problem.

To me, this is exactly the point. People= have had ten years to switch to SHA-256. At this point, people will only m= ove if the threat of breakage is upon them. And this isn't breakage, th= is is a document that says using SHA-1 is no longer acceptable, and you MUS= T use SHA-256. If it's the right security recommendation, we should say= it explicitly.
=C2=A0
--001a114f444051b9dd05526cc19a-- From nobody Tue Jun 20 16:50:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2BB1294FA for ; Tue, 20 Jun 2017 16:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=V2TB3PSg; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Z31adx2y 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 ZLEs51T-kF1F for ; Tue, 20 Jun 2017 16:50:03 -0700 (PDT) Received: from winserver.com (unknown [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 068A81293DF for ; Tue, 20 Jun 2017 16:50:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1628; t=1498002594; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=awDhb0hYSzVE+UytJ688DNpmHrI=; b=V2TB3PSgwjNZDu4h8cM9C3pXioerCHpYfSGHJ+ObTTiCW/zjKO3uhST2HHFUYL U37bXmwSEzZSYseJJeMVz/m3H+m/Tn5uXKbb6ES6JNWfB31ClkhRivI3CV9G9Sq0 NV2izuRLJk4bpI2TxVVTnnWDNM3zAz+0+7D08OtePvouU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 19:49:54 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2361472925.1.3376; Tue, 20 Jun 2017 19:49:53 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1628; t=1498002387; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5YBt6v4 qHgqWcHlQS8Wmd0bk+b/tztnkqqjOfM8xUVA=; b=Z31adx2y217xy/pHGo+PEdi VyZDDeip7ricTmE56yQnLBAe8HU/A44ZS0sfmsPBpHStl1GKdvAOjCBfxmJDms/D xCpnitgUjSHQsD7N/lnKr2hIyB34BFwTQ2/+gdlLAjWZnuRB1REW6ZcHzNe5y4a2 5CjrKnsMJMFvsSD6CjC4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 19:46:27 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2904025079.9.622376; Tue, 20 Jun 2017 19:46:26 -0400 Message-ID: <5949B49D.3010400@isdg.net> Date: Tue, 20 Jun 2017 19:49:49 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 23:50:05 -0000 On 6/20/2017 7:38 PM, Seth Blank wrote: > On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos > wrote: > > Back in 2007 RFC 4871 said "In general, sha256 should always > be used > whenever possible." I think people have had enough warning, > and if we > want to kill it, we should just kill it. > > > Unless whitelisted, this will create invalid SHA1 signatures from > perfectly good domains. New systems who initially avoid SHA1 > legacy support will quickly learn not all systems use SHA256. i.e > a quick support problem. > > > To me, this is exactly the point. People have had ten years to switch > to SHA-256. At this point, people will only move if the threat of > breakage is upon them. And this isn't breakage, this is a document > that says using SHA-1 is no longer acceptable, and you MUST use > SHA-256. If it's the right security recommendation, we should say it > explicitly. My point is the protocol/document should also discuss how to deal with SHA1 legacy operations when dealing with a migration design issue, not ignore its existence, i.e. kill it, wipe it out, remove it from discussion. New verifiers following such advice may quickly see a problem when they see SHA1. Should the document suggest to invalidate them? Can a key lookup or DMARC lookup enforce this? (Preferred) If SHA1 can be exploited for a domain, then the domain should be able to provide a hint to the verifier about its validity. Or should a verifier just completely ignore it, therefore inherently invalidating the signature for lack of SHA1 support? -- HLS From nobody Tue Jun 20 16:54:04 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990D212952E for ; Tue, 20 Jun 2017 16:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 zhpv_ZGbFX8R for ; Tue, 20 Jun 2017 16:54:00 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 CB9CA129521 for ; Tue, 20 Jun 2017 16:54:00 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:fd7a:2368:ef63:6afe]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5KNrx1v031368 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 20 Jun 2017 16:54:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1498002840; bh=CrhQ8nvWXFJlWOkVdyQRH47da3WdOcTydg8o9C17ero=; h=Subject:To:References:From:Date:In-Reply-To; b=T7pv/HaEkIn+YybBgtzHDcEv5sapUwCNTAcgNIJvdqFAP4GgeEowwkkixLHweyeJx 0ksDWjPar1WNB43Rj4WQ6H1ipVs0R2VuJqCIrg1RD6WtZMCcBB1Y8Qep6ghuvWdmnz 9311D7TkJOwPUo0zHZKtqm8525docbIUXBTAR9dA= To: dcrup@ietf.org References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> From: Jim Fenton Message-ID: <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> Date: Tue, 20 Jun 2017 16:53:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B27AC2CF688DA28BACD1DCF5" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 23:54:03 -0000 This is a multi-part message in MIME format. --------------B27AC2CF688DA28BACD1DCF5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/20/17 4:38 PM, Seth Blank wrote: > On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos > wrote: > > Back in 2007 RFC 4871 said "In general, sha256 should always > be used > whenever possible." I think people have had enough warning, > and if we > want to kill it, we should just kill it. > > > Unless whitelisted, this will create invalid SHA1 signatures from > perfectly good domains. New systems who initially avoid SHA1 > legacy support will quickly learn not all systems use SHA256. i.e > a quick support problem. > > > To me, this is exactly the point. People have had ten years to switch > to SHA-256. At this point, people will only move if the threat of > breakage is upon them. And this isn't breakage, this is a document > that says using SHA-1 is no longer acceptable, and you MUST use > SHA-256. If it's the right security recommendation, we should say it > explicitly. The verb "use" isn't precise enough because it doesn't specify whether it refers to signing or verifying. I agree that the document should say that signers MUST NOT sign using SHA-1. Even though SHA-1 hasn't been broken seriously enough to be exploitable in this application, it's good for us to be out in front of that. Several people have said that it doesn't matter whether we say MUST NOT verify rsa-sha1 or SHOULD NOT verify rsa-sha1. That may very well be true, but we shouldn't be in the habit of saying MUST NOT for something that is actively being used and is not currently exploitable. We should be paying at least lip service to interoperability by saying MUST NOT sign prior to saying MUST NOT verify. Any signers that are concerned about downgrade attacks (bad actors creating valid rsa-sha1 signatures somehow, despite the domain using rsa-sha256) should put h=3Dsha256 in their key records to close that possibility. -Jim --------------B27AC2CF688DA28BACD1DCF5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 6/20/17 4:38 PM, Seth Blank wrote:
On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos <hsantos@isdg.net> wrote:
Back in 2007 RFC 4871 said "In general, sha256 should always be used
whenever possible."  I think people have had enough warning, and if we
want to kill it, we should just kill it.

 Unless whitelisted, this will create invalid SHA1 signatures from perfectly good domains.  New systems who initially avoid SHA1 legacy support will quickly learn not all systems use SHA256. i.e a quick support problem.

To me, this is exactly the point. People have had ten years to switch to SHA-256. At this point, people will only move if the threat of breakage is upon them. And this isn't breakage, this is a document that says using SHA-1 is no longer acceptable, and you MUST use SHA-256. If it's the right security recommendation, we should say it explicitly.
The verb "use" isn't precise enough because it doesn't specify whether it refers to signing or verifying.

I agree that the document should say that signers MUST NOT sign using SHA-1. Even though SHA-1 hasn't been broken seriously enough to be exploitable in this application, it's good for us to be out in front of that.

Several people have said that it doesn't matter whether we say MUST NOT verify rsa-sha1 or SHOULD NOT verify rsa-sha1. That may very well be true, but we shouldn't be in the habit of saying MUST NOT for something that is actively being used and is not currently exploitable. We should be paying at least lip service to interoperability by saying MUST NOT sign prior to saying MUST NOT verify.

Any signers that are concerned about downgrade attacks (bad actors creating valid rsa-sha1 signatures somehow, despite the domain using rsa-sha256) should put h=sha256 in their key records to close that possibility.

-Jim
--------------B27AC2CF688DA28BACD1DCF5-- From nobody Tue Jun 20 17:11:34 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5579112956B for ; Tue, 20 Jun 2017 17:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 sOexZwvdKk1c for ; Tue, 20 Jun 2017 17:11:30 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 724BF1289B5 for ; Tue, 20 Jun 2017 17:11:30 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 24174C400E6 for ; Tue, 20 Jun 2017 19:11:29 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1498003889; bh=E1qT1FRcFvSkOR3ZwflzYZClB96J9yrCv76laPn3nAk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TvqYpriH0FfC6SHR1vhOKVWAAWZGJDs5XYrT3yq0NblIcDfMsplO7M5DEEQYdJGTy rQgWhvnhjvNUbsmxdrBo5cMPaPfuGZjJFw+jyQV43RA+Yn4MtulZjocg7Gk0hh7jug 2BOMB3XyAHXLp94UD2q71zvH6419ZYQL5+Eyrnko= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 20 Jun 2017 20:11:28 -0400 Message-ID: <9555495.sOxsJ65lRg@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <5949B49D.3010400@isdg.net> References: <20170620230641.18814.qmail@ary.lan> <5949B49D.3010400@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 00:11:32 -0000 On Tuesday, June 20, 2017 07:49:49 PM Hector Santos wrote: > On 6/20/2017 7:38 PM, Seth Blank wrote: > > On Tue, Jun 20, 2017 at 4:20 PM, Hector Santos > > > > wrote: > > Back in 2007 RFC 4871 said "In general, sha256 should always > > be used > > whenever possible." I think people have had enough warning, > > and if we > > want to kill it, we should just kill it. > > > > Unless whitelisted, this will create invalid SHA1 signatures from > > perfectly good domains. New systems who initially avoid SHA1 > > legacy support will quickly learn not all systems use SHA256. i.e > > a quick support problem. > > > > To me, this is exactly the point. People have had ten years to switch > > to SHA-256. At this point, people will only move if the threat of > > breakage is upon them. And this isn't breakage, this is a document > > that says using SHA-1 is no longer acceptable, and you MUST use > > SHA-256. If it's the right security recommendation, we should say it > > explicitly. > > My point is the protocol/document should also discuss how to deal with > SHA1 legacy operations when dealing with a migration design issue, not > ignore its existence, i.e. kill it, wipe it out, remove it from > discussion. New verifiers following such advice may quickly see a > problem when they see SHA1. Should the document suggest to > invalidate them? Can a key lookup or DMARC lookup enforce this? > (Preferred) If SHA1 can be exploited for a domain, then the domain > should be able to provide a hint to the verifier about its validity. > Or should a verifier just completely ignore it, therefore inherently > invalidating the signature for lack of SHA1 support? I think it would be useful for DMARC feedback reporting to be extended to include the signing algorithm used, but that's off topic for this working group. Scott K From nobody Tue Jun 20 17:25:10 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503F3129490 for ; Tue, 20 Jun 2017 17:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Os8M7MDl; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=T4q+r+9x 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 gCqWqaftcHM9 for ; Tue, 20 Jun 2017 17:25:05 -0700 (PDT) Received: from winserver.com (unknown [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4CD12AF6E for ; Tue, 20 Jun 2017 17:25:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1427; t=1498004699; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=0HUWAprFFVMbrZzURWmf/ExMiQM=; b=Os8M7MDl4O0m1LamPkLwKra9+MxhEaRZuzyThBgd/2DHfi1l6PsoVMaQ2VCQU0 HQQdHMjEw4HaxmcILjQlbLO2lrLoRG9sDXvupROM5WRCYOWQ7J9M0U2D/VByU7Rc TahRn3+zHre1rr+Qfu4oZqHqP5VMMHH81wvybrp5rdyLE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 20:24:59 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2363578018.1.5612; Tue, 20 Jun 2017 20:24:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1427; t=1498004493; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XMztUXn +VBlOgPVTgC8n3VhIH4K/t4ezBLg0Kj6vG68=; b=T4q+r+9xxuX6uk+E8Sh8c/c kUZhGQzsa9rgQQNa8bk5QSMzjX+R03INSpVui+jFdJ9xyI6qFwG5GprxAQPnEkKh Li5w96gV97a2XJv8Kgj540qyXPp1+ftOyEaTH1UshgD9oqd/idqXFt3dEeyn4CR6 o69TPkU5UxilUFLd4Mv4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 20:21:33 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2906130939.9.622420; Tue, 20 Jun 2017 20:21:32 -0400 Message-ID: <5949BCD7.4030207@isdg.net> Date: Tue, 20 Jun 2017 20:24:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> In-Reply-To: <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 00:25:07 -0000 On 6/20/2017 7:53 PM, Jim Fenton wrote: > I agree that the document should say that signers MUST NOT sign using > SHA-1. Even though SHA-1 hasn't been broken seriously enough to be > exploitable in this application, it's good for us to be out in front > of that. > > Several people have said that it doesn't matter whether we say MUST > NOT verify rsa-sha1 or SHOULD NOT verify rsa-sha1. That may very well > be true, but we shouldn't be in the habit of saying MUST NOT for > something that is actively being used and is not currently > exploitable. We should be paying at least lip service to > interoperability by saying MUST NOT sign prior to saying MUST NOT verify. > > Any signers that are concerned about downgrade attacks (bad actors > creating valid rsa-sha1 signatures somehow, despite the domain using > rsa-sha256) should put h=sha256 in their key records to close that > possibility. +1. If the document were to suggest "Keep in mind, future Verifiers MAY NOT support SHA1" then this may enough of an incentive for new and old signers to begin avoiding SHA1, even for the smallest of DKIM applications. The "higher coverage" verifier will most likely keep SHA1 simply to avoid any future support issues. Therefore, it would really help via policy to give the verifier what is to be expected. The key "h=" protocol information should be updated to help in this area. -- HLS From nobody Tue Jun 20 17:40:56 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5727D12948A for ; Tue, 20 Jun 2017 17:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 FBGVglS2zwJ8 for ; Tue, 20 Jun 2017 17:40:45 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 F13DC131653 for ; Tue, 20 Jun 2017 17:40:44 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5L0bled009403; Wed, 21 Jun 2017 01:40:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=OtaU/T92T4t3EtVTNLqtwfHao7UQc96j32OEuUMBUVk=; b=IRjKZqcjFbe4J21wou87DvYLEnah7kd7PiDZlGJCqlg7nX59lO0bDB17R0hWN+DgfplK DpPA7WvqoIYGTk9jPfDLZ9Ohx9rxX0YolQLveG6JqyYsRPCqRs57SkKjRwyJ4XwbQmev X7/VCUR/cKCLAEfbqYSjgc0NaFE81BRt3taDR1u8iH70fMtuJim9yA6KukzjMGomK5/G MWPcHCPtyjmQ5Fl6U9cD5Fx692+SiSAAEZrbqGCDzUxViPyrk3/o7zp3eFk7VyIF07+/ MBNscyaQN9240OoZwpFFJXXrM5y+Nhasd5o0FdGmBrQeyI2Suo4O5PrZdexYYLY8QWGJ Qg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b6fhy29pj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 01:40:41 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5L0aW5r019576; Tue, 20 Jun 2017 20:40:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yrummwn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Jun 2017 20:40:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 20 Jun 2017 20:40:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 20 Jun 2017 20:40:35 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "kurta@drkurt.com" Thread-Topic: [Dcrup] rsa-sha1 proposals Thread-Index: AQHS6dwEx6Qzh7qeKkuelYoLg0TlfaIuXjGAgABE5oD//9bk0A== Date: Wed, 21 Jun 2017 00:40:35 +0000 Message-ID: <21ab5cf19f034d4ca13dd4cf8a45de4f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170620230641.18814.qmail@ary.lan> In-Reply-To: <20170620230641.18814.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.119.115] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210008 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210008 Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 00:40:46 -0000 > Back in 2007 RFC 4871 said "In general, sha256 should always be used > whenever possible." I think people have had enough warning, and if we > want to kill it, we should just kill it. Yes there have been enough documents, for a long enough time, that says "do= n=92t use SHA1" Yet another document saying might not change things very much. But yet ano= ther document saying "think about doing it" will change nothing. From nobody Tue Jun 20 17:43:49 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052DA129516 for ; Tue, 20 Jun 2017 17:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 sWqcBDbNxDKp for ; Tue, 20 Jun 2017 17:43:47 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C2351294E1 for ; Tue, 20 Jun 2017 17:43:47 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 10B88C400E6; Tue, 20 Jun 2017 19:43:44 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1498005824; bh=O2Yn7OpzOZX/OKemxuKemNTkpYFCjD8T+WunnNObadI=; h=Date:In-Reply-To:References:Subject:To:From:From; b=srKHS7iyrlH16x78RBhypZCOnKxgQMi2MvsAmQmGJ94ZPkG442k4z6ntL77Sm5cKR fVIcbl+CVBIb6lG8pMWb+tz2EzDYBcytSZ/M92rqVIUkeu1w2wqP7LSaHMTJ0m0aVr JNZ12xjHlYvVjz7eM15K+B33lNaS57XSjfWCO5XE= Date: Wed, 21 Jun 2017 00:43:43 +0000 In-Reply-To: <5949BCD7.4030207@isdg.net> References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> <5949BCD7.4030207@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 00:43:49 -0000 On June 20, 2017 8:24:55 PM EDT, Hector Santos wrote: > >On 6/20/2017 7:53 PM, Jim Fenton wrote: > >> I agree that the document should say that signers MUST NOT sign using >> SHA-1=2E Even though SHA-1 hasn't been broken seriously enough to be >> exploitable in this application, it's good for us to be out in front >> of that=2E >> >> Several people have said that it doesn't matter whether we say MUST >> NOT verify rsa-sha1 or SHOULD NOT verify rsa-sha1=2E That may very well >> be true, but we shouldn't be in the habit of saying MUST NOT for >> something that is actively being used and is not currently >> exploitable=2E We should be paying at least lip service to >> interoperability by saying MUST NOT sign prior to saying MUST NOT >verify=2E >> >> Any signers that are concerned about downgrade attacks (bad actors >> creating valid rsa-sha1 signatures somehow, despite the domain using >> rsa-sha256) should put h=3Dsha256 in their key records to close that >> possibility=2E > >+1=2E > >If the document were to suggest "Keep in mind, future Verifiers MAY=20 >NOT support SHA1" then this may enough of an incentive for new and=20 >old signers to begin avoiding SHA1, even for the smallest of DKIM=20 >applications=2E > >The "higher coverage" verifier will most likely keep SHA1 simply to=20 >avoid any future support issues=2E Therefore, it would really help via=20 >policy to give the verifier what is to be expected=2E The key "h=3D"=20 >protocol information should be updated to help in this area=2E I think just using the tag in key records operationally is all that's need= ed=2E Also, when it comes to migration away from rsa-sha1, it looks like you're = one of the ones with work to do: DKIM-Signature: v=3D1; d=3Disdg=2Enet; s=3Dtms1; a=3Drsa-sha1; Scott t From nobody Tue Jun 20 18:15:37 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A951242EA for ; Tue, 20 Jun 2017 18:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=iHUR2FC1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=epg2nmmt 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 1yCtqC2GGeda for ; Tue, 20 Jun 2017 18:15:31 -0700 (PDT) Received: from mail.santronics.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id A8B0A1200E5 for ; Tue, 20 Jun 2017 18:15:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1809; t=1498007729; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=bicCLLpF+j8YVqswFyWjcGIr2x8=; b=iHUR2FC18JZuUlpKRZUlxq26CzV/NAwfC058JqGsjaOoVRrfukyRVxUaD3noch R4HrdZo0fM6rHdFXKtbCmRxLI5YRmgcPU6SWOcGPmWy9oPMGmGFZgrmcknLxA4/g ktawnx6p773Wer1KoR22A9xgBkg91z5YdN0YLKxiLkV04= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 21:15:29 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2366608213.1.1724; Tue, 20 Jun 2017 21:15:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1809; t=1498007524; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DBcQIOF 0vZrScbQcD7J+39tg6PxCmtoNLmbVT7R4+M0=; b=epg2nmmty2V+QrMzm1d3djN Uqkkl6Baclh0HNvC0GiSaweDB1hInKdM0efhWtJQrHl0Y37opaaqgSzU41YF8li7 XirRpYf0fRZ7u7RWqGdJkhefbvIaXvYqU2Omj9vgGFHTz/JDKScoL3bqzPfFVh5i NvKKMcp3rvtwqko8eGXw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 20 Jun 2017 21:12:04 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 2909162345.9.622084; Tue, 20 Jun 2017 21:12:03 -0400 Message-ID: <5949C8AF.4050102@isdg.net> Date: Tue, 20 Jun 2017 21:15:27 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> <5949BCD7.4030207@isdg.net> <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> In-Reply-To: <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 01:15:36 -0000 On 6/20/2017 8:43 PM, Scott Kitterman wrote: > On June 20, 2017 8:24:55 PM EDT, Hector Santos wrote: >> >> The "higher coverage" verifier will most likely keep SHA1 simply to >> avoid any future support issues. Therefore, it would really help via >> policy to give the verifier what is to be expected. The key "h=" >> protocol information should be updated to help in this area. > > I think just using the tag in key records operationally is all that's needed. > > Also, when it comes to migration away from rsa-sha1, it looks like you're one of the ones with work to do: > > DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; > Plus any customers who decided to keep a lower overhead DKIM/SHA1 email operation running for their setup. Its just a simple switch for us, but I am thinking about the "other legacy endpoints" and the customers who may encounter new "support issues" because of an update to a version where SHA1 support may have been removed. Therefore I can't turn it off even I changed it for my own setup. But I can help with a new possible migration/enforcement option such as: [X] If Key has "h=sha256", invalidate an SHA1 signed message from the signer domain. And with a protocol change note such as: "Notes: 1) Future Verifiers MAY NOT include support SHA1. 2) If the signer domain key has "h=sha256" then any signed message not sha256 SHOULD be invalidated. it should be incentive for signers to begin avoiding sha1 and new defaults for signer setups with will be SHA256. But I think it is important for such language as #2 because this is both a security and a migration problem. If we are here to seek a change, then signers needs a quick way to tell verifiers to discard/invalidate SHA1 signatures. -- HLS From nobody Wed Jun 21 09:33:28 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7180F12EBD3 for ; Wed, 21 Jun 2017 09:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JIMjgu1l1wmJ for ; Wed, 21 Jun 2017 09:33:25 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0920B12EBA8 for ; Wed, 21 Jun 2017 09:33:24 -0700 (PDT) Received: (qmail 31085 invoked from network); 21 Jun 2017 16:33:24 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Jun 2017 16:33:24 -0000 Date: 21 Jun 2017 16:33:02 -0000 Message-ID: <20170621163302.22286.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: fenton@bluepopcorn.net In-Reply-To: <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:33:26 -0000 In article <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> you write: >The verb "use" isn't precise enough because it doesn't specify whether >it refers to signing or verifying. > >I agree that the document should say ... If you don't like what draft-ietf-dcrup-dkim-crypto-02 says, please send text. R's, John From nobody Wed Jun 21 09:35:39 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A0412717E for ; Wed, 21 Jun 2017 09:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IN8g8Qgw84Lr for ; Wed, 21 Jun 2017 09:35:34 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C9F128616 for ; Wed, 21 Jun 2017 09:35:32 -0700 (PDT) Received: (qmail 31301 invoked from network); 21 Jun 2017 16:35:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Jun 2017 16:35:31 -0000 Date: 21 Jun 2017 16:35:09 -0000 Message-ID: <20170621163509.22309.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:35:37 -0000 In article <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> you write: >>The "higher coverage" verifier will most likely keep SHA1 simply to >>avoid any future support issues. Therefore, it would really help via >>policy to give the verifier what is to be expected. The key "h=" >>protocol information should be updated to help in this area. > >I think just using the tag in key records operationally is all that's needed. I agree. That's exactly what the h= tag in the key record has always been for. R's, John From nobody Wed Jun 21 09:57:10 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEDB126DFF; Wed, 21 Jun 2017 09:57:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149806422172.15488.12775072778180430519@ietfa.amsl.com> Date: Wed, 21 Jun 2017 09:57:01 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-ecc-01.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:57:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update of the IETF. Title : Defining Elliptic Curve Cryptography Algorithms for use with DKIM Author : Scott Rose Filename : draft-ietf-dcrup-dkim-ecc-01.txt Pages : 7 Date : 2017-06-21 Abstract: DomainKeys Identified Mail (DKIM) uses digital signature to associate a message with a given sending domain. Currently, there is only one cryptography algorithm defined for use with DKIM (RSA). This document defines four new elliptic curve cryptography algorithms for use with DKIM. This will allow for algorithm agility if a weakness is found in RSA, and allows for smaller key length to provide the same digital signature strength. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-ecc-01 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-ecc-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 21 09:59:54 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA0128B38 for ; Wed, 21 Jun 2017 09:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WwvJpLdSndL1 for ; Wed, 21 Jun 2017 09:59:38 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8863B127876 for ; Wed, 21 Jun 2017 09:59:37 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 21 Jun 2017 12:59:35 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.319.2; Wed, 21 Jun 2017 12:59:34 -0400 Received: from [129.6.219.88] ([129.6.219.88]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v5LGxLVV032741 for ; Wed, 21 Jun 2017 12:59:21 -0400 From: "Rose, Scott" To: "dcrup@ietf.org" Date: Wed, 21 Jun 2017 12:59:20 -0400 Message-ID: <113ECC18-25E6-41E0-95CE-8DB965651BF8@nist.gov> In-Reply-To: <149806422188.15488.17268482858426622561.idtracker@ietfa.amsl.com> References: <149806422188.15488.17268482858426622561.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Dcrup] New Version Notification for draft-ietf-dcrup-dkim-ecc-01.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:59:47 -0000 New version to clean up the editing of the previous version. Also removed SHA-512 as a newly defined hash algorithm. This will probably be the last version unless the WG wants it. There are two drafts about adding a new ECC algorithm, which is one more than necessary. Scott On 21 Jun 2017, at 12:57, internet-drafts@ietf.org wrote: > A new version of I-D, draft-ietf-dcrup-dkim-ecc-01.txt > has been successfully submitted by Scott Rose and posted to the > IETF repository. > > Name: draft-ietf-dcrup-dkim-ecc > Revision: 01 > Title: Defining Elliptic Curve Cryptography Algorithms for use with > DKIM > Document date: 2017-06-21 > Group: dcrup > Pages: 7 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-dcrup-dkim-ecc-01.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/ > Htmlized: > https://tools.ietf.org/html/draft-ietf-dcrup-dkim-ecc-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-ecc-01 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-ecc-01 > > Abstract: > DomainKeys Identified Mail (DKIM) uses digital signature to > associate > a message with a given sending domain. Currently, there is only > one > cryptography algorithm defined for use with DKIM (RSA). This > document defines four new elliptic curve cryptography algorithms > for > use with DKIM. This will allow for algorithm agility if a weakness > is found in RSA, and allows for smaller key length to provide the > same digital signature strength. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== From nobody Thu Jun 22 16:17:20 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD22D127867 for ; Thu, 22 Jun 2017 16:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 6Y7phTB0lggR for ; Thu, 22 Jun 2017 16:17:17 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8820127369 for ; Thu, 22 Jun 2017 16:17:17 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B0B84C400E6 for ; Thu, 22 Jun 2017 18:17:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1498173434; bh=wSWF/V1ayDyR/CAL6v8GpjrJ79sx5BWyELUXPcrKaNQ=; h=From:To:Subject:Date:From; b=ZsxonbJK38HKo7tDqIEN4gsFaNxtpMcoaQoy1VlyCtyoj1VG8esPoO7dP14xepSXO aSd6YMLVr3+UBFPdZH2Q97zwzQmteOBBaCBfeqTh+z0Jv3Zhf539iAiK/6d2Lr8LTZ eWoz5ccGcXSFeEwrD6IKL7S/WzR0wnbUBCRmAoF8= From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 22 Jun 2017 19:17:13 -0400 Message-ID: <2793611.63lxTaCm4r@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 23:17:19 -0000 It seemed like the hashed RSA variant ought to be easy enough to implement, so I decided to give it a go. I almost immediately ran into a question. For terminology, I'm using what openssl says [1] I am assuming that "SHA-256 hash of the public key, stored in base64" means use the output of the digest in binary form (--binary) option and encode it in base 64. Is that correct? So if my signing key were (I know, but just to make sure I understand the tranformations): 'Hello World' Then the the p tag in DNS would be: p=pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4= Am I understanding it correctly? A python one liner: >>> base64.b64encode(hashlib.sha256(b'Hello World').digest()) 'pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=' Scott K [1] https://www.openssl.org/docs/man1.1.0/apps/sha256.html From nobody Thu Jun 22 16:45:01 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908EF129B0A for ; Thu, 22 Jun 2017 16:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 JlfJU3Jzas9h for ; Thu, 22 Jun 2017 16:44:56 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B445129BAC for ; Thu, 22 Jun 2017 16:44:55 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id y47so21738102oty.0 for ; Thu, 22 Jun 2017 16:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uDa+eO/f/Mkwq4fhzTC0jBIA1FgsZT2brBmfH0c4NhQ=; b=mxafzFuHE0yhVJhEe7oO3LImh9FQeeCru1iDa7U/bzDJ+kQ1rZM03ewqBAXugG/MNP /u0/lLw6ulyVYBjuFk6z1JjT+PpNPP1n4lIqbgiq65DuQiYKh3Mj1GofD7k1lIhsk28e OLekurOtv4ZU2GVeZeLBd4iwMgkBCINwiuazeu2Gshk4ktT+5xHkJtKdwYgP4teUCOyy Ai07g6W6H9IGxEc9mysBS6Tywo1jKrv9Vh2SweA9QuKym/nG4QKsjm0DtEV8vo1PZ0X5 o+YUbIcc7QMwcjct7Yt5UNYLNrlpf37o0qc5mwHyyJccgZEQOghRLb+iN9Db2rXdpM7K c16A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uDa+eO/f/Mkwq4fhzTC0jBIA1FgsZT2brBmfH0c4NhQ=; b=ND6uB8qY/DIDDW7pFNko9gbmhR/BhCnLiCkJy74CPnRD8HHCPRA0J1SWr/Enln35pI /Ydxl6eGcUJoFo9qqe0eIztQSyxnurqYcobIf1+sOZTLZk9QrwNxAb3QtOZRxFahnGfJ 0tJAJckdbQLV9DjwHggEA7zEd+wbQ/Hi4vlHdRPVm1kzLbO26gpAuvpMAqJvdqrWxnFm nL07tS/inJ7KLZyHhCHhidNYVytR0r4wrdc4JcI5oA2p9Rivp9xsZRqJwEkcO/i3RP8a roRG9x5P0yJKBx4L2yWZ3o+w2msGSMUNIHLG0pGXXzjcfIE0EoMzIyR9vzCmjZeeToTU ko/g== X-Gm-Message-State: AKS2vOzvI6Ov0aRu9XbMkHSBo+Q1IKEAfWBMWFOPjQWeTflxIbkMFcnq coFG1n8QiqPAPdUGmhVuKnnx0Bz75w== X-Received: by 10.157.63.139 with SMTP id r11mr2552621otc.28.1498175094699; Thu, 22 Jun 2017 16:44:54 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.206 with HTTP; Thu, 22 Jun 2017 16:44:54 -0700 (PDT) In-Reply-To: <2793611.63lxTaCm4r@kitterma-e6430> References: <2793611.63lxTaCm4r@kitterma-e6430> From: Phillip Hallam-Baker Date: Thu, 22 Jun 2017 19:44:54 -0400 X-Google-Sender-Auth: ZeZjohjwmVy_YUW1a8hQ2fcmMTw Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11c04b8054bc4005529512fa" Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 23:44:59 -0000 --001a11c04b8054bc4005529512fa Content-Type: text/plain; charset="UTF-8" I would really like to get to a point where we could use one fingerprint format everywhere. This would then allow fingerprints to be cut and pasted from one place to another. When I suggest we do something of this sort, people say 'write a draft'. Once I write a draft they say I am peddling my proposal. So pretend that I don't have a draft yet. These are the features I think are needed: 1) Use Base32 encoding. DNS labels are case insensitive. Using fingerprints in DNS labels is very powerful. It allows DANE like effects without the need for DANE records or DNSSEC. 2) Incorporate the algorithm identifier into the fingerprint, do so in a way that ensures a Base32 fingerprint will never be confused with a PGP fingerprint. 3) Include a description of the content type in the target of the fingerprint. This prevents semantic substitution attacks. 4) Allow for optional grouping of characters to encourage readability. On Thu, Jun 22, 2017 at 7:17 PM, Scott Kitterman wrote: > It seemed like the hashed RSA variant ought to be easy enough to > implement, so > I decided to give it a go. I almost immediately ran into a question. For > terminology, I'm using what openssl says [1] > > I am assuming that "SHA-256 hash of the public key, stored in base64" means > use the output of the digest in binary form (--binary) option and encode > it in > base 64. Is that correct? > > > So if my signing key were (I know, but just to make sure I understand the > tranformations): > > 'Hello World' > > Then the the p tag in DNS would be: > > p=pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4= > > Am I understanding it correctly? > > A python one liner: > > >>> base64.b64encode(hashlib.sha256(b'Hello World').digest()) > 'pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=' > > Scott K > > > > [1] https://www.openssl.org/docs/man1.1.0/apps/sha256.html > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a11c04b8054bc4005529512fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I w= ould really like to get to a point where we could use one fingerprint forma= t everywhere. This would then allow fingerprints to be cut and pasted from = one place to another.

Whe= n I suggest we do something of this sort, people say 'write a draft'= ;. Once I write a draft they say I am peddling my proposal. So pretend that= I don't have a draft yet. These are the features I think are needed:

1) Use Base32 encoding.=C2= =A0

<= div class=3D"gmail_default" style=3D"font-size:small">DNS labels are case i= nsensitive. Using fingerprints in DNS labels is very powerful. It allows DA= NE like effects without the need for DANE records or DNSSEC.

2) Incorporate the algorithm identifier= into the fingerprint, do so in a way that ensures a Base32 fingerprint wil= l never be confused with a PGP fingerprint.

3) Include a description of the content type in the ta= rget of the fingerprint. This prevents semantic substitution attacks.
=

4) Allow for optional grouping= of characters to encourage readability.
On Thu, Jun 22, 2017 at 7:17 PM, Scott Kitterm= an <sklist@kitterman.com> wrote:
It seemed like the hashed RSA variant ought to be easy enough to = implement, so
I decided to give it a go.=C2=A0 I almost immediately ran into a question.= =C2=A0 For
terminology, I'm using what openssl says [1]

I am assuming that "SHA-256 hash of the public key, stored in base64&q= uot; means
use the output of the digest in binary form (--binary) option and encode it= in
base 64.=C2=A0 Is that correct?


So if my signing key were (I know, but just to make sure I understand the tranformations):

'Hello World'

Then the the p tag in DNS would be:

p=3DpZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=3D

Am I understanding it correctly?

A python one liner:

>>> base64.b64encode(hashlib.sha256(b'Hello World').d= igest())
'pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=3D'

Scott K



[1] https://www.openssl.org/docs/man1.1.= 0/apps/sha256.html

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a11c04b8054bc4005529512fa-- From nobody Thu Jun 22 16:51:56 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9EE127369 for ; Thu, 22 Jun 2017 16:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 U4xsduAKuvfp for ; Thu, 22 Jun 2017 16:51:53 -0700 (PDT) Received: from mail.wordtothewise.com (mail.wordtothewise.com [IPv6:2001:470:1:6d::9a]) by ietfa.amsl.com (Postfix) with ESMTP id 47791129493 for ; Thu, 22 Jun 2017 16:51:53 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) by mail.wordtothewise.com (Postfix) with ESMTPSA id E96DD23379 for ; Thu, 22 Jun 2017 16:52:10 -0700 (PDT) From: Steve Atkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 22 Jun 2017 16:51:52 -0700 References: <2793611.63lxTaCm4r@kitterma-e6430> To: dcrup@ietf.org In-Reply-To: Message-Id: <29347FB0-BFF6-42C4-B489-302342F6F2C0@blighty.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 23:51:55 -0000 > On Jun 22, 2017, at 4:44 PM, Phillip Hallam-Baker = wrote: >=20 > I would really like to get to a point where we could use one = fingerprint format everywhere. This would then allow fingerprints to be = cut and pasted from one place to another. +1. >=20 > When I suggest we do something of this sort, people say 'write a = draft'. Once I write a draft they say I am peddling my proposal. So = pretend that I don't have a draft yet. These are the features I think = are needed: >=20 > 1) Use Base32 encoding.=20 >=20 > DNS labels are case insensitive. Using fingerprints in DNS labels is = very powerful. It allows DANE like effects without the need for DANE = records or DNSSEC. >=20 > 2) Incorporate the algorithm identifier into the fingerprint, do so in = a way that ensures a Base32 fingerprint will never be confused with a = PGP fingerprint. >=20 > 3) Include a description of the content type in the target of the = fingerprint. This prevents semantic substitution attacks. >=20 > 4) Allow for optional grouping of characters to encourage readability. (and maybe be specific about what embedded whitespace means) These all seem good features.. I'm reminded of the $1$... style password hashes. Immediately = recognizable in general, but including enough embedded information that you know which spec to follow. Cheers, Steve= From nobody Thu Jun 22 17:01:32 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B6A129493 for ; Thu, 22 Jun 2017 17:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oU2iDWq41KID for ; Thu, 22 Jun 2017 17:01:29 -0700 (PDT) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58DA3126BFD for ; Thu, 22 Jun 2017 17:01:29 -0700 (PDT) Received: by mail-ot0-x22f.google.com with SMTP id y47so21905478oty.0 for ; Thu, 22 Jun 2017 17:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=le1JaTBxQX+DHY7QQcqJCUpeb1DA/Dr4Y43SDBPukLI=; b=EjInBemsN26jrk3/kNkYI/+lADsV6AVCWsQG/EpPkFijakY7chUuCKKRbzR7zJkiNq /c0hWtOptt7WnaaCFnxQw9ug9lcR1fJn8RtAyn5ZIuA20IhN+AwMlh76kSszbY1UpAUd AntzQF9MEfje2LwhC/H9B1tfZSLfOQjWeZx3gchqWwTTfUetpbIASdbcSiM6fGisplTm /0KeY2rCoyCQvYIsZbTmCsHWxGntlW+4We2QZngbwar098cmvN5Y8jCI7at3fuu0wrqq Peo3JeM2Zl3ZxsWvokjVm6SOeJmnmhwl9GplcvdjyR+2hRIqsSn1Nj39S8IEYoLOuNXO hIOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=le1JaTBxQX+DHY7QQcqJCUpeb1DA/Dr4Y43SDBPukLI=; b=cRujVz/oxYjW/nxrGlXdQrNvgUykw3H5brgf6mxHYV5rWuQa5mnguTvCSa/us3WQZa qSKRThBLujz3E8fcuw97Z25xoc9mvPJx6POouT6GM9cSxIbD05q2dURA+hdaWKIz2e6x rwyW0D9JywnyA43J1mHyLPBlESKyQR4oj4zWnDJA0NYkfFV3xweEE8TfGtaAa3svOVuU 4HCAbn3sBJQlUxob75wBFQ3hVC2fuQiSD0bmf3xalzwqLOglgikKEL8SzP9C5mFwFCHN dam771v8+cmk4WQoylwUBxUmPU1u1qB9JNRYztOR9ZcUU/2zVhDzF1jhlxkJ/efw9uaA RcUg== X-Gm-Message-State: AKS2vOzsaajNZ0UPEiCuxR8m7ukFzPW7BJGWn0de2yNSHesvY9CP9Oc2 ytzIYhxejX48+JyMzgZNdyztemxCWw== X-Received: by 10.157.34.85 with SMTP id o79mr2452787ota.214.1498176088798; Thu, 22 Jun 2017 17:01:28 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.206 with HTTP; Thu, 22 Jun 2017 17:01:28 -0700 (PDT) In-Reply-To: <29347FB0-BFF6-42C4-B489-302342F6F2C0@blighty.com> References: <2793611.63lxTaCm4r@kitterma-e6430> <29347FB0-BFF6-42C4-B489-302342F6F2C0@blighty.com> From: Phillip Hallam-Baker Date: Thu, 22 Jun 2017 20:01:28 -0400 X-Google-Sender-Auth: 9T274vVJSPFPRBaO02LX0GIgN0s Message-ID: To: Steve Atkins Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113c239e957cc60552954dbb" Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 00:01:31 -0000 --001a113c239e957cc60552954dbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 22, 2017 at 7:51 PM, Steve Atkins wrote: > > (and maybe be specific about what embedded whitespace means) > > These all seem good features.. > > I'm reminded of the $1$... style password hashes. Immediately recognizabl= e > in > general, but including enough embedded information that you know which > spec to follow. > =E2=80=8BThe other thing I would like is the ability to truncate fingerprin= ts to arbitrary lengths by truncating the string specifying the fingerprint. In all but a few applications, a fingerprint with a workfactor of 2^118 is sufficient to prevent most attacks.=E2=80=8B That is 25 characters in my pr= oposal (since there is a one byte algorithm identifier prefix). There are also some hacks that can be used for compressing the fingerprint but I don't think these would be relevant here. --001a113c239e957cc60552954dbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, Jun 22, 2017 at 7:51 PM, Steve Atkins <steve@blighty.com> wrote:

(and maybe be specific about what embedded whitespace means)

These all seem good features..

I'm reminded of the $1$... style password hashes. Immediately recogniza= ble in
general, but including enough embedded information that you know which
spec to follow.

=E2=80=8BThe other thing I would like is the abi= lity to truncate fingerprints to arbitrary lengths by truncating the string= specifying the fingerprint. In all but a few applications, a fingerprint w= ith a workfactor of 2^118 is sufficient to prevent most attacks.=E2=80=8B T= hat is 25 characters in my proposal (since there is a one byte algorithm id= entifier prefix).

There a= re also some hacks that can be used for compressing the fingerprint but I d= on't think these would be relevant here.
--001a113c239e957cc60552954dbb-- From nobody Thu Jun 22 17:07:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9B7126B72 for ; Thu, 22 Jun 2017 17:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, 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=kitterman.com 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 g2z8rViAPMDM for ; Thu, 22 Jun 2017 17:07:21 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 784D3129413 for ; Thu, 22 Jun 2017 17:07:20 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 683BDC400E6 for ; Thu, 22 Jun 2017 19:07:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1498176439; bh=mwtwRvqIfH2lQ7OL5MMFcNzod+AyFPgNdF6t8/Gchp8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=lxgT7cOhOfBlpMF6+joh9I0XFLNwJMO6b9QfiTWlJDnLhmRZK0K4URoWTrMmqzUhX V82Qvwymm0E+QRx0oZx7RrLFDokD26uh7PoT4KeJezuHR1ATHr+C1+Ly9JdJ7rjRMt HTARFaSKqJSIDj/PDOT/JMfEeh32OddsKF3TrqhM= From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 22 Jun 2017 20:07:18 -0400 Message-ID: <2322507.4QhTyLSsXE@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-119-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <2793611.63lxTaCm4r@kitterma-e6430> <29347FB0-BFF6-42C4-B489-302342F6F2C0@blighty.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 00:07:23 -0000 On Thursday, June 22, 2017 08:01:28 PM Phillip Hallam-Baker wrote: > On Thu, Jun 22, 2017 at 7:51 PM, Steve Atkins wro= te: > > (and maybe be specific about what embedded whitespace means) > >=20 > > These all seem good features.. > >=20 > > I'm reminded of the $1$... style password hashes. Immediately recog= nizable > > in > > general, but including enough embedded information that you know wh= ich > > spec to follow. >=20 > =E2=80=8BThe other thing I would like is the ability to truncate fing= erprints to > arbitrary lengths by truncating the string specifying the fingerprint= . In > all but a few applications, a fingerprint with a workfactor of 2^118 = is > sufficient to prevent most attacks.=E2=80=8B That is 25 characters in= my proposal > (since there is a one byte algorithm identifier prefix). >=20 > There are also some hacks that can be used for compressing the finger= print > but I don't think these would be relevant here. I'm probably just grumpy because it's been a long day in a long week, b= ut if=20 you are going to not answer my question and go off in a completely diff= erent=20 direction (in case you missed it, my question was about what's in the d= raft=20 now, not an invitation to imagine what should be in the draft), would y= ou=20 please at least start your own thread so others are less likely to assu= me I=20 already got my answer somewhere in what seems likely to be a long threa= d=20 spiraling off into some new ocean that wants boiling? Thanks, Scott K From nobody Thu Jun 22 17:20:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3C4129BB3 for ; Thu, 22 Jun 2017 17:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ZfksRCCxos-g for ; Thu, 22 Jun 2017 17:20:02 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765A6129BB2 for ; Thu, 22 Jun 2017 17:20:02 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id c189so17840032oia.2 for ; Thu, 22 Jun 2017 17:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6A66t2jDoFq5vhxH8bLEIchP2mzw69Kkn8QSDMO/290=; b=hrqJ202hITdz0WKZB06VB/emozfTHx7L9xHPsYjohcPhR5DliYJ6KsJc6Ddh5W5cz8 WIC3hQHjDcQB58tfPdquXu5DX60ii3mHNREK2xcvSBNEt+K/TliEGaxtY/u5Ah1NBRfV 3QoTnOSnmWce5BrgSo2hQ+xUX0kc255TS+hK2VXm2xPJLHrFGw8g5XJmvZP3keVg6uKh Dz4G0Ystfb9k2B9aOCVtSjT9yta2Yxtt/AAG3X3bLniaJCbd+TMT3YM4UyRBZXe1vN7W Y/4D2XA/uqsglccKYkwwrIXYpxJl27Nf8hZIh9CsOmbkJWlw9YBSB5QVNYdco6jxFKtV rmAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6A66t2jDoFq5vhxH8bLEIchP2mzw69Kkn8QSDMO/290=; b=D4U6Raq/LXwTqYhe4U2sLGrDsTC/2zW1otWhzr7ZHfwZ3hIFL3MMDUtEGZswpwjQZB cXafX9AKN7/Hb1MVe2E9ro/5dGoi4Wd9FmW4fsgVPiogL//cZ+DvAgc+HWCHN3IEmp5S q/eSDLlRk+UyNJ/48GSa1EJbLvI7N+/2mi08nLXWrvy0DynphepEf3uAwFsaJDYXuYL8 h6QbrdbRZgxutuUA2E9ax7onmZc6zel513jq1nr1iaplW3c+4gYky84ep7rzp6MKjH2L gmSZfY6nFlYs0dPLkXz8hes/6xQr9VztWCxTKU6icd2a5nH9VPfZzsWXBfzZQJPBuzPQ 7uGQ== X-Gm-Message-State: AKS2vOyB9u8zamGcFNjCtyF9UgYvf9t21zk41JPCizd8HV8B2w5fF/vV AIJ16WLW74ViUjGmNrG7oe+zmIJ8vkOs X-Received: by 10.202.235.12 with SMTP id j12mr2422163oih.2.1498177201765; Thu, 22 Jun 2017 17:20:01 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.206 with HTTP; Thu, 22 Jun 2017 17:20:01 -0700 (PDT) In-Reply-To: <2322507.4QhTyLSsXE@kitterma-e6430> References: <2793611.63lxTaCm4r@kitterma-e6430> <29347FB0-BFF6-42C4-B489-302342F6F2C0@blighty.com> <2322507.4QhTyLSsXE@kitterma-e6430> From: Phillip Hallam-Baker Date: Thu, 22 Jun 2017 20:20:01 -0400 X-Google-Sender-Auth: wtcsaDQr5mXWBIxLOYFXdjRmodY Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113cc70cec04660552958fc1" Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 00:20:05 -0000 --001a113cc70cec04660552958fc1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This draft describes all the requirements etc and the current proposal. https://tools.ietf.org/html/draft-hallambaker-udf-05 The reference implementation is actually rather shorter than the draft describing the requirements. Basically it is little more than a wrapper around SHA-2-512. On Thu, Jun 22, 2017 at 8:07 PM, Scott Kitterman wrote: > On Thursday, June 22, 2017 08:01:28 PM Phillip Hallam-Baker wrote: > > On Thu, Jun 22, 2017 at 7:51 PM, Steve Atkins wrote= : > > > (and maybe be specific about what embedded whitespace means) > > > > > > These all seem good features.. > > > > > > I'm reminded of the $1$... style password hashes. Immediately > recognizable > > > in > > > general, but including enough embedded information that you know whic= h > > > spec to follow. > > > > =E2=80=8BThe other thing I would like is the ability to truncate finger= prints to > > arbitrary lengths by truncating the string specifying the fingerprint. = In > > all but a few applications, a fingerprint with a workfactor of 2^118 is > > sufficient to prevent most attacks.=E2=80=8B That is 25 characters in m= y proposal > > (since there is a one byte algorithm identifier prefix). > > > > There are also some hacks that can be used for compressing the > fingerprint > > but I don't think these would be relevant here. > > I'm probably just grumpy because it's been a long day in a long week, but > if > you are going to not answer my question and go off in a completely > different > direction (in case you missed it, my question was about what's in the dra= ft > now, not an invitation to imagine what should be in the draft), would you > please at least start your own thread so others are less likely to assume= I > already got my answer somewhere in what seems likely to be a long thread > spiraling off into some new ocean that wants boiling? > > Thanks, > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a113cc70cec04660552958fc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This draft describes all the = requirements etc and the current proposal.

https://tools.ietf.org/html/draft-hallambake= r-udf-05

The reference implementation is actually rather shorter than= the draft describing the requirements. Basically it is little more than a = wrapper around SHA-2-512.






On Thu, Ju= n 22, 2017 at 8:07 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On Thursday, June 22, 2017 08:01:28 PM Phillip Hallam-Baker wrot= e:
> On Thu, Jun 22, 2017 at 7:51 PM, Steve Atkins <steve@blighty.com> wrote:
> > (and maybe be specific about what embedded whitespace means)
> >
> > These all seem good features..
> >
> > I'm reminded of the $1$... style password hashes. Immediately= recognizable
> > in
> > general, but including enough embedded information that you know = which
> > spec to follow.
>
> =E2=80=8BThe other thing I would like is the ability to truncate finge= rprints to
> arbitrary lengths by truncating the string specifying the fingerprint.= In
> all but a few applications, a fingerprint with a workfactor of 2^118 i= s
> sufficient to prevent most attacks.=E2=80=8B That is 25 characters in = my proposal
> (since there is a one byte algorithm identifier prefix).
>
> There are also some hacks that can be used for compressing the fingerp= rint
> but I don't think these would be relevant here.

I'm probably just grumpy because it's been a long day i= n a long week, but if
you are going to not answer my question and go off in a completely differen= t
direction (in case you missed it, my question was about what's in the d= raft
now, not an invitation to imagine what should be in the draft), would you please at least start your own thread so others are less likely to assume I=
already got my answer somewhere in what seems likely to be a long thread spiraling off into some new ocean that wants boiling?

Thanks,

Scott K

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a113cc70cec04660552958fc1-- From nobody Thu Jun 22 18:18:59 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C2A129BDA for ; Thu, 22 Jun 2017 18:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 LnDNnRQMLcNw for ; Thu, 22 Jun 2017 18:18:55 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3250E129BBD for ; Thu, 22 Jun 2017 18:18:55 -0700 (PDT) Received: (qmail 71411 invoked from network); 23 Jun 2017 01:18:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jun 2017 01:18:53 -0000 Date: 23 Jun 2017 01:18:31 -0000 Message-ID: <20170623011831.27734.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <2793611.63lxTaCm4r@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 01:18:57 -0000 In article <2793611.63lxTaCm4r@kitterma-e6430> you write: >'Hello World' > >Then the the p tag in DNS would be: > >p=pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4= > >Am I understanding it correctly? Yes. For us oldthinkers who use shell scripts: $ echo -n 'Hello World'|openssl sha256 -binary|base64 pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4= R's, John PS: In the interest of not inventing anything new, since every existing DKIM key record has a base64 version of the data, these do too. From nobody Thu Jun 22 18:40:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB97129BEE for ; Thu, 22 Jun 2017 18:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com 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 tbpiY1x1486S for ; Thu, 22 Jun 2017 18:39:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240EB129BEC for ; Thu, 22 Jun 2017 18:39:59 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DEE2FC40166; Thu, 22 Jun 2017 20:39:54 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1498181995; bh=AKmVHsfmHwSuuEZb5Gi0/fCjfA7fN7ek4ThuDDdBW1A=; h=Date:In-Reply-To:References:Subject:To:From:From; b=bBAnS2rnD+rZrSRI5P2W3bMlVNrJD7zlxkUoyn7YJkJPdfpkDt47dVIssLfosqxRt VeARqU2feBr1h+MEaZH9Ipz7hHsxG8ToebMTIG9oG13SueNXbsxLqfS2sP2iBmSSWj blXJR8IzWHT1oZ7j8Wd5KxV6DFcvH63AoyNEUlfQ= Date: Fri, 23 Jun 2017 01:39:53 +0000 In-Reply-To: <20170623011831.27734.qmail@ary.lan> References: <20170623011831.27734.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: <78E6014E-8D22-497F-9E54-1D5C348B4E0F@kitterman.com> Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 01:40:01 -0000 On June 22, 2017 9:18:31 PM EDT, John Levine wrote: >In article <2793611=2E63lxTaCm4r@kitterma-e6430> you write: >>'Hello World' >> >>Then the the p tag in DNS would be: >> >>p=3DpZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=3D >> >>Am I understanding it correctly? > >Yes=2E > >For us oldthinkers who use shell scripts: > >$ echo -n 'Hello World'|openssl sha256 -binary|base64 >pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=3D > >R's, >John > >PS: In the interest of not inventing anything new, since every >existing DKIM key record has a base64 version of the data, these do >too=2E Thanks=2E I'm working my way through implementing the new options and tha= t seemed like a reasonable place to start=2E The dkimpy trunk version of d= knewkey=2Epy [1] can make rsafp records now=2E It may take awhile as I'm short on available time=2E Scott K [1] http://bazaar=2Elaunchpad=2Enet/~dkimpy-hackers/dkimpy/trunk/files From nobody Fri Jun 23 06:34:34 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70D212EAE2 for ; Fri, 23 Jun 2017 06:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 k7j9cFsvTlHo for ; Fri, 23 Jun 2017 06:34:29 -0700 (PDT) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BD9126D45 for ; Fri, 23 Jun 2017 06:34:28 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id s9so13243539ybe.3 for ; Fri, 23 Jun 2017 06:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uPSkX4k5x8jPSA92GH+cGge2ERMecD/htvlN7U+yd14=; b=a1X1woDA/iWFPl/E+zqxXHaniH85NeRgW0y2vCPb+cU3Ym2luugvHK2dHogRWxBv3+ FPvjIBztZS50DZCbnMhAX+2ktziyKyJHw5zbRu+cUmdgJK3k2lAz096thq4o2gVm3UBs 6OP72rBQmy8LF5SO2V9zGRtBE1rvwA2amTgPh0YR3DgqHmV8Ew2VQbcXX4Fh67X/Sqrq kTzMvJfYX6X36Rnd7LyCBxlXGynq5qvz0WSSYxwkqkOlI607mmxN1oUaMOycJ/AByque ieeAmlzbltOpVjnjFzoMdN6bqPU98RSNRlGQW64tw115u3L3lLV/+Uzq9hEOFjq/lY0B dBGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uPSkX4k5x8jPSA92GH+cGge2ERMecD/htvlN7U+yd14=; b=ERvoKSYIOoGE7Opb1tbF7pNHKBsDN/5IrfAE3Yqna+ELyGrOJUZPpCRX4YUadUzesg //yjxeNByWcvTfIEmVHUyiPLeRmbN9ESjmvEvQq5/fRglYaLM8vGOinzss68QqlccnJT KBWrp+/JmDTa+mynDGhSMYK15zDQ01k5GWWhiEedsXCudtO5/e9LDP7e6287HYgC3W/p 7kUetZIkbnfblsdG0kwKeeuGZlpe6miaxd+j2Ec6LdlIfwhXFli7W4PvWghntzKX+PUk NNtRoA53fk7IG/0cs5K1y8XuUfEaOxnRywLV1rqdhTTxF+/sVLiSz43fhPJeq5EOX2cH NnPg== X-Gm-Message-State: AKS2vOz4ym0RFTjRp0b7wQ9uKtgZbpl+39WWrTeDAnRx8ClSD2KvBR32 edC6wMyhixWdTCUK6fXz/P5u35h+RQLG X-Received: by 10.37.125.133 with SMTP id y127mr5858001ybc.238.1498224868102; Fri, 23 Jun 2017 06:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.65 with HTTP; Fri, 23 Jun 2017 06:34:27 -0700 (PDT) In-Reply-To: References: <2793611.63lxTaCm4r@kitterma-e6430> From: denis bider Date: Fri, 23 Jun 2017 07:34:27 -0600 Message-ID: To: Phillip Hallam-Baker Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dc5960e99840552a0a996" Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 13:34:32 -0000 --001a114dc5960e99840552a0a996 Content-Type: text/plain; charset="UTF-8" I propose that the best fingerprint encoding designed so far is the Bubble-Babble encoding by Antti Huima. Example: xedec-nypul-taboz-mugaz-supak-nekyc-bibec-busek-fegon-gekug-loxix It is easy to compare words both visually, and on the phone. Users like it. I found the spec preserved here: http://wiki.yak.net/589/Bubble_Babble_Encoding.txt It was intended to be standardized as part of SSH, but somehow didn't make it to RFC. A number of implementations implemented Bubble Babble, and still have it. However, open source implementations (you know who you are!) went with hexadecimal (MD5) and now Base64 (SHA-256), and now we're stuck with that. If we want to standardize a universal fingerprint format, Base32 is certainly better than either hex or Base64. However, I'd suggest checking out Bubble Babble. denis On Thu, Jun 22, 2017 at 5:44 PM, Phillip Hallam-Baker wrote: > I would really like to get to a point where we could use one fingerprint > format everywhere. This would then allow fingerprints to be cut and pasted > from one place to another. > > When I suggest we do something of this sort, people say 'write a draft'. > Once I write a draft they say I am peddling my proposal. So pretend that I > don't have a draft yet. These are the features I think are needed: > > 1) Use Base32 encoding. > > DNS labels are case insensitive. Using fingerprints in DNS labels is very > powerful. It allows DANE like effects without the need for DANE records or > DNSSEC. > > 2) Incorporate the algorithm identifier into the fingerprint, do so in a > way that ensures a Base32 fingerprint will never be confused with a PGP > fingerprint. > > 3) Include a description of the content type in the target of the > fingerprint. This prevents semantic substitution attacks. > > 4) Allow for optional grouping of characters to encourage readability. > > On Thu, Jun 22, 2017 at 7:17 PM, Scott Kitterman > wrote: > >> It seemed like the hashed RSA variant ought to be easy enough to >> implement, so >> I decided to give it a go. I almost immediately ran into a question. For >> terminology, I'm using what openssl says [1] >> >> I am assuming that "SHA-256 hash of the public key, stored in base64" >> means >> use the output of the digest in binary form (--binary) option and encode >> it in >> base 64. Is that correct? >> >> >> So if my signing key were (I know, but just to make sure I understand the >> tranformations): >> >> 'Hello World' >> >> Then the the p tag in DNS would be: >> >> p=pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4= >> >> Am I understanding it correctly? >> >> A python one liner: >> >> >>> base64.b64encode(hashlib.sha256(b'Hello World').digest()) >> 'pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=' >> >> Scott K >> >> >> >> [1] https://www.openssl.org/docs/man1.1.0/apps/sha256.html >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a114dc5960e99840552a0a996 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I propose that the best fingerprint encoding designed so f= ar is the Bubble-Babble encoding by Antti Huima. Example:

xedec-nypul-taboz-mugaz-supak-nekyc-bibec-busek-fegon-gekug-loxix

It is easy to compare words both visually, and on the phone= . Users like it.

I found the spec preserved here:<= div>

It was intended to be standardized as part of SSH, but some= how didn't make it to RFC.

A number of impleme= ntations implemented Bubble Babble, and still have it. However, open source= implementations (you know who you are!) went with hexadecimal (MD5) and no= w Base64 (SHA-256), and now we're stuck with that.

If we want to standardize a universal fingerprint format, = Base32 is certainly better than either hex or Base64. However, I'd sugg= est checking out Bubble Babble.

denis


On Thu, Jun 22, 2017 at 5:44 PM, Phillip Hallam-Baker <phi= ll@hallambaker.com> wrote:
=
I w= ould really like to get to a point where we could use one fingerprint forma= t everywhere. This would then allow fingerprints to be cut and pasted from = one place to another.

Whe= n I suggest we do something of this sort, people say 'write a draft'= ;. Once I write a draft they say I am peddling my proposal. So pretend that= I don't have a draft yet. These are the features I think are needed:

1) Use Base32 encoding.=C2= =A0

<= div class=3D"gmail_default" style=3D"font-size:small">DNS labels are case i= nsensitive. Using fingerprints in DNS labels is very powerful. It allows DA= NE like effects without the need for DANE records or DNSSEC.

2) Incorporate the algorithm identifier= into the fingerprint, do so in a way that ensures a Base32 fingerprint wil= l never be confused with a PGP fingerprint.

3) Include a description of the content type in the ta= rget of the fingerprint. This prevents semantic substitution attacks.
=

4) Allow for optional grouping= of characters to encourage readability.

On Thu, Jun 22, 2017 at= 7:17 PM, Scott Kitterman <sklist@kitterman.com> wrote:
It seemed like the hashed RSA variant ough= t to be easy enough to implement, so
I decided to give it a go.=C2=A0 I almost immediately ran into a question.= =C2=A0 For
terminology, I'm using what openssl says [1]

I am assuming that "SHA-256 hash of the public key, stored in base64&q= uot; means
use the output of the digest in binary form (--binary) option and encode it= in
base 64.=C2=A0 Is that correct?


So if my signing key were (I know, but just to make sure I understand the tranformations):

'Hello World'

Then the the p tag in DNS would be:

p=3DpZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=3D

Am I understanding it correctly?

A python one liner:

>>> base64.b64encode(hashlib.sha256(b'Hello World').d= igest())
'pZGm1Av0IEBKARczz7exkNYsZb8LzaMrV7J32a2fFG4=3D'

Scott K



[1] https://www.openssl.org/docs/man1.1.= 0/apps/sha256.html

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a114dc5960e99840552a0a996-- From nobody Fri Jun 23 09:52:41 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E55127201 for ; Fri, 23 Jun 2017 09:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 gRxTL936RaAq for ; Fri, 23 Jun 2017 09:52:38 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 5081012700F for ; Fri, 23 Jun 2017 09:52:38 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5NGhv0V004122; Fri, 23 Jun 2017 17:52:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=E90ulO0wcuhY6aFTYku0ox4e8yKG3ZK6M+JfV4hXe/4=; b=dbqdjyXh6LIlji7EK9+L/Kicek3BVStchpSA275OuYSAlCn2A9P3MRXE7nYv8sf8dlQP pgPhhBge0vNNNOGq6T5yVQUvxh3Xbu29X9p/v0cxKkp9K8jTirpIqnI/Jn6ULp7Wjakm t7UuQ7DCfGxFf7HGkE4ZN67iiCB4F9B58T4GLrfT0RWHJ/bcihkXAreeRlNbvd24IcGM OOjX5mDDS30dfvezEl1WlYizq1YjWOkey4wgK0bixTpLU7cvfezlsTvY38wae8rrI0zv FsQRdr5PdjbqOo/9Q3gusFJQ19WSju4NQmOlIRFrpFoE/7AZCBotNY1xzn51d3ueEXf4 oA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2b934p9aer-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 17:52:34 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5NGopMB028580; Fri, 23 Jun 2017 12:52:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b4yrvh2p5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 12:52:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Jun 2017 09:52:32 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 23 Jun 2017 12:52:32 -0400 From: "Salz, Rich" To: denis bider , Phillip Hallam-Baker CC: "dcrup@ietf.org" , Scott Kitterman Thread-Topic: [Dcrup] Hashed Key Records Thread-Index: AQHS6621pmpTdvgaKkSv9ck3x8Opt6IxzsoAgADnx4D///PbkA== Date: Fri, 23 Jun 2017 16:52:32 +0000 Message-ID: <87c3e917f0624991a7cac1d80bb38d65@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2793611.63lxTaCm4r@kitterma-e6430> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.104] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230284 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230280 Archived-At: Subject: Re: [Dcrup] Hashed Key Records X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 16:52:40 -0000 U291bmRzIHNpbWlsYXIgdG8gdGhlIGRpY3Rpb25hcnkgc2NoZW1lIHVzZWQgaW4gUy9LZXksIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMjg5IA0KDQo+IGh0dHA6Ly93aWtpLnlhay5u ZXQvNTg5L0J1YmJsZV9CYWJibGVfRW5jb2RpbmcudHh0DQoNClBlcmhhcHMgc29tZW9uZSB3b3Vs ZCBjb25zaWRlciB3cml0aW5nIGFuIGluZGl2aWR1YWwgZHJhZnQsIEFEIHNwb25zb3JlZC4NCg0K LS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVu U1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQo= From nobody Fri Jun 23 10:42:22 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59F1270A3 for ; Fri, 23 Jun 2017 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JBJXj9usc2G1 for ; Fri, 23 Jun 2017 10:42:17 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24BA7127333 for ; Fri, 23 Jun 2017 10:42:17 -0700 (PDT) Received: (qmail 13272 invoked from network); 23 Jun 2017 17:42:15 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 Jun 2017 17:42:15 -0000 Date: 23 Jun 2017 17:41:53 -0000 Message-ID: <20170623174153.31788.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: denisbider.ietf@gmail.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Hashed Key Records in draft-ietf-dcrup-dkim-crypto-02 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:42:19 -0000 In article you write: >I propose that the best fingerprint encoding designed so far is the >Bubble-Babble encoding by Antti Huima. .... No doubt, but we're talking about the one in draft-ietf-dcrup-dkim-crypto-02, in which I tried to make the minimum perturbation to existing DKIM implementations. If you're aware of reasons why that one can't be implemented, or has horribly security problems, or otherwise won't interoperate, now's the time to tell us about it. R's, John From nobody Fri Jun 23 10:43:09 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C039127333 for ; Fri, 23 Jun 2017 10:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 N6YZP5yFHLIH for ; Fri, 23 Jun 2017 10:43:04 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 6C1821270A3 for ; Fri, 23 Jun 2017 10:43:04 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5NHTjTJ010086; Fri, 23 Jun 2017 18:43:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dSN8Hsp9Z1Q8jQzR5V5oWuHD8E2U8fpMq4sBW9AjeXI=; b=EKC9ROQruhOHPJY4MOl1Grcj4l9+Gp0lPWjHmwEYS/fazWuAHL+wOWzVViJann1OPK5x GbPypJrjK2Ghj9ugl9NU7MuijWpPwqzWgrx1klHz0TBk5BJfZAB8jDOG1YjdNMCAXNRO RxoOP10L3mRHZGrGpljw+3Rz1ilwwmZ3EDayUI3jZmpZnuBleDw7fW1FY2X7/vTmSOee 9cdm8zVF8o/whFQZpvcPWv8To5azuXum4Oq2knw3UQ9P5UWuqwfERe/dnTgDxcy44CX7 RKsJLqVxRzPz1w69YQun856G05bMOoJXOK89/sBh3AloLt7ncCDN0l/t8SNUYQP/xi5B eg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b934p9pbh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 18:43:00 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5NHeb4g017471; Fri, 23 Jun 2017 13:42:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b4yruyuur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 13:42:59 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 23 Jun 2017 10:42:59 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 23 Jun 2017 13:42:59 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "denisbider.ietf@gmail.com" Thread-Topic: [Dcrup] Hashed Key Records in draft-ietf-dcrup-dkim-crypto-02 Thread-Index: AQHS7EgTkDTb7utuZUWdHTe7cILRMaIyt6Uw Date: Fri, 23 Jun 2017 17:42:58 +0000 Message-ID: <36390af3acd44f6ca5e69495a9c4f5b8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170623174153.31788.qmail@ary.lan> In-Reply-To: <20170623174153.31788.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.104] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230297 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-23_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230295 Archived-At: Subject: Re: [Dcrup] Hashed Key Records in draft-ietf-dcrup-dkim-crypto-02 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 17:43:07 -0000 > No doubt, but we're talking about the one in draft-ietf-dcrup-dkim-crypto= - > 02, in which I tried to make the minimum perturbation to existing DKIM > implementations. I agree. I was just trying to move that off to a separate track. From nobody Fri Jun 23 12:03:54 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602661200F3 for ; Fri, 23 Jun 2017 12:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1t0LkTgvVInu for ; Fri, 23 Jun 2017 12:03:50 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9471B1287A7 for ; Fri, 23 Jun 2017 12:03:50 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id 63so20387245ywr.0 for ; Fri, 23 Jun 2017 12:03:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=B5HgLgJZYmV8QWz1gVmRp50KkYPcYQztHP4K80yQ+3I=; b=kBb9Y+JhSugkJq48zi4/J2dvEMw5a758+ZSWwSwGhezJhZxKkWriRQEQ1i0yimDuJH BokNcSpo/xV0ePLY9lUZMClznbfUyz2OZGd33OAXSJVPKjlkbhNJQCehsrNi6YrXlpZT MYzeAsfWsT6YfvWKJTzxxmUzyazfbkCo5/KMRZ+BlsUOZeX54pM0i8vLiGQ50R7R39rx TJ5WhVq3Z3VQuhusPhbk+1QquJK5/OmoWJgoDSX3mTbcbDDJZJBXQM4QYeIkTzIG8A/r V2vF1BSOmxGwqHydc5JBmOWha5PlhIlqPp9HtBMrFeAkJYUCzqKPSQm+VMOtCzb7JMqs sdyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=B5HgLgJZYmV8QWz1gVmRp50KkYPcYQztHP4K80yQ+3I=; b=alQFeJF1rOjlDY8YBj9w5vrnuU0lUJKto0Vr8vAzqwNRZ7QHgeneF7flEfntXbyiUx w3WmmrFGaE3XxCIug9fF4By0OzoGLKdjDSOdy4yo+Qd81FYfspcdxxH9Kxs6Lwpnu5+I ayGX+Pg3ft/hnjIjQQzaA7f8cOy/6H0bTxjodglILPRN5gwwqhZ0rO3Nnk2re20t1IcV hqqod7sY6V9s2cui+76dFbtWHYKi81GEeMr3K0aS/YqyC86mw6Y5NO4RQnQVj9P/PXUA BJUPnjgYG0tmCF6Xeb4W6Psv73Q9dmj+fJ4nrlkUwmj7oF52sjkjyQeq63j2tzRJmNj6 +zOg== X-Gm-Message-State: AKS2vOzyN+ooSdcDHJ0LTpZFcHIPhz8P8h1fYa8tBi7vSiSXJIXIG34/ 3awL2RByYBIOvca++0K1wUi0bRykTQ== X-Received: by 10.13.231.7 with SMTP id q7mr6910598ywe.8.1498244629796; Fri, 23 Jun 2017 12:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.65 with HTTP; Fri, 23 Jun 2017 12:03:49 -0700 (PDT) In-Reply-To: <20170623174153.31788.qmail@ary.lan> References: <20170623174153.31788.qmail@ary.lan> From: denis bider Date: Fri, 23 Jun 2017 13:03:49 -0600 Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0805a4f21e0b0552a542e1" Archived-At: Subject: Re: [Dcrup] Hashed Key Records in draft-ietf-dcrup-dkim-crypto-02 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 19:03:52 -0000 --94eb2c0805a4f21e0b0552a542e1 Content-Type: text/plain; charset="UTF-8" Certainly, did not mean to suggest that one was not fit for purpose. I was responding specifically with respect to "one fingerprint everywhere". That seems like a good idea to me, if only we could gather interest from implementers of multiple protocols to adopt in the future. It would not work as a DKIM-specific endeavor. On Fri, Jun 23, 2017 at 11:41 AM, John Levine wrote: > In article gmail.com> you write: > >I propose that the best fingerprint encoding designed so far is the > >Bubble-Babble encoding by Antti Huima. .... > > No doubt, but we're talking about the one in > draft-ietf-dcrup-dkim-crypto-02, in which I tried to make the minimum > perturbation to existing DKIM implementations. > > If you're aware of reasons why that one can't be implemented, or has > horribly security problems, or otherwise won't interoperate, now's the > time to tell us about it. > > R's, > John > --94eb2c0805a4f21e0b0552a542e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Certainly, did not mean to suggest that one was not fit fo= r purpose. I was responding specifically with respect to "one fingerpr= int everywhere". That seems like a good idea to me, if only we could g= ather interest from implementers of multiple protocols to adopt in the futu= re. It would not work as a DKIM-specific endeavor.

On Fri, Jun 23, 2017 at 11:41 AM, Jo= hn Levine <johnl@taugh.com> wrote:
In article <CADPMZDD+1vG8=3DsMEPz=3D-+wwRLSWJTjAV5pLyxsURU5xZH6WKhw@m= ail.gmail.com> you write:
>I propose that the best fingerprint encoding designed so far is the
>Bubble-Babble encoding by Antti Huima. ....

No doubt, but we're talking about the one in
draft-ietf-dcrup-dkim-crypto-02, in which I tried to make the minimum<= br> perturbation to existing DKIM implementations.

If you're aware of reasons why that one can't be implemented, or ha= s
horribly security problems, or otherwise won't interoperate, now's = the
time to tell us about it.

R's,
John

--94eb2c0805a4f21e0b0552a542e1-- From nobody Fri Jun 23 14:20:14 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539C2129AD1 for ; Fri, 23 Jun 2017 14:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 eowQVwRO4VB5 for ; Fri, 23 Jun 2017 14:20:07 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656701294F8 for ; Fri, 23 Jun 2017 14:20:07 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id p187so31990421oif.3 for ; Fri, 23 Jun 2017 14:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=haQaK/nNRKl0dIteca0ATolQrpabSTUzirNgmxWvQeA=; b=UMoy/bf5DJzDqfKF6CmIReQlqOwB7YG2aWgSDM2WJAGr9h+sxo1zZEIHk0JQBYFZ8K OJ2N3aLwwTIpJ3cKqYb+9ig249LGqBMixHj+DW7Aj3pzaBjKBIQpwb4e15fr476Tikqa ddWa7Vhck6yHpe3qIBA/tlNw8EhP15ir8Dxw8CHCSXgs91FN9tVZiq0+yMo/TTRugydt pKOwuV27HM3yJT/ffz8Le9N2PXRNnMKhGM0eTYSgiaptWrQoCgYSjHkh254ezPTMKmRE 7rb+5u88leOpQAkA3pqHSTGCF29C8Ph0RNCLM3j6nRjDJz+Z7QoCBhxGu3+JQkamrFxh nbEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=haQaK/nNRKl0dIteca0ATolQrpabSTUzirNgmxWvQeA=; b=pp74TLfBHjD4wr9VVETMSPyqH31sgg8mstdzAUKSLelmvlGyIqb1WyF5vbmn/eI37e KaMjPXVBd3OqH7E581YIGM+rPsOcr3vgfNO7NlI4ziZAfWgsHVEF2QM4OilCsVLMjLbJ NKLrNk9NwME4HARSqBYjKMB+mll7INVz8kc1PzQ6WI5crfXF7/RjAYcNEhlra0v1IvoY A5J5CPGzjmIxPvL3Zo+zLodNdfYz/BztUOx+ivdOVb/SMkQlF1SnogaDt9hByDPuqLOO BBKrsmMNN7XA5Wh2kRVfu0aC6X6tJhJoo8+0cMYZgaq+0BzNeuGvkkobYUzIaUjFeZ9r PtjQ== X-Gm-Message-State: AKS2vOx09SRKRbvhVnJh8wUrjixiHuBH1kDwqOCCeEHJR4rqpPZAyQAB atkMMsZk+0E3Zayx7aqLc44S4+wPqKux/Sk= X-Received: by 10.202.72.20 with SMTP id v20mr5485476oia.44.1498252806405; Fri, 23 Jun 2017 14:20:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Fri, 23 Jun 2017 14:20:05 -0700 (PDT) In-Reply-To: <5949C8AF.4050102@isdg.net> References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> <5949BCD7.4030207@isdg.net> <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> <5949C8AF.4050102@isdg.net> From: Brandon Long Date: Fri, 23 Jun 2017 14:20:05 -0700 Message-ID: To: Hector Santos Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11c17cda4fe2a70552a72abd" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 21:20:12 -0000 --001a11c17cda4fe2a70552a72abd Content-Type: text/plain; charset="UTF-8" On Tue, Jun 20, 2017 at 6:15 PM, Hector Santos wrote: > On 6/20/2017 8:43 PM, Scott Kitterman wrote: > >> On June 20, 2017 8:24:55 PM EDT, Hector Santos wrote: >> >>> >>> The "higher coverage" verifier will most likely keep SHA1 simply to >>> avoid any future support issues. Therefore, it would really help via >>> policy to give the verifier what is to be expected. The key "h=" >>> protocol information should be updated to help in this area. >>> >> >> I think just using the tag in key records operationally is all that's >> needed. >> >> Also, when it comes to migration away from rsa-sha1, it looks like you're >> one of the ones with work to do: >> >> DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; >> >> > Plus any customers who decided to keep a lower overhead DKIM/SHA1 email > operation running for their setup. Its just a simple switch for us, but I > am thinking about the "other legacy endpoints" and the customers who may > encounter new "support issues" because of an update to a version where SHA1 > support may have been removed. Therefore I can't turn it off even I > changed it for my own setup. But I can help with a new possible > migration/enforcement option such as: > > [X] If Key has "h=sha256", invalidate an SHA1 signed message > from the signer domain. > > And with a protocol change note such as: > > "Notes: 1) Future Verifiers MAY NOT include support SHA1. > > 2) If the signer domain key has "h=sha256" then > any signed message not sha256 SHOULD be > invalidated. > Isn't that just a truism? Ie, any signing algorithm may be invalidated in the future. We're explicitly trying to move the needle away from SHA-1 right now, not in the future. Brandon --001a11c17cda4fe2a70552a72abd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 20, 2017 at 6:15 PM, Hector Santos <hsantos@isdg.net>= ; wrote:
On 6/20/= 2017 8:43 PM, Scott Kitterman wrote:
On June 20, 2017 8:24:55 PM EDT, Hector Santos <hsantos@isdg.net> wrote:

The "higher coverage" verifier will most likely keep SHA1 simply = to
avoid any future support issues. Therefore, it would really help via
policy to give the verifier what is to be expected.=C2=A0 The key "h= =3D"
protocol information should be updated to help in this area.

I think just using the tag in key records operationally is all that's n= eeded.

Also, when it comes to migration away from rsa-sha1, it looks like you'= re one of the ones with work to do:

DKIM-Signature: v=3D1; d=3Disdg.net; s=3Dtms1; a=3Drsa-sha1;


Plus any customers who decided to keep a lower overhead DKIM/SHA1 email ope= ration running for their setup.=C2=A0 Its just a simple switch for us, but = I am thinking about the "other legacy endpoints" and the customer= s who may encounter new "support issues" because of an update to = a version where SHA1 support may have been removed.=C2=A0 Therefore I can&#= 39;t turn it off even I changed it for my own setup. But I can help with a = new possible migration/enforcement option such as:

=C2=A0 =C2=A0[X] If Key has "h=3Dsha256", invalidate an SHA1 sign= ed message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 from the signer domain.

And with a protocol change note such as:

=C2=A0 =C2=A0 =C2=A0"Notes: 1) Future Verifiers MAY NOT include suppor= t SHA1.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) If the signer domain key= has "h=3Dsha256" then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 any signed message = not sha256 SHOULD be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 invalidated.

Isn't that just a truism?=C2=A0 Ie, any s= igning algorithm may be invalidated in the future.=C2=A0 We're explicit= ly trying to move the needle away from SHA-1 right now, not in the future.<= /div>

Brandon=C2=A0
--001a11c17cda4fe2a70552a72abd-- From nobody Fri Jun 23 15:39:33 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A3C129ADA for ; Fri, 23 Jun 2017 15:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ITbZVlIK0w9K for ; Fri, 23 Jun 2017 15:39:25 -0700 (PDT) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D201B129ABE for ; Fri, 23 Jun 2017 15:39:24 -0700 (PDT) Received: by mail-ot0-x230.google.com with SMTP id 95so40487811ott.3 for ; Fri, 23 Jun 2017 15:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UQ7ZCprjPuvn40ohsIwRhqfJwJ/z2NAO9TkY79BVA8o=; b=RvKeeFA1cRmFLY2Lmia2d0YF2Uwa43afoPtHdwiO5bqI5CHxfd/wLCHxLcWi30FO8g 02uk2Ge/YqJbYD0bl5uqinUZtEB/qHzDQP+JZJIq1q8rEoXVbZRTm4JMsEXxrLshJx8Y XjF2URofnxqzHN/nDamCKN12JnGpRgIqjdSv9lNjmT/OyZGSIt/5kQC17zxqgn8yvboM ONeDo0NCmXINcfz7799gLKqxebJgmbop9cXdSFx0XEHOKffw/xKXieYzSo7WzqOoI52Q 245wAW8zqGPLMN0xk1LMMQUvwOVyjHZEW+ajyrq2kLflJQb1uPn7i/wmx0rQuuSXlD70 3GMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UQ7ZCprjPuvn40ohsIwRhqfJwJ/z2NAO9TkY79BVA8o=; b=UGobht0+zD5UwfAlZKBwFmij8V0mD8Pgv6tt4bDDDt0vD5JTvx1EXjLcH8o6BO3e/U qN+q4NSAT+NSlUiFybXOLyNlX8QmFT6fCORDr/E73HlisBhKP5nxk+wMpb0qLC9iU+uG OGQwf5I3HUJRVPkS9PHoQLHS0WNU8Yl/7PJvMLcD8JjYbKQGa484Xbb+Vo6wzybOcj/1 zUDwRfE3ALAs77BJA52aAkPOUIl0Z/JyqZWWEqd0J2Dw1JEAyaXsl05g+o+Jh0Eov57r B9gE+JFv9TCXPYBuETyZ3PJsMphrTavWw7PM8KDc/EWFmUdcZ9SjRbzDiu7YT1vcXr3l zgZw== X-Gm-Message-State: AKS2vOy5d4PZivJgKqic+WeFXT4R/c+I+PSstDTKGVNFmrFZLotUWmcl Y6K4OMy90po/k21uMGkoI0bqWr3/iQ== X-Received: by 10.157.15.231 with SMTP id m36mr6205211otd.33.1498257564141; Fri, 23 Jun 2017 15:39:24 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.14.206 with HTTP; Fri, 23 Jun 2017 15:39:23 -0700 (PDT) In-Reply-To: References: <20170620230641.18814.qmail@ary.lan> <5949ADA0.3050702@isdg.net> <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> <5949BCD7.4030207@isdg.net> <19DDA93A-9A4F-44EC-9740-FF825DFF33FE@kitterman.com> <5949C8AF.4050102@isdg.net> From: Phillip Hallam-Baker Date: Fri, 23 Jun 2017 18:39:23 -0400 X-Google-Sender-Auth: 8lQSAQDYuUZ9p4VfjTG6LJXMgd8 Message-ID: To: Brandon Long Cc: Hector Santos , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113ef88ce48f750552a8458d" Archived-At: Subject: Re: [Dcrup] rsa-sha1 proposals X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 22:39:27 -0000 --001a113ef88ce48f750552a8458d Content-Type: text/plain; charset="UTF-8" In general MAY NOT is to be avoided as ambiguous. RFC 2119 does not permit it as normative text. On Fri, Jun 23, 2017 at 5:20 PM, Brandon Long wrote: > > > On Tue, Jun 20, 2017 at 6:15 PM, Hector Santos wrote: > >> On 6/20/2017 8:43 PM, Scott Kitterman wrote: >> >>> On June 20, 2017 8:24:55 PM EDT, Hector Santos wrote: >>> >>>> >>>> The "higher coverage" verifier will most likely keep SHA1 simply to >>>> avoid any future support issues. Therefore, it would really help via >>>> policy to give the verifier what is to be expected. The key "h=" >>>> protocol information should be updated to help in this area. >>>> >>> >>> I think just using the tag in key records operationally is all that's >>> needed. >>> >>> Also, when it comes to migration away from rsa-sha1, it looks like >>> you're one of the ones with work to do: >>> >>> DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; >>> >>> >> Plus any customers who decided to keep a lower overhead DKIM/SHA1 email >> operation running for their setup. Its just a simple switch for us, but I >> am thinking about the "other legacy endpoints" and the customers who may >> encounter new "support issues" because of an update to a version where SHA1 >> support may have been removed. Therefore I can't turn it off even I >> changed it for my own setup. But I can help with a new possible >> migration/enforcement option such as: >> >> [X] If Key has "h=sha256", invalidate an SHA1 signed message >> from the signer domain. >> >> And with a protocol change note such as: >> >> "Notes: 1) Future Verifiers MAY NOT include support SHA1. >> >> 2) If the signer domain key has "h=sha256" then >> any signed message not sha256 SHOULD be >> invalidated. >> > > Isn't that just a truism? Ie, any signing algorithm may be invalidated in > the future. We're explicitly trying to move the needle away from SHA-1 > right now, not in the future. > > Brandon > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a113ef88ce48f750552a8458d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In = general MAY NOT is to be avoided as ambiguous. RFC 2119 does not permit it = as normative text.

On Fri, Jun 23, 2017 at 5:20 PM, Brandon Long <blong@google.co= m> wrote:
=

On Tue, Jun 20, 2017 at 6:15 PM, Hector Santos <= hsantos@isdg.net&= gt; wrote:
On 6/20/2017 8:43= PM, Scott Kitterman wrote:
On June 20, 2017 8:24:55 PM EDT, Hector Santos <hsantos@isdg.net> wrote:

The "higher coverage" verifier will most likely keep SHA1 simply = to
avoid any future support issues. Therefore, it would really help via
policy to give the verifier what is to be expected.=C2=A0 The key "h= =3D"
protocol information should be updated to help in this area.

I think just using the tag in key records operationally is all that's n= eeded.

Also, when it comes to migration away from rsa-sha1, it looks like you'= re one of the ones with work to do:

DKIM-Signature: v=3D1; d=3Disdg.net; s=3Dtms1; a=3Drsa-sha1;


Plus any customers who decided to keep a lower overhead DKIM/SHA1 email ope= ration running for their setup.=C2=A0 Its just a simple switch for us, but = I am thinking about the "other legacy endpoints" and the customer= s who may encounter new "support issues" because of an update to = a version where SHA1 support may have been removed.=C2=A0 Therefore I can&#= 39;t turn it off even I changed it for my own setup. But I can help with a = new possible migration/enforcement option such as:

=C2=A0 =C2=A0[X] If Key has "h=3Dsha256", invalidate an SHA1 sign= ed message
=C2=A0 =C2=A0 =C2=A0 =C2=A0 from the signer domain.

And with a protocol change note such as:

=C2=A0 =C2=A0 =C2=A0"Notes: 1) Future Verifiers MAY NOT include suppor= t SHA1.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) If the signer domain key= has "h=3Dsha256" then
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 any signed message = not sha256 SHOULD be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 invalidated.

Isn't that just a truism?=C2=A0 Ie= , any signing algorithm may be invalidated in the future.=C2=A0 We're e= xplicitly trying to move the needle away from SHA-1 right now, not in the f= uture.

<= div>Brandon=C2=A0

_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a113ef88ce48f750552a8458d-- From nobody Fri Jun 23 17:10:43 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0AC129B9C; Fri, 23 Jun 2017 17:07:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dcrup@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282424.7840.13913939335306531717.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:04 -0700 Archived-At: Subject: [Dcrup] dcrup - Requested session has been scheduled for IETF 99 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:04 -0000 Dear Rich Salz, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dcrup Session 1 (0:30:00) Thursday, Morning Session I 0930-1200 Room Name: Berlin/Brussels size: 100 --------------------------------------------- Special Note: 11:00-11:30 Request Information: --------------------------------------------------------- Working Group Name: DKIM Crypto Update Area Name: Applications and Real-Time Area Session Requester: Rich Salz Number of Sessions: 1 Length of Session(s): 30 Minutes Number of Attendees: 20 Conflicts to Avoid: First Priority: cfrg lamps jmap dmarc dispatch People who must be present: Rich Salz Alexey Melnikov Murray Kucherawy Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 26 11:46:44 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6212EB2B for ; Mon, 26 Jun 2017 11:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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=bluepopcorn.net 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 DRYmTBW9EIoK for ; Mon, 26 Jun 2017 11:46:41 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 3CA9212EB3D for ; Mon, 26 Jun 2017 11:46:40 -0700 (PDT) Received: from splunge.local ([IPv6:2601:647:5500:1330:b890:b6b2:2e1:fc5d]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v5QIkcsD023910 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 26 Jun 2017 11:46:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1498502800; bh=+Q9JGkI+eZZDvUddzdE26+GnTMtgBc//i1jQqSqA/Kg=; h=Subject:To:References:From:Date:In-Reply-To; b=dUPD0OFKd/fNSIqylJqLV8FBP1qVqnhwkBfKjIDqkSt8uOov+0yI8oLm3KdI6cRyj SXQvwEMm+2lHwTXANvkmIjC3rKVLZEeSdqigdgWX4fcECpLf9KOAvWMiAUcHBIVefC PrKbIK9a2MF4FhnAmprzNrMu4O7TdzRD1Lds/uY0= To: dcrup@ietf.org References: <20170621163302.22286.qmail@ary.lan> From: Jim Fenton Message-ID: <3b00f065-4bda-2add-804d-c3ba60d76f53@bluepopcorn.net> Date: Mon, 26 Jun 2017 11:46:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170621163302.22286.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-02 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 18:46:43 -0000 On 6/21/17 9:33 AM, John Levine wrote: > In article <66bc2692-7807-9e5c-329d-77c2759d89f1@bluepopcorn.net> you w= rite: >> The verb "use" isn't precise enough because it doesn't specify whether= >> it refers to signing or verifying. >> >> I agree that the document should say ... > If you don't like what draft-ietf-dcrup-dkim-crypto-02 says, please sen= d text. Good idea. I'm changing the subject line because this is a general review rather than specific to that particular point. Section 3 paragraph 1: It might be a good idea to have a forward reference to Section 4 for "k=3Deddsafp" and rsafp since it hasn't been introduced yet. It might also be a good idea to make ABNF to optionally append "fp" or "-fp" to any of the signing algorithms since the use of fingerprints is orthogonal to the signing algorithm, in the same way that the choice of hash is. Section 4: - Is the algorithm used to hash the key always SHA-256, or should there be a tag for algorithm choice for that too? SHA-256 looks pretty good now, but who knows if that will change at some point. - Paragraph 1, since the hash and signature algorithms are orthogonal, suggest "Signing Algorithm is rsafp" and "Signing Algorithm is eddsafp". But also see above comment above about making the "fp" part independent. - After paragraph 1, there is an abrupt transition between k=3Drsafp or k=3Deddsafp and the next paragraph where k=3D contains the public key. It= should make it clear in the first paragraph that it is talking about the DNS record containing k=3Drsafp etc. and in the second case it is talking= about a new tag/value in the signature itself. - It appears that the only indication in a signature whether it is using keys or key fingerprints published in DNS is the presence or absence of a k=3D tag/value in the signature. Is that a good idea, or should there b= e something more explicit? Section 5: - Paragraph 2, rsafp-256 -> rsafp-sha256. Might also want to reinforce that signers MUST implement rsa-sha256. - I'm having trouble with all the use of "MUST NOT implement" in paragraph 2. We're concerned with what they actually use, not what their implementations are capable of (paragraph 3 is worded better). - My suggestion for paragraph 2: Signers MUST NOT use the sha1 hash algorithm in generating signatures. Verifiers MAY accept signatures generated using the sha1 hash algorithm, although the use of that algorithm is deprecated due to its known security weaknesses. Verifiers MUST be capable of verifying signatures generated using the sha256 hash algorithm. Verifiers MUST be capable of verifying the rsa, rsafp, eddsa, and eddsafp signature algorithms. Section 7: Since this is removing sha1 support, the security considerations should say something about that. -Jim From nobody Wed Jun 28 06:59:04 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C12129B2A for ; Wed, 28 Jun 2017 06:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com 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 0X6_LqMnNeXt for ; Wed, 28 Jun 2017 06:59:01 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33F3129B10 for ; Wed, 28 Jun 2017 06:59:00 -0700 (PDT) Received: (qmail 90867 invoked from network); 28 Jun 2017 13:58:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=162f1.5953b623.k1705; bh=c5NO7AZDlGKGjmKmArjtkXRPUNK0oOiLdSBqNy8aJH4=; b=PJCvwBEsRN0BNV2hqhhFjlULP5d/tqYpxGlwGF6JpV92B8jlMKaZ4DOyKNAdjG4bwRCqeOWhNeGcgrGCXugdrwzPm80yVSoqTy3nhixOtKOwxnf3fxTIVy3dLqjnhO17z5mY+XAAL8+QNKDpGTPVbZgaU8i2x68n6Bl350HPUUdLJy/EwdHVEXktqnbyjyxRnYn2ZSr8WFPdWTECMUdADv4jD5619qwaLmJ2p0VHPuTd/nNx+LPfJhUk6S3UV068 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 28 Jun 2017 13:58:59 -0000 Date: 28 Jun 2017 15:58:55 +0200 Message-ID: From: "John R. Levine" To: "Jim Fenton" Cc: dcrup@ietf.org In-Reply-To: <3b00f065-4bda-2add-804d-c3ba60d76f53@bluepopcorn.net> References: <20170621163302.22286.qmail@ary.lan><20170621163302.22286.qmail@ary.lan> <3b00f065-4bda-2add-804d-c3ba60d76f53@bluepopcorn.net> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-02 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 13:59:02 -0000 On Mon, 26 Jun 2017, Jim Fenton wrote: > Good idea. I'm changing the subject line because this is a general > review rather than specific to that particular point. Thanks, will take another whack at it when time permits. > Section 3 paragraph 1: It might be a good idea to have a forward > reference to Section 4 for "k=eddsafp" and rsafp since it hasn't been > introduced yet. Sure. > It might also be a good idea to make ABNF to optionally > append "fp" or "-fp" to any of the signing algorithms since the use of > fingerprints is orthogonal to the signing algorithm, in the same way > that the choice of hash is. I don't see what problem this solves. If we add new algorithms we'll need a new draft, and we can decide whether to add fp versions. It also occurs to me that eddsafp offers no benefit relative to eddsa since the key fingerprint is longer than the key, so I'm thinking the fingerprint option should only be for RSA. That's one less signature variant to implement and test. > Section 4: > > - Is the algorithm used to hash the key always SHA-256, or should there > be a tag for algorithm choice for that too? SHA-256 looks pretty good > now, but who knows if that will change at some point. Same thing, if we need to change we'll have a draft that adds whatever we need to add. If we add new key hashes, backward compatibility will mean that an unspecified hash is SHA-256, just like a missing k= means the algorithm is RSA. Or by the time SHA-256 is too weak, maybe everone will have moved to eddsa and we just deprecate RSA signatures, with or without key hashes. > - After paragraph 1, there is an abrupt transition between k=rsafp or > k=eddsafp and the next paragraph where k= contains the public key. It > should make it clear in the first paragraph that it is talking about the > DNS record containing k=rsafp etc. and in the second case it is talking > about a new tag/value in the signature itself. OK. > - It appears that the only indication in a signature whether it is using > keys or key fingerprints published in DNS is the presence or absence of > a k= tag/value in the signature. Is that a good idea, or should there be > something more explicit? It'll also say a=rsafp-sha256 rather than a=rsa-sha256. > - My suggestion for paragraph 2: > > Signers MUST NOT use the sha1 hash algorithm in generating signatures. > Verifiers MAY accept signatures generated using the sha1 hash algorithm, > although the use of that algorithm is deprecated due to its known > security weaknesses. Verifiers MUST be capable of verifying signatures > generated using the sha256 hash algorithm. Verifiers MUST be capable of > verifying the rsa, rsafp, eddsa, and eddsafp signature algorithms. I'm OK with MUST NOT use rather than MUST NOT implement, but for interoperability I think verifiers SHOULD NOT implement sha1 or maybe SHOULD NOT accept is correct. SHOULD NOT means don't do it unless you understand the consequences which seems right. > Section 7: > > Since this is removing sha1 support, the security considerations should > say something about that. Good point. This elucidates the SHOULD NOT above. R's, John