From nobody Sat Jul 1 18:17:05 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 DAD3D126C25; Sat, 1 Jul 2017 18:17:03 -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: <149895822385.17234.3769626520997443267@ietfa.amsl.com> Date: Sat, 01 Jul 2017 18:17:03 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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: Sun, 02 Jul 2017 01:17:04 -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-03.txt Pages : 7 Date : 2017-07-01 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-03 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 Sat Jul 1 19:18: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 8F1DE129B06 for ; Sat, 1 Jul 2017 19:18:03 -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 (1536-bit key) header.d=iecc.com header.b=um19NS7/; dkim=pass (1536-bit key) header.d=taugh.com header.b=rawDsUEg 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 S9BVBD_cBuiC for ; Sat, 1 Jul 2017 19:18:02 -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 D1C79124C27 for ; Sat, 1 Jul 2017 19:18:01 -0700 (PDT) Received: (qmail 88087 invoked from network); 2 Jul 2017 02:18:00 -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=15812.595857d8.k1707; bh=MWPaTiZP2fBgDXK6J2tbDca+Xi++rZvZq4IVEuAIpL4=; b=um19NS7/4oeSfO2hkibdUUd6aVaID5+GkYLo2DnmNLuO/P727pFuN1sYmnPT3C/GBOUK5RrB67tcmbx4xs5DY+Du7IILQSlv3ufml+hacGaillZ/XJkOrMfCS9OPE3BQe5sG57JeCpXW5rDyK0nXLYZ/+gDP2kD3QGV1o9sCyPNP0bH54BySRLFbHEHjEm1kS+e9KXqmtYIAbH9ZQkPtxEwtqW6YKQj0/dmI05QJHBK2IRQgBcpluuYlVIqAY438 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=15812.595857d8.k1707; bh=MWPaTiZP2fBgDXK6J2tbDca+Xi++rZvZq4IVEuAIpL4=; b=rawDsUEg/Z30ToQI3o2temHtzsMRyCjvS/QMEviIO36I9MkSA2e4hf9b17uRqKsja6g1K1IDbWjHcflbVAsISkGhLQ/GvBZzhirWmZobkwLGULCOYMdAYWEeTKM6NF1wtsjvD4ACw3cqnVXmYI5qEqxRdb1dA0e/uc9a35GpP/MFeH0hXyPN/XhxJnVjaCuE11vWTWqpbN16uSXD2Wg0dIdUfCPaDOIxEMpu3bwhKDWVzY8T2aOByOv8bToDk8Hj 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; 02 Jul 2017 02:18:00 -0000 Date: 1 Jul 2017 22:17:59 -0400 Message-ID: From: "John R Levine" To: dcrup@ietf.org In-Reply-To: <149895822385.17234.3769626520997443267@ietfa.amsl.com> References: <149895822385.17234.3769626520997443267@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-03.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, 02 Jul 2017 02:18:04 -0000 This version addresses Jim's comments, reorganizes the draft somewhat to put all the syntax changes in one place, and makes one significant change. SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints. Since an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, there's no point to eddsa fingerprints, so I took them out. If there is an actual problem that eddsa fingerprints would solve ("symmetry" isn't a problem), let me know. Otherwise I'll leave them out since we now have less code to write and verify. R's, John From nobody Sat Jul 1 19:41: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 ABAA4128B8F for ; Sat, 1 Jul 2017 19:41:53 -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 7MLQla8-E-Nh for ; Sat, 1 Jul 2017 19:41:51 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 BA5FE12702E for ; Sat, 1 Jul 2017 19:41:51 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so61121313ywr.0 for ; Sat, 01 Jul 2017 19:41:51 -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=l5zcgY4P8doFD1SIpRjTTR7JZQ71g+aktRW+BydDfhc=; b=rCOx1hUXy8quOVxTSygxqUv5NOTJX3M8tPTXcYtR67MoJoy2UI7s35UNwIrpnevyux sMA0D1ywcKw0puV5KKserPwJ3m+ARlzbGQjCW4x0a3ifarxxn8wtVjL81ufuQlWdk8SI fc9Mpyhhpkt0CjvM/VK4kcZGiyoNBF7n/MMnMAW5ApKzmEhh/zLDxgB9glvuqWpQuBMD N0Jm/ujAAKPRGngO7BQtOu2o9kKDWwQJSfZy2oPdaxqx63VZdAfrTgBqLFxIitENRCEe IxoUIJCkh29qcxP4Y1aHVccVhtWsDk5/zX2OuFI9k8plYO8Xb8ihDBdZRTDokBwq8KeM Q4sg== 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=l5zcgY4P8doFD1SIpRjTTR7JZQ71g+aktRW+BydDfhc=; b=MJYPvWnmW2lNFgaUOd1EzOdMSTmoP6cNGoUT9lW8oBv2ohDGm/SeuKGHA8RliVNYln /YTfIbYqUTq0CzoseSKVBr+cKKV2a2Yt3bkVZN/0CTTn/4jaIa0tPlY1tIWznLrkl+pK Gai1cNtgFqP4liwmad3bJv9f9k+VuYFmeZPUZl3BAAyVfq56DwoXaKuGvLvnq0xKXmUv yR4GaXDuQwBjmQu2WnPSwoH7+zkHsMlZOAw5vKT+xMyp2npVGItq8BnIR4sTTopW/gGk 8D1HIUs+PspMYVKJEgsj9xk8QU32Erv+ezh3dZeErO0g5vEayAdVdgBaZIrRGlVsdt4O vzPw== X-Gm-Message-State: AKS2vOzXUFa5boR527zenVsiYokQ9URmtJLhLmcZZghAVaA3zTdPTYon eHADxjB4mVWK8opSJQJ5BYsjKV3BQaHyQZA= X-Received: by 10.129.146.15 with SMTP id j15mr21443384ywg.283.1498963311067; Sat, 01 Jul 2017 19:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 19:41:10 -0700 (PDT) In-Reply-To: References: <149895822385.17234.3769626520997443267@ietfa.amsl.com> From: Eric Rescorla Date: Sat, 1 Jul 2017 19:41:10 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c094216b0206c05534c97eb" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 02:41:54 -0000 --94eb2c094216b0206c05534c97eb Content-Type: text/plain; charset="UTF-8" On Sat, Jul 1, 2017 at 7:17 PM, John R Levine wrote: > This version addresses Jim's comments, reorganizes the draft somewhat to > put all the syntax changes in one place, and makes one significant change. > > SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints. Since > an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, > there's no point to eddsa fingerprints, so I took them out. > > If there is an actual problem that eddsa fingerprints would solve > ("symmetry" isn't a problem), let me know. Well, actually the value at hand here is consistency, not "symmetry". In any case, it's not true that eddsa keys are 256 bits. Eddsa keys are 256 bits when you are using X25519 but not when you are using X448. To the extent to which you believe that it's redundant to have both non-FP and FP variants, the answer is to *always* use a fingerprint. -Ekr Otherwise I'll leave them out since we now have less code to write and > verify. > > R's, > John > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c094216b0206c05534c97eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Jul 1, 2017 at 7:17 PM, John R Levine <johnl@taugh.com> wr= ote:
This version addresses Jim's com= ments, reorganizes the draft somewhat to put all the syntax changes in one = place, and makes one significant change.

SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints.=C2=A0 Sin= ce an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, th= ere's no point to eddsa fingerprints, so I took them out.

If there is an actual problem that eddsa fingerprints would solve ("sy= mmetry" isn't a problem), let me know.=C2=A0

=
Well, actually the value at hand here is consistency, not "= symmetry".

In any case, =C2=A0it's not tr= ue that eddsa keys are 256 bits. Eddsa keys are 256 bits when you are using= X25519 but not when you are using X448. To the extent to which you believe= that it's redundant to have both non-FP and FP variants, the answer is= to *always* use a fingerprint.

-Ekr

Otherwise I'll le= ave them out since we now have less code to write and verify.

R's,
John


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

--94eb2c094216b0206c05534c97eb-- From nobody Sat Jul 1 19:57: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 A2A85128B8F for ; Sat, 1 Jul 2017 19:57:14 -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 ni1fbtYLV2pm for ; Sat, 1 Jul 2017 19:57:13 -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 4F6F4126B7F for ; Sat, 1 Jul 2017 19:57:13 -0700 (PDT) Received: (qmail 91139 invoked from network); 2 Jul 2017 02:57:12 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 Jul 2017 02:57:12 -0000 Date: 2 Jul 2017 02:56:50 -0000 Message-ID: <20170702025650.55902.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: ekr@rtfm.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-crypto-03.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, 02 Jul 2017 02:57:15 -0000 In article you write: >In any case, it's not true that eddsa keys are 256 bits. Eddsa keys are >256 bits when you are using X25519 but not when you are using X448. To the >extent to which you believe that it's redundant to have both non-FP and FP >variants, the answer is to *always* use a fingerprint. The only eddsa algorithm we're adding is ed25519. The point of the fingerprints was to make it easier to use long RSA keys. We're stuck with unfingerprinted RSA keys because they're what we have now. R's, John From nobody Sat Jul 1 20:35: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 3AC79127337 for ; Sat, 1 Jul 2017 20:35:43 -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 rEQFsq-kvMBM for ; Sat, 1 Jul 2017 20:35:41 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002: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 4E31F12708C for ; Sat, 1 Jul 2017 20:35:41 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id 63so61266450ywr.0 for ; Sat, 01 Jul 2017 20:35:41 -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=CRbOlQ8JkmN855SZLaL7yuoM4nYfeaSBHVdizLShBCE=; b=Rui3D1aeF6Ex3KXxaFtYkn/1dUfIIf7VmdpE1N//sh+9t3nVBRJWm44BSFmRsLIZ6N plb/qD0KhpO2VbsBjWdFmSlj2QnbZ8J6U/DxCEw+cknNmBUjnYBVw+tIb6KUE44uluVE Slbj6mJKejdj7+1pf8qSZRgBw4QNz2UBVKjoUqt6aReTPrLiT2zvQhF2EUimeyNEvEqX N0aKJgburneVbqsHGqylwsv4RTrO3P1/FIWk0jLZ1iLSyKfTzMS7bWP5DpFOYPht8Q/R PkX3yZ3/UB7DzTWfvx8GfpNe5LH67tIDx96dfynn8T2ACLNHAYzaFL4EMaKneZlFvgRV m7Xw== 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=CRbOlQ8JkmN855SZLaL7yuoM4nYfeaSBHVdizLShBCE=; b=mFlp5y0gErKZlRFKRycvta7MokW2qMcuHBaKXJIvMFiYsBb/QBchZYKk9dZetKKeht 5Pm49oFj5ks15rYx8+NnglWV83RbEpQk6fQNMuNLLBwPXw79tJIjTi4nlQ1R5uXrMeH2 8fZN3YhJI5Q1+SgX6Z6sORhv7/rgGQAFYcT8pKnccwxqu+9RIW47A8QggC266pz3wEDD h9Rg2izhTDtiGgWdrJj+q7TW99kM4kk3Mk3/uoT5LopoOKi16YSEn0Kdj542ebIADLBK pW+5RxH6gl75GP0MSf/VGoxwcpQk+4TkRms/Re6Xs2u9pQtv0E80x2NUlDvM8/+GUqv+ 4/ZA== X-Gm-Message-State: AKS2vOw1Dnt56k1NSzzlEI8Bk5CK6LrxaDLVvcc5c/brnKs5V4DDIM65 9nbSiBbirWLpLKKjZH6NOscJ1pTHvLvPWa8= X-Received: by 10.129.71.213 with SMTP id u204mr22646376ywa.270.1498966540571; Sat, 01 Jul 2017 20:35:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 1 Jul 2017 20:35:00 -0700 (PDT) In-Reply-To: <20170702025650.55902.qmail@ary.lan> References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sat, 1 Jul 2017 20:35:00 -0700 Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114c6ec02ede3f05534d5804" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 03:35:43 -0000 --001a114c6ec02ede3f05534d5804 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 1, 2017 at 7:56 PM, John Levine wrote: > In article gmail.com> you write: > >In any case, it's not true that eddsa keys are 256 bits. Eddsa keys are > >256 bits when you are using X25519 but not when you are using X448. To the > >extent to which you believe that it's redundant to have both non-FP and FP > >variants, the answer is to *always* use a fingerprint. > > The only eddsa algorithm we're adding is ed25519. > Right now yes, but I'm interested in thinking past this document. The point of the fingerprints was to make it easier to use long RSA keys. That may have been your point, but when I suggested it, my objective was to future proof the protocol against other algorithms with larger keys as well. > We're > stuck with unfingerprinted RSA keys because they're what we have now. > Yes, but that doesn't mean we need to continue that trend for future algorithms. -Ekr > > R's, > John > --001a114c6ec02ede3f05534d5804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 1, 2017 at 7:56 PM, John Levine <johnl@taugh.com> wrote:
In article &l= t;CABcZeBOs1yZ7q3oBgNeVkw=3DzSQb_SuS4hqK8BH0ebrD5LRYTFg@mail.gmail.com>= you write:
>In any case,=C2=A0 it's not true that eddsa keys are 256 bits. Edds= a keys are
>256 bits when you are using X25519 but not when you are using X448. To = the
>extent to which you believe that it's redundant to have both non-FP= and FP
>variants, the answer is to *always* use a fingerprint.

The only eddsa algorithm we're adding is ed25519.

Right now yes, but I'm interested in thinking pas= t this document.


The point of the fingerprints was to make it easier to use long RSA keys.

That may have been your point, but when I su= ggested it, my objective was to
future proof the protocol against= other algorithms with larger keys as well.

=C2=A0=
=C2=A0 We're
stuck with unfingerprinted RSA keys because they're what we have now.

Yes, but that doesn't mean we need t= o continue that trend for future
algorithms.

=
-Ekr
=C2=A0

R's,
John

--001a114c6ec02ede3f05534d5804-- From nobody Sat Jul 1 20:41: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 EFD21129B1A for ; Sat, 1 Jul 2017 20:41:48 -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 (1536-bit key) header.d=iecc.com header.b=j6TWAGXL; dkim=pass (1536-bit key) header.d=taugh.com header.b=auhNyYnI 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 u_VcvBv-NyN1 for ; Sat, 1 Jul 2017 20:41:47 -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 387791200C5 for ; Sat, 1 Jul 2017 20:41:47 -0700 (PDT) Received: (qmail 93891 invoked from network); 2 Jul 2017 03:41:46 -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=16ec1.59586b7a.k1707; bh=Hy6/NFLcNMFAEi04rsQ5K3yYZwAyEWlQu3yXlMKfrVA=; b=j6TWAGXLLeiKNK17O2muFh/w0Frnv39NeuLxmn35GYQX7BM/OfreQ92dp2P8FxJEaoqpVw2lUvHKNonsPsq9xUEIwZ3z4rljQQ2i1onKgTF8cAJDozpHYoYjtbXHj1OmC3nTUnz4nH7RUYCzxLdV885Y7d/VTkhmzLSq1bSqok/NnkuuD9GSgiCsIMVKidzYFsr7XeyEZmknImrtveDJeHig7sSWmup+giSF5kVBxx7iYZ4wy8Qh3Az1dtkPlm8B 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=16ec1.59586b7a.k1707; bh=Hy6/NFLcNMFAEi04rsQ5K3yYZwAyEWlQu3yXlMKfrVA=; b=auhNyYnICgdVyXbGhILJqhShnyc8ApqE1E4aR0T8vsTpteFZ61h5MZCaY0+sQiNh6z2v5IU5n7MRW3CDcbQrOMk2Z3vXsP32Z1C0jSBwj/UZCaER/VKPbYb9z7xb8hfsO8hwmdLQ77A9/4rYfVkqQ/VRc1LukkVkQdHFpDUiVQ9C0U6+HaDs+fldSfTC7sVxdQHVTaOuQ1ext0sKMrtuf+EAESRpRbt9ZPXK+oJlmm7dTUEZbZQNI2lQq9lKitQo 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; 02 Jul 2017 03:41:45 -0000 Date: 1 Jul 2017 23:41:45 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170702025650.55902.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] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 03:41:49 -0000 > The point of the fingerprints was to make it easier to use long RSA keys. > > That may have been your point, but when I suggested it, my objective was to > future proof the protocol against other algorithms with larger keys as well. I'm wondering how likely that is. 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 Jul 2 08:15:31 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 A3CDA12EC47 for ; Sun, 2 Jul 2017 08:15:29 -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=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 cVdagcOnjXnk for ; Sun, 2 Jul 2017 08:15:28 -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 2B57D12EC3E for ; Sun, 2 Jul 2017 08:15:28 -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 v62FERG0023511; Sun, 2 Jul 2017 16:15: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 : mime-version; s=jan2016.eng; bh=CdeU9014BIw618NDKIX9hmQGSfBg6wWKgiXgurGYMbI=; b=BK69PakuLYZW5aMLZ3oUXhyHqv1IkHk4sl4FRk6hpamiRJE2m3tX/jTnWKbXzcv57qNr ddCSPH7u601S3LkzFTGp8IV0d44R+GIrvtxrTSdYk8ev9xzVDifpLgWtiMHI0HUOVhRl SgIwu1zOEA9KXUcoXYaxtGdCxOhcvNE0cv8C9JNA00BaRH+iZIZJOjP3UMWsJQ2oRPO6 lpTZEaMFNn4CNqr9lEecelvEXCPrdhhlEeuXMgyJmPhcw64Y7c84i+u7n2T5+z5YChhO /DzuORrQBZSmuSUtVpI0KsWq+G2amWbKYsfd2Rfs638Fh3kqNS2MPyxeDwkeC+69Y9mt pQ== 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 2be39450xg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 16:15:26 +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 v62FB6Y9023916; Sun, 2 Jul 2017 11:15:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2be72u2j73-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 11:15:25 -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, 2 Jul 2017 11:15:24 -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, 2 Jul 2017 11:15:24 -0400 From: "Salz, Rich" To: Eric Rescorla , John Levine CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt Thread-Index: AQHS8tDsZumR14DzNUaGCSGU4BHMIaJAEEWAgAAGegCAAARhAIAACqoAgACAfxA= Date: Sun, 2 Jul 2017 15:15:23 +0000 Message-ID: <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170702025650.55902.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.43.110] Content-Type: multipart/alternative; boundary="_000_388acdd7731b45b797fde389bdb92681usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_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-1707020262 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707020262 Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 15:15:30 -0000 --_000_388acdd7731b45b797fde389bdb92681usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSB0aGUga2V5IHR5cGUsIGNhbuKAmXQgb25lIGluZmVyIGlmIGl04oCZcyBhIGhhc2ggb3Ig dGhlIGFjdHVhbCBrZXk/ICBJIHRoaW5rIGF2b2lkaW5nIHRoZSBpbmRpcmVjdGlvbiBjYW4gYmUg dXNlZnVsLg0K --_000_388acdd7731b45b797fde389bdb92681usma1exdag1mb1msgcorpak_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb20gdGhlIGtleSB0eXBlLCBjYW7igJl0IG9uZSBpbmZl ciBpZiBpdOKAmXMgYSBoYXNoIG9yIHRoZSBhY3R1YWwga2V5PyZuYnNwOyBJIHRoaW5rIGF2b2lk aW5nIHRoZSBpbmRpcmVjdGlvbiBjYW4gYmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_388acdd7731b45b797fde389bdb92681usma1exdag1mb1msgcorpak_-- From nobody Sun Jul 2 08:33: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 CEEB5126CD8 for ; Sun, 2 Jul 2017 08:33:22 -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 (1536-bit key) header.d=iecc.com header.b=Qhxtj6Tw; dkim=pass (1536-bit key) header.d=taugh.com header.b=Jt1wwqH9 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 VUuyxVIEW3Qt for ; Sun, 2 Jul 2017 08:33:21 -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 EAFAD1204DA for ; Sun, 2 Jul 2017 08:33:20 -0700 (PDT) Received: (qmail 70370 invoked from network); 2 Jul 2017 15:33:19 -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=112e0.5959123f.k1707; bh=iGZQn1mHbl8vXSvjA/WopUr1pT48iDuICEJissnNBL0=; b=Qhxtj6TwoUdWGWo2lg9mik6A3hjT14gqhVxnhUibVm1XDtszzWQ8BnO/kKh6wwQDU5A+C8AyGk3ObGCLDaMJRI8NJFkNhG080WaFIUkZV0u7uUViABOsWq91QK/PyLRbrju6NRNDfaQREsRZjbsjnNTymB2jpX0WD+NzKbwbhIuZvGgbvApxGnHIPOp3QJIGJx/RU372oNFJAqWIJ6V2ZT48a8uYY/LH0f5mYxSz53K7TispHTn+CvU69UzHZ2Gt 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=112e0.5959123f.k1707; bh=iGZQn1mHbl8vXSvjA/WopUr1pT48iDuICEJissnNBL0=; b=Jt1wwqH9EXg7jIw9YO8EemAYkcZJOVd1aOMFltthf3x7hg9u3WDrhvPa3vywO7B+GqYIuoteamJlQn8pOHphM0OdP2tzBbj2AKRGRmMljO40ns5qthbK5vl3UGRNq4iu2C7g+Hymzqjk1d8ShHH+WP5zDXuakOoidhwesQ3sYoqnPAdMmr54YaGYkXEsYmSZ3fiUTPaH96Vnw96nglwtJ8NX77zxGTSo7nTzB7eZlk32gLaVXp9SxX50ADraKhEE 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; 02 Jul 2017 15:33:19 -0000 Date: 2 Jul 2017 11:33:19 -0400 Message-ID: From: "John R Levine" To: "Salz, Rich" Cc: "dcrup@ietf.org" In-Reply-To: <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170702025650.55902.qmail@ary.lan> <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-576072389-1499009599=:72389" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 15:33:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-576072389-1499009599=:72389 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > From the key type, can’t one infer if it’s a hash or the actual key? I think avoiding the indirection can be useful. It's in the algorithm type -- an RSA key is rsa, RSA key fingerprint is rsafp. In the signature, the a= algorithm tag also includes the message hash algorithm so it's a=rsa-sha256 or a=rsafp-sha256 or a=eddsa-sha256, with no default. In the key record, the k= key tag is k=rsa or k=rsafp or k=eddsa, with the default being rsa for backward compatibility. The previous draft also had eddsafp. I took it out since the point of the hash is to make the key records smaller, but for eddsa the hash is the same size as the key. I suppose it's possible that in the distant future we'll find some problem with both rsa and ed25519 so that we'll need to add yet another signature algorithm and that algorithm will have keys big enough (more than 1100 bits) to make hashes attractive, but that seems speculative in the extreme and we'd need to do another revision of the DKIM spec and code anyway. To me it seems more likely that ed25519 is good enough that it'll last until we deprecate all of DKIM in favor of something different. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-576072389-1499009599=:72389-- From nobody Sun Jul 2 08:44: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 BD45B1277BB for ; Sun, 2 Jul 2017 08:44:09 -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_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 yIGf2j9a0guf for ; Sun, 2 Jul 2017 08:44:08 -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 668BD1204DA for ; Sun, 2 Jul 2017 08:44:08 -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 v62Fgkc0019239; Sun, 2 Jul 2017 16:44:06 +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=0roMlTr2hBahQmIKXD/xAfWK8dh3913nPlsVB2fm6gU=; b=ITyFHm+JzzpR68ERKI6e/6oSQ04qnhA/5fePhnL5A6725DGfQU0PWtMh+DBUNznUV2HV M/rJ3ZFdOblym1gdfDh9CGFyRTr1xvlMwDxZewJJ6g2XF5Hy/Q9NIC73WzSJWhrNy+Gp njDqqrqBa+PgnRKJd4E6OZxQRfhoF3w7X3PoxGbH4aWM0kaUUBI4Ei2tTIS566Qjv2Ml zbJbivUvuMfjERyKNRubcA3dczX8NddX8MA2SY+POfRuwdc7BnelNCGcDAGsx7r46Xot sn8cbOwEdhmMDKqgibfLuYMEjWLD1xZbHI1+zeXGqDq04zMF/7N8fflml1hhSVD65SCy qw== 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 2be30pw44n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 16:44:06 +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 v62Ffw3h027381; Sun, 2 Jul 2017 11:44:04 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72u2jtx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 11:44:04 -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; Sun, 2 Jul 2017 11:44:03 -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, 2 Jul 2017 11:44:03 -0400 From: "Salz, Rich" To: John R Levine CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt Thread-Index: AQHS8tDsZumR14DzNUaGCSGU4BHMIaJAEEWAgAAGegCAAARhAIAACqoAgACAfxCAAEgzgP//v8rQ Date: Sun, 2 Jul 2017 15:44:02 +0000 Message-ID: References: <20170702025650.55902.qmail@ary.lan> <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> 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.43.110] 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-07-02_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-1707020270 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707020270 Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 15:44:10 -0000 PiBUbyBtZSBpdCBzZWVtcyBtb3JlIGxpa2VseSB0aGF0IGVkMjU1MTkgaXMgZ29vZCBlbm91Z2gg dGhhdCBpdCdsbCBsYXN0IHVudGlsIHdlDQo+IGRlcHJlY2F0ZSBhbGwgb2YgREtJTSBpbiBmYXZv ciBvZiBzb21ldGhpbmcgZGlmZmVyZW50Lg0KDQpBcyBhbiBpbmRpdmlkdWFsLCBJIHRoaW5rIHRo aXMgaXMgcmVhc29uYWJsZS4NCg0KQXMgY28tY2hhaXIsIGRvZXMgYW55b25lIGluIHRoZSBXRyBk aXNhZ3JlZT8NCg== From nobody Sun Jul 2 12:17: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 EF39D126B72 for ; Sun, 2 Jul 2017 12:17:38 -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 p4Gdv5xQETKd for ; Sun, 2 Jul 2017 12:17:37 -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 F03C7124234 for ; Sun, 2 Jul 2017 12:17:36 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id e201so50112381ybb.1 for ; Sun, 02 Jul 2017 12:17:36 -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=uJ1rvTq1CdKpcdev4ojJVlOZu2U2e4EfiAcKvw1Smy4=; b=h759n+CvXCIg+m1KgYjHOIIYRr0aeorXIRddOsVftvRny7youGaA5rScUFS/ZqD8lw DVzYbksh2gGoXfxx8vioGmqYRcQ9tiezM2sWwD0ZtkDoLd9ixvaAx7e3nj/WTHMwBLv7 PbE1P1Vh2hx//Z16Jrh2vSOfm+89PaBxlmxUCnREQakW3LZFPd4skKeNDcTEYJFlzpG6 hXtImN22Z7rgV9hdPEnnnfxJkUIE4VrqokezzJc86DNOTWYlYeVrGs638hBJfnuIvM5B Ygj3ve7AcT1b3E1SzMlMFLsRXYYQFoTcSVPinLY2vogJ13m7PgGR2Cs1lIS5DCUWNp8r edUQ== 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=uJ1rvTq1CdKpcdev4ojJVlOZu2U2e4EfiAcKvw1Smy4=; b=tDVFsyNimBXuzmDg9ZEcPWGX0DFXbVGXTah0q00G1Vi1Dp6ZAHLNTjPe+7DwmS256y pR8cmJdcSbkhYrVegw5ziccUykiEM+UcVtZsTT/LBWSv8zVgpvMumndl+cUZOqtKuPMJ A2ol074IUmwzNJzlDHUDc2leLE0rWSbrbbUv/U9tFZCXV8ReTQ0ortx4bXEKL0G7Re04 c90Y+c+pjVntpsj90r37OZRuGPq6VteGr/b8lq5o9CU+s9OYzrPXNvtRYHWOiHY9CPgV 2hrjyC/yUbY0Dbjwl/OWTrYxgJdlDbhrVw9dAHj4DU6Giki1RY3HxL64hg7lz3t3uSQf /fnA== X-Gm-Message-State: AKS2vOzZyfTypiCvF2ZacnOZEVNmYBGD6r1PGzi+UHbIECAYDzk4KCqR Nq54nhOfzVGeVmp1snI0OirK3Y+7pCXp X-Received: by 10.37.162.104 with SMTP id b95mr25311827ybi.29.1499023056200; Sun, 02 Jul 2017 12:17:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 12:16:55 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Sun, 2 Jul 2017 12:16:55 -0700 Message-ID: To: "Salz, Rich" Cc: John R Levine , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19fcf8c67f4605535a802a" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 19:17:39 -0000 --94eb2c19fcf8c67f4605535a802a Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 8:44 AM, Salz, Rich wrote: > > To me it seems more likely that ed25519 is good enough that it'll last > until we > > deprecate all of DKIM in favor of something different. > > As an individual, I think this is reasonable. > > As co-chair, does anyone in the WG disagree? > I don't agree that we should design to this assumption. -Ekr > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c19fcf8c67f4605535a802a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 8:44 AM, Salz, Rich <rsalz@akamai.com> wrote:
> To me i= t seems more likely that ed25519 is good enough that it'll last until w= e
> deprecate all of DKIM in favor of something different.

As an individual, I think this is reasonable.

As co-chair, does anyone in the WG disagree?

I don't agree that we should design to this assumption.

-Ekr
=C2=A0
______________________________= _________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--94eb2c19fcf8c67f4605535a802a-- From nobody Sun Jul 2 12:18: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 99B89126DED for ; Sun, 2 Jul 2017 12:18:52 -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 Dax6_VANKHB2 for ; Sun, 2 Jul 2017 12:18:51 -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 C9D81124234 for ; Sun, 2 Jul 2017 12:18:50 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id s15so15952560ybe.2 for ; Sun, 02 Jul 2017 12:18:50 -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=rKriKGOAJRED9lgmhksOwnPeUvcWdqLn2ROks8tXUAk=; b=HPmlYfwjkGaHGGSe8hOkVHGwpTMpfFSZ2LEiN6IGaK3DmqIIasfhhrJBzUuKluMfW1 RkACr3M4pfzHax+4h4LeWsTEmA1kYHRL6WpxsYe1j3QiFuwTKpn5MVQAkHHv23MJzB4y FtIrysPaopr96rSTpHH44uyiKp5dgoXXVBtUB5X/qfjE0miBAKYIeL22aopc5yWywJ12 kVkB5Lry/k4NqeBUqRP2u3Ktr5WXk41jcb5V/hTki4MJgAgyCwXx/sSuZVzJSFaSFMM4 bRREfz1lUl3v3ROfNK3bWrN3fM74BMk3ofaOw86fewe4jEn7h1+ohD/Tl04Rlf3T4t61 K9UA== 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=rKriKGOAJRED9lgmhksOwnPeUvcWdqLn2ROks8tXUAk=; b=B6CMk04VFTXE4B1GddzBrkrPiuO5Byn4VrDTvgDD2cDacWASQ97ZqLFSl3lXG0pyde 3CaDWjR/ASuQHCVzLc3mss6CvAHRHwXEBlzAPrzVhXePb24iwuevRMKXanf8urYLWe8n M4bLcAAQ+rYCQl8QIR4C0QHqH5HFunfnr7Tp5Rf9K4ffhpRuvoTKWSmG0fJbajW2quAt g1XnZzHvnt3PYRYg/zsJe9d8gWbpZsE47K5kX9pFXtTDk+bX3MbG3SnevOsKwaGENAGv QNVht98cm/T+lfHRJcGqDJVBxh4z2h/fesZxPV3miBUI6/5nxcRaH0mR5h4FPYG07myd GqCA== X-Gm-Message-State: AKS2vOw4mjcYHfMmEJAgpZWHvZ/gsw7rAXsmqog/i7wm3U5lzlB/QWUo XaVHY75fDvQdYiSpi4hLyiGU0jjMVq59 X-Received: by 10.37.48.67 with SMTP id w64mr24702901ybw.89.1499023130166; Sun, 02 Jul 2017 12:18:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 12:18:09 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sun, 2 Jul 2017 12:18:09 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114899c42f1c2f05535a856b" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 19:18:53 -0000 --001a114899c42f1c2f05535a856b Content-Type: text/plain; charset="UTF-8" On Sat, Jul 1, 2017 at 8:41 PM, John R Levine wrote: > The point of the fingerprints was to make it easier to use long RSA keys. >> >> That may have been your point, but when I suggested it, my objective was >> to >> future proof the protocol against other algorithms with larger keys as >> well. >> > > I'm wondering how likely that is. > Given that (a) we already have algorithms that are bigger and (b) post-quantum keys might be quite a bit bigger, it seems unwise to design under the assumption that it will not happen. -Ekr > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --001a114899c42f1c2f05535a856b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jul 1, 2017 at 8:41 PM, John R Levine <johnl@taugh.com> wrote:
The point of the fingerprints was to make it easier to use long RSA keys.
That may have been your point, but when I suggested it, my objective was to=
future proof the protocol against other algorithms with larger keys as well= .

 I'm wondering how likely that is.

G= iven that (a) we already have algorithms that are bigger and (b) post-quant= um keys
might be quite a bit bigger, it seems unwise to design un= der the assumption that it will
not happen.

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

--001a114899c42f1c2f05535a856b-- From nobody Sun Jul 2 12:53: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 E7C7D127137 for ; Sun, 2 Jul 2017 12:53:21 -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 (1536-bit key) header.d=iecc.com header.b=3GoMMSfU; dkim=pass (1536-bit key) header.d=taugh.com header.b=bLJGfsLB 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 WMx0U-wrVrHF for ; Sun, 2 Jul 2017 12:53:20 -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 22B5A1201F8 for ; Sun, 2 Jul 2017 12:53:19 -0700 (PDT) Received: (qmail 90628 invoked from network); 2 Jul 2017 19:53: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=16202.59594f2e.k1707; bh=RZ5f4vZdBpIBcxeurB/y0mFlDRtkYNw9TMSYuszVgHE=; b=3GoMMSfUxwhXgRCwHgHqrjLVDjfeL40QvJYVS16uDMhOXHdG1MaRIRnhUXUhBhsTXzvovXkxzGvPE2Z2uQXtOsQgFxkL2zCnwpqBjz4Et2R/JC20hxbvTiveJwL9fKl2LfI/bVVyJIbhUcNA9kqsPad9uCnNUUW+f92Kk+ioK7mHDg3cTTDzIELQsWH3MC/f3jTkFQBPbKngBv74KPUrlnZOka0WfJW/fhqScamJD0fmycUPZuo7V/ZplLh6BLgr 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=16202.59594f2e.k1707; bh=RZ5f4vZdBpIBcxeurB/y0mFlDRtkYNw9TMSYuszVgHE=; b=bLJGfsLBlJw3ZIi84MfHJ4SOUwiWu8rh0upQ0aHxHl4tk015q5IagODXQ3DtblZ8Yut1/7O1Pj/WoGqlPGkF9CTottmJlUu7t6oD2l+37W6BnSUp+7m8ypI/d4DO92KNayRzthftMquyOWx7HrZgRAE6weOxTc7reJ6C6xyCeC77Is1a3Nm8jBoFJ6L9ZM917vlqFyJExKHiRLeYZhHNfibNhdh2D+9blKEF18cqBJy+NF8C2mSPhWe78l0r0P95 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; 02 Jul 2017 19:53:18 -0000 Date: 2 Jul 2017 15:53:18 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170702025650.55902.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] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 19:53:22 -0000 > Given that (a) we already have algorithms that are bigger and (b) > post-quantum keys might be quite a bit bigger, it seems unwise to design > under the assumption that it will not happen. Well, OK, but concretely, what do you want us to do now? DKIM has had algorithm tags since it was defined a decade ago. This draft adds two new algorithm tags (rsafp-sha256 and eddsa-sha256) and deprecates one old one (rsa-sha1) and as part of that adds RSA key hashes as a key verification method. If it turns out that we need to switch signature algorithms, we'll revise DKIM again, and add and deprecate tags and algorithms as needed. Maybe new algorithms will use key hashes, maybe they won't, but at that point we can define whatever we need. Right now, today, I don't see that hasned ed25519 keys solve any problem, so I'm not going to include them unless there is something I don't understand that they can do that plain ed25519 keys in the key records don't. R's, John From nobody Sun Jul 2 13:00: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 5732D127B57 for ; Sun, 2 Jul 2017 13:00: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, 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 e7GW8_Z8GCkD for ; Sun, 2 Jul 2017 13:00:49 -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 E229F120454 for ; Sun, 2 Jul 2017 13:00:48 -0700 (PDT) Received: from [10.53.15.243] (mobile-166-170-30-35.mycingular.net [166.170.30.35]) (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 81F7EC401B8; Sun, 2 Jul 2017 15:00:46 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499025646; bh=qSeK2Kzofngv88XoFUzumuAmB4q7xL31iDmEZAGIXuA=; h=Date:In-Reply-To:References:Subject:To:From:From; b=AxK6jSVv0BAjeqesJ1Ylma45bPFgV32Od5otAu6lCacdRoeBrbRWN9lu37Skb5X+4 +zCtrZDUwKdp4rxiVn2EeTKDTlXBFQ4+taU5wmSQePazxx4Dz1zd9OgsWRGqW0x3bE 2O+B/MveZq7bof7QRKhzW/4OsZr3fsE4PnCDZhsc= Date: Sun, 02 Jul 2017 20:00:44 +0000 In-Reply-To: References: <20170702025650.55902.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: <54B05A3A-C142-4CB9-8DD7-2E303E1B1869@kitterman.com> Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 20:00:51 -0000 On July 2, 2017 3:53:18 PM EDT, John R Levine wrote: >> Given that (a) we already have algorithms that are bigger and (b)=20 >> post-quantum keys might be quite a bit bigger, it seems unwise to >design=20 >> under the assumption that it will not happen=2E > >Well, OK, but concretely, what do you want us to do now? > >DKIM has had algorithm tags since it was defined a decade ago=2E This >draft=20 >adds two new algorithm tags (rsafp-sha256 and eddsa-sha256) and >deprecates=20 >one old one (rsa-sha1) and as part of that adds RSA key hashes as a key > >verification method=2E If it turns out that we need to switch signature= =20 >algorithms, we'll revise DKIM again, and add and deprecate tags and=20 >algorithms as needed=2E Maybe new algorithms will use key hashes, maybe= =20 >they won't, but at that point we can define whatever we need=2E > >Right now, today, I don't see that hasned ed25519 keys solve any >problem,=20 >so I'm not going to include them unless there is something I don't=20 >understand that they can do that plain ed25519 keys in the key records=20 >don't=2E +1 Scott K From nobody Sun Jul 2 13:21: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 E86CA128D3E for ; Sun, 2 Jul 2017 13:21:12 -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 WV0bKZDDLiSc for ; Sun, 2 Jul 2017 13:21:09 -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 B5657129503 for ; Sun, 2 Jul 2017 13:21:09 -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 v62KGvMN018820; Sun, 2 Jul 2017 21:21:07 +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 : mime-version; s=jan2016.eng; bh=bZXAIwgTm7NWZrycRNgkUWA6YB1bf91L3L0mOUP7qfs=; b=A2IhrFULK4WUgKVQOsO82CGV4PzfDeXvAwzLWyogQBBtfewt+ugZ7kiAofyD/EJDNmNI 2hvluryaviCL4JWlHGR/R2M9DNkYs4cPkAMxxynCZ87nz+meN3lDPqQanm1Q7ww8WMln TjU9mfCXsLA5N10zAyRynTM/cs6+n9VaLIQfKBJjgz++w7XVLCIWPo4sRdihjs0HzFSj uwYDSICFoeZX6StdNEwbpT/IQHuNVXytGtVhXDTj/me4xtj5W4mAJ1sewh3TW0vp41j2 cV8gDbRhqgKe6MmkogiVie2C22+7wxRFmHr0T59lrMgk4ErdV1yQU925WN5qX1jLizMa MA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2be456dj7p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 21:21:07 +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 v62KKkkn023640; Sun, 2 Jul 2017 16:21:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2be72uuueq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 16:21:05 -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; Sun, 2 Jul 2017 16:21: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; Sun, 2 Jul 2017 16:21:04 -0400 From: "Salz, Rich" To: Eric Rescorla , John R Levine CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt Thread-Index: AQHS8tDsZumR14DzNUaGCSGU4BHMIaJAEEWAgAAGegCAAARhAIAACqoAgAAB4oCAAQWhgP//zlKw Date: Sun, 2 Jul 2017 20:21:04 +0000 Message-ID: <158ff29b0ff8494abb5703da76535a56@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170702025650.55902.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.43.110] Content-Type: multipart/alternative; boundary="_000_158ff29b0ff8494abb5703da76535a56usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_15:, , 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-1707020351 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_15:, , 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-1707020350 Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 20:21:13 -0000 --_000_158ff29b0ff8494abb5703da76535a56usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBwb3N0LXF1YW50dW0gY3J5cHRvIGlzIG91dCBvZiBzY29wZSwgYnV0IG1heWJlIEni gJltIGluIHRoZSByb3VnaC4NCg0K --_000_158ff29b0ff8494abb5703da76535a56usma1exdag1mb1msgcorpak_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgcG9zdC1xdWFudHVtIGNyeXB0byBpcyBvdXQg b2Ygc2NvcGUsIGJ1dCBtYXliZSBJ4oCZbSBpbiB0aGUgcm91Z2guPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_158ff29b0ff8494abb5703da76535a56usma1exdag1mb1msgcorpak_-- From nobody Sun Jul 2 13:23: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 47041129503 for ; Sun, 2 Jul 2017 13:23:31 -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_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 Sw7fM4Tt9oYJ for ; Sun, 2 Jul 2017 13:23:30 -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 EE29C127867 for ; Sun, 2 Jul 2017 13:23:29 -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 v62KM2eu005608; Sun, 2 Jul 2017 21:23:28 +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=cqb41wAfbspvXjF99XSPO9xtIRLmjCslpEQTNPdeOGM=; b=YUiSWwoqx2RMHUr3khOReOphDvsr8zuli+potxWNDNIwt7r6E5Ffq8Zw27mKh+JTQmHk uEdIHJamrBMaEwABW3c60ssY6jpSJlfZgRM1u4QhUHwokogfL/R1l8LxrxGgmJ58O1oA OYDm5xS+7k7kYwcVNAi1CmtJt9r1+1JGR0R4BObi6q+KrjfyVqo6sThFhn8QtAED9m3t RH0BFfM6NXB0zFU3kAZ0+gUDCUUOVaSp01UyoiMEpuSvDHJ4sBqwPXAMefT6PaHY3vjg lCZHaKVKB8vslsbto+1XxoGBNs14IEsJaoXiACXkMizZDtaeVeGMUBH7LsqxciQIX+Kc UQ== 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 2be3945p42-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 21:23:28 +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 v62KKqqo021321; Sun, 2 Jul 2017 16:23:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72u2wpk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 02 Jul 2017 16:23: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; Sun, 2 Jul 2017 16:23: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; Sun, 2 Jul 2017 16:23:26 -0400 From: "Salz, Rich" To: Eric Rescorla CC: John R Levine , "dcrup@ietf.org" Thread-Topic: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.txt Thread-Index: AQHS8tDsZumR14DzNUaGCSGU4BHMIaJAEEWAgAAGegCAAARhAIAACqoAgACAfxCAAEgzgP//v8rQgAB+r4D//88cAA== Date: Sun, 2 Jul 2017 20:23:25 +0000 Message-ID: References: <20170702025650.55902.qmail@ary.lan> <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> 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.43.110] 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-07-02_15:, , 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-1707020351 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_15:, , 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-1707020351 Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 20:23:31 -0000 Sm9obiBMZXZpbmU6DQoNCj4+IFRvIG1lIGl0IHNlZW1zIG1vcmUgbGlrZWx5IHRoYXQgZWQyNTUx OSBpcyBnb29kIGVub3VnaCB0aGF0IGl0J2xsIGxhc3QgdW50aWwgd2UNCj4+IGRlcHJlY2F0ZSBh bGwgb2YgREtJTSBpbiBmYXZvciBvZiBzb21ldGhpbmcgZGlmZmVyZW50Lg0KDQpBcyBhbiBpbmRp dmlkdWFsLCBJIHRoaW5rIHRoaXMgaXMgcmVhc29uYWJsZS4NCg0KTWU6DQoNCj5BcyBjby1jaGFp ciwgZG9lcyBhbnlvbmUgaW4gdGhlIFdHIGRpc2FncmVlPw0KDQpFa3INCg0KPiBJIGRvbid0IGFn cmVlIHRoYXQgd2Ugc2hvdWxkIGRlc2lnbiB0byB0aGlzIGFzc3VtcHRpb24uDQoNCg0KSSdkIGxp a2UgdG8ga25vdyB3aGF0IG90aGVyIG1lbWJlcnMgb2YgdGhlIFdHIHRoaW5rLiAgQXMgaXQncyBh IG1ham9yIGhvbGlkYXkgaW4gdGhlIFVTIGFuZCBhIHNob3J0IHdlZWssIEkgZXhwZWN0IHdlIHNo b3VsZCBwbGFuIG9uIGRpc2N1c3NpbmcgdGhpcyBpbiBQcmFndWUuDQoNCg== From nobody Sun Jul 2 13:58: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 2AF0B129AAD for ; Sun, 2 Jul 2017 13:58:44 -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 mlw5-tzAeTvL for ; Sun, 2 Jul 2017 13:58:42 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 6D666128B8F for ; Sun, 2 Jul 2017 13:58:42 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id l21so56263087ywb.1 for ; Sun, 02 Jul 2017 13:58: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=pcFypomPLWggrCozqndvG6Fzm96nlPdvKYRBEIGcZUg=; b=bmNP2XEeSJbaL+6PbxuT+QjYkVjth07iQ2UMT5Ez6toatFeBu7mfObDvrwWATiAJGm +e0kJGSEkJVqPKrOgCsL7Ft1kR6tzZgnQE7qYk+HdX/w0B4Ub4mXS5FgDdHA7oMIIsdA 6np768SqaQF/M7AEO75vR15lAXRfvJmCs6MYIbnG/FmBcnYUhExCFnScX0Nw5S1BcG09 b64ufgxHm6xfRCq/j2boCkMVVrrrQkb2kkpplqaGR86r0IfppRHJ9nbK8ldPbp61yw/H 3r2xZDfiaXf+nNbNwpCzrgUeaSssE1FYczjy0gEDEzgIHEN+8MZnXVKim0qW/V2U50Ml 1Hvg== 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=pcFypomPLWggrCozqndvG6Fzm96nlPdvKYRBEIGcZUg=; b=Wk1CRN2UPps7q06iLuNlybEWlaKhKCaR2bvWhheJNWmFif++8FWorPQO5t3jYlWlBO 13ys84vo7md2O864NZ/wEL74ULlW+mVlY6UXyp7rl47bC3LQtQGjAlv4A4/plcwuxRad E4316ozFS8mwLVHycYanYc0MIG9LeUm2mgQ7PHubpl4Kt8UJuf9vDNL+bbESSHsSMCGd 1O7e9lC7nEt3i4NclwcgqPHKSPsKz0uMWkQkrCDqBrQFnjqtA7KxpAWgPyIpZDiEHGI1 6trUb1kE7tAuONaZCcmZeG1h0fqq8Eg4059Ko2cV/nIDuuj2hnvQ/sFtFW95uanCNc/c H+0Q== X-Gm-Message-State: AKS2vOwmqtuUZ0awtzBmgZBPRCPSWARA2xXyUcMTb2ViY+mSbyVmhPRd ZOGEyLS2I3+Sd93kZY7DJVEVoNugOuGzunI= X-Received: by 10.129.50.140 with SMTP id y134mr24300538ywy.312.1499029121647; Sun, 02 Jul 2017 13:58:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 13:58:01 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sun, 2 Jul 2017 13:58:01 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1140932a4dd6c405535beac7" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 20:58:44 -0000 --001a1140932a4dd6c405535beac7 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 12:53 PM, John R Levine wrote: > Given that (a) we already have algorithms that are bigger and (b) >> post-quantum keys might be quite a bit bigger, it seems unwise to design >> under the assumption that it will not happen. >> > > Well, OK, but concretely, what do you want us to do now? > I thought I made that clear: I think the default representation should be hashed, not unhashed. Right now, today, I don't see that hasned ed25519 keys solve any problem, > so I'm not going to include them unless there is something I don't > understand that they can do that plain ed25519 keys in the key records > don't. > Uh, the way this works isn't that the editor decides what happens and everyone needs to persuade him. Rather, the draft needs to represent consensus of the WG. Happy to talk about this in Prague, of course. -Ekr > > R's, > John > > --001a1140932a4dd6c405535beac7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 12:53 PM, John R Levine <johnl@taugh.com><= /span> wrote:
Given that (a) we already have algorithms that are bigger and (b) post-quan= tum keys might be quite a bit bigger, it seems unwise to design under the a= ssumption that it will not happen.

 Well, OK, but concretely, what do you want us to do now?

I thought I made that clear: I think the default represen= tation should be hashed, not unhashed.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Right now, today, I don't see that hasned ed25519 keys solve any proble= m, so I'm not going to include them unless there is something I don'= ;t understand that they can do that plain ed25519 keys in the key records d= on't.

Uh, the way this works isn= 9;t that the editor decides what happens and everyone needs to persuade him= . Rather, the draft needs to represent consensus of the WG. Happy to talk a= bout this in Prague, of course.

-Ekr
=C2= =A0

R's,
John


--001a1140932a4dd6c405535beac7-- From nobody Sun Jul 2 13:59: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 CB4FC129AB0 for ; Sun, 2 Jul 2017 13:59:25 -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 fsJswmfu9gA3 for ; Sun, 2 Jul 2017 13:59:24 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 3F95F129AAD for ; Sun, 2 Jul 2017 13:59:24 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id j11so64699676ywa.2 for ; Sun, 02 Jul 2017 13:59:24 -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=+UvMGliV2JAQphQnyhnMHuqqFRomNont3jtt4gRGoXY=; b=IKj1YtgHj5RBeo4VHTiFq5I1yrplFGY/qnF322FvLBxFinkPxHkl4QirFXtVtJMNVy VtTEP1Io6kIhovoizDGJMzSYu8hqIboTs6xoanM8ECTDU363v+23lugIKTIfvoUzUOx9 y+utAZ/iZnRmQR9Xql00nOTjoC1Aj0na9wKQHlTvFr1kxZqIHFXfd3oy1wqZBOW5x6TA ZrrpB/n1+mS1P7oh2JCH19VVfmPPtFhJK2xcPsZFCKP0b3UWZ+ODXIWNxtfHIsbuLjXE IZwGIE8HwEimUcFBTu4iaZ4C2V7GcKIA1l72HCmdOUXJ9WOASzxVD3vnFlivi4/6hkEh Y0cQ== 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=+UvMGliV2JAQphQnyhnMHuqqFRomNont3jtt4gRGoXY=; b=Yu6LCKBVymGZeMlbgMurOhSMkmp4Wih+qNg3XIdpnOKg5QvQH5wZMwjgfLDjhNaVbW iG1VfQpivXdRtcfQsRt3wXelr4OKwNteiy463AbgiZdBixECVH57EAK3q7HT0tdcJIVT d985qwSzX8fr/8zGOdSAynIEznmcIme8rnuMGQw09pCI4lc8qeC/fz7hLoQQKPPZgag3 8glOs/b1N762Nbeq3sL1iwGzmrtIaPlGfWPX0sh7JjDmrXMDofOsz7tsTphS/AKe2OA3 +/pvG+980vIvtv/Dxav2pfuF2kdYOYOIALORDMTYJRNqDN1xPBaolIOuheGgg5Ln79UA AtiA== X-Gm-Message-State: AKS2vOzOgghx/8TybbNgh4DnVaSjLOHp+V5wCG36EH7g6/2l36AApyHI FPa/QoBkRg/cePMAKFbePSoZ8+9yV2KCla0= X-Received: by 10.129.71.213 with SMTP id u204mr25446530ywa.270.1499029163588; Sun, 02 Jul 2017 13:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 13:58:43 -0700 (PDT) In-Reply-To: <158ff29b0ff8494abb5703da76535a56@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170702025650.55902.qmail@ary.lan> <158ff29b0ff8494abb5703da76535a56@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Sun, 2 Jul 2017 13:58:43 -0700 Message-ID: To: "Salz, Rich" Cc: John R Levine , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a114c6ec0cddf3305535bec4c" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 20:59:26 -0000 --001a114c6ec0cddf3305535bec4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 2, 2017 at 1:21 PM, Salz, Rich wrote: > I think post-quantum crypto is out of scope, but maybe I=E2=80=99m in the= rough. > > I agree it's out of scope. I'm talking about having a design which cleanly scales from what we have now to new algorithms, and I don't think that that's out of scope. -Ekr > > --001a114c6ec0cddf3305535bec4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 1:21 PM, Salz, Rich <rsalz@akamai.com> wrote:

I think post-quantum crypto is out of scope, but ma= ybe I=E2=80=99m in the rough.


I a= gree it's out of scope. I'm talking about having a design which cle= anly scales from what we have now to new algorithms, and I don't think = that that's out of scope.

-Ekr
=C2= =A0

=C2=A0

=
--001a114c6ec0cddf3305535bec4c-- From nobody Sun Jul 2 14:03: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 6FBAE129AC4 for ; Sun, 2 Jul 2017 14:03:36 -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 rE99WSScyxbV for ; Sun, 2 Jul 2017 14:03:35 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 09835127078 for ; Sun, 2 Jul 2017 14:03:35 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id a12so16586467ywh.3 for ; Sun, 02 Jul 2017 14:03:35 -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=LxAmbm7B5HWC8f4MPfjLZ4W+crVezsSyVKGPv0tZB8w=; b=Em7zus22ZmYX/4R/UI8OmtO6iZ8wey8upTw33cYtyepRitxH50i21FtUxmGAdwyc8v cjSL3rrUbKHkp2dgLBqEcMUeDOFoBNhp0HZ5v2VOaMXofVVv6pZU1+Tjtcue3hZCvDx3 Zm2jwr4lN58ySIRVD3yPfsI5ketR+eokuKh39YuNPa7kghE4y3sSpwtTchV69WlfC8Wo 5LeHbDKY3tADQ8l5FMaeD0bTI0kO3A4dFDRegExs2xuRkQTKZu1Ccw0SMacPZKszrsBE vQApx9mdWS/5bGXg64fwclN/5HpVhK4r7boLmYLv6cR2NoJKhhv+InoZNZyvD2NwVRna 5SLQ== 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=LxAmbm7B5HWC8f4MPfjLZ4W+crVezsSyVKGPv0tZB8w=; b=QRPcw4UNiZwYJFb0ulBWO1lg6MKi6Q2dq96lASe8DBBT3pPfNDpcpkxVr/6bko7kFQ 2vW/bqSdvCSkYjD5uqj2mHBBeJNd0UqQ/ePmUhHRW5teDifndCoZ7plBXMhBntUxbkCv FL4ZkMvaEzxTy785TsLixDfazzcz73HuJmXwUd+ezRYMSvdG+RGgRcx3E8OkICygllxC ZRRKdFxs/hiGSs47Ozaym1nDT622Xml7rDNd3NKkZyfJQ97V7os/PpgSrpVb8/XffZS6 qiRp7PFvd+iq/wshnZjajDGLFgV4BMDMTb/CqtQN1AXhaX+za6pTH6kVTLbY1Dkzp7Nl yMMw== X-Gm-Message-State: AKS2vOyvEsJwhOZ+23jhcBKbIv1oV8i3CcQj3k7Kf0FE0QMpjFUGM3Ew TD/Ju/VXtJNVxrfHIpxas4qkjy+9FxlZ X-Received: by 10.129.202.71 with SMTP id y7mr22574304ywk.74.1499029414265; Sun, 02 Jul 2017 14:03:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 14:02:53 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sun, 2 Jul 2017 14:02:53 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="089e08259780bf1c6b05535bfb01" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 21:03:36 -0000 --089e08259780bf1c6b05535bfb01 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 1:58 PM, Eric Rescorla wrote: > > > On Sun, Jul 2, 2017 at 12:53 PM, John R Levine wrote: > >> Given that (a) we already have algorithms that are bigger and (b) >>> post-quantum keys might be quite a bit bigger, it seems unwise to design >>> under the assumption that it will not happen. >>> >> >> Well, OK, but concretely, what do you want us to do now? >> > > I thought I made that clear: I think the default representation should be > hashed, not unhashed. > I'd also be fine with having both representations, though I think it's confusing. However, I don't think it's great to have just unhashed in the future. -Ekr Right now, today, I don't see that hasned ed25519 keys solve any problem, >> so I'm not going to include them unless there is something I don't >> understand that they can do that plain ed25519 keys in the key records >> don't. >> > > Uh, the way this works isn't that the editor decides what happens and > everyone needs to persuade him. Rather, the draft needs to represent > consensus of the WG. Happy to talk about this in Prague, of course. > > -Ekr > > >> >> R's, >> John >> >> > --089e08259780bf1c6b05535bfb01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 1:58 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Sun, Jul 2= , 2017 at 12:53 PM, John R Levine <johnl@taugh.com> wrote:
=
Given that (a) we already have algorithms that are bigger and (b) post-quan= tum keys might be quite a bit bigger, it seems unwise to design under the a= ssumption that it will not happen.

 Well, OK, but concretely, what do you want us to do now?

I thought I made that clear: I think the default r= epresentation should be hashed, not unhashed.

I'd also be fine with having both representa= tions, though I think it's confusing. However, I don't think it'= ;s great to have just unhashed in the future.

-Ekr=
=C2=A0

Right now, today, I don't see that hasned ed25519 keys solve any proble= m, so I'm not going to include them unless there is something I don'= ;t understand that they can do that plain ed25519 keys in the key records d= on't.

Uh, the way this works= isn't that the editor decides what happens and everyone needs to persu= ade him. Rather, the draft needs to represent consensus of the WG. Happy to= talk about this in Prague, of course.

-Ekr
<= div>=C2=A0

R's,
John



--089e08259780bf1c6b05535bfb01-- From nobody Sun Jul 2 14:16: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 59D3B126B7E for ; Sun, 2 Jul 2017 14:16: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 (1536-bit key) header.d=iecc.com header.b=cm/dKeaM; dkim=pass (1536-bit key) header.d=taugh.com header.b=Q2RMUtW3 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 XN4FVTREEH1T for ; Sun, 2 Jul 2017 14:16:49 -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 6A3A212ECB4 for ; Sun, 2 Jul 2017 14:16:49 -0700 (PDT) Received: (qmail 98599 invoked from network); 2 Jul 2017 21:16:48 -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=18125.595962c0.k1707; bh=sIKD+uzPdfOeJdV1dnGnCNd/G/gWFUsVgNueT0D/xN0=; b=cm/dKeaMT1vJYMQI1zz5k+AbLZ+yguYZ0FyPeIpM14dUR4lVoibgbcSv83YxJT7xHerpp06tJCoTegDO2OtJoz2BilXxXtvWxvILnQbn2HoQzU4o2OqErJ0vjauhAka/RlWZL0Wlg89PBjEGjLR4Rwg6QEVMdH/MRv52q8VK8lnCGejcgoL9HK4RWlamFndXkFKgdJ1jxWmsgcNDNuqDJRmUQNSy/YByVa8nkSPgSB6HuKZ8ASJ3ZoiMCDwGlSS/ 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=18125.595962c0.k1707; bh=sIKD+uzPdfOeJdV1dnGnCNd/G/gWFUsVgNueT0D/xN0=; b=Q2RMUtW3cIAPaZ/F/JBS1+mWRwVxsjcSUNu5S0KqSEtJICtnNNSLgL7qe/hX6wF10VZwtB051hvVuLfN5ioQFfXXyq99J6H3DbKNkFf0PGDMIv1nP6W4/tXSgH8EhFpqJfMm1iwihriKq0TJ+CdMDGrbhgKbZEEbhF40WcGLPGclqVkGt5e9+S0IrKlrPu8/SXGRcKoGgoav6/+wpaiauJgJ6ftFfMLCWqx0GP5LS1mT/FuaoGoyGBGoejNzUezn 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; 02 Jul 2017 21:16:47 -0000 Date: 2 Jul 2017 17:16:47 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170702025650.55902.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] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 21:16:51 -0000 > I'd also be fine with having both representations, though I think it's > confusing. However, I don't think it's great to have just unhashed in the > future. Since nobody is currently proposing that, and as far as I can tell nobody in this thread has ever proposed that, I really don't understand what we're arguing about. 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 Jul 2 14:34: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 EDC47129601 for ; Sun, 2 Jul 2017 14:34:56 -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 jLCNw4JqulKA for ; Sun, 2 Jul 2017 14:34:55 -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 E5E291275AB for ; Sun, 2 Jul 2017 14:34:54 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id z78so51522580lff.0 for ; Sun, 02 Jul 2017 14:34: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=B9P8p/83VHHLJ4vWOr0dDCONFgMpCvG8VyJQojOI1QA=; b=qiBvUKvCQkmGQgcPP7BW2HOhiWY06ApYryMse1hCxZQVB7JuG0tB/EtbjobjoSdrGE z056vi4WWJf2Rbon0iCRjaNiMm48To8yWBegU/dAJjtJNf4+iJm1QchrUCWbjjO63+ra Q8fheZDoc86Y2ct+DnR5ekRBqaYY1ibkprCPoSOxKx45duyrR5fw/7XL/XgGUCHdmO7f Y55QU5ow/XO3CYZ3CKvK42lcbBR0EeGzEtZe0IEBvCFOrARUT+p3mRS6LcJM9qzrMj9X JXbYcBKM3iWUHVJB0tHfkEQweLP0/cBpLAorQY2tMb9FAMLdCh0yK++SGqgqAWB8thaE 5S1g== 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=B9P8p/83VHHLJ4vWOr0dDCONFgMpCvG8VyJQojOI1QA=; b=FpQ9KAV7Uhj6IiOAJCjEpYlvsd/EBUp6W4/kTUKm2sUgDOmjOQvRQFIeOW+BDASknN qGIrBeycK4mY27Tsq1gNdPKwqWKdKXyJJc+7PofovLjeVwnigQl4d0fedF8p2DyPqp0b X5TP4w+lZK7qhSYhZdYNYEpL4xpY94rLMoEHWbhlE0US7GYhdsRSC9SYNBwezSZQ6aaR RWC81LJec1ZqQ2o17APCuNT5CWOJMx2SBdH4zMxvMJHwqjSZjh6mvxBV5/8dWCUt0YXy xGfiX3YqDY5X+89CG6jMZ197zFDHASmeV2wC4zoJc4RolEM4iuA+1gQWBE2OnMmEvSQN nSgA== X-Gm-Message-State: AKS2vOx2I5ZEDKbXd99bRlzaCJPaI/vMowq7mmXV8Cpo1BZADNOwrDU+ XEfZnCqwHFJRYrs7grIm16t33M+dYg== X-Received: by 10.46.8.89 with SMTP id g25mr9656862ljd.18.1499031293242; Sun, 02 Jul 2017 14:34:53 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.25.181.214 with HTTP; Sun, 2 Jul 2017 14:34:52 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> <388acdd7731b45b797fde389bdb92681@usma1ex-dag1mb1.msg.corp.akamai.com> From: Phillip Hallam-Baker Date: Sun, 2 Jul 2017 17:34:52 -0400 X-Google-Sender-Auth: 3VVz8IfuLmXpfvvoDx_DxPuJIwk Message-ID: To: "Salz, Rich" Cc: John R Levine , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="f403045f9f72bdb38e05535c6b85" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 21:34:57 -0000 --f403045f9f72bdb38e05535c6b85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jul 2, 2017 at 11:44 AM, Salz, Rich wrote: > > To me it seems more likely that ed25519 is good enough that it'll last > until we > > deprecate all of DKIM in favor of something different. > > As an individual, I think this is reasonable. > > As co-chair, does anyone in the WG disagree? > > =E2=80=8BI would phrase it differently. We will use DKIM until we start usi= ng something different to SMTP.=E2=80=8B I can't see a viable transition path = out of DKIM without re-designing SMTP. The only thing I see on the horizon that might force us away from ed25529 is quantum and that is going to be so different that backwards compatibility just isn't going to be a concern. --f403045f9f72bdb38e05535c6b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Sun, Jul 2, 2017 at 11:44 AM, Salz, Rich <rsalz@akamai.com> w= rote:
> To me it seems more likely t= hat ed25519 is good enough that it'll last until we
> deprecate all of DKIM in favor of something different.

As an individual, I think this is reasonable.

As co-chair, does anyone in the WG disagree?

<= br>
=E2=80=8BI = would phrase it differently. We will use DKIM until we start using somethin= g different to SMTP.=E2=80=8B I can't see a viable transition path out = of DKIM without re-designing SMTP.

The only thing I see on the horizon that might force us away fro= m ed25529 is quantum and that is going to be so different that backwards co= mpatibility just isn't going to be a concern.=C2=A0

--f403045f9f72bdb38e05535c6b85-- From nobody Sun Jul 2 15:03: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 45A5A129461 for ; Sun, 2 Jul 2017 15:03:38 -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 U5G5jGkbvM7d for ; Sun, 2 Jul 2017 15:03:36 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 86A40127076 for ; Sun, 2 Jul 2017 15:03:36 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id s15so16395568ybe.2 for ; Sun, 02 Jul 2017 15:03:36 -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=K1ngvSAbSYPHhSAIBVCDdmif4kvgVxdSc8iBZ0F83OY=; b=tpBus69qJR7TdURxW9AxhC/WCHYBuvmpXG62DBdbdR5F28ORno57m5wnyl11m1LOj6 vTWQVMz9sO3kzxrzQjPMSE+oUCTnLxFVljeoWUR6PpqnMMswCI0YvPtTaE2ExkToku4X 24b/D0bIWuJNu21azHlX4QWUv7EZv5SrLQ9hu1IZRbLHTpjBCwyCl/62xAR5oYLFCtTT +qD/LlOraj3GNgPD3+KlYKBmh2yvV+rNud2Vl6g4XewKf3K+pj79UWnXCUgfhhP/KMXs OYiCOgB//H8pu8hRIFmJi2nA9C+9sSrEJJrmUhlnSsENbqDOy0q//7OADV0cCIrijwPs vZow== 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=K1ngvSAbSYPHhSAIBVCDdmif4kvgVxdSc8iBZ0F83OY=; b=f2HRTcoI2xxAX419XpQEsubf9zuRI1+Atmfrh13IZLSiw1OvV5ZCPEkh4Kg82u5OHU qTIwkmBJIGjQYICKSpBMdV2qzW80J+Y/VskzjEuU3bJNOzIAJxqA7CtzCNH+KQ5qI0t+ D1m92g6ZCClEZBGUm0vovu8BxniwJRU5oIgZqo2xKdhyK0klc9XVIah2b48kdT4Qgn/A NnMSLp01JoVcz03Y6zSG4/RNlhGH52A/y3HmDefeQXYImqFHt6h/N3K3NomVbkPIIJS/ LdoSZ+OBSvcqr66F4L35UMm6ocsDedQdb3DVQ8pY3JEkFiOE6pcj8rIOF4tI/2IIvgr6 Krmw== X-Gm-Message-State: AIVw110QuOlJX7qNhi2zmNFLOMl0FUeppmwMJC0r9K7c3tOdCI0layS9 2pb9oIqT7Dg0SQZxkcm2L3CBpO39dtVo9zZzFw== X-Received: by 10.37.42.207 with SMTP id q198mr13204323ybq.71.1499033015788; Sun, 02 Jul 2017 15:03:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 15:02:55 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sun, 2 Jul 2017 15:02:55 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1144184469eefd05535cd29c" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 22:03:38 -0000 --001a1144184469eefd05535cd29c Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 2:16 PM, John R Levine wrote: > I'd also be fine with having both representations, though I think it's >> confusing. However, I don't think it's great to have just unhashed in the >> future. >> > > Since nobody is currently proposing that, and as far as I can tell nobody > in this thread has ever proposed that, I really don't understand what we're > arguing about. I'm responding to this change: "SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints. Since an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, there's no point to eddsa fingerprints, so I took them out." My point is that you should revert it. -Ekr > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --001a1144184469eefd05535cd29c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 2:16 PM, John R Levine <johnl@taugh.com> wrote:
I'd also be fine with having both representations, though I think it= 9;s
confusing. However, I don't think it's great to have just unhashed = in the
future.

 Since nobody is currently proposing that, and as far as I can tell nobody i= n this thread has ever proposed that, I really don't understand what we= 're arguing about.

I'm responding t= o this change:
"SIGNIFICANT= CHANGE: Only RSA signatures can use key fingerprints.=C2=A0 Since an eddsa= key is 256 bits, and a SHA-256 fingerprint is also 256 bits, there's n= o point to eddsa fingerprints, so I took them out."

My point is that you should revert it.

-Ekr



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

--001a1144184469eefd05535cd29c-- From nobody Sun Jul 2 15:28: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 5274C12F092 for ; Sun, 2 Jul 2017 15:28:55 -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 (1536-bit key) header.d=iecc.com header.b=jSR/pWFO; dkim=pass (1536-bit key) header.d=taugh.com header.b=jxRawGY2 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 RxSXM92Ru4yX for ; Sun, 2 Jul 2017 15:28:53 -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 B0E4D12EC36 for ; Sun, 2 Jul 2017 15:28:53 -0700 (PDT) Received: (qmail 4452 invoked from network); 2 Jul 2017 22:28:52 -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=1162.595973a4.k1707; bh=YjV0HQbwfYTOuiDfIpdEzk5NT0D1QQ+tsRVSVyIDj+s=; b=jSR/pWFO7YzRhDI5GAmaDs7l8cpbK+Oyajfe55IcBmvmZI6Yx2f8FhcdYKdwFGyRRwRXuLcWNoaI4B/80bzHd6rTM9yrf8Kb+jnDz7x2bOulS23heosAHmoZXUpGOWd1yAztkBP063DKGe3NWHYcm/zQGb9Cw7JafzaSmAaUqzGLHnZNn30iHpklvFUfsgt4hXqwioj7HQaI5GkVeh3Ekd3YeKFHId6JCBLzWbkjdlrfdwYt+8hyXQrc544kJ7gK 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=1162.595973a4.k1707; bh=YjV0HQbwfYTOuiDfIpdEzk5NT0D1QQ+tsRVSVyIDj+s=; b=jxRawGY2KtNe8cUJ8eZnZJSeZUvtTdKzyqkruoeclOzKg00wUIHJfqUUU4Mg7/Okhm+EveN3d1KqogUdGm/PfIoFRYSxhf4tniqG9kH9Y3vCsi85mta+Om6XmAzihFwan8A0xDb9uprNew3itloRFzYgEwFnzcV7eJKWkD5O74T2e3HiPC32onG6a+CmIlckFV10MOdwUPA7sKggt+hObwVH+rcXXogKCJq+URJgTqsvw+fSNCy811+W8LOnUc9n 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; 02 Jul 2017 22:28:52 -0000 Date: 2 Jul 2017 18:28:51 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170702025650.55902.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] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 22:28:55 -0000 >> Since nobody is currently proposing that, and as far as I can tell nobody >> in this thread has ever proposed that, I really don't understand what we're >> arguing about. > > > I'm responding to this change: > "SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints. Since > an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, > there's no point to eddsa fingerprints, so I took them out." > > My point is that you should revert it. The current draft is substantially rewritten so it's not that simple. Please identify the sections and lines of the -03 draft to which you object. R's, John From nobody Sun Jul 2 15:37: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 A390412F17A for ; Sun, 2 Jul 2017 15:37: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 bRET6Iu8nNma for ; Sun, 2 Jul 2017 15:37:07 -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 0041F12EC36 for ; Sun, 2 Jul 2017 15:37:06 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id 63so65203151ywr.0 for ; Sun, 02 Jul 2017 15:37: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=J2BoDv7VGbjLmJo6wu8GAhnbsRgO3WOndLPuJofOwws=; b=n8yrp4mxD7o0TSRNOd6Fi0wwBO+SPILj21tL9HXxNunppiKqv5GbOFmSWHgvoj/6uL bHetchJrNT6jwsjmvmDCQsX8DnjLaCwYpX97wdSbjEcdECj2uHd/6FlhTuJTj8WvmGEU okw/Fg5FmG2FQZUs0ybAFyJWXGPk9Ofc2FifBYbkqBufIdjc6GXHHJIB4PR8486UtpJ+ eGY7rZSTD+XcIIIiai2f6xt290C7cXFvmTQtf1is277+FMLNM+7l1u+FkUzKf+JfSY5o t63oJptiSGN21URI9W5o/73bORI+XVvZa2jBvRAKrpvPYo+FRd4kc6b53Aez0eC7uMeC oOtQ== 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=J2BoDv7VGbjLmJo6wu8GAhnbsRgO3WOndLPuJofOwws=; b=b4U9eNs7ZwWbkffaTwiI+VMGQqBTsxuYrGrkruCPkp0/UD79gp6b0YFPK1diQWEiNn GYt/WrsWJOe0Q7RNMKaaaSD2Ku+QzhxBroedFmEAsaNuLFWhYO83bqRfxIGCTtpjzLgy db/Ofk3Hzw4J6PXor/g74QU2lcbKP2eiuraAMzaTk0ZaeZjYsox5cn0loILIx3QQGmXT l/dmndMq2C/dM8ZZZb3MLwU+4qP+7nqD0F/W4wRHuttVJYYN7Xp4PcjlUOpxq5SUw5lY EbUx0AoPYzJcursz6e2Gg6/uDTPK0UYHSX+Uf4AB22F0WSy294fa9ZvS5cVWVIJ129A9 WxbQ== X-Gm-Message-State: AIVw113wcNM3Y8Bnk7giBwpT9aLt5YcZtpY6KMAaIhShAJXXZwQ3tTwH 0g2aT4DuAt7rYCQAYShKsrmIDFV0+oaw X-Received: by 10.129.118.66 with SMTP id j2mr7827466ywk.85.1499035026265; Sun, 02 Jul 2017 15:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 15:36:25 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sun, 2 Jul 2017 15:36:25 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403045eed8a3f4c9805535d4af8" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 22:37:08 -0000 --f403045eed8a3f4c9805535d4af8 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 3:28 PM, John R Levine wrote: > Since nobody is currently proposing that, and as far as I can tell nobody >>> in this thread has ever proposed that, I really don't understand what >>> we're >>> arguing about. >>> >> >> >> I'm responding to this change: >> "SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints. Since >> an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, >> there's no point to eddsa fingerprints, so I took them out." >> >> My point is that you should revert it. >> > > The current draft is substantially rewritten so it's not that simple. > Please identify the sections and lines of the -03 draft to which you object. > Is the document on Github? I'll send you a PR. -Ekr > R's, > John > --f403045eed8a3f4c9805535d4af8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 3:28 PM, John R Levine <johnl@taugh.com> wrote:
Since nobody is currently proposing that, and as far as I can tell nobody in this thread has ever proposed that, I really don't understand what w= e're
arguing about.


I'm responding to this change:
"SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints.=C2= =A0 Since
an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits,
there's no point to eddsa fingerprints, so I took them out."

My point is that you should revert it.

 The current draft is substantially rewritten so it's not that simple. P= lease identify the sections and lines of the -03 draft to which you object.=

Is the document on Github? I'll se= nd you a PR.

-Ekr



R's,
John

--f403045eed8a3f4c9805535d4af8-- From nobody Sun Jul 2 16:16: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 41FF81267BB for ; Sun, 2 Jul 2017 16:16:36 -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 (1536-bit key) header.d=iecc.com header.b=dZs4Hw/D; dkim=pass (1536-bit key) header.d=taugh.com header.b=niR/YY90 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 GWgNjIC-1faS for ; Sun, 2 Jul 2017 16:16:34 -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 78EA11200FC for ; Sun, 2 Jul 2017 16:16:34 -0700 (PDT) Received: (qmail 7570 invoked from network); 2 Jul 2017 23:16:33 -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=1d90.59597ed1.k1707; bh=4jEEov3Y9HfB9YJkcp388/mEZ3Bd/y9gknBb0xuaYf4=; b=dZs4Hw/DQBttvmssD/VtmNfjKHKXT0UW7Bx1yKQiQtskJnSva8p5gPpASDzdRkjto2AMV1iNYV3A4+I4LGEHuPtkNoqVz7MXl+1c4h8dJbp+NxBi8Bb/gJzF+nZEQBEfALs8NRTqDPDz33H2nigu9xVXQbdIZSJTb4DtvlT7KpAh3gC7Qzs+NBwBr1xB7CYAEf9g1v/9hbyflR1iqZFO02FEvZGaXqWr+l8YPvyd85szYcE27FciX+Kcvnzl8Px8 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=1d90.59597ed1.k1707; bh=4jEEov3Y9HfB9YJkcp388/mEZ3Bd/y9gknBb0xuaYf4=; b=niR/YY90clQ9HRKRylcv32NsDQeKxc1oSiH5KwaI+WHBkqwRPoIkwCDfKttkJ5fyZ3YWTpSwpGZtGsIyPAR6PHOuqrdIxZSc0Fr6R+xmoJkAEkx2id1C8u4j4ixFshvmwU80ietTMADJ5scoyyK7yJCeKcpTxR35ghaZVuLPVbkWYVZNHKDKepEKYCzmlOn+cRDJGqLaRJvitgd0oBkvX5tYva8quKh7uWm4c6J1hVsffyox7lHHvGAVbrFOlwok 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; 02 Jul 2017 23:16:33 -0000 Date: 2 Jul 2017 19:16:32 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <20170702025650.55902.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] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 02 Jul 2017 23:16:36 -0000 >> The current draft is substantially rewritten so it's not that simple. >> Please identify the sections and lines of the -03 draft to which you object. > > Is the document on Github? I'll send you a PR. No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place. Just tell us which sections should change, or if you want you can send a diff to the XML but that's probably overkill. Perhaps this will help: SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than three, rsafp for RSA with key fingerprints in the DNS, and eddsa for ed25519 with keys in the DNS. NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what signature schemes, key representations, and/or message hashes might be added or changed in future versions of DKIM. 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 Jul 2 17:01: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 F3BAF12741D for ; Sun, 2 Jul 2017 17:01:34 -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 leyhaMljCcFz for ; Sun, 2 Jul 2017 17:01:32 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 B66DE126E3A for ; Sun, 2 Jul 2017 17:01:32 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id j11so65326040ywa.2 for ; Sun, 02 Jul 2017 17:01:32 -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=x5nasXmQNV2xkdso2MLvRbCiKCMejcpC3TYivon4W04=; b=Gp1WDtSHAh86hfKSwuCuKhvUq676WYbmUN9AdmDhsWca3CnJDiu4rkFgO4yj0to8ZZ CEMllzKv/W/Mj+vm+F0ZCHK9sDD5d1bHqfMS/mgxUjSjpjHwjlAjOc0wxRiKLB3ROSHV pkwWmcngqrkC65yCiHUO02go3Fp/ippIAtXIM1G7Lxr7044Gs7TJHyZsEdZ81Hj1FmYs bLyk4C08R66DTOPIcUCkRo+NNFIoE/NmoJA724A6o2J0dkb2fm/S7/RQO/aOsX6eqeSt YKNMZDwSVr0dbLdCHjI1Vr7NaldbnQtxU1YUBAqnjuD5GMLr6P+dWu10t6bw/Q2G3E01 /iBQ== 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=x5nasXmQNV2xkdso2MLvRbCiKCMejcpC3TYivon4W04=; b=p3ytjgvC3AxgRssJfyhFct2sJkTekz2Re0afDLld7oBN8WWptajfJtk0CklxOJh36m erUI1PsW0ymrnTDDyBnWH/XDiwRK4lt6BgdG3PLBLAsJR+bUdTYUqLGpIFgZnE0I6NwZ L96Bqo/ncHy3OtG426TMELpNcK9zjPYSvBmynB8V19+OnWK8olYbmt8+//SxrY5kBYMD Nf5Jzd72RPUia/jnSDBskS2/Vuf//vLM3fyFTKJHrClFTjXSQe3MZfgR/JPXGhQ7+YAs gSswA/9HAuV4buM2ShqBPei8bftDTdokDah5YlX5fb6fmU8o60JA4qQHPDCgtiOeEH7l SCkg== X-Gm-Message-State: AKS2vOyQmKrdkk1cmfIH/+v+OoChX8mH4rilh8vBf/pQEIEZVWe2Nh6+ wu/LrHYu0BMoJpLF2opt5fa5GxitMob+o7A= X-Received: by 10.129.109.206 with SMTP id i197mr18601688ywc.24.1499040092010; Sun, 02 Jul 2017 17:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 2 Jul 2017 17:00:51 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Eric Rescorla Date: Sun, 2 Jul 2017 17:00:51 -0700 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114dd2663052a705535e7842" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 03 Jul 2017 00:01:35 -0000 --001a114dd2663052a705535e7842 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 2, 2017 at 4:16 PM, John R Levine wrote: > The current draft is substantially rewritten so it's not that simple. >>> Please identify the sections and lines of the -03 draft to which you >>> object. >>> >> >> Is the document on Github? I'll send you a PR. >> > > No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place. Just tell > us which sections should change, or if you want you can send a diff to the > XML but that's probably overkill. > > Perhaps this will help: > > SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than > three, rsafp for RSA with key fingerprints in the DNS, and eddsa for > ed25519 with keys in the DNS. > > NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what > signature schemes, key representations, and/or message hashes might be > added or changed in future versions of DKIM. I'll send you comments, but it won't be before Prague. -Ekr > > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > --001a114dd2663052a705535e7842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 2, 2017 at 4:16 PM, John R Levine <johnl@taugh.com> wrote:
The current draft is substantially rewritten so it's not that simple. Please identify the sections and lines of the -03 draft to which you object= .

Is the document on Github? I'll send you a PR.

 No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place.=C2=A0= Just tell us which sections should change, or if you want you can send a d= iff to the XML but that's probably overkill.

Perhaps this will help:

SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than t= hree, rsafp for RSA with key fingerprints in the DNS, and eddsa for ed25519= with keys in the DNS.

NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what sig= nature schemes, key representations, and/or message hashes might be added o= r changed in future versions of DKIM.

I'= ;ll send you comments, but it won't be before Prague.

-Ekr



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

--001a114dd2663052a705535e7842-- From nobody Mon Jul 3 10:47:51 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 1A17A1316F1; Mon, 3 Jul 2017 10:47:47 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910406709.22786.10851393520664641633@ietfa.amsl.com> Date: Mon, 03 Jul 2017 10:47:47 -0700 Archived-At: Subject: [Dcrup] IPR Disclosure Jim Fenton's Statement about IPR related to draft-ietf-dcrup-dkim-crypto belonging to Cisco Technology Inc. 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, 03 Jul 2017 17:47:47 -0000 Dear John R. Levine: An IPR disclosure that pertains to your Internet-Draft entitled "Cryptographic Update to DKIM" (draft-ietf-dcrup-dkim-crypto) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3025/). The title of the IPR disclosure is "Jim Fenton's Statement about IPR related to draft-ietf-dcrup-dkim-crypto belonging to Cisco Technology Inc." Thank you IETF Secretariat From nobody Mon Jul 3 17:49: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 22EFE126E3A for ; Mon, 3 Jul 2017 17:49: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 n74B85u9WgMY for ; Mon, 3 Jul 2017 17:49:50 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::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 1CAE512741D for ; Mon, 3 Jul 2017 17:49:50 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id s15so25536927ybe.2 for ; Mon, 03 Jul 2017 17:49: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=HDAZItAbRmsnalg7VJMtqQ5tBcycFGg7NtpemJeAMcI=; b=BF0BjiqOtLHG2fizMtYdIc0sIBJY/XHkesm0CVMppBMN9hnkgslLGjFzx34Sukodo7 umiAICnjmknwstgtIfjts64PZd5vBr6ET6pK5ZWq5emaVX9rmu8LaN5+oshg03ROfzdq ufSNlhaoDdmPfG8Osp4X3pKq8+Wjo25uFMuGAOXdm19GFeuNz3HFPZp9V7KadGrPYcyS MRXzN/v9X9REf5e2N4Iq12Bbj393PAH/GSSipAXjrXKNqAHBphu6nj0oVVXa9GK6r4yk u2r8sD7paQGgcTK8hvhJqnulxAjeVVNP8T8J16PGhrTdIyoUBDR3pP9jTPsPj6QRkCzo Wnmw== 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=HDAZItAbRmsnalg7VJMtqQ5tBcycFGg7NtpemJeAMcI=; b=RegJwx13yDUXJZHkxWFCCJhxMwkgq2rwI/UPKY/RAGw/M+bP4GUTahRpl01Si5m3Ap 6rkkxc4davFUz+SpW6G6BnR+cHaufpfYtOhDfAcd6rJIUYQwh265+voUKm/FLhnuqrkA QaeuN+M0bp7qV2g1G5kKmd1d5Nz7mHA3gThAVtKVitRZ+BQZNEqHJbogjsbZ/a2j2blo jxhwlnUKNoO1tD3BXI9OsAUL3xZKul/K7z1PbNBs3qKeCXnLRAifuMDhue5qgXpwZCdG xAynQSphYAgBxD1X402+MJdMkm/aZjx1kveBOla6fx2Xo0hXxsjubxB75QLuMPKpaen5 dfcw== X-Gm-Message-State: AKS2vOwGGkgLbzbbljpj0iTa97IOhz2sJShErtv0XuWc9rTkKYCzjS5t z8NeL+DJP867P49nd0QL58T1nQyAEQ== X-Received: by 10.37.205.133 with SMTP id d127mr30490998ybf.215.1499129388881; Mon, 03 Jul 2017 17:49:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.174.92 with HTTP; Mon, 3 Jul 2017 17:49:48 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: denis bider Date: Mon, 3 Jul 2017 18:49:48 -0600 Message-ID: To: Eric Rescorla Cc: John R Levine , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c189eecb265c6055373426a" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 04 Jul 2017 00:49:52 -0000 --94eb2c189eecb265c6055373426a Content-Type: text/plain; charset="UTF-8" I agree with John's reasoning, and the +1 from Scott K, and think this request is unwarranted. I see no gain from reverting this removal. The current design defines algorithms on a case-by-case basis. Both X25519 and X448 have keys small enough to be represented without hashing. Hashed keys cannot be made default at this point. That ship sailed 10 years ago. SMTP is a 40 year old protocol. At this point we should all understand that things are basically forever once they become widely accepted. 2048-bit RSA can be represented as-is unhashed. The only reason unhashed RSA would therefore go away is if 2048-bit RSA is broken and becomes deprecated. If that happens, chances are we'll need post-quantum crypto, and EDDSA will be deprecated as well. Hashed keys will not be default until post-quantum is a strict requirement, and we're not in a position to specify that right now. There is no purpose served by adding "eddsafp". On Sun, Jul 2, 2017 at 4:02 PM, Eric Rescorla wrote: > > > On Sun, Jul 2, 2017 at 2:16 PM, John R Levine wrote: > >> I'd also be fine with having both representations, though I think it's >>> confusing. However, I don't think it's great to have just unhashed in the >>> future. >>> >> >> Since nobody is currently proposing that, and as far as I can tell nobody >> in this thread has ever proposed that, I really don't understand what we're >> arguing about. > > > I'm responding to this change: > "SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprints. Since > an eddsa key is 256 bits, and a SHA-256 fingerprint is also 256 bits, > there's no point to eddsa fingerprints, so I took them out." > > My point is that you should revert it. > > -Ekr > > > >> 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 > > --94eb2c189eecb265c6055373426a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with John's reasoning, and the +1 from Scott K= , and think this request is unwarranted. I see no gain from reverting this = removal.

The current design defines algorithms on a case= -by-case basis. Both X25519 and X448 have keys=C2=A0small enough to be repr= esented without hashing. Hashed keys cannot be made default at this point. = That ship sailed 10 years ago. SMTP is a 40 year old protocol. At this poin= t we should all understand that things are basically forever once they beco= me widely accepted.

2048-bit RSA can be represente= d as-is unhashed. The only reason unhashed RSA would therefore go away is i= f 2048-bit RSA is broken and becomes deprecated. If that happens, chances a= re we'll need post-quantum crypto, and EDDSA will be deprecated as well= .

Hashed keys will not be default until post-quant= um is a strict requirement, and we're not in a position to specify that= right now. There is no purpose served by adding "eddsafp".
=


On Sun, Jul 2, 2017 at 4:02 PM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Sun, Jul 2= , 2017 at 2:16 PM, John R Levine <johnl@taugh.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I'd also be fine with having both representations, though I think it= 9;s
confusing. However, I don't think it's great to have just unhashed = in the
future.

 Since nobody is currently proposing that, and as far as I can tell nobody i= n this thread has ever proposed that, I really don't understand what we= 're arguing about.

I'm respo= nding to this change:
"SIGNIFICANT CHANGE: Only RSA signatures can use key fingerprin= ts.=C2=A0 Since an eddsa key is 256 bits, and a SHA-256 fingerprint is also= 256 bits, there's no point to eddsa fingerprints, so I took them out.&= quot;

My point is that you should = revert it.

-Ekr
=



Regards,
John Levine, johnl@tau= gh.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


--94eb2c189eecb265c6055373426a-- From nobody Tue Jul 4 00:26: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 A4F2C131456 for ; Tue, 4 Jul 2017 00:26: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, MIME_QP_LONG_LINE=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 UMDihVcPZtep for ; Tue, 4 Jul 2017 00:26:30 -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 26D5212ECC7 for ; Tue, 4 Jul 2017 00:26:30 -0700 (PDT) Received: from [172.50.3.168] ([72.253.124.8]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v647QQev008939 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Jul 2017 00:26:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1499153189; bh=hgsr3ZJvovA0FlVPS/oPSPx1s2ZFF60dqU/4dbOfVq4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=DPtD65Q0jHKoQgtESn+mkdGpJ/HPAicyncn5CQMSpmj9DNp/9RVFFKTa9CqWsyJ/N 1Zvbt5C3L1Ut6+Grt5xCnsg6E0O+h3QB2XFICX+jc30Rzqrng5HWwCzmwjCuSt6pVz 9/DGGt1gsclvdvDDwyPlpnClObtExUBAC9vIiBUQ= Content-Type: multipart/alternative; boundary=Apple-Mail-2B4246DA-6923-489F-BDAF-4B2374F01D72 Mime-Version: 1.0 (1.0) From: Jim Fenton X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Mon, 3 Jul 2017 21:26:26 -1000 Cc: John R Levine , dcrup@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <20170702025650.55902.qmail@ary.lan> To: Eric Rescorla Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 04 Jul 2017 07:26:32 -0000 --Apple-Mail-2B4246DA-6923-489F-BDAF-4B2374F01D72 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I agree with ekr on this one: publishing a key fingerprint is the more gener= al solution, even if right now we can't think of keys that require it other t= han RSA. So why not, in the future, always publish key fingerprints? Related side question: in my last review I asked whether we should make prov= ision in the protocol for different hash algorithms to be used for key finge= rprints. The answer was "no" because we would not be able to use them withou= t doing another dcrup-ish effort. I suppose that is reasonable, except that w= e had included the h=3D tag in DKIM selector records; it seems inconsistent t= o not be able to specify the algorithm here too. -Jim > On Jul 2, 2017, at 2:00 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Sun, Jul 2, 2017 at 4:16 PM, John R Levine wrote: >>>> The current draft is substantially rewritten so it's not that simple. >>>> Please identify the sections and lines of the -03 draft to which you ob= ject. >>>=20 >>> Is the document on Github? I'll send you a PR. >>=20 >> No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place. Just tell u= s which sections should change, or if you want you can send a diff to the XM= L but that's probably overkill. >>=20 >> Perhaps this will help: >>=20 >> SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than= three, rsafp for RSA with key fingerprints in the DNS, and eddsa for ed2551= 9 with keys in the DNS. >>=20 >> NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what s= ignature schemes, key representations, and/or message hashes might be added o= r changed in future versions of DKIM. >=20 > I'll send you comments, but it won't be before Prague. >=20 > -Ekr >=20 >>=20 >>=20 >> Regards, >> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY >> Please consider the environment before reading this e-mail. https://jl.ly= >=20 > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup --Apple-Mail-2B4246DA-6923-489F-BDAF-4B2374F01D72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I= agree with ekr on this one: publishing a key fingerprint is the more genera= l solution, even if right now we can't think of keys that require it other t= han RSA. So why not, in the future, always publish key fingerprints?

Related side question: in my last review I asked whether w= e should make provision in the protocol for different hash algorithms to be u= sed for key fingerprints. The answer was "no" because we would not be able t= o use them without doing another dcrup-ish effort. I suppose that is reasona= ble, except that we had included the h=3D tag in DKIM selector records; it s= eems inconsistent to not be able to specify the algorithm here too.

-Jim



On Jul 2, 2= 017, at 2:00 PM, Eric Rescorla <ekr@rtfm.= com> wrote:



On Sun, Ju= l 2, 2017 at 4:16 PM, John R Levine <johnl@taugh.com> wrote:
=
The current draft is substantially rewritten so it's not that simple.
Please identify the sections and lines of the -03 draft to which you object.=

Is the document on Github? I'll send you a PR.

 No, it's draft-ietf-dcrup-dkim-crypto-03 in the usual place.  Just= tell us which sections should change, or if you want you can send a diff to= the XML but that's probably overkill.

Perhaps this will help:

SIGNIFICANT CHANGE: This draft adds two new signature schemes rather than th= ree, rsafp for RSA with key fingerprints in the DNS, and eddsa for ed25519 w= ith keys in the DNS.

NON-CHANGE: like RFCs 4871 and 6276, this draft says nothing about what sign= ature schemes, key representations, and/or message hashes might be added or c= hanged in future versions of DKIM.

I'll send= you comments, but it won't be before Prague.

-Ekr<= /div>



Regards,
John Levine, johnl@taug= h.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/mai= lman/listinfo/dcrup
= --Apple-Mail-2B4246DA-6923-489F-BDAF-4B2374F01D72-- From nobody Tue Jul 4 08:09: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 9E4B813155A for ; Tue, 4 Jul 2017 08:09:37 -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 (1536-bit key) header.d=iecc.com header.b=qiihW5FA; dkim=pass (1536-bit key) header.d=taugh.com header.b=VoqkLA+y 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 KQLXIKX6af4X for ; Tue, 4 Jul 2017 08:09:35 -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 348B3126C83 for ; Tue, 4 Jul 2017 08:09:35 -0700 (PDT) Received: (qmail 17028 invoked from network); 4 Jul 2017 15:09: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=4282.595bafae.k1707; bh=7P/mBL4DolmUDcsDd202llQiEuFcUqxWw1Lh9tDoTkY=; b=qiihW5FAT71L8CBVQOnMTseyVUMzjEsggosTqRa3jpwPOM0DqOJdCJvriGqLdAzLCH/Fb861NVWi5TUKmqCKP+/Trej95FzBaJNXcRP16EaAd/m0h5gwxqsG18SejnkoFyTBkzf2wlVXM4+gn2H1IB0cGvbDm7oGzIbrZhyWRuLdvEBpvtyXxmYZ30rDlth1Sf4iYmesMYHFeLWpO2Kl88nW2ujoSxs0w0FYFTcwPyOtgR+q8uTfC6O09Ly7TObv 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=4282.595bafae.k1707; bh=7P/mBL4DolmUDcsDd202llQiEuFcUqxWw1Lh9tDoTkY=; b=VoqkLA+yOWcN8ijuzRbWmpBJtjd8z3YxWbrevH6a4sTaibp4Rmx/9Fe6zfwbGCqUlV/mftHZiQeuqrKAD5SCPXTAaFpeuEtN3abZ/ytlLFs9GQYvjGqoJVxpxCI8aoDFS9uBcW0QEjBOm7eSAuxNZsxBhTqsTz8viFfdaAJsif97B64JSLGqoQEQrbolElikISvpZA9KC9oSeEOmyWLFCxJLpDgFNxXYsfDsp8aTIz1YWPLLfPAZKsk4cA0omAdm 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; 04 Jul 2017 15:09:33 -0000 Date: 4 Jul 2017 11:09:33 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" Cc: dcrup@ietf.org In-Reply-To: References: <20170702025650.55902.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] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 04 Jul 2017 15:09:38 -0000 > I agree with ekr on this one: publishing a key fingerprint is the more general solution, even if right now we can't think of keys that require it other than RSA. So why not, in the future, always publish key fingerprints? 1) For the next decade or so, to the extent anyone uses a signature other than plain rsa, I expect they'll use eddsa since it's faster than rsa and the keys are smaller. (Librariess will have the code since they need it to verify other people's signatures, the only question is whether they use it, just like sha-1 and sha-256 body hashes now.) Key hashes use more time and space while providing no benefit to eddsa signatures. It doesn't seem like great design to pessimize the common case. B) Barring surprises, eddsa should be good enough to last as long as DKIM does. But if we have surprises, they tend to be, you know, surprising. Maybe we'll switch to some other elliptic curve which has keys smaller than 1100 bits, in which case key hashes still have no benefit. Or maybe some mega-parellel rainbow table scheme will come out of left field and we'll deprecate all of the sha-N hashes. It doesn't seem like great design to plan for stuff that we can't predict and that will probably never happen. Our crystal ball has never been great: back in 2006 would anyone have suggested that crudware that can't handle multi-string TXT records would be a design issue a decade later? iii) It seems unliely that Cisco will assert your patent, but until they say something one way or the other, who knows. It'd be prudent to be prepared for the eventuality, particularly since it costs us nothing to do so. 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 Jul 4 09:06: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 8FEDC13217D for ; Tue, 4 Jul 2017 09:06:15 -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 cu2zAgTIueRT for ; Tue, 4 Jul 2017 09:06:13 -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 42D78132178 for ; Tue, 4 Jul 2017 09:06:13 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id i2so168428268qta.3 for ; Tue, 04 Jul 2017 09:06:13 -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=YF++6bqZsM0PJpyDfoBibp9zBmVywWX3dE9yCLa10Y8=; b=gPGqQvtXOC5k54Wl0KhXHi3Rz5SMQ3SFsZJR7h3dti8G5ScV7Z0xpRtld5t68ZR+KW w/YmhcymbGXI5vG9Oq2TVMo924SBwqwN+YXxrdmjZ4QuLpboSIzQZyT5SukDQF8eyTVA 9z7Q/VfMuAxLPYwJZ7TBktlgnsCFohWMZ8yuV5Z9/xPFyE5sFqB9JmRV6vDoUZC/a7eU UvUvdMKG+6Cq93hazQi6BjGuL1OfOPbaclDbjFcWGDr91JGLBKvN8VHk/8Lbhw22sTyt TCq4h5qarFB+8fkXdPbrRfIYbKOqTgD7w/Id2Xr5XGX0u1f7B78l6Jqpag4NMOxXC8Ww ozcw== 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=YF++6bqZsM0PJpyDfoBibp9zBmVywWX3dE9yCLa10Y8=; b=mHMz5IH5hiMZuba3lrDqHsoN6VJKwbGvB6xBZJ93Bx+th8kv7SfEwqNg4TEqmLmF75 G+1MUsANIITRxUV6U1N/RIKt7+tu3rJJDjBW+t0irX9SMuFYvDJLgrs6WlyH8NJ2NrvF T141iKhGiSVzqJhQL5bnafbPnn1jKIAbh+6G5M/lvYROzKZD9IrKPpXQ44g/IbCEq+rr nyv8u5ik4csULC4Ksw0QL2bfuCvFlGx+VVgsNy54lHwWodsnPmcaNtUG0BNZlNjMiepZ +aNs2ehw5p2O6noyDPat9KcHBadLCSdGwk4xgwZWZGgrlc3kkKo7k8nbyHiZyOIhlrx4 FNBg== X-Gm-Message-State: AIVw1108OeFSiBQIvwDp61ie+e8robyuUv/eYcYIHwVxec+YDOWUUEXM p6DC6iLZf5pLrwGud1S20rUgFF0GYJrDE8E= X-Received: by 10.237.59.78 with SMTP id q14mr13180389qte.143.1499184372372; Tue, 04 Jul 2017 09:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.157 with HTTP; Tue, 4 Jul 2017 09:06:11 -0700 (PDT) In-Reply-To: References: <20170702025650.55902.qmail@ary.lan> From: Peter Goldstein Date: Tue, 4 Jul 2017 09:06:11 -0700 Message-ID: To: John R Levine Cc: Jim Fenton , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c095930f7eb090553800ff3" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-03.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, 04 Jul 2017 16:06:15 -0000 --94eb2c095930f7eb090553800ff3 Content-Type: text/plain; charset="UTF-8" I agree with John here. If we don't have even a single concrete notion of a future key type that would need fingerprinting, why should we try to bias the implementation in that direction? It's also not clear to me why fingerprints are the more 'general' solution. As John notes, fingerprints wind up using more time and space - an additional hash computation, and the addition of the base64 key to all signed messages. Fingerprints provide no benefit, other than a workaround for DNS crudware that can't handle multi-string TXT records. And in the EdDSA case it doesn't even provide that benefit. There's no compelling reason to make fingerprints the default. +1 to moving forward with the -03 draft. Best, Peter On Tue, Jul 4, 2017 at 8:09 AM, John R Levine wrote: > I agree with ekr on this one: publishing a key fingerprint is the more >> general solution, even if right now we can't think of keys that require it >> other than RSA. So why not, in the future, always publish key fingerprints? >> > > 1) For the next decade or so, to the extent anyone uses a signature other > than plain rsa, I expect they'll use eddsa since it's faster than rsa > and the keys are smaller. (Librariess will have the code since they > need it to verify other people's signatures, the only question is > whether they use it, just like sha-1 and sha-256 body hashes now.) > Key hashes use more time and space while providing no benefit to eddsa > signatures. It doesn't seem like great design to pessimize the common > case. > > B) Barring surprises, eddsa should be good enough to last as long as DKIM > does. But if we have surprises, they tend to be, you know, surprising. > Maybe we'll switch to some other elliptic curve which has keys smaller > than 1100 bits, in which case key hashes still have no benefit. Or > maybe some mega-parellel rainbow table scheme will come out of left > field and we'll deprecate all of the sha-N hashes. It doesn't seem > like great design to plan for stuff that we can't predict and that will > probably never happen. Our crystal ball has never been great: back in > 2006 would anyone have suggested that crudware that can't handle > multi-string TXT records would be a design issue a decade later? > > iii) It seems unliely that Cisco will assert your patent, but until they > say something one way or the other, who knows. It'd be prudent to be > prepared for the eventuality, particularly since it costs us nothing to > do so. > > > 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 > -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --94eb2c095930f7eb090553800ff3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with John here.=C2=A0 If we don't have even a = single concrete notion of a future key type that would need fingerprinting,= why should we try to bias the implementation in that direction?

It's also not clear to me why fingerprints are the more 'g= eneral' solution.=C2=A0 As John notes, fingerprints wind up using more = time and space - an additional hash computation, and the addition of the ba= se64 key to all signed messages.=C2=A0 Fingerprints provide no benefit, oth= er than a workaround for DNS crudware that can't handle multi-string TX= T records.=C2=A0 And in the EdDSA case it doesn't even provide that ben= efit.=C2=A0 There's no compelling reason to make fingerprints the defau= lt.

+1 to moving forward with the -03 draft.
=

Best,

Peter=C2=A0

On Tue,= Jul 4, 2017 at 8:09 AM, John R Levine <johnl@taugh.com> wrote= :
I agree with ekr on this one: publishing a key fingerprint is the more gene= ral solution, even if right now we can't think of keys that require it = other than RSA. So why not, in the future, always publish key fingerprints?=

1)=C2=A0 For the next decade or so, to the extent anyone uses a signature o= ther
=C2=A0 =C2=A0than plain rsa, I expect they'll use eddsa since it's = faster than rsa
=C2=A0 =C2=A0and the keys are smaller.=C2=A0 (Librariess will have the code= since they
=C2=A0 =C2=A0need it to verify other people's signatures, the only ques= tion is
=C2=A0 =C2=A0whether they use it, just like sha-1 and sha-256 body hashes n= ow.)
=C2=A0 =C2=A0Key hashes use more time and space while providing no benefit = to eddsa
=C2=A0 =C2=A0signatures.=C2=A0 It doesn't seem like great design to pes= simize the common
=C2=A0 =C2=A0case.

B)=C2=A0 Barring surprises, eddsa should be good enough to last as long as = DKIM
=C2=A0 =C2=A0does.=C2=A0 But if we have surprises, they tend to be, you kno= w, surprising.
=C2=A0 =C2=A0Maybe we'll switch to some other elliptic curve which has = keys smaller
=C2=A0 =C2=A0than 1100 bits, in which case key hashes still have no benefit= .=C2=A0 Or
=C2=A0 =C2=A0maybe some mega-parellel rainbow table scheme will come out of= left
=C2=A0 =C2=A0field and we'll deprecate all of the sha-N hashes.=C2=A0 I= t doesn't seem
=C2=A0 =C2=A0like great design to plan for stuff that we can't predict = and that will
=C2=A0 =C2=A0probably never happen.=C2=A0 Our crystal ball has never been g= reat: back in
=C2=A0 =C2=A02006 would anyone have suggested that crudware that can't = handle
=C2=A0 =C2=A0multi-string TXT records would be a design issue a decade late= r?

iii)=C2=A0 It seems unliely that Cisco will assert your patent, but until t= hey
=C2=A0 =C2=A0say something one way or the other, who knows.=C2=A0 It'd = be prudent to be
=C2=A0 =C2=A0prepared for the eventuality, particularly since it costs us n= othing to
=C2=A0 =C2=A0do so.


Regards,
John Levine, johnl@tau= gh.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



--
=
=


3D"logo

Bringing Trust to= Email

Peter Goldstei= n | CTO & Co-Founder

peter@valimail.= com

+1.415.793.57= 83
<= /div>
--94eb2c095930f7eb090553800ff3-- From nobody Thu Jul 6 09:10: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 97FDC12EC2D for ; Thu, 6 Jul 2017 09:10:31 -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 DgHMeVpnT3qZ for ; Thu, 6 Jul 2017 09:10: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 573AA127444 for ; Thu, 6 Jul 2017 09:10:30 -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 v66G9Ipo005605 for ; Thu, 6 Jul 2017 17:10:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cUWYV5mwwndAWQlHr4KDJn+FXTeZ97+CZsm8Y//KHt4=; b=iMeNFFmYl3CtxM/dZdjEtyryyrmfMSlmUUvhkpwfQYLCx28UHfCDgiGXNgVf0rX+Wf1/ InLUVjuGfmowz8543zzZe+uhwgh9Nljnm7id7GKJ3Fv8Kmwf3/O9cWpvVdJ3Wv/0hYCv 6z8pjkYKwTQKHcV5du8od6NSQ/tZCQcAWP2HxuLuAthN4m67pl3j+0R2MDvSG5CpGg7q kmjOT7GmeNSeowslPjxoAWMX81vmAblGi6wJ8ZeNeufYx1N4WqNyGSyDQdnX49VNdFL9 x3qJt3ZZvdKQyytISewsPP/x3nVPRYedkuONCTm7B77+kGCHznVEFvyvasJgGzJbzHSq Nw== 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 2bgaw0b3nu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Jul 2017 17:10:27 +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 v66G6apx011375 for ; Thu, 6 Jul 2017 12:10:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bhm6e0s2h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 06 Jul 2017 12:10: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; Thu, 6 Jul 2017 12:10: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; Thu, 6 Jul 2017 12:10:26 -0400 From: "Salz, Rich" To: "dcrup@ietf.org" Thread-Topic: Draft agenda for DCRUP at IETF Thread-Index: AdL2cmBUfpDyr5qUTfWga+NmtT/8OQ== Date: Thu, 6 Jul 2017 16:10:25 +0000 Message-ID: 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.32.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_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-1707060277 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_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-1707060277 Archived-At: Subject: [Dcrup] Draft agenda for DCRUP at IETF 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, 06 Jul 2017 16:10:31 -0000 We have 30 minutes in the agenda, but there seems to be nothing scheduled f= or the last 30 minutes. Administrivia, 5 minutes Note well jabber scribe, minute-taker (there will be gifts) Introduction; charter tweak John Levine, draft-ietf-dcrup-dkim-crypto 15 minutes - To hash the key or not, that is the question. Well one of them, anyway Scott Kitterman, draft-ietf-dcrup-dkim-usage 5 minutes - Changing RSA key size, moving to sha256 - Still RSA PKCS1.5; do we need RSA-PSS? Scott Rose, draft-ietf-dcrup-dkim-ecc 5 minutes - P256 ECDSA. From nobody Thu Jul 6 09:14: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 469B2129462 for ; Thu, 6 Jul 2017 09:14:15 -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 9h9TECJZ-WWs for ; Thu, 6 Jul 2017 09:14: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 863E8127444 for ; Thu, 6 Jul 2017 09:14: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 v66G7XkT024766 for ; Thu, 6 Jul 2017 17:14:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=4XtsH07VFUrpmPL65rAW2bdIE8Wzx01639lT95BUkRY=; b=B2A6CPi/fs9c5fQ7J8ddgutBwEysNU4T0Wh+tdzGrldyr2UExFs554le7sgQ3qZWem5t KQ1XZa6shrthoBzIT4UzzrVRhEaQMUaRXg0qkk3zPM2b/vWFK1qpg4jUQUQ8Wu50jF8g ol/yGBLpvAvlNP+Pim8z4Mn2c/VaMTEg6GBp9AGGDdXFUUk7gol0wIZue3TjuP2+tBDa Qz4I1YqMJ+TmKDCwOwUyo31c178V+N5LgF7n82h6SdkuKzmFGA3ImLnOsmKU7GhxQbO3 kPgU7zxKEAnOzIdiFvi8m4Tm2FKDFZK4DDi3qHgx9A5ibqLzgnjH9wNNEEDHQy4Qyu/y KA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxw9k60-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 06 Jul 2017 17:14:12 +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 v66GBDgx030480 for ; Thu, 6 Jul 2017 12:14:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2be72vgwqv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 06 Jul 2017 12:14:11 -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; Thu, 6 Jul 2017 12:14: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; Thu, 6 Jul 2017 12:14:10 -0400 From: "Salz, Rich" To: "dcrup@ietf.org" Thread-Topic: I do not like the dcrup ECC document Thread-Index: AdL2cn5JfQbYF9myRj+u6KjUEOWtEQ== Date: Thu, 6 Jul 2017 16:14:09 +0000 Message-ID: <14cd0f4ff66348e495e0a7d0da8adc0e@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.32.233] Content-Type: multipart/alternative; boundary="_000_14cd0f4ff66348e495e0a7d0da8adc0eusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_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-1707060278 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-06_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-1707060277 Archived-At: Subject: [Dcrup] I do not like the dcrup ECC document 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, 06 Jul 2017 16:14:15 -0000 --_000_14cd0f4ff66348e495e0a7d0da8adc0eusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wrong. It specifies curve P256 and ECDSA. The IETF is moving off of ECDSA to dete= rministic ECC signatures, and also moving toward the 25519 and 448 curves. As this is a completely new signature use, unencumbered by an installed bas= e (and probably codebase), I think we should specify the mechanisms in http= s://datatracker.ietf.org/doc/rfc8032/ -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_14cd0f4ff66348e495e0a7d0da8adc0eusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Speaking as an individual, I think the draft-ietf-dc= rup-dkim-ecc is wrong.

 

It specifies curve P256 and ECDSA.  The IETF is= moving off of ECDSA to deterministic ECC signatures, and also moving towar= d the 25519 and 448 curves.

 

As this is a completely new signature use, unencumbe= red by an installed base (and probably codebase), I think we should specify= the mechanisms in https://datatracker.i= etf.org/doc/rfc8032/

 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_14cd0f4ff66348e495e0a7d0da8adc0eusma1exdag1mb1msgcorpak_-- From nobody Thu Jul 6 10:04: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 4357313153B for ; Thu, 6 Jul 2017 10:04:49 -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 rLzQuidakpTt for ; Thu, 6 Jul 2017 10:04:47 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0094.outbound.protection.outlook.com [104.47.41.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 0B55E12EC30 for ; Thu, 6 Jul 2017 10:04:46 -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=HaDvhopK+0miSz4h5qS68QMfZFeOvaFTI8Qb8vmD4SI=; b=VADNIV0a9/xan3GeTMNVRAQhSNP0AJJWgWMnKKjGXwlOEvhw4if3k8a+LUmqkI1ARU+9YTcLjiC9UhLzuWmQtukdoIt/JpKXSgIVvUuj4hu131EXzJVADwqzUDqda7F10MYuV2MU+zQqREyFJ7k4U/OkDOVMxw3FLb26TAhIPRc= Received: from CY1PR05CA0016.namprd05.prod.outlook.com (10.166.186.154) by CY1PR05MB1980.namprd05.prod.outlook.com (10.162.216.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Thu, 6 Jul 2017 17:04:45 +0000 Received: from DM3NAM05FT052.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::207) by CY1PR05CA0016.outlook.office365.com (2a01:111:e400:c5a4::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4 via Frontend Transport; Thu, 6 Jul 2017 17:04:45 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; akamai.com; dkim=none (message not signed) header.d=none;akamai.com; 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.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by DM3NAM05FT052.mail.protection.outlook.com (10.152.98.166) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1240.9 via Frontend Transport; Thu, 6 Jul 2017 17:04:45 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Jul 2017 10:04:44 -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 v66H4iCF022951; Thu, 6 Jul 2017 10:04:44 -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 84C7F1144E; Thu, 6 Jul 2017 10:04:42 -0700 (PDT) To: "Salz, Rich" CC: "dcrup@ietf.org" In-Reply-To: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> Comments: In-reply-to: "Salz, Rich" message dated "Thu, 06 Jul 2017 16:14:09 -0000." From: "Mark D. Baushke" Date: Thu, 6 Jul 2017 10:04:42 -0700 Message-ID: <96041.1499360682@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.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39850400002)(39410400002)(39400400002)(39450400003)(39840400002)(2980300002)(199003)(189002)(9170700003)(8676002)(8936002)(7126002)(356003)(4326008)(81166006)(626005)(5660300001)(77096006)(86362001)(55016002)(305945005)(6916009)(2950100002)(50986999)(76176999)(7696004)(229853002)(110136004)(6266002)(189998001)(38730400002)(7846003)(76506005)(97876018)(54356999)(48376002)(53936002)(6306002)(478600001)(6246003)(966005)(53416004)(105596002)(2906002)(47776003)(50466002)(5003940100001)(117636001)(2810700001)(6392003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1980; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT052; 1:qneOsBIkOJl8FcTtSRufgfdivOLN7XW4/6kVu+HrtoTCs+Tulvw16kM5va1XD51rV3bvWeoRpBWWG4l3zc58JKbJGVQYuOY8GSPSmN8wxAwm/EQliYAI9MVVOm3sdGFUoMzoMXxDqX5tKmuC+UUMPZeVcxQ2awwYA8xHdk54AgJdIqAwPLcSyb75hNI0bVcix3WZn0gUjJu8Uun54T4GzV+97ZLl49WrMf9bJrTpNluSrWcZ9X8GrHQbHV3MtHApNzagjjSJVoVbpeZgAM/G184ta/JxCf9291ZxdEXY5u13GdjHo4+cWD5dDKmZMUQJ7L5JE58uIdP9zqwkiWlrxnF07p+3e2hnfwirZrNe1bLQUPbOMtovcsFAHysHitE9PQkmAqrutMI5vFbrSHcgHhLcdQeSnnVyUGbJ5t0fLmw5dS0eiYu1zejKtmKoxBOXbYnZlN5ThSUgVNIgyliKQN+muib+4nxHE2bHrDYJdi+wPjiunDSrwsRr1M/ME9QITyH7A5qh4xicbBbM/7J1i02BePe+0xdTMkLoK2C1WO75v6ZQnBnHQue51gou7WsjSpEZTPcJlXgRHxa/SnrvnK7YB6+aLgzEc3iNLS7jIYROC3EOBOvqRuPdvHjs6K01tGFhYGoOrZUEllA/iD2tdhLeHbNJ4SkCtWtBW+365iHgQlU0csy8JhMMMZMQmbYvHD6OTtAyNKhZ016594sZyMa+VJyKu13nOLLXMYV8HrU7RY3sg04j/BOCRAP63gRzVoi4zDlnu9Vx/0YnztkEPMWko96OobjMHZFWitE/FyFDBhVwWBDjG8h2jGcXbMaI X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0667610f-2e0a-4f77-06c8-08d4c4911a52 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB1980; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1980; 3:phmXid4xXRLtT6+UqdFZYz75yitftKaktlBBPxgWFAX7RqSZ3+Kt4205ysll7/ub66beun8+ByhW2bEJIwagwPbO1V4CWXBJPCJKv/hpGOmqIYglO5Sp2wKqgkr6bSNTtQI0D1mVariQKjF1Rc9CHLIv+8YbjxdR8dhyBaQe1pdySHvjP5o99+klCudWPk2XJEEUNGoAnXGBCgkqed9NEcSXAlxY9rybobyMRlxeb+6fb6j++/8qbQmhUBfyNsgCxscdWslYgjhdwRyhtayF8LRProsl4s3DYoMJASP+YhYwRpqpwTkYCBwvIrh/CDWdYxmRdBfH5gpzb+0nNaJkfEHUc6eLmA8RyQQgWELvBy60ZbGJUhvDRjIyZwfOTpgOekanIY/zHxXCJ3kY8kfVpd1ec28Oim6B8pgnZqAbYUKXU6Ck0oV2Zl141gxqm7NjvI08cyDxWyUYwEM7qSaR6VdRfoih88wzJdlTDDhcIJyZUCiiupNPHeIQQ3CP9v89vqT0d+3IGnLyeWBKaTkSdw9Bkmy36TSyUygDQKNDuvpYnAWnUPo6JhmZla5oCBuDci8mAVaN93niVzR8Pmu4eH7N9ZscxiAfqpJXNIratLnkTyZJhV7NRH32KjtqMtLaRsD8anGsOcTLirPsft3IObbDFwXswOPSxTk4OG3z6JMxOFKRZoNOQHG/ufAK3nLTc4mBBoAN6Mj39mOCaOD2s5HLuizu7mxRTwnCGvofVaZ24lHmv6lpKB/f6hoh2gQXBqENx84cGBm+G4t1+PGKdKADkBvzfb4GIHxaa0wgMrLCGMooz2QMe+BdqgvWP7Zu+zIzamBMWHjlUpSUzB/fv2EN9SNmi+vUGp3DOrm6JAzwXOH1bp4flSX+vlBQmxmc/vR+I8anVuHc8CJCQBSYtA== X-MS-TrafficTypeDiagnostic: CY1PR05MB1980: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1980; 25:uhjXXhVdU3CnlErl1ZqkSYfSgvACtFIhJCet3Ryfu9WA5qF7XCSytweHGO8FZTgEDq88WFei9tNYlknFpG5lZXa6BPsrI+EeaOT13G923noF+uyAorQa9PFj/1M+JKMQzEXvvzxKNM9dMA3gopJCXVx8Y48slUSxmyItyqtSGJO88u19nEl27PXHoAGyun4ok6iKdOisVAUbZ83GjQTJQkYEwHvltleXJmO5g8imllZyUF+6N9kzMWqa7+VrLRdMCgp4hg3gR54h53f7y8yxQ7d05lIJ8VvZ/GftaobpAfkkb6Dh3lSR67VDYJEC2ssdstgOxDy+gRQ/l5E9/rQ0oWQ061gQ4tmFFCPX7Og7YfOv2nIr8Va3sQyygODEIRvB3R6Tcfw0ubpY5mktz4/0lT5yxE/87IzJYW0R4NTlFuzK3/3NizXokLhY4HzWkhZGHFfE7tFg55nJUxjjOOhjn+SLi6EQCGTJszBz00UvPpoqJtEtu4s90d3HiXwZYP0H4oxFJtxbzHpstP8YbaokWCsEPJ/A/TH3Bj2GmfCAXGw5vr1mlUp4rh/Uy+H1xPV9Do73dTQH2+F6dvJpZxvkhKKqeHI062bI68dxObhBpOxO7iwFWtIEp1FaXv9q1mTvVtQO1Rmw4TtkOwQgmPV9BcDequK5ExWmto4fd7ynLiKQaZ327YE0QVrnOr2JvnAakXV9F3T7X9uh8qg6aWdOP+6+zsVdGD4v+dVs/rUFWzUFA117DtUnBuvhEdpQNHeddhqOpIcOkOt39/9kXImJkrrTTx7U4vw9GU3wpxZ7FimGWpGx8ZDmIOa02Jyl01nlgmKgid4cNpMgokW/0SH07F6jVJv61YexY73ytxZrm8hDZRf/i14HYIKzcA0Y/O3SVK2jBh+tAoKXn5UCtKDtSZgwM+r9mndY5voEAe/ebi0= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1980; 31:VHAFrL0Od0Sdnm+QfrSS48RNQwKuK/UaOfnFHsUhYYLvfW3bhWoA5w5/NT3YFqDP3cRWr4wRo4LSUSwGxVjZBOaUvvJiCc47hTEWgUqh+BeoZ1iszwsIKw2NIrOGqYCdDqHtvrXVHcg3U9i5b80Qn86XlcKEBLbl3TbcAM8tozAVpsqabhotWe+Q6AFl4eVOEgcjQcbQDG7qRNCm5WM9BWHPZNeiN+i3bk95vAU8/mGm98PtmI3TpmfnmQs9BZXK80nqn4cfhlnlnXEbhlEF0OxsM90YZkpBkKK6ePwWDCNladmp5uybq4szc2WyuV4sgMahGk0m2hM1KlNUEE0fqaxt3heyEkXI8YoZDcPT7jw/bEH3TYSu+o3Dr6q780uH7W3N7TeG4q4U5/ijA2UMklnCyBN+jfvCapcfcmPfygmPdWeihh+PuFiOidDu6pDwVcf8n1szpi0O7P7/b6tMqx4IAE20aLoL2dmFcOEp13pfc6tedPz0sJ9PD2wGI8gjxwle6EBc/2GLkkz6GauyfPPysWiZVYPL0/8Ntr8iFqN5jTAi1ctkRtv4zNOX9+5c5rTmHDwfN9zZYhb6sG03z2BBSdVrAPim3e3AGMcc7VeZtQ5XwHWKwpMZpNu4mBRZpv4LsultSz0wY0+Z3Fn4/k24xxikLAz2E+t/0DlVuwwEgQixfxjhAdxVRng/he3zN/TW5o0+bfxYKFdx+9XnZw== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1980; 20:QNThI+fljbB/UW2MU0dpL8Sf+MCBjAwN/onlc/H2rL5i2wNJpNU/Z2NjS8dSe5xEDPT7w4+i1+gnYeqp3eEyg9mgZ+21amM1vB2XJSvSh/me/HK5R+0ggeR4e7MFeDf9znNe8uku77edE1h1OHMfGZKqTYbQySqFrYPMj1BP44EqBbZYagSsqkTYG2rla076EnB/pxPSZKtKJEiyJ4D8a2aMNXERhcnPaWPcjLG6adlXig/pwEV2dTMD7omz1NWLfn30IMoxO127ni3wLP6c4D/sFdM7ui9uEWPZQTMLvs4VeCBAdTOg4zSAig7fqPAZHfoxeUHWQr01P9Y4ZSVOzXiFLqE8Gdr0R1OWYwB/uGkIGqhob05W7kP7o3QiMZyAj0SE7mOqIxq/dv/Wool0BKTIuqqELlOwDbjCCoesO++jH3OHMw4b6yyrA9bXklQWyoZ+kTM0LsIoskC6Gry20ltGrXqQmwyxiL04SLzjJf27E+IGTcZuSd8noxr2csBv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(133145235818549)(120809045254105)(236129657087228)(148574349560750); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(13018025)(2017060910050)(13016025)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB1980; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB1980; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1980; 4:fs6IzboEH3JbzW7bGis1CYoqA+6HYa9tEtAObnc1qx?= =?us-ascii?Q?yzZ1IjdcxiRg1jZRwd2mxr02655+TAQHF8KuQZijwln2WJoBGaXzqfXu13mW?= =?us-ascii?Q?qfemYb9xvRUb/H85CqfOErG+ps9rGfaVTcxJeK5Mey3TdBr8ROrfNnScH/Jc?= =?us-ascii?Q?SFag4M/sx6ESyp17tEqIwLk1QE3JNr/w7L2Vl7F7LtCtEdcgpnBGbYa7D279?= =?us-ascii?Q?Dln02JHAOc+W/YTbOE8rpXM29bt3DxuplV0KaX8+kZTOILYuAWtzc2eEtWNy?= =?us-ascii?Q?SLzPG+NaN1OrbckSzeBQ3JurWMXCULzLXsPMPzJ5eorB9z9CMBImR+8O+qGS?= =?us-ascii?Q?cpqa33uqmXhVkAN3iH/ke4KRuNGoeveIhxHX8d/nUDOreJ4h44f26DRR/D2P?= =?us-ascii?Q?YIlol6ykfOuCYjxNLJ6Diwk/1zefxq6CzlUmm5K1GBHG/QoLXMjnUE1XPeWp?= =?us-ascii?Q?4GNGBoceF8TS2yNL8Ei6NBBv9qM7YrmecnWL2O7YCfGLZDxxrVEKA1SttPEM?= =?us-ascii?Q?m/5+I6QzJYth8pOGiqPkasfS1LZIy3NoB39OTxkE91+2A6NPLeFr6RxFpcRy?= =?us-ascii?Q?WOgXl6PUhtUmgu4sQ7Ibek+tkwFXMN80kP0io5pl6wirnXqt4YOJb+seHGar?= =?us-ascii?Q?O+FoVRfRWMZaMrNrWuiXwc6/YaZfcWTgSfhoNUO0u624bSBoAQGPYYmfQXHE?= =?us-ascii?Q?2t+ktGJJ54IcXlyDyqVSSbrPmzMqC5is7ldmtyYR4OkopqAi8wX6ov0zdQGT?= =?us-ascii?Q?VL+wvosrvUG2iTP8zPvH1g3HwCSxZEwUr/1L9Evlfu7NxOqGDU77J4WwCAEs?= =?us-ascii?Q?7h6YgGzu0lEeSXxfY9MSz470Hr9Dmqpr7TXv6e2QwFbrVads625nZ8uMvWpH?= =?us-ascii?Q?3oE8/Kvms+vUBB7N38qXjN1lOR188pISrI4m1bLPFJagMOHVKgSDb9z3P7dS?= =?us-ascii?Q?vbtoS2299YTYpNl+y3RMuc+JV9zDTNIQQVlLLQlaxirLBlkc49gIkaEf13uC?= =?us-ascii?Q?qzbNwHijT3zHkFHrWHuPzzRZ8g6pL1E3hZP6xiqh+uD2fmC/wOYnpmos9uoj?= =?us-ascii?Q?YjJ/+Fm0rexUrx5gkr8xrzlG0pMxGdB0qBj7GY0S2ZKGmS7Hz54b0+NHybzC?= =?us-ascii?Q?PTJpLEBvjzdcvfLE6jzbdFfU5MLPYbydgYRmqZTzYvoTFy4/sSY9izj6b+P+?= =?us-ascii?Q?f/+qGQujMQrB6G83ZKirdObj7FvzW0RwFRIvH5xeSvMkPM668hhdpCy1sAA8?= =?us-ascii?Q?42LVtBipP/Im6Uk6rkPSHv5FR5locMZRqpTuVegNgQX7NJHI5U1miTu08mMe?= =?us-ascii?Q?+XB30LwTYHUILH88gRSUl4s+HViSZBm1NGp5scHDifkQO0ArEZsSOjfgsknx?= =?us-ascii?Q?8KezhxnLdmKFuRHMVsQjG1k5AjcWBvhKDJ41YPjYLULRKoxjqECEfsrZb/v/?= =?us-ascii?Q?37Vr4K3g=3D=3D?= X-Forefront-PRVS: 03607C04F0 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1980; 23:9YAfo+1q+M+n9QkN4RkpYW6Fmr7QW7R/AlL0rcjtn?= =?us-ascii?Q?Md4Q8l/l7f/crKDM/mjFkg6eHpR+UN+3AxvGZ2YfH8unP2SSYMiDEGF9eMEb?= =?us-ascii?Q?03xlPmcNUARNW8t9of4KckxeUbisKKasTtvzBXJLvTlxsueKb/9TfU0dw/1o?= =?us-ascii?Q?C3bLNa31lthFPeFDx7dCf68clzhO7fy3K9NOlnowJtOXBFADBuI63/42Nb0W?= =?us-ascii?Q?i1U46Oxyf23YOquCGbEZJxanGW4jvpixpw4IhZVhC9ei03Wpybb827nhZbns?= =?us-ascii?Q?7/wifGyEWyjd+3Ux4qK+NdiM/32ySGaGktVGwn1jm1lkLrYBL8vDtzL16b73?= =?us-ascii?Q?06uc2ou6c3xXrNNjFDQk/MxsRux0TMdRt6jnzvhgg4iJeUTZ31IqYCRY8Lb3?= =?us-ascii?Q?GJIpkYnummBog7+Nlt38uukCsWGq2oRM3jX3Qs2WAswEAaCo+iMKUpzZg4Iu?= =?us-ascii?Q?Z7FqGFkQs03AWmpGjo+lBIU5bFJv08sugB9kCzuYcV3HZUpMuJyaLEQ4V+at?= =?us-ascii?Q?8HrVt17RTpwd3DplVu/Cz82TgU+zLwjx5cfL7MMpChyBd+iIsl742qmiglsV?= =?us-ascii?Q?727qOT6Xb7rI8E5OpQ6yhdwc1x6HKnJOXWvz/1/xSG9Qr/1iJBAOcuCt3H44?= =?us-ascii?Q?yy+qYDuPiNth+XtZU/vLqp4jHxVy57Vn81nkIEXMWwmM7LxS14LZPgjzTcW4?= =?us-ascii?Q?EpUTnL1StWkr/LU2ByRRQVIUdSVdtrTHANxaVeh0+Y7wtZ1T5SiV33kPCxbB?= =?us-ascii?Q?wQg/IO4KXWMOav243thVRgkQ4pO8PfJsgZzNFrgZ8TXCVrJdc1BmOF+e3koh?= =?us-ascii?Q?Ga+bn6Bl1YzZHuKBKfj6sHJmvjY/ICwmGvFwSCXXKO5BM7tvHPyFsRWDGKNM?= =?us-ascii?Q?BaqwWd9EyxShM2ONRd3yXngbUf1twYsUFyJSM4sj8BSpbdwpuFxWe6ZL8bT+?= =?us-ascii?Q?iGrwaJJjGJDZD0xn7p769ZKvhxWqvlpNr1agYJZ9eXLxD9n13GjK4fyoqVjj?= =?us-ascii?Q?6snwkeZQkATnkV2u9qa3nNyUChzgm/mWmnC11OglUKCQQ/jH5YAL+NBMRI8g?= =?us-ascii?Q?ieaLnaOXXTFJUuYGPy08JhKO8BrAgl9iJBm0LUuJy/hcSbonqQ9bG5aCshDy?= =?us-ascii?Q?zg9Q0JguaAayAVTXp5otVBmZOp35/sWDvb6eltphlrasjcq+j/vxi4GeXiqN?= =?us-ascii?Q?ItU7d776O5kpGCFy2HvmrhKDzt73RfiXLRIivX1G2CezYR6KrThk0GJ7bRqa?= =?us-ascii?Q?Du5ivZtKZvJ7h/p4uIldBdnTIX+Z9Lu9EzWlokdlxehjbqD/fYgarD+bDgeb?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1980; 6:gF4aOCb5ReXVWYPYNfiekzgHhDfWrARLxcQ4hXZE9W?= =?us-ascii?Q?UBEOtZOHWu1SPnFPNO0+XKSAxY139/U5wkV2Bj+UvJ6b2hqRDrn0TTYOoDMu?= =?us-ascii?Q?cKrbtXClZdqMegcERQePK6qNFfx2sI2l0NaG5oAS5MvdR0qEYsaPZ7/AyTg2?= =?us-ascii?Q?xe1bZffotE7QHlrKXoVBU2EHwito0e9Ff5r9aWlfetfxu+OPaYd5mswJeffb?= =?us-ascii?Q?TkyujlEUEQ8m7srsoW81U5nSfkdWlKkC6vqM0gOfmkQuH6aXPMqLYz3TmcaR?= =?us-ascii?Q?RQUQLvwQ1sHu+MBoeuRO1PXXgv/7b7VNqtBS4nEbWx9bvWw61+ZZFyRVlTS8?= =?us-ascii?Q?A1ujskoRHrfYHFnzKgHtAgD1CjmxIaawJ+FMuWLoE+BmBdNAKb3oThjd62vx?= =?us-ascii?Q?jfEXrnFKZbf25h8bqkdwXDprkr39LBg0KbcQxBKKlYIYmWzjNDZPtVpc7gLT?= =?us-ascii?Q?SzuRSPdaYxPySouBK3FXo7EAsjZirSS8rrmmUBvIDiIszFckuiWoPKchGRpw?= =?us-ascii?Q?yx+v4ZlOKGn0JtrjzMdHWolUcPvRqBpt15eBtIZ4Ls3iitF799FUSVHaSgt7?= =?us-ascii?Q?bTUY01NgW4YbxK5f4N2e4/FgfbJqM1jDaIWAeFbenn9Xp5OhREwe/kRfJGgL?= =?us-ascii?Q?a57hNHcgocAGDBMc0IVVDC4JfHTY0Md//K9Lb48S69LaQpGYi+w69fNG+sAP?= =?us-ascii?Q?M3968/59HgY7Z9yadEY1Kw9QDlZLmqWoVWmF0ucE2/TVGchQ0b//ePUe8TDv?= =?us-ascii?Q?v5UfMETGcWo6FT3Qp2sPxa0WBcLQtuUz7pirqrRumIZU5TKJNXtJWM5+N+AX?= =?us-ascii?Q?iNqbP9bwQVaHDy/IrN9KgyI3r/HdmZANkCNJwgJ3DuI1kQUxvMR+gC3dJDLV?= =?us-ascii?Q?cvmvMbt1/8CTRlAbO1bDS8zW7bggmMw4I3VajxKYD/yt7xJywx6u8SXWfdP3?= =?us-ascii?Q?+CJ6q/48zRAYEV1gH8EB16czheO6Tf3gdaQZ33nrdZ9etEgsKgMJOL3msbll?= =?us-ascii?Q?lyPmFXf2paRc0IjCefFv/2?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1980; 5:kpwTeX6MGT8wuJV/pAUkhVKFdddanZzMANKU+GerGzdlUl14+AlQy3SIRbNXKS5eRsK7HVbYJQq0tHS7RPTl8LNPCOsh9V8LDRnvpqKvUdJ4FdcZdWUvFZ7yFGlNE6uIvp9S4U3oi1onha6AwdIYsvZyCuhyJ+hy14d1W5DpyBuapmJvGkmlmBjdkL5v6wTy6njYprJR5yukm2f/vg4z+XqMGXKlzqvQO85fRBp7aQjFGAGAi91IIj3RN1IJorpZHD0OT4S0976oGHqEEnDW9UHDBhvu3SL2U4cJLTVjWyrtNGVMEVhoB1XaACca2oO6TEg4Ns8q28jrNkkRuq+Anc8LMxIeQcCBoyTExinz9n/Vo5IKLAKOtTAth8T+FVt5PEYK2Jxbi/0AG6VkZChrrsqj6zSK5ze6VBSC3Q7NJWs4kzwmevjF7qwebdxhf15sj8I/DVAfNPgmDJSOlxinNncoNWIc/kbZbZepvwrUn3a2BwcDC7p+Ci239j38/p3z; 24:3DffsFwaOz0PZxnIKymU8JaYj6QfrlAPe4lbihdzBNbtuNPQCpVzbhBJCVvViTlgt+ruNc7weSjqRpg6vo1BIe6Gvt4nnS/Nye9mXgWng9Q= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1980; 7:VeymbVApCd/2Zx7mucSyDqDaThfV/J9rOFMpypu3GCkw3EpCD/pBsNNvVWFgCTlXCSobwXIOtWE7KmGTsiNgLC/7Y/QJ86Hmj4Wg84203Jpo/bTv3uKTxyiPLX5E+/185/Kh6rhhKU3VVRPqH6c6AhWbOGtNCCRM/fsi9XRALeBCdBBsJ4OD+u2drj8pr/lNcA92jrOcGonyKo5DYR0V9qEookA15Sc3CnEnvtTV9RItVBXdSJvBAbxWCIqrjekZSyFTah3425s1mE663kH534y1IyyBfEPhdujkVyKNWApDxo5CABCH78Yl6T+WYZ+226Bxa8GBlXheqLNDyKsI/yAPJTI7SGbdN7EmJ2AzJbQ6HaNaUthEnrYx4XEbbUkzkfHP4Dxq9cnNsluudYYn5Loev8vYoeMPV4vpmTeXSjSJSUjB70HPUut5erdM64UoZljwU9Tqjrhed/WTgB4csMmxygJtOvBjLsZ85hFsQR4nCoOH0tGOqOigcgPK6r+iKnq+Ru1fCIcE2az5VPFRaN9Jswo/quyrn6M3B7IrWD27Ke3u93BN3a8oRud957Te6f5KYT2bpIRcA2hbjpDBmp2Hyh8oF029qfKsvgyAyvjVWWLgIbmihRswMEwFiIoPqkx3/meB8pAltV+WeR62mYuO/BcKBK1xuPFSuKjIH2/oE/DKkBzfOy7sIcdFz6/Vo7r5kYaL3dRdJzzSXHf2mWD6zkjXXowkqasCs6JtB/BWbLgGS620NY2vO3fkyFN5yKggZEmMf2ZDQLyI2SnLiEXaRej+vvl5gc/neMZeYDI= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2017 17:04:45.3842 (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.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1980 Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 06 Jul 2017 17:04:49 -0000 Salz, Rich writes: > Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wrong. > > It specifies curve P256 and ECDSA. The IETF is moving off of ECDSA to > deterministic ECC signatures, and also moving toward the 25519 and 448 > curves. +1 I support use of 25519.. > As this is a completely new signature use, unencumbered by an > installed base (and probably codebase), I think we should specify the > mechanisms in https://datatracker.ietf.org/doc/rfc8032/ This seems reasonable to me. -- Mark From nobody Thu Jul 6 20:20: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 6276712EBFF for ; Thu, 6 Jul 2017 20:20:15 -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 TpOhaQoCM8Bk for ; Thu, 6 Jul 2017 20:20:13 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 9CD3512741D for ; Thu, 6 Jul 2017 20:20:13 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id v202so20430402itb.0 for ; Thu, 06 Jul 2017 20:20:13 -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=pQ7Y3vNHW35gytng7kCc5XW+3tB0iNjbuQgdHBUoszY=; b=rPBqWj5JuwpFc+2m+1Udk7XN/R2oEgQERoruiAz8kKQBlFJEG9Jiz0uG/Xy2h5zJft S2PWNqNFA8eQCh9JjRaEZ6MKfReCq93LMCH4wLBDVZLF5NAAxapkqNQ052377rb8RD4+ 7tQ50Vcn9VTwXDbipFpX8p8DHt3fH0Z2e92yrp951PY4gx/dz7DX6A6ujwRpnilCo++P ax3rua5lIfHlNUGXZFrAb10R6EkugB1es0AuDNKhWUFVKzzZyX6I5bbE3IVX0691O+8u rlivUuBjOglWPzRYc+GZeW4Se6c5pEq3wb7f9KVg4cGmZ5VYOJU9C/zlK6avd7V2RR69 2a3Q== 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=pQ7Y3vNHW35gytng7kCc5XW+3tB0iNjbuQgdHBUoszY=; b=Uah85D9tlNbGf0ncHMg8XaFV1X8OtfrO9aAqVIdUbXw6iAYs+D02RD3xqZXZ74cCiD WCfZey47b8vBqdShImuIxsqd58OPEvlfMYeL182S+TGa+g9rAusIgBgyT/EMVX5nPwCG cc4P9/tp7CQRFc2++/yBuP+wtHs5H3DtuZzYeuY4QDVq0w59kACF8boktbVegeYNxIeT miqJDStypKwTXYXzE5GG+XAoYEaRB8MFJ84ZozPIyCsz9eysRmPQ1CkZS9HRNBe3NXaZ FCVqvGVUdL/u+n2n3BkEDZsKyeJPs1ROOlKO/A3mGB0kQBqYK3zHPtV9G70+MxMM1XRT B58A== X-Gm-Message-State: AIVw111ARGS9lRwgtvTBsKqxOoKrZG4sZwLc1fePxX1CsRpzZtwNSTR2 gyoHe/gWhwTyu/gtpV21pFZXKvK2EIoecyg= X-Received: by 10.36.36.135 with SMTP id f129mr1143818ita.60.1499397612714; Thu, 06 Jul 2017 20:20:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.129.162 with HTTP; Thu, 6 Jul 2017 20:20:12 -0700 (PDT) From: Martin Thomson Date: Fri, 7 Jul 2017 13:20:12 +1000 Message-ID: To: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 03:20:15 -0000 In its current form, I had a hard time extracting the goals of this document from the text, even though the abstract is clear, the introduction isn't clear enough on the specifics, see below. I think that Scott's draft does a much better job of the SHA-1 removal and attempting to do this all at once in this document isn't helping its clarity at all. (Also, this practice of patching RFCs by providing replacement for statements in them makes reading the update as a standalone document unnecessarily difficult in my opinion.) On hashing here: hash everything. Ed25519 might be the last algorithm that has a key that is this small. Uniformity is more valuable than space here. On PSS: I think that the idea is to retain the existing primitive with the fingerprint-based mode, so we should define "rsafp" as using PKCS#1v1.5 and accept the shortcomings of that. I would support the addition of a PSS-based scheme. Introduction The framing of this document needs to be improved. The point of this draft is to define new ways to sign e-mail messages that are stronger than what the existing mechanisms allow. The first paragraph here is good, it establishes that the existing mechanism (the only one!) is limited by real practical concerns. The second paragraph should instead say that it is introducing signature algorithms: ~~~ This document adds two signing mechanisms for DKIM. A mechanism using the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032] is defined in Section 3. A variant of RSA signatures that uses the existing underlying RSA primitives is defined in Section 4. This RSA variant uses a hashed representation of the public key that allows for use of larger keys. ~~~ Section 3 This could be more direct: ~~~ 3. Signature with Ed25519 The "ed25519" signature algorithm uses Ed25519 [RFC8032] and SHA-256 [SHA-2]. To use this signature method, the message is canonicalized according to [RFC6376] then hashed using SHA-256. The hash is signed using the Pure variant of Ed25519. This signature algorithm is identified with the value "ed25519" in the "k=" parameter of a textual key representation and the value "ed25519-sha256" in the "a=" parameter of the DKIM-Signature header field. ~~~ IMPORTANT: This should be "ed25519" instead of "eddsa"; we've started identifying a single primitive in other protocols, and you don't want to contort things if you ever have to add Ed448. Section 4 In the same way, this could be direct. This is defining a new signature algorithm. The description can explain how this diverges from the existing norm, but still be a complete specification. ~~~ The "rsafp" signature algorithm uses the same RSA-PKCS#1v1.5 [RSA-REF] primitive to sign as that used in "rsa". However, this algorithm places a hash of the public key in textual representation in place of the DER-encoded RSAPublicKey defined in [RFC6376]. This allows for use of larger keys without the need for larger textual representations, which might otherwise exceed the space in DNS TXT records. The method for signing a message is the same as that described for "rsa-sha256" in [RFC6376]. The signer MUST also include a "p=" parameter in the DKIM-Signature header field (see Section XXX). This parameter includes the base64- and DER-encoded RSAPublicKey that was used to generate the signature. Textual representations of "rsafp" keys are identical to that of "rsa-sha256", except that the "p=" parameter contains a SHA-256 hash of the DER-encoded RSAPublicKey. This limits the size of the textual representation. In addition to verifying the signature using this public key, a verifier MUST also ensure that the decoded "p=" parameter that accompanies the signature is equal to the SHA-256 hash of the decoded "p=" parameter from the textual representation of the key. This signature algorithm is identified with the value "rsafp" in the "k=" parameter of a textual key representation and the value "rsafp-sha256" in the "a=" parameter of the DKIM-Signature header field. ~~~ IMPORTANT: The document then needs a new section defining "p=" for use in DKIM-Signature. This paragraph doesn't seem to be adding any value: Section 3.7 of [RFC6376], on computing the message hashes, is not modified. Since the key in the k= tag is known in advance, it [is] included in the signature in the same manner as all of the other signature fields other than b=. Sections 3 and 4 Both Section 3 and Section 4 need to explicitly say that the "h=" parameter is not valid for the algorithms defined in this document and that SHA-256 is the only allowed hash algorithm that can be used with these. The current structure does not permit the use of a different hash algorithm for the fingerprint; we should be prepared to define a new identifier if we ever need to provide a SHA-256 alternative. Nits Capitalize "section" throughout. There is a reference to FIPS-180 in a table, but it doesn't appear in the references section. From nobody Fri Jul 7 06:16: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 254B91201F2 for ; Fri, 7 Jul 2017 06:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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, 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 CNXu_lvuZCIo for ; Fri, 7 Jul 2017 06:15:56 -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 CA1BD12EB5D for ; Fri, 7 Jul 2017 06:15:55 -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, 7 Jul 2017 09:15:40 -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, 7 Jul 2017 09:15:54 -0400 Received: from [129.6.140.7] (7-140.antd.nist.gov [129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v67DFfJr017168 for ; Fri, 7 Jul 2017 09:15:41 -0400 From: "Rose, Scott" To: "dcrup@ietf.org" Date: Fri, 7 Jul 2017 09:15:40 -0400 Message-ID: In-Reply-To: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_27B7CCAA-85D8-4039-B96B-E4BC054F076E_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[646, 2077], "plain":[362, 540], "uuid":"5FD52A28-8256-46A9-859E-C26F42F09247"}] X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 07 Jul 2017 13:15:59 -0000 --=_MailMate_27B7CCAA-85D8-4039-B96B-E4BC054F076E_= Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Some deployments have an additional requirements on using FIPS-140 approved algorithms. There is work on trying to get the Edwards curves on that list, there isn’t a reliable timeframe for when that will happen. Until then, this is a proposed option to get those DKIM users an option that they can use. Scott On 6 Jul 2017, at 12:14, Salz, Rich wrote: > Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is > wrong. > > It specifies curve P256 and ECDSA. The IETF is moving off of ECDSA to > deterministic ECC signatures, and also moving toward the 25519 and 448 > curves. > > As this is a completely new signature use, unencumbered by an > installed base (and probably codebase), I think we should specify the > mechanisms in https://datatracker.ietf.org/doc/rfc8032/ > > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > _______________________________________________ > 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 =================================== --=_MailMate_27B7CCAA-85D8-4039-B96B-E4BC054F076E_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Some deployments h= ave an additional requirements on using FIPS-140 approved algorithms. Th= ere is work on trying to get the Edwards curves on that list, there isn=E2= =80=99t a reliable timeframe for when that will happen.

Until then, this is a proposed option to get those DKIM u= sers an option that they can use.

Scott

On 6 Jul 2017, at 12:14, Salz, Rich wrote:

Speaking as an individual, I think the draft-ietf= -dcrup-dkim-ecc is wrong.

=C2=A0

It specifies curve P256 and ECDSA.=C2=A0 The IETF= is moving off of ECDSA to deterministic ECC signatures, and also moving = toward the 25519 and 448 curves.

=C2=A0

As this is a completely new signature use, unencu= mbered by an installed base (and probably codebase), I think we should sp= ecify the mechanisms in https://datatr= acker.ietf.org/doc/rfc8032/

=C2=A0

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0

____________________________________________= ___
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.= org/mailman/listinfo/dcrup


=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

--=_MailMate_27B7CCAA-85D8-4039-B96B-E4BC054F076E_=-- From nobody Fri Jul 7 08:06: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 1BFF9131627 for ; Fri, 7 Jul 2017 08:06: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 ZSqCWhzl3T1A for ; Fri, 7 Jul 2017 08:06:23 -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 C6FB913160A for ; Fri, 7 Jul 2017 08:06:16 -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 v67F4RWH021416; Fri, 7 Jul 2017 16:06:13 +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=34WE6U1U3c62E6a4djeziG4Iw0cttksPR1FixdvdnqU=; b=dBVIfz+vqMAcB7OSDiH6oqFq5BdmNHF0qXGhHXM/5AYM/e4yODvKBF+X0zwCbDRYHLG3 lnYxeifU8xXVQ6nm6/+tr5p/7rVTgXAQLrVbVgrXVTdN8uW4sMlp6i1myHwYFkW9eLDw cHMkny6HMhSO/FqhiCpMFzkaUojyECPoU7+oMZ/ZG4uKoudFCfCO8RWX0FsfRWqgeXqa 2742k+f2/T2xxML3RkTG+DHgV5SLS67M6WRFhAreBUZBDizu/jvTY3ZuK+HIDQ4kPoMK AMZRz6nwQ/5PCdUBCHyZUor5hu8vPrylx5ggaTcihcfdkMw9Y9fLkgOhQgIy2z7uZr7G +w== 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 2bhjxwe1fm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 16:06:13 +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 v67F0vKq016254; Fri, 7 Jul 2017 11:06:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ug270-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 11:06:12 -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; Fri, 7 Jul 2017 08:06:12 -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; Fri, 7 Jul 2017 11:06:11 -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; Fri, 7 Jul 2017 11:06:11 -0400 From: "Salz, Rich" To: Martin Thomson , "dcrup@ietf.org" Thread-Topic: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 Thread-Index: AQHS9s/65iHlD+jTJUCp9nqNsWi4aqJIdm4A Date: Fri, 7 Jul 2017 15:06:11 +0000 Message-ID: <6d4b76c9b42848f1b18c42ba22895993@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.32.247] 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-07-07_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-1707070249 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_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-1707070249 Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 15:06:25 -0000 As an individual ... > I think that Scott's draft does a much better job of the SHA-1 removal an= d > attempting to do this all at once in this document isn't helping its clar= ity at all. I assume you mean Scott Kitterman and not Scott Rose. :) I think we should= refer to documents by name to avoid the ambiguity (and keep in mind that t= hese are WG documents, not individual authors's). > On hashing here: hash everything. Ed25519 might be the last algorithm th= at > has a key that is this small. Uniformity is more valuable than space her= e. I disagree, and so far the WG seems to be leaning against this view. We'll= talk in Prague, of course, but right now the only voices for hashing are y= ou and ekr. From nobody Fri Jul 7 08:09: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 5E294131686 for ; Fri, 7 Jul 2017 08:09: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, HTML_MESSAGE=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=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 yXpf3mTiB99I for ; Fri, 7 Jul 2017 08:09:43 -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 9AE90131665 for ; Fri, 7 Jul 2017 08:09:43 -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 v67F5ubn031212; Fri, 7 Jul 2017 16:09:41 +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=cFea6usBVYUxMoU8fzwlZYt2BnPIbrnoquNHmAlQC2c=; b=FMse5REMI4zdW6buATkhubV8HU/wQh+sLb482RJDWVtDqdaxUAib27g4gFandgPU+7FQ IO1Gm/A6gUjiKYaHsYn3If/45kDoxnJlGGLrm/Z9zGLRvcVxFvtaxxwGGH06uTa230Bs 6OrEeFhwiO4z0quUtFsPbnFBZkMPV3zE008DdPihjVLUUhsAZZn5Bak9/ZjJDQzfrPYV 1AqbGkddyO1RiGxuJ4/hTYVsAeZszaGkXbQWPtBQMVt50s9hx0qD9ej9muPxmW6B9Tpq TKZLAOI48JUxUe3rhQpSfF2+qq5naSOTnY/EMZGo3Dwm9EOmx/9ibxDMwGcXWTlEuqvK ng== 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 2bj3dy1vsv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 16:09:41 +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 v67F6khw019861; Fri, 7 Jul 2017 11:09:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72ug2fw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 11:09:40 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 11:09:39 -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; Fri, 7 Jul 2017 11:09:39 -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; Fri, 7 Jul 2017 11:09:39 -0400 From: "Salz, Rich" To: "Rose, Scott" , "dcrup@ietf.org" Thread-Topic: [Dcrup] I do not like the dcrup ECC document Thread-Index: AdL2cn5JfQbYF9myRj+u6KjUEOWtEQA0in4AAASDp2A= Date: Fri, 7 Jul 2017 15:09:39 +0000 Message-ID: <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> 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.32.247] Content-Type: multipart/alternative; boundary="_000_3509c4a1901e49d885e2dd3205a95be8usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_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-1707070250 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_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-1707070249 Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 07 Jul 2017 15:09:45 -0000 --_000_3509c4a1901e49d885e2dd3205a95be8usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgdGhlIGVudGlyZSBJRVRGIGlzIG1vdmluZyB0byB0aGUgRWR3YXJkcyBjdXJ2ZXMsIGlz IHRoZXJlIGEgZGVwbG95bWVudCByZXF1aXJlbWVudCBmb3IgRklQUyBQMjU2IG5vdz8gIE9yIGNh biB0aG9zZSB3aG8gbmVlZCBGSVBTIGFsZ29yaXRobXMgZm9yIHNpZ25pbmcga2V5cyBzdGljayB3 aXRoIFJTQT8NCg0KSWYgUDI1NiBpcyBuZWVkZWQgbm93LCB0aGVuIEkgdGhpbmsgd2Ugc2hvdWxk IGhhdmUgb25lIGRvY3VtZW50IHRoYXQgY292ZXJzIEVkMjU1MTkgYW5kIFAyNTYsIG9yIGF0IGxl YXN0IG1vZGlmeSB0aGUgZHJhZnQgbmFtZXMgYW5kIHRpdGxlcyB0byBtYWtlIGl0IGNsZWFyIHRo YXQgdGhpcyBpcyDigJxh4oCdIGNob2ljZSwgbm90IOKAnHRoZeKAnSBjaG9pY2UgZm9yIEVDQyBE S0lNIHNpZ25hdHVyZXMuDQoNCklmIEROUyBvcGVyYXRvcnMgYXJlbuKAmXQgd2VsbCB2ZXJzZWQg aW4gY3J5cHRvLCBkbyB3ZSBuZWVkIHRvIGJlIGNvbmNlcm5lZCBhYm91dCB0aGVtIGRlcGxveWlu ZyBEU0E/DQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVy LCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hT YWx6DQo= --_000_3509c4a1901e49d885e2dd3205a95be8usma1exdag1mb1msgcorpak_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNp bmNlIHRoZSBlbnRpcmUgSUVURiBpcyBtb3ZpbmcgdG8gdGhlIEVkd2FyZHMgY3VydmVzLCBpcyB0 aGVyZSBhIGRlcGxveW1lbnQgcmVxdWlyZW1lbnQgZm9yIEZJUFMgUDI1NiBub3c/Jm5ic3A7IE9y IGNhbiB0aG9zZSB3aG8gbmVlZCBGSVBTIGFsZ29yaXRobXMgZm9yIHNpZ25pbmcga2V5cyBzdGlj ayB3aXRoDQogUlNBPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZiBQMjU2IGlzIG5lZWRlZCBub3csIHRoZW4g SSB0aGluayB3ZSBzaG91bGQgaGF2ZSBvbmUgZG9jdW1lbnQgdGhhdCBjb3ZlcnMgRWQyNTUxOSBh bmQgUDI1Niwgb3IgYXQgbGVhc3QgbW9kaWZ5IHRoZSBkcmFmdCBuYW1lcyBhbmQgdGl0bGVzIHRv IG1ha2UgaXQgY2xlYXIgdGhhdCB0aGlzIGlzIOKAnGHigJ0NCiBjaG9pY2UsIG5vdCDigJx0aGXi gJ0gY2hvaWNlIGZvciBFQ0MgREtJTSBzaWduYXR1cmVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZiBETlMg b3BlcmF0b3JzIGFyZW7igJl0IHdlbGwgdmVyc2VkIGluIGNyeXB0bywgZG8gd2UgbmVlZCB0byBi ZSBjb25jZXJuZWQgYWJvdXQgdGhlbSBkZXBsb3lpbmcgRFNBPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0tJm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1lbWJlciwg T3BlblNTTCBEZXYgVGVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNo U2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_3509c4a1901e49d885e2dd3205a95be8usma1exdag1mb1msgcorpak_-- From nobody Fri Jul 7 08:25: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 C8A2413163B for ; Fri, 7 Jul 2017 08:25:14 -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_H3=-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 4423r3X7NYm4 for ; Fri, 7 Jul 2017 08:25:12 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0118.outbound.protection.outlook.com [104.47.38.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A315C13160A for ; Fri, 7 Jul 2017 08:25:11 -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=yq0Nn1OwIKBTGU7oKI6qoGIdvU3+CKORZb1uRDpLv5w=; b=VUi/dIL7349pniaRowSCp650mijzPZGf/a8sqKAVccGwffypZ7EbWA94qLdExJd0S6yP5v+Pbb3l/GhsQ8VlYFaEGuqOJ/cCAwJT1q2LD0con2DGoLSXdrBL788dP9QlIGd6BFe+mdK25UYzihR0X54SNUg8+EPzm2Zm6EEaC3s= Received: from MWHPR05CA0014.namprd05.prod.outlook.com (10.168.242.152) by CY1PR05MB1978.namprd05.prod.outlook.com (10.162.216.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Fri, 7 Jul 2017 15:25:10 +0000 Received: from CO1NAM05FT017.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::200) by MWHPR05CA0014.outlook.office365.com (2603:10b6:300:59::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.4 via Frontend Transport; Fri, 7 Jul 2017 15:25:10 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; akamai.com; dkim=none (message not signed) header.d=none;akamai.com; 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.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by CO1NAM05FT017.mail.protection.outlook.com (10.152.96.124) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1240.9 via Frontend Transport; Fri, 7 Jul 2017 15:25:09 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Jul 2017 08:25:08 -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 v67FP744032574; Fri, 7 Jul 2017 08:25:07 -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 65BD011446; Fri, 7 Jul 2017 08:25:07 -0700 (PDT) To: "Salz, Rich" CC: "Rose, Scott" , "dcrup@ietf.org" In-Reply-To: <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> Comments: In-reply-to: "Salz, Rich" message dated "Fri, 07 Jul 2017 15:09:39 -0000." From: "Mark D. Baushke" Date: Fri, 7 Jul 2017 08:25:07 -0700 Message-ID: <95440.1499441107@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.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(2980300002)(189002)(199003)(9170700003)(5003940100001)(50466002)(229853002)(356003)(106466001)(53416004)(47776003)(38730400002)(105596002)(48376002)(8676002)(76506005)(81166006)(8936002)(86362001)(626005)(4326008)(7126002)(5660300001)(7696004)(305945005)(50986999)(53936002)(76176999)(110136004)(6266002)(77096006)(54356999)(97876018)(6246003)(966005)(6916009)(2950100002)(478600001)(189998001)(2810700001)(2906002)(6392003)(7846003)(117636001)(54906002)(55016002)(8656002)(6306002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1978; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT017; 1:N7SJ48RWFX2QdlV3jqX7D+PRKos0Rsa6thI3pfStO4KYmMeOdAJpi0ftKWPQDhnfZPC+ENpq0J9fDYBs6sXmpfo0w6Q8Yi7NaGo244NjyP94KHfYDvK2v81nCECxZyG/M/9jxV8g3HzwrXheDX1t3E90+CS/fKBZXlsvXTBQDTBB9uT3QHuXNwJc3vJkvnkWgVTegJHd3N+Q1egTMe/aj5mO2R0swlZafZMAjrzZIV2pMxoAQBHRyCir5pSKSfFcbxxpzDPQBXNjnlpcdjyJCoddAUYUC/B5WOLuFIboxr4TzkIuA2J7Rc+UDMKzRBMSzwOZ7KnpkV+alUr4k+Q06Pc/tg54uQ4HsQo4XrDq1QxzmSjwN7K/U17vgZCf0IYypGRJc1DMolvdCYY2256bOG+WmM8xAxVQ8t9hyFoO/1J7/IQYOYKMxpvC6GTnO+3L0qteuYWumreDRNKaKFpKk309ifzzuWba3yNmoixTTgBpPA5HN9PBXaQI+wDho62PQX3QdSgb1bD1eCQ0heUIbgSI5Eb6fhWa1swsS2IKQ6YZFxetq4bj1SSMJz70dJ4KL2u5eDYXCy2m+YnCBCq4nSIk+pZZRhJhNWM0L+YS6q6RGTLKiRClDDEAmph9kLLnA+6kNg4RbDSDVryoF2WVYUhgCKrpPJcmsPtVLSKf2iZvqs0beqBSpvtOzTwxGgXxN58Ee5sjMWLg1XUeTrfcVzhGbj8/YyKn5/nWk9kxNPNfWFae6X8vtYl0X4SpmI2Si08YWgfA318vjAErWfqefcCLlihwBJ1HddXMZy4xtu4/MtP6daPo3Sk34NBdeFJ2QYYfmGVVgHfGPDkhT7dYtQ== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 21e47835-155d-449f-36b5-08d4c54c5afd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR05MB1978; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1978; 3:VolPAMja09vo+khyOLbW1HQGa7AzCVRONMOvSAzrokN7pYt2pgZWQ6lnsZX3Ic1d5VGVB9Aa2NhOHFldFJIXXBH5eOAS4/+GcHGVtSBwIiooM70kGUNrcx15q9KrVsiiI1aiMcX3DSQ/2hJQ5+TPxhkCLjCHh0+q5qAyb/CIw2OtfKgAp0ndTvyNo6p26o8LTE8VoRJI82zcYCUiJrb5syVdntdX/niE08GWA6zDxSZedj8nxjOZsnN+JdeUL/UH+OibDh5gOQ6mpXmY7n0aRYlMkjdzSTcT/Rpjd9O+YZ5MANMs8mrPUQT4c+xvF7qs/pnyT1Wb4S2aRP1WSdqke/pDw3UNL/qEZGhr0e5Hz23Wzuvp2oEfEWMNuEL/NSbEwBEymc5vZd4yVlb1ZI3qZ9NqVqYB19anqeS5I52gn7Lshxmyc1GiQSQlmClyeumWVvKnY/n5qV6SfowGEpF86u1nqwKZj2Qzh54R4599IlF1IXmd4xn6z/ewhz3T+UQZTESrM2lsA9GueUiinQMmAVcSd9mhqaINVVFk9dBVPLvkiAXB5958pX0waFnWQZIvzudoi8/8NFzLjYviLa6xmSr6M14J31S7B7pABifgMREq4z//cuoR8oLRXgp/A/1cR7Pcmz3OBcBjlbnLKfqfRAADxOkuMdOxw8fuYRTIfCmLJ/k6KxcvI4T3tsPNHNSCwq67svHXvyQgDH+z4U9bF+AE5zrBIpFMSbFH1YKyBhFKQLQRVuogD1IUFIXWwSFLi3pwizES5e7nDIH7IRhD8a9Ze7tzSg0CA643zMmcGdyEizbDDlfgAINBJsVoNCIdDMBjVtozQRaYJhnIaEZdNYcDc1fzgbSNuwcY+oABJwmqGyhXhBbUaeAjcrB3eRWgRmEetmKr8c+Qi3SI9cVxpA== X-MS-TrafficTypeDiagnostic: CY1PR05MB1978: X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1978; 25:oyyNeqjBoTz2zN7HJlbSVbGNgChz8N0X+R/ihQhXmPgu9aw9c1RmVOXXlL5lhJeq7pgT+F1r9tAJMI17A40JlxGRE1c2Q5eF/o8K5KVZSuMNPzkjaGNyxPQI7n7qb9TKMBp0AqlaI6vymLI/xABPpHlVTrqFIt+MH9ALSzCo//lkFMsaJ7mSsel/Bokx3eqlRGXefGiHZsjMl9muEaHcV04+VVEIzvKREpkc4QnzpOGPr0I1cPgevsVwMKS39IPSJzW+Enm4/icHfVF09/zehmI1R0mObIgalmvhfn/0840Q+x1ZWyoQgChXXhKzRluMXiVWOdAEkNwgmTC5/mMf7YMFw6E5uGisSXJv/QBtEzYlCQoz2sE9c540Z+HJsU8VqonURKxhLvUgwltTNAH4eNEXCc3IOFCGrKtRXk/ZxGt51TS6L9CbPz+83zM6avjOyQSSLW7ZNbWEw2VDT5/ViAG8eyi+UA1KrOI+ubK52Hw1jGSkLimKZp1ji/Uj49Uga8Xz7Iq0YGIrUEkyourGT1JNbLuXpFhpvqzF/O8QS8nN7XcsryXkTgkW/OXLt8SGi7DTWX4ULoBsHy1O2JBZ8E6E5Yr/CH1zSAwliiVuXSFNnCTE1uw5S4+tgiCVZHfZbOQKmSr1Hfh9yqisXYwwGMr8nnMZr9a8YjiGa4cyoaU+/Ft54dnP42a05k5FpLJEMseMLB8sJQJt/I23Xo3eVGyH7TC0fH8MGIwQRk1t5wXKoOXI0FhMwzwGlZFH05aAIcOQFoaGJA9C4XHfTIJ5GMcQrYEyeeqesWK8PZ2LWdeyDY9iDG+oXoR0YsyynUwT0m4+OFtOcnnVX+sKWKAeuS6hKYBO+ZeA2CJLcHoS3V8ogHW2/CcVObczgjjxKga1zrUXNFCjn13A5JV6Dij96hau9yaNhB1CWgVyTge8kG8= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1978; 31:hmW2S3k0IYHZg0x5ZAhDT6EZKrcP79wvlkGkpDJMcVVeK6uPX+sqEDrYI1sJw3IhpdOUSIkWsH1wX0HIhHHzEcTkZp0rNhl0/Tz9KrkqnjBMNrKr+x7L20vKeCgNHpUbgU5IE3prWEoNNlJ0ENTNw3VkbbVNDvWNQJHLycIvM0R/wcJ/3RlQxdaCcQK3sjlzBmB253iRZDCYnfus3OGghKVVuZagnjXUUQjN3eZQ+Cia9ubDbROxF6gFGBgbWhQgsQ32eR0I5IHXOlQ7JC/BRS5FUI1bd6XY5vDKPG+X2NiKIr6hX6pc0PLCMOnQ4X8PVLOm+GzTclnZ1x/x/FCQbgjF96q/mfLR9Yhhbuu2yceghfxstj5ilRR2+d29dCfwjw4JOnmXdje1DZBZxApl+qW5l6iGYEmD9WhvypQzJ3LzsGDPgTG66YslDkou8mrZyEouqpQSrkeTOv22Zyg2Z4XejmQOKUQwtqFRlcJUHFRb9K9ep+qE4g8cTC2T8Le3g2+XAMgmqUx6Gmjlj8Gm03OyUW80z4KeuGG3yn5z8ns7nK8mJbkY7gGEM452vzy7AWgTn8IKjqAj8Anf+6RXJpYm14d2vSXhDxrcIwq5xZ/cN0VWrSUnjjmhCyEPJ1VVQ1eF0XGycQ9lk5z8NhHlb3AqqTdhYSS/FnSi3T8ll+SLWTc2kWVUqFWikS8dRFB+ X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1978; 20:xTMHy2u63jTkxVHuxKHxYW8shCr/hS+1dok4dphE8bd2/88UdZYdV/TCooEzO+Li3eQQFuuza3BtgwuIJKO6i3VnCeFKn1QlJAsxUoEgcZi/ZEE+SgCBz8y46OBoCNk6PS2jFLXlimGpapIz7VDeqhf0kGVQoGPDBlhpVB4s+F9XmZfpbLEmJTFc8EDPu+INvF3v+hpTZY+AYVzyFJXOLRnOUYNTWS5waULw0t2Jcosuzop9uk9KzCgtSSC9M88mXnRVbCAZKwK8G7GfCQEmRQZCEwSWVOhBAcRwN/4jnDCQk8d87XleywJRw6ndOZ1ZkML43Bz2r1w1bhj9XrA3Kn/1uspMJhRlF7jH0ntHA6tIE8mCekTtXsR8/N124pJhlULm6nrjF+WkYx6gaEgAVbXA1qgpNbJqm/+OqDztmDUuLiaKYqH2PNh5dK0UVq+vBAiWNskCbcF4XiooffWb2nekYBQXTQAmKPCefTMMn3myWrN8yU+0r+jd86DSFeqO X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278178393323532)(236129657087228)(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13016025)(8121501046)(5005006)(13018025)(2017060910064)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR05MB1978; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR05MB1978; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1978; 4:a8Jk8qGOLnV3EdsU+Yj2DXfgPb3UkXga6Vi17sFTYb?= =?us-ascii?Q?c42fpYTaim8lU/dARcQjOWUIqZZ/Mp35EqajtJWLHsV2LejwvJi8ymjDd7WQ?= =?us-ascii?Q?pmOKF2nTLqs60fhi7rvpAbb7ZIm3+mCBlCg8eA88rPgx3J55Mc/Dnm/Pjwmc?= =?us-ascii?Q?4L9h1l/t8TLi/ACFF9RRU+8BytF4C/ZyRvKp/T6NsUvxgnZcNnZayrqwzeu/?= =?us-ascii?Q?P95fiV+2jzJVj/ASFiGtiiNMenxKS4ih4BMWbwNBkAkx50xXGMB0YaO2J10U?= =?us-ascii?Q?3KVCKeaptWq/bdgiicZ0zNPnMaMTbCVETySPZDSEvlTc93ZgxYSshCQjev7d?= =?us-ascii?Q?4FPXdADTAV25bynRrJ57LjTkKYDykootLdLESs0ZMiO36+sRN0Cop6tudtFZ?= =?us-ascii?Q?3b64T2gwvc41IWtp9WtqzY7T2Wc6Ab2v0GEyCW+FcLwAz4t+wflfOlF7/+5d?= =?us-ascii?Q?s2X9nn3I9Jh1X8Ce9LIxCsBD8vouT6c4ao83TxRYhiJmpZSTHOIrOSdGGHmG?= =?us-ascii?Q?6ISncnP3NXrY5AZl2PkY0Kr0u7ERBYn2VyfXRGSKXhQkowdPyFVR+LcX91kL?= =?us-ascii?Q?HLkB/2MAmsOPBaJ0H2T5oADn4VdK++K+P+UXt8SmjyJMsV+RZ3fVP9mq6KPs?= =?us-ascii?Q?289FqHuWNCvxbiGTbF2FpAHn7DDWYB0VnecFh0F60Hiw7CYz538h+6e3RjhT?= =?us-ascii?Q?+zzMja/UPCNyliGetuZNpBNf9t/EH96sciFtAgSd+3p9uZ4hKgh2iz7Wz/ps?= =?us-ascii?Q?On40qXPfE22QwvK/i8PnXG7JgYJgsGu1+vfI7eP+AVjs1MvVaPfNyUlu3/QD?= =?us-ascii?Q?E+9S8CtbMThO4I8fH5DzhxC95OLzgOuZEBuY6aivg/fsTZaIWyCSiLzaDdxx?= =?us-ascii?Q?7gffpJDhUJbJKfY1D2NPMZMkM53jF1DWYwfFT8sPP8rZjJygZxZV19AywDn7?= =?us-ascii?Q?9YUCOS41k31Z/aWFlkxJBNwjifFKynbvjmejqJ4OL1TnG4kGDMYzUDPiIg9i?= =?us-ascii?Q?m7iQ0Mzhv29aVTbcSagqQDm82Mvj5aefRrWd3j6/eUEmTKxjxbQPE1lcUM6j?= =?us-ascii?Q?AATx4h/+CXxy6NAX7/M2XNmdgbYqUSQ/pQStKAmgvnOuJ+wJIk88Vpy/cZEW?= =?us-ascii?Q?tvCRutTXwndFtthYAcloqncVsocaq2jYBba+fXFSRXm1Yu+OidlnafE6jPFL?= =?us-ascii?Q?n55L+ECZSeMg+/cb2/aFdrlvYfqdMx8isWyb7pM25SY3QB3IZaAuAR36SVkd?= =?us-ascii?Q?dw7NgYVTUlCNpH2aubbQD0zJvZU0c5hjIqUD/sNPDPSobdBVnu8UW+9o+S4C?= =?us-ascii?Q?hu32+Fnbrm/dZZJDP5SFfexYgMhRBIhjHDzoxSX812gHauT/RvcXUU/CWFfY?= =?us-ascii?Q?VUMg=3D=3D?= X-Forefront-PRVS: 0361212EA8 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1978; 23:5mxsPl1E3g+ux9B4iRdvESbCF4mFRu8dcM6/JoFoX?= =?us-ascii?Q?CisB2ZMMFFpLhVnm/IyEIcoylr3g0PWA60eW1cw1EpTjvqaXJ31VzvgtT/zA?= =?us-ascii?Q?kO4V7TWgjQ3sIDz6prEyXlH3cNqjBxNqh979HpkNfndQ+shfJDiyxFGFoiBo?= =?us-ascii?Q?jGHY8k3xKJ3noZkay4EJpkW4uagrGF39sBE21h5aX2jC9Hhwb8u5N5otMqFQ?= =?us-ascii?Q?4IYoCIk19a/1lwPVjR8UxBuv9DX/ghbMQlPp2bfDmtr5SeBVECZ/fsmYSEae?= =?us-ascii?Q?UBsNd8N3tgiygH2IulLNyIn+lKAgmZ2SGNJpuE+5a9hq3kpKpxCfNrhLwF0W?= =?us-ascii?Q?G5eh73Dz/lH8NmXUv03yHH4fxValH+UyJ3uJpR/sF7ER+YLv3imqkEOrU8T7?= =?us-ascii?Q?AXmnzpLIdP8aQaw5uUyxUiSjmoD08Wo8WMWzxrvEigD/MqSdxBIZI9Kvb+8n?= =?us-ascii?Q?fM4hIU0/fhbWUdY2TvdRrDWcQVK61folSpc4cqFJ9Zb/yDdIoudjH6nx3VSJ?= =?us-ascii?Q?8ARL+9S+wzlr0Wttb7dRI1P/rQnRCSHsoA0alFFJFeX6oT3AdmcWHSKv2UKW?= =?us-ascii?Q?AVwbDwECfRKMff01ZKQjX8i7KS6ruLQd6aTTomiH6Tm3AmCTaqmAtB3URKcu?= =?us-ascii?Q?q0JaDpw7ZbOSTc+9c9jXEMdk0VBG7T7zD0UMWWu7xRP0qp3eH2WVp0z1LIf7?= =?us-ascii?Q?/dFouWxAJavpOHAhG2/GriNG3JW1jf39yDFE/bvDp25nB2T/w2eb5WYNHzZB?= =?us-ascii?Q?6LMywWVq8RCwtnxLUHssKUDxS3x+Cxbg77DNEJlCfE6tJfWAtuVv8flhVb3+?= =?us-ascii?Q?uGTdpRwGjMnBioXQcToz1qP7sNmgyDTTdyj3JTBvqDf3mah7XWVsdnvh8b2G?= =?us-ascii?Q?GByP6ptIY35TOpCfhR+SPplr08xoCR8ZWjbNt3xCWXV2IAU3Y/XwlV8PahyX?= =?us-ascii?Q?ZI3XuUEstChT3VgrJeR0q1A25WZv/4absVJmLJY3XqSl2HbvqYepylCRkoqp?= =?us-ascii?Q?mtRfh1iyYQvZGojHpFLlgdGKd3Vad0muHGDYL/EEOIBnTOOnuIB0D78CdGrz?= =?us-ascii?Q?4PIqjHhhdRbdYfhhrTflIit5c8nLAG3uOfLoo+xVxBC+Vq729fblGwuWnHJ+?= =?us-ascii?Q?4TFkrmq9nxvYup9I7DPG2D+bS6rVCKDBnFVRbBMGfi6R2tvqqLZiTYWOMVPl?= =?us-ascii?Q?ubNPcS6raJx2ZlNNLtqrEYXAbySV/c+cK5YFf280vY3gVC4P+nF25/gTLukN?= =?us-ascii?Q?bzGrl8BKJBHI6ipbPU+LghB6FEVKxKRhuhB/6hDeS5jj3XkX06/kk3OOuEIP?= =?us-ascii?Q?Vokazo1zJvbdjlauweNfa6h76g1Oasdygdv6IsaIrEtWUuWtfXQL2Aw8OMv5?= =?us-ascii?Q?KArLA=3D=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1978; 6:VXLnXs77egvjH9bAQeqHqMXmKwf8mT162NlDvbEs8p?= =?us-ascii?Q?+FHXRfwBQZFyR4nB5Ds97h1pqTO/SVPwSEnz4MmxQzH3v1RNzKqeEw7vyJPD?= =?us-ascii?Q?gTg+OOxRGJecaqn3J+jIXy6JvYjmWauDbAC7d48wr+SesQdjt9vkSgmaks7T?= =?us-ascii?Q?xZ7eBe29Rt7mHGXkpwi41bcjBZFeIr5yLFJeSDC8wtjEIIL+c3KGQM1d5bTu?= =?us-ascii?Q?Tcsqjsk+T+VeUtURE+KqrPCWI747ss9rLd+qUF8yva/WoGAe/NvydMKqqyXI?= =?us-ascii?Q?WU+14uxURY36qO+/f3tL46P6k21/llw9WrKMuKnIctG/PEPW5fTI0MftnUXi?= =?us-ascii?Q?PsknuBG8LLBp97k9zFo//KgmVU2gX/544rofegxoUDThk0XD1dN2tViqFOqW?= =?us-ascii?Q?3eOq2QzB+BaH3F1Bt7o0lDFpnBAlmHxaDIiFrCXmxAg/PK/BKx0m6Dkd97Cu?= =?us-ascii?Q?Bn4f+arMkf6PFI9tMzB1/dg17t4PfRkq5rBvLenfuv8ObLAHlnziZLUbVLgJ?= =?us-ascii?Q?BcChJiNKIGtOK5S4AR6fbTvtvsrYrata/WkG/CMhvFzDiXVgNPIMshgEm0Kc?= =?us-ascii?Q?BTfmAnek6/GwKbQHmuUpHcaS0x15aAUjfr0PxapQsT7P3Gs+HVnMb+F5XZbn?= =?us-ascii?Q?gxySIkpc+FoWeDfJgULH47RXGKS4tGmvk9Tz1kU5DqLUVsk7GuGr6N0dqUYr?= =?us-ascii?Q?ZmFyzLNWwWVL/G3M8bqhSHJ41HiVGFKJZdRQicO5KhZmMgTISW3Uv0rqOqNx?= =?us-ascii?Q?bVY8XVkIeWj/6lGQTUunrhWlUYrJF4ZBb3aewfgR6IRGZTC/P6fnrE/Zeonj?= =?us-ascii?Q?jy6qKKEk6jyOcFxnzSRYiqGEkZkjz44KnHBbUB8jKFNJxsa5OHz6Ff5I7in1?= =?us-ascii?Q?C/jDG7OTYKOx0m0k467/+ldAx2FWemvOwLUaanZ7BQ/ufm7waNcbeipeUu9T?= =?us-ascii?Q?BcTEjLWb/Lrh8HIXU2Tj61CRbz4A0ti5TQDr/xNBrPxFqw+WXl8ErfkaY0o6?= =?us-ascii?Q?EU7OKy6pr/vwqzBJp7WScC?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1978; 5:LkNB1FnrXCvr8qawHjFOK/HGfh26u3DB/jJFHNt7fkzzdgfy3BfEtx1CP5UPkI0q/X26yXNBgpxKTvrCLGK6DPC1UaK9O1N1yk6mYs7iFHRMbVcV8b7zLiVHEN8Li6QYQB62gmfnRYiGYxIft472l6ojCQftPAMw11EKbfvPazsH0KbOXglNaIY1Ktu6I6bOKrPInVBppVbhh4vgz6kpMvjzAYN5xkRmy2EDekHU6Ls36xMl497hDRUGd/gm/Mc2Fh5pc7dUALRdK6/DwaNaBWN8hk+UiFPQpxuujYikZXU6L5LrvuL2rwS7MhT9SdA6BJyVSQfnwHwmOAVe3uLxpa7OG3n6It0kgpPsxTkrEV5LIqaP4sevqCVwZafmMxa8h1uSEh1gF4j6IccQ/qvCP+mTcKfOWb9L6g4xTuqy1k6e6nQ4gVbFHwJcDXeIdoEtlb6+cOc1UFq8giNzA+4ACk7K84dCkUdTFXZFIGx3ydpJ/YsRwYp3sa+zrVMU6uRk; 24:HpbWYbeneYe1ULfbGOhCdiRXrjgIOJZrkB7DMnN3Je2WWZX/J6lzpmvdmNk1b9HvYxVgoOxA+W+Se/ipIfixWD2+Nxu5q17KCzieyxSLecU= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1978; 7:zTfHWV4nXDpcxrUPSBGnoJTolEL3zVz9STXDCaC/JY/hFvrG4VXQ37+416FiWZLTOZ7tU1PpPAZCnnMbLzudvslOrexL8LFvui7rdNMLdSL8pC/kwsRcPUR5Gv70cmISQBS0TQxipFRWuQi20+/u3nL/B6vyfbUQTWMVu8hREEEMl4GxG9bdeu1QEjW1w+XQA4lfs3JBYMTmhv8pcstqzgPz1zRXfapfJh47MWdCptKK0F+8YEEfkzwYYbxJylssfXkM2l7wNJflsHvGPKEZs5HwcdtLPbTBcmnUGM6LlCdKEMcVoY14nXRBK+PGV+TO7sLCdJO4u1PawtrOBeeJfkSOGOJRw6V3zIgPm0sQbNm8DZ4cmobrvypgxSruhuha1ix4Z5pahHyF7+LQ9l91dzAc6LasRBvjrNljqEl88b2Yh3COqeKLbcHLguuBqCApOU9OI3GZLbzPjUDgkJrV3Fj53Eua+gv1svIV97L4ntrEWFnb8nSk0eFfvbixiWA7FKN90ecNIKrj3UkRlYmPLt//5RfDtjuNloQzb/5mdy9ZhoO4iA9KNlwanhyz+hUf75hn5DEw5M8vyqKLoV0JpiKNb/T3fz8DxIRtFO0P9AhhIjVhyCrwHhYpWC02e25kM/R0kWsUOumqZoaN1qqgZR/bbRnNw/p6e3Jp++ptHxl45wV7LM1EepES0kql4Fw7/xzf8EqPLBANMnxc1bGmB+Gm8oLv4A52rGOO5TEZzZwz5C2I9JUijvBQ7n/LPdW4zXTIvHPHVhXFrhf3q8NL9VSsPv1+Jvauqfj5am7Zo+k= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2017 15:25:09.7844 (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.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1978 Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 07 Jul 2017 15:25:15 -0000 Salz, Rich writes: > Since the entire IETF is moving to the Edwards curves, is there a > deployment requirement for FIPS P256 now? Given the NSA IAD Commercial National Security Algorithm Suite letter (URL: https://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm) The trend seems to be against P256. Of course, "top secret" documents will NOT be sent via SMTP in any case. > Or can those who need FIPS algorithms for signing keys stick with RSA? If what I heard at the ICMC17 conference this year is correct, then I believe that Ed 25519 and/or Ed 448 will be getting added to the list of approved algorithms before too long (within the next year). -- Mark From nobody Fri Jul 7 08:30: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 B39C2131645 for ; Fri, 7 Jul 2017 08:30:11 -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 zKouckR6roXC for ; Fri, 7 Jul 2017 08:30:09 -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 4475B13163C for ; Fri, 7 Jul 2017 08:30:09 -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, 7 Jul 2017 11:29:53 -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, 7 Jul 2017 11:30:06 -0400 Received: from [129.6.140.7] (7-140.antd.nist.gov [129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v67FTsVw026375 for ; Fri, 7 Jul 2017 11:29:54 -0400 From: "Rose, Scott" To: "dcrup@ietf.org" Date: Fri, 7 Jul 2017 11:29:54 -0400 Message-ID: <4B905074-9A3A-4C03-B5E0-15928E2BA636@nist.gov> In-Reply-To: <95440.1499441107@eng-mail01.juniper.net> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> <95440.1499441107@eng-mail01.juniper.net> 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 do not like the dcrup ECC document 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, 07 Jul 2017 15:30:12 -0000 On 7 Jul 2017, at 11:25, Mark D. Baushke wrote: >> Or can those who need FIPS algorithms for signing keys stick with >> RSA? > > If what I heard at the ICMC17 conference this year is correct, then I > believe that Ed 25519 and/or Ed 448 will be getting added to the list > of > approved algorithms before too long (within the next year). > > -- Mark From inter-office talk, yes it will be added, and everyone wants to be added. Bureaucracy and sudden fire drills slow things down. I would like for this draft to not be needed, and one option is to just continue to use 2048-bit RSA for DKIM until the curves are added. That is the only apparent way forward for now. Scott =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== From nobody Fri Jul 7 08:30:31 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 54085131671 for ; Fri, 7 Jul 2017 08:30:21 -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 RgJCkgkF1JI5 for ; Fri, 7 Jul 2017 08:30: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 8ED5B13163C for ; Fri, 7 Jul 2017 08:30: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 A25B4C401EB for ; Fri, 7 Jul 2017 10:30:12 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499441412; bh=Au2oavYZzL2IGj6TmDQO0KaXkD9a080ECjadI0Wj86E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yA+ZjT0poDM7aR4jtjMajTb74Ojf4oM691UMFjaYBw09mbnn5O7Dfah7/bOPoj6h6 LsDEfKhMbRhU7GgPt1ElayEJ1Q257UddtypfvVsUx1mgyOowwbatk4lCmh/41jp0kV YGTcfzT5he1Ep9uE5h2lUBzs/7xgAQL86A+ZLopM= From: Scott Kitterman To: dcrup@ietf.org Date: Fri, 07 Jul 2017 11:30:12 -0400 Message-ID: <6025949.j6Hv4PBd49@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 07 Jul 2017 15:30:21 -0000 On Friday, July 07, 2017 03:09:39 PM Salz, Rich wrote: > Since the entire IETF is moving to the Edwards curves, is there a dep= loyment > requirement for FIPS P256 now? Or can those who need FIPS algorithms= for > signing keys stick with RSA? =20 > If P256 is needed now, then I think we should have one document that = covers > Ed25519 and P256, or at least modify the draft names and titles to ma= ke it > clear that this is =E2=80=9Ca=E2=80=9D choice, not =E2=80=9Cthe=E2=80= =9D choice for ECC DKIM signatures. =20 > If DNS operators aren=E2=80=99t well versed in crypto, do we need to = be concerned > about them deploying DSA? Every option you add, implementers need to add signing and verification= code=20 for (even if it's just more calls to appropriate libraries). As far as= I know=20 there's no security urgency to using ECC now. The reason to add it now= is to=20 future proof the protocol. If there is a transient issue with some implementers not using ECC due = to=20 internal policy reasons, I don't think that should affect the WG's path= . Adding one ECC DKIM method is enough. "For now" anyone who doesn't lik= e the=20 curves the IETF picked can stick with RSA. If the IETF needs to be mak= ing=20 different choices in the ECC arena, I don't think this is the right WG = to work=20 that out. So far I'll have to add the sha256 hashed DNS record approach and one E= CC=20 method. I think those are reasonable. Now maybe it's maybe two ECC schemes and adding PSS in addition to supp= orting=20 PKCS#1v1.5 (mentioned in Review of draft-ietf-dcrup-dkim-crypto-03) plu= s the=20 hashing. Every single option has to be widely deployed by both senders and recei= vers=20 before it can realistically be used in the field. If we just keep pili= ng on=20 the options it gets insane. Maybe I have to sign a message seven times= to get=20 interoperability: rsa-sha1 (because some people use ancient stuff) rsa-sha256 rsafp rsa-sha256 PSS rsafp PSS ECC Ed25519 ECC P256 If we specify too many new options, that will ensure none of the them g= et=20 deployed until there's a disaster discovered around rsa-sha256. Personally, I've started work on rsafp and plan to do Ed25519, but ther= e's no=20 way I'm up for coding more options just because someone thought it'd be= a nice=20 idea. Scott K From nobody Fri Jul 7 08:31: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 79450129B37 for ; Fri, 7 Jul 2017 08:31:26 -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 XNAIwPmomQr9 for ; Fri, 7 Jul 2017 08:31:24 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 8991612762F for ; Fri, 7 Jul 2017 08:31:24 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 84so11817623ybe.0 for ; Fri, 07 Jul 2017 08:31:24 -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=Rs4uGF0lVAuZL7BThX7ksPwyDyecWeSFDwrnq4X+PVs=; b=JNvy/pOxyjmv2RnslIy9dp9hVhuE0J7CYyCJzVMVHtwlLAL7PbPyzeofjGJAm2wRId 3VIU8CSFwUKSEaqUiogdPyf2y32Yw5MBxqImdf1UequR4Q3CfIRon/PBVl/0CUccNwFQ kQ1A+2IprEI0USY+CfS87QbHPswArNXYhPxlfRrYrebh/1hzaXItBKFsK1ui5KqNlS+x 1pxcEWA1MNHg0mYUrAqwtKLBUKObyCgIc+JZK3fTvDLytHkgby5FwdVSvoIimaMH82UH 5aSjZoldYxvvrBEkZ0K8RRnqZFhOCUW0iiEURifZIzlT71wJQL38W+xypQKNhUcKJqUm 71Uw== 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=Rs4uGF0lVAuZL7BThX7ksPwyDyecWeSFDwrnq4X+PVs=; b=NRZYxLwExfypXURMj+Vu1Uhi49301j6ALvUR29Zpy0PvKK5niGvTbqPr9l+larM9vu i+zyye6NwynNl8ic+kAGcvAT9ID9z6FDGn/2tpWZS89BlMrSQTRbI02h2AFeZm2soEWa XBfUuNYu3PPUeu9u2so2bWqFiK+jdYgqmgNyWiMP5QSmUlsWU0oNROjLOMGi+sqNQlyg Cj2C2PA4WL805r1ZMlvjw4gs+uAU9HitrUox9XHVmeejCaRrc1iAK2OKBa0kmsLIYmyw t1UAHecIDUhcnAzNS05RMn+QrgZmQgKJ9f75HeVP+3/M78ZnO/Z7IVIwqrIbl1u+131y 1cMg== X-Gm-Message-State: AIVw113mgWnM+z5g0fhUqjsg/dMaYHfV8MLs+4MwjBN2vAde8cqk7bNL ZlUcVuzZ9VCMAmIt7tjAnEb6AILdVDg/ X-Received: by 10.37.42.10 with SMTP id q10mr5152331ybq.71.1499441483765; Fri, 07 Jul 2017 08:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Fri, 7 Jul 2017 08:30:43 -0700 (PDT) In-Reply-To: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Fri, 7 Jul 2017 08:30:43 -0700 Message-ID: To: "Salz, Rich" Cc: Martin Thomson , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a114401080077920553bbedbd" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 15:31:26 -0000 --001a114401080077920553bbedbd Content-Type: text/plain; charset="UTF-8" On Fri, Jul 7, 2017 at 8:06 AM, Salz, Rich wrote: > As an individual ... > > > I think that Scott's draft does a much better job of the SHA-1 removal > and > > attempting to do this all at once in this document isn't helping its > clarity at all. > > I assume you mean Scott Kitterman and not Scott Rose. :) I think we > should refer to documents by name to avoid the ambiguity (and keep in mind > that these are WG documents, not individual authors's). > > > On hashing here: hash everything. Ed25519 might be the last algorithm > that > > has a key that is this small. Uniformity is more valuable than space > here. > > I disagree, and so far the WG seems to be leaning against this view. > We'll talk in Prague, of course, but right now the only voices for hashing > are you and ekr. > Also Jim Fenton, I believe. https://www.ietf.org/mail-archive/web/dcrup/current/msg00304.html -Ekr > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a114401080077920553bbedbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 7, 2017 at 8:06 AM, Salz, Rich <rsalz@akamai.com> wrote:
As an indi= vidual ...

> I think that Scott's draft does a much better job of the SHA-1 rem= oval and
> attempting to do this all at once in this document isn't helping i= ts clarity at all.

I assume you mean Scott Kitterman and not Scott Rose. :)=C2=A0 I thi= nk we should refer to documents by name to avoid the ambiguity (and keep in= mind that these are WG documents, not individual authors's).

> On hashing here: hash everything.=C2=A0 Ed25519 might be the last algo= rithm that
> has a key that is this small.=C2=A0 Uniformity is more valuable than s= pace here.

I disagree, and so far the WG seems to be leaning against this view.= =C2=A0 We'll talk in Prague, of course, but right now the only voices f= or hashing are you and ekr.

Also Jim Fe= nton, I believe.

-Ekr
=C2=A0=



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

--001a114401080077920553bbedbd-- From nobody Fri Jul 7 08:37: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 3EB2D129B33 for ; Fri, 7 Jul 2017 08:37:11 -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 wYagGq9TwjG4 for ; Fri, 7 Jul 2017 08:37:10 -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 DF7A112706D for ; Fri, 7 Jul 2017 08:37:09 -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 v67Fafjk018597; Fri, 7 Jul 2017 16:37:07 +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=kQG5wvUvcpWcy4xmGc7j8IfayU63y2PUqTzNOX50gkU=; b=mcF4VGr5/W1Yrx7cYsH7JMGzwDbNvMmYnstQkKCbWsUajOfGVOA4MrnyMXqu+S9ipuy+ rwkr5Kg5+95x95Vd2hxTDXLCqCyD99ex2vIQ1iurRf3D96kxUPykAXeYi8CwP+GuwRKy EuEhlagpVjlB8HOujp1JfwE9F+lnq6nFDM8abMSxf/CauLRzdIZfQn0dpWkQNkN4V8BN VVQRMnbRjdCfYcB3qvjVD7kINKxuYIm9/UfWzpb1F1hdVJ2kSpwKSi+AwB8CnH70YSTT +mmllrMXM8HLXJbw2h9hoU0i3MQoO4wpcwzxAJI4fYXkUSas1BpjQa9IWncdorDDgwri ng== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2bhjxwe5a0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 16:37:07 +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 v67Fa4Cl007791; Fri, 7 Jul 2017 11:37:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2be72vcjsm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 11:37:06 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Jul 2017 11:37:05 -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; Fri, 7 Jul 2017 11:37:05 -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; Fri, 7 Jul 2017 11:37:04 -0400 From: "Salz, Rich" To: Eric Rescorla CC: Martin Thomson , "dcrup@ietf.org" Thread-Topic: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 Thread-Index: AQHS9s/65iHlD+jTJUCp9nqNsWi4aqJIdm4AgABK/oD//76KMA== Date: Fri, 7 Jul 2017 15:37:03 +0000 Message-ID: <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> 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.32.247] 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-07-07_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-1707070259 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-07_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707070259 Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 15:37:11 -0000 Pj4gSSBkaXNhZ3JlZSwgYW5kIHNvIGZhciB0aGUgV0cgc2VlbXMgdG8gYmUgbGVhbmluZyBhZ2Fp bnN0IHRoaXMgdmlldy7CoCBXZSdsbCB0YWxrIGluIFByYWd1ZSwgb2YgY291cnNlLCBidXQgcmln aHQgbm93IHRoZSBvbmx5IHZvaWNlcyBmb3IgaGFzaGluZyBhcmUgeW91IGFuZCBla3IuDQoNCj4g QWxzbyBKaW0gRmVudG9uLCBJIGJlbGlldmUuDQoNCk9vcHMsIHlvdSBhcmUgY29ycmVjdC4gIFRo YW5rcy4NCg== From nobody Fri Jul 7 10:18: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 B7EFE131749 for ; Fri, 7 Jul 2017 10:18: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, 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 f0WOWUnPE32f for ; Fri, 7 Jul 2017 10:18:34 -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 3BB48131747 for ; Fri, 7 Jul 2017 10:18:34 -0700 (PDT) Received: from [IPv6:2605:e000:d482:d500:70ca:f47f:a93f:e0a8] ([IPv6:2605:e000:d482:d500:70ca:f47f:a93f:e0a8]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v67HIOjr028297 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 7 Jul 2017 10:18:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1499447906; bh=AENQnkllEdCNtSoB68Duzt1XbYwYw0Vk5YEqhvUTF2o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=as/NsMjWPgGMkiCBE831opfYr6EVtYQUlYM0jXD694AetiNEgz0W3J8g/ScNrPBpq xYva/iemuN0YSBkWONyd8mXgTPG/lZ53hrChsiNHdDRleLh7TmopIctVIpgcICkaKS jFtZGttvXAL2yNOvXyZeQwWDi14ViRt7PEuSDj0E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jim Fenton X-Mailer: iPad Mail (14F89) In-Reply-To: <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Fri, 7 Jul 2017 07:18:18 -1000 Cc: Eric Rescorla , "dcrup@ietf.org" , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 17:18:36 -0000 On Jul 7, 2017, at 5:37 AM, Salz, Rich wrote: >>> I disagree, and so far the WG seems to be leaning against this view. We= 'll talk in Prague, of course, but right now the only voices for hashing are= you and ekr. >=20 >> Also Jim Fenton, I believe. >=20 > Oops, you are correct. Thanks. Confirming, I favor hashing. -Jim From nobody Fri Jul 7 12:59: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 CFA3A1316E5 for ; Fri, 7 Jul 2017 12:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, 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 qYXMCMA3nkWN for ; Fri, 7 Jul 2017 12:59:07 -0700 (PDT) Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (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 5C8C3126C3D for ; Fri, 7 Jul 2017 12:59:07 -0700 (PDT) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 2A358522C; Fri, 7 Jul 2017 15:58:49 -0400 (EDT) X-Auth-ID: jon@merrymeet.com Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: jon-AT-merrymeet.com) with ESMTPSA id 511AA5127; Fri, 7 Jul 2017 15:58:48 -0400 (EDT) X-Sender-Id: jon@merrymeet.com Received: from [172.16.82.52] ([TEMPUNAVAIL]. [65.199.22.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 07 Jul 2017 15:58:49 -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: Fri, 7 Jul 2017 12:58:44 -0700 Cc: Jon Callas , "Salz, Rich" , Eric Rescorla , Martin Thomson , "dcrup@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> To: Jim Fenton X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 19:59:09 -0000 > On Jul 7, 2017, at 10:18 AM, Jim Fenton = wrote: >=20 >=20 >=20 > On Jul 7, 2017, at 5:37 AM, Salz, Rich wrote: >=20 >>>> I disagree, and so far the WG seems to be leaning against this = view. We'll talk in Prague, of course, but right now the only voices = for hashing are you and ekr. >>=20 >>> Also Jim Fenton, I believe. >>=20 >> Oops, you are correct. Thanks. >=20 > Confirming, I favor hashing. >=20 For what it's worth, I agree with Jim and Ekr. Hashing is just fine. Jon From nobody Fri Jul 7 13:02: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 8091212EC1B for ; Fri, 7 Jul 2017 13:02:26 -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 lltKMI8JA2K8 for ; Fri, 7 Jul 2017 13:02:24 -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 BA90A126C3D for ; Fri, 7 Jul 2017 13:02: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 9A7A8C401EB for ; Fri, 7 Jul 2017 15:02:23 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499457743; bh=LDC7MNSvmQeqQVBkM0lDRWlXjyuXVRM/MMGE8avK4Ew=; h=From:To:Subject:Date:In-Reply-To:References:From; b=A6d1GZBFIugOJOQSLBMjLQoLzI1ry2cyihq6tdp7YF72Cy8ghNAfQxmtnJ+TCFprV 1FSKgzQNsCNnmCdOBgQRjE5k+xR4MIzBfGV2A/F5liGYIUCblRHEA8WwlXrTF3E2N0 bkfMSPplV2rMNrqjp9EwctQN/l3xGDG6WsacLnl4= From: Scott Kitterman To: dcrup@ietf.org Date: Fri, 07 Jul 2017 16:02:23 -0400 Message-ID: <16151385.i3VAuqtOpv@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> References: <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 07 Jul 2017 20:02:26 -0000 On Friday, July 07, 2017 12:58:44 PM Jon Callas wrote: > > On Jul 7, 2017, at 10:18 AM, Jim Fenton wrote: > > > > On Jul 7, 2017, at 5:37 AM, Salz, Rich wrote: > >>>> I disagree, and so far the WG seems to be leaning against this view. > >>>> We'll talk in Prague, of course, but right now the only voices for > >>>> hashing are you and ekr.>>> > >>> Also Jim Fenton, I believe. > >> > >> Oops, you are correct. Thanks. > > > > Confirming, I favor hashing. > > For what it's worth, I agree with Jim and Ekr. Hashing is just fine. For the ECC algorithm we're considering what advantage does it have? As far as I can tell, it adds implementation complexity and provides no gain. Anytime you add complexity, you add risk of defects that negatively affect interoperability. I would be a mistake to add more complexity to this, because it is 'just fine'. Scott K From nobody Fri Jul 7 16:29: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 1AAD412EC41 for ; Fri, 7 Jul 2017 16:29:41 -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 Pf6XQr10FjDe for ; Fri, 7 Jul 2017 16:29:38 -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 86CE7129AEB for ; Fri, 7 Jul 2017 16:29:38 -0700 (PDT) Received: by mail-yb0-x22c.google.com with SMTP id p207so15098145yba.2 for ; Fri, 07 Jul 2017 16:29: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=YG6W01JE1dfj2DEKYLgHxp057WAyLXurKKgQqLoDrrA=; b=Z3zY2HSbXyBA+tFDaY7KccsYQJH5G3Z9embIyDlMVKPEZgw2OgF68cGJSdSA3hq0kh 8DdxlABPcBepJbr+D16DgIXKdqGAT2dHxO5as9SX/ZN8WAJUvahoJmNMgEQNILdPoT5M 149+8Z/+7TYyBMS3mMsI1be/JHk0OZZ5tVcvoote9gno5aSg4FbSCaS299g+9qTS3oDx HxL+TcgZTJ+Be0DMovzo5IZu4SEXJS2ZgHWNQVfUSrmFsxJwroFiXO3BdB6WyGkwXY8s iJFR6+h1nCiFPVELZBZLejgyJGbKrcJQNMnZwZyUzexfrtTQRwoy6DmH1oxvFD05P9YJ 4ZnA== 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=YG6W01JE1dfj2DEKYLgHxp057WAyLXurKKgQqLoDrrA=; b=EPBkkvyuEhEMhSK85RJnhcpbcBO8dnfRe22bCEiz5xJ+gsrjYP4hMdVHhdfTWBt89G 3PydCRP3sj+luSvo1yVhEZ9INFoB3Exu/Q8Z6aqj5WDMfewiGpZT9YtzioWYqNxg608+ DC0XvdWGDnFUzcOHwObWKCJT4RyaqygK3xkC6Bepp9/JEnyKplC4iCb6YW2/csJMjq4O +E82eJKmAb+WA1XpLRg6sQfSTwM3eJUStgVkiV86ZILQJMztGh0aYKChU9CAlIWelSSM 7CeNnnHoupvRFkeijH4AZUC+Ll6rmNGCsf8t8s6h+ZlmxJoIZE3gLdqVBBh68BWsxD5a rj4A== X-Gm-Message-State: AIVw111Eo5u4cNBP8LE2lfpMb4YXHJt3AGn9ocb2c+/wyNXYKw5fmbNZ ga13wuBxffm0k9bbmyXaSh8aEWZ+EQ== X-Received: by 10.37.205.133 with SMTP id d127mr6376885ybf.215.1499470177790; Fri, 07 Jul 2017 16:29:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.173.203 with HTTP; Fri, 7 Jul 2017 16:29:37 -0700 (PDT) In-Reply-To: <6025949.j6Hv4PBd49@kitterma-e6430> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <3509c4a1901e49d885e2dd3205a95be8@usma1ex-dag1mb1.msg.corp.akamai.com> <6025949.j6Hv4PBd49@kitterma-e6430> From: denis bider Date: Fri, 7 Jul 2017 17:29:37 -0600 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c189eec4c80c30553c29b43" Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 07 Jul 2017 23:29:41 -0000 --94eb2c189eec4c80c30553c29b43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed. It is a substantial advantage of DKIM as-is that the only algorithm that needs to be supported is RSA. Adding "rsafp" and one elliptic curve option makes for 3 algorithms to be supported by everyone. That's plenty. If anything, I'd cut "rsafp" so that there are only two options (RSA and EC). Users affected by crudware can migrate to EC instead of large RSA keys. But this might not be a popular option. On Fri, Jul 7, 2017 at 9:30 AM, Scott Kitterman wrote: > On Friday, July 07, 2017 03:09:39 PM Salz, Rich wrote: > > Since the entire IETF is moving to the Edwards curves, is there a > deployment > > requirement for FIPS P256 now? Or can those who need FIPS algorithms f= or > > signing keys stick with RSA? > > > If P256 is needed now, then I think we should have one document that > covers > > Ed25519 and P256, or at least modify the draft names and titles to make > it > > clear that this is =E2=80=9Ca=E2=80=9D choice, not =E2=80=9Cthe=E2=80= =9D choice for ECC DKIM signatures. > > > If DNS operators aren=E2=80=99t well versed in crypto, do we need to be= concerned > > about them deploying DSA? > > Every option you add, implementers need to add signing and verification > code > for (even if it's just more calls to appropriate libraries). As far as I > know > there's no security urgency to using ECC now. The reason to add it now i= s > to > future proof the protocol. > > If there is a transient issue with some implementers not using ECC due to > internal policy reasons, I don't think that should affect the WG's path. > > Adding one ECC DKIM method is enough. "For now" anyone who doesn't like > the > curves the IETF picked can stick with RSA. If the IETF needs to be makin= g > different choices in the ECC arena, I don't think this is the right WG to > work > that out. > > So far I'll have to add the sha256 hashed DNS record approach and one ECC > method. I think those are reasonable. > > Now maybe it's maybe two ECC schemes and adding PSS in addition to > supporting > PKCS#1v1.5 (mentioned in Review of draft-ietf-dcrup-dkim-crypto-03) plus > the > hashing. > > Every single option has to be widely deployed by both senders and receive= rs > before it can realistically be used in the field. If we just keep piling > on > the options it gets insane. Maybe I have to sign a message seven times t= o > get > interoperability: > > rsa-sha1 (because some people use ancient stuff) > rsa-sha256 > rsafp > rsa-sha256 PSS > rsafp PSS > ECC Ed25519 > ECC P256 > > If we specify too many new options, that will ensure none of the them get > deployed until there's a disaster discovered around rsa-sha256. > > Personally, I've started work on rsafp and plan to do Ed25519, but there'= s > no > way I'm up for coding more options just because someone thought it'd be a > nice > idea. > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c189eec4c80c30553c29b43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed. It is a substantial advantage of DKIM as-is that t= he only algorithm that needs to be supported is RSA.

Add= ing "rsafp" and one elliptic curve option makes for 3 algorithms = to be supported by everyone. That's plenty.

If= anything, I'd cut "rsafp" so that there are only two options= (RSA and EC). Users affected by crudware can migrate to EC instead of larg= e RSA keys. But this might not be a popular option.

On Fri, Jul 7, 2017 at 9:30= AM, Scott Kitterman <sklist@kitterman.com> wrote:
On Friday, July 07, 2017 03:09= :39 PM Salz, Rich wrote:
> Since the entire IETF is moving to the Edwards curves, is there a depl= oyment
> requirement for FIPS P256 now?=C2=A0 Or can those who need FIPS algori= thms for
> signing keys stick with RSA?

> If P256 is needed now, then I think we should have one document that c= overs
> Ed25519 and P256, or at least modify the draft names and titles to mak= e it
> clear that this is =E2=80=9Ca=E2=80=9D choice, not =E2=80=9Cthe=E2=80= =9D choice for ECC DKIM signatures.

> If DNS operators aren=E2=80=99t well versed in crypto, do we need to b= e concerned
> about them deploying DSA?

Every option you add, implementers need to add signing and verificat= ion code
for (even if it's just more calls to appropriate libraries).=C2=A0 As f= ar as I know
there's no security urgency to using ECC now.=C2=A0 The reason to add i= t now is to
future proof the protocol.

If there is a transient issue with some implementers not using ECC due to internal policy reasons, I don't think that should affect the WG's = path.

Adding one ECC DKIM method is enough.=C2=A0 "For now" anyone who = doesn't like the
curves the IETF picked can stick with RSA.=C2=A0 If the IETF needs to be ma= king
different choices in the ECC arena, I don't think this is the right WG = to work
that out.

So far I'll have to add the sha256 hashed DNS record approach and one E= CC
method.=C2=A0 I think those are reasonable.

Now maybe it's maybe two ECC schemes and adding PSS in addition to supp= orting
PKCS#1v1.5 (mentioned in Review of draft-ietf-dcrup-dkim-crypto-03) pl= us the
hashing.

Every single option has to be widely deployed by both senders and receivers=
before it can realistically be used in the field.=C2=A0 If we just keep pil= ing on
the options it gets insane.=C2=A0 Maybe I have to sign a message seven time= s to get
interoperability:

rsa-sha1 (because some people use ancient stuff)
rsa-sha256
rsafp
rsa-sha256 PSS
rsafp PSS
ECC Ed25519
ECC P256

If we specify too many new options, that will ensure none of the them get deployed until there's a disaster discovered around rsa-sha256.

Personally, I've started work on rsafp and plan to do Ed25519, but ther= e's no
way I'm up for coding more options just because someone thought it'= d be a nice
idea.

Scott K

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

--94eb2c189eec4c80c30553c29b43-- From nobody Fri Jul 7 19:24: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 7FFB412EBFB for ; Fri, 7 Jul 2017 19:24:19 -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_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 J6yaZddwq_XF for ; Fri, 7 Jul 2017 19:24:18 -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 382B4120454 for ; Fri, 7 Jul 2017 19:24:18 -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 v682MO1i021296; Sat, 8 Jul 2017 03:24: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=S9n21hXjMSiqY/6jiyBdYu7blIZbYA3toPtHAGWko20=; b=ejBcyOzWFYxk7tXqIMpYTHWKGGK7xgf01xBx2Bm6KpHOpKTaQlsG34Cx7+LW7o4xpGw6 nJpHz2xnQroTstRQUBpFa5Uten9YDYhQDcnpKqoji4vUmgnyITlg+2eYLeN6u4MaGBfK yynunKgNQC4hwJ8BOMMcJYEvauTyc3LV8YKwej5BkVXXRjAQbHlRpimAGf0buAOdYcfy 343H9qF2RbWBejKT5KYjqlMyp8zJaK4OdPL1wy86U4sY0LUIjSPKHb3NsMkr3Qy0BnJ7 zj9jMMncUzC49FY/6T/8jhgeuVrerTrcfacX9r8mwEN0AvAhccsHydF7Drdd68jw16CU 8g== 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 2bhry2679u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 08 Jul 2017 03:24:08 +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 v682KV0v011875; Fri, 7 Jul 2017 22:24:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2be72uhbx4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Jul 2017 22:24:06 -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; Fri, 7 Jul 2017 19:24:06 -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; Fri, 7 Jul 2017 22:24:05 -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; Fri, 7 Jul 2017 22:24:05 -0400 From: "Salz, Rich" To: Jon Callas , Jim Fenton CC: Eric Rescorla , Martin Thomson , "dcrup@ietf.org" Thread-Topic: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 Thread-Index: AQHS9s/65iHlD+jTJUCp9nqNsWi4aqJIdm4AgABK/oD//76KMIAAX4UAgAAs0wCAAChLwA== Date: Sat, 8 Jul 2017 02:24:05 +0000 Message-ID: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> In-Reply-To: <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> 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.72] 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-07-08_01:, , 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-1707080039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-08_01:, , 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-1707080040 Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 08 Jul 2017 02:24:19 -0000 > For what it's worth, I agree with Jim and Ekr. Hashing is just fine. Is it fine, or is it a required or just good? Nobody is saying there is anything wrong with hashing. Several are saying = that, given the limitations of some DNS deployments, it is useful to avoid = the indirection and just put the key when we can. From nobody Sat Jul 8 00:08: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 24FB9131688 for ; Sat, 8 Jul 2017 00:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[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 ZvOdNOYfZHD9 for ; Sat, 8 Jul 2017 00:08:25 -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 3D630131684 for ; Sat, 8 Jul 2017 00:08:24 -0700 (PDT) Received: from [IPv6:2605:e000:d482:d500:adb0:a38f:783:36f] ([IPv6:2605:e000:d482:d500:adb0:a38f:783:36f]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6878C2f003845 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 8 Jul 2017 00:08:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1499497696; bh=0BIXtPLhAbMz2wN2Ucv2e2J7DX+P9mMJve3P9bq8tHU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YzD4Zl0FZ8Xk1rn5XHcMUxRw3+qEKbM1pP9F4/2nI0KrjstahM9TUOGIbT/BO1iQi zh/oEIZMiBel44MZXWieXlE6vZBQkJSFLl48oKyd/sw1VTRjqwiPf5I3oAEqqR3ip2 AgsBH1bk/ShyLAsARi7xiRvlbxHrCEsLP5O9OTnI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jim Fenton X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Fri, 7 Jul 2017 21:08:06 -1000 Cc: Jon Callas , Eric Rescorla , Martin Thomson , "dcrup@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> To: "Salz, Rich" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 08 Jul 2017 07:08:26 -0000 On Jul 7, 2017, at 4:24 PM, Salz, Rich wrote: >> For what it's worth, I agree with Jim and Ekr. Hashing is just fine. >=20 > Is it fine, or is it a required or just good? >=20 > Nobody is saying there is anything wrong with hashing. Several are saying= that, given the limitations of some DNS deployments, it is useful to avoid t= he indirection and just put the key when we can. What DNS deployment limitation would be adversely affected by the use of a h= ash? I can't think of any. "Avoid the indirection" makes it sound like more network round-trips would b= e required if a hash is used. No more network traffic is involved; the verif= ier only needs to compute the hash of the key included in the message and co= mpare that with the fingerprint included in the key lookup response from DNS= . The verifier can even check the signature prior to receiving the DNS respo= nse, if it wants. I'm supporting publishing key fingerprints because I think it's slightly mor= e future-proof, and having been burned by that once already, I don't want to= make the same mistake again. But if rough consensus decides otherwise, we g= o with that of course. I still haven't heard an answer to the following question I posed about the f= ingerprints, though: Will the fingerprints always be sha256, or do we need t= o specify the fingerprint algorithm in the DNS record? In other words, will w= e assume that sha256 will be strong enough for the life of this protocol? -Jim= From nobody Sat Jul 8 00: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 82952126BF3 for ; Sat, 8 Jul 2017 00:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 AHmpCnJiiKW5 for ; Sat, 8 Jul 2017 00:40:53 -0700 (PDT) Received: from smtp72.ord1d.emailsrvr.com (smtp72.ord1d.emailsrvr.com [184.106.54.72]) (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 03432128B8F for ; Sat, 8 Jul 2017 00:40:52 -0700 (PDT) Received: from smtp10.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp10.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id 2D3D1A0081; Sat, 8 Jul 2017 03:40:52 -0400 (EDT) X-Auth-ID: jon@merrymeet.com Received: by smtp10.relay.ord1d.emailsrvr.com (Authenticated sender: jon-AT-merrymeet.com) with ESMTPSA id 8AD30A0080; Sat, 8 Jul 2017 03:40:51 -0400 (EDT) X-Sender-Id: jon@merrymeet.com Received: from [10.0.23.16] (media.merrymeet.com [173.164.244.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Sat, 08 Jul 2017 03:40:52 -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: Sat, 8 Jul 2017 00:40:50 -0700 Cc: Jon Callas , Jim Fenton , Eric Rescorla , Martin Thomson , "dcrup@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org> References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> To: "Salz, Rich" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 08 Jul 2017 07:40:54 -0000 > On Jul 7, 2017, at 7:24 PM, Salz, Rich wrote: >=20 >> For what it's worth, I agree with Jim and Ekr. Hashing is just fine. >=20 > Is it fine, or is it a required or just good? Fine. Into just good. >=20 > Nobody is saying there is anything wrong with hashing. Several are = saying that, given the limitations of some DNS deployments, it is useful = to avoid the indirection and just put the key when we can. Yeah, I know. They've mentioned the limitations of some DNS = implementations going back to the original DKIM work. It's true, but I = tend to be on the side of just sucking it up and doing a big DNS query = over TCP or whatever.=20 I'm also with Jim Fenton that I think the fingerprints make things more = future-proof, and I'd make some trivial encoding to put the algorithm = along with it for even more future-proofing. Jon From nobody Sat Jul 8 03:00: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 EBCAC1277BB for ; Sat, 8 Jul 2017 03:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[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 jutjuEdt3MiE for ; Sat, 8 Jul 2017 03:00:49 -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 80683120726 for ; Sat, 8 Jul 2017 03:00: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 D3E09C40550; Sat, 8 Jul 2017 05:00:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499508047; bh=vuJnQFaD8/UdYH2YP6qNEBTaW8dRhKFFQ5x+uNUbLJc=; h=Date:In-Reply-To:References:Subject:To:From:From; b=pDptEGpBGnbDsvrQ1nPE1LfaU8mXaSp80eUOdrlK9FNzN+DMc7i8Vs69EMOdIOElq M2mjtiEX45zfMIlQ2t98gGlukCTIsf606ZHJjtCD0XNFe49aB9Qb9Q/FZHWypOnzzQ 74a7iD5BQLwFVOSW+peG0LcIoQ43EvcOeEXSzf8s= Date: Sat, 08 Jul 2017 10:00:47 +0000 In-Reply-To: <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org> References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org> 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: <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@kitterman.com> Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 08 Jul 2017 10:00:51 -0000 On July 8, 2017 3:40:50 AM EDT, Jon Callas wrote: > >> On Jul 7, 2017, at 7:24 PM, Salz, Rich wrote: >>=20 >>> For what it's worth, I agree with Jim and Ekr=2E Hashing is just fine= =2E >>=20 >> Is it fine, or is it a required or just good? > >Fine=2E Into just good=2E > >>=20 >> Nobody is saying there is anything wrong with hashing=2E Several are >saying that, given the limitations of some DNS deployments, it is >useful to avoid the indirection and just put the key when we can=2E > >Yeah, I know=2E They've mentioned the limitations of some DNS >implementations going back to the original DKIM work=2E It's true, but I >tend to be on the side of just sucking it up and doing a big DNS query >over TCP or whatever=2E=20 > >I'm also with Jim Fenton that I think the fingerprints make things more >future-proof, and I'd make some trivial encoding to put the algorithm >along with it for even more future-proofing=2E Let's imagine we go down the path of hashing everything=2E When we want t= o add another new algorithm, how does having hashed the ECC key record help= ? It will still need a new RFC to define the new algorithm usage=2E It will still need new code to use the new algorithm=2E What future proofing does it buy? Also, you don't need to futz with the DNS record format to specify the alg= orithm=2E That's already in the signature, so the verifier has that inform= ation before they even do the DNS lookup=2E Scott K From nobody Sat Jul 8 10:52: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 B598312F3D0 for ; Sat, 8 Jul 2017 10:52:08 -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 HjBmsA82uyyH for ; Sat, 8 Jul 2017 10:52:02 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 0501A12F287 for ; Sat, 8 Jul 2017 10:52:01 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id r30so48021235qtc.0 for ; Sat, 08 Jul 2017 10:52:01 -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=tt8eqj7UVYVzQv2+akEUMJT4PCpxMdTUzQBSF0HOgvI=; b=Z0K3pDWUN0P+m8vc0y4W8j4RyU4xAF22v53eU9ptThdYey0zeGNpnn1SJc26+o2iN6 P7XSM3VUbJBcmfzGTNYdKHq+DBI4cghl5zLp8drRp/ezluY2ElOGy6xCN4ZreiJRCNu/ v+bj+D8vYEHe6vzplUMcHSZSFtvLsrKJ6uwFlNt5MD+KWWCsqo02pvYLpGz9oVDNa0Nr 4ASFLve7TpSfUNJnLOx/gxzHO1qU6zx/3u6ixNrhDTMBR7L32hLYme5HXtVm92QqBkSL qL+xMA75ZnmkdpBx7Qg2A2KzWhvvFk34ZIMAmAM4MGCsfjJRizNYeiPnX/6bkm66TBY3 jmLg== 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=tt8eqj7UVYVzQv2+akEUMJT4PCpxMdTUzQBSF0HOgvI=; b=qm+O22ws+Yd0uayG+CDMkspNcPNs/6RNg46RvhVDq+H5Tlgm2pgaXMMdpXLjoQMtPh 33D444GVHtIFC0fwrXt1rnXykVVTCl9OKVmLtGot6TXmczaP1qpqPK1lYwbN6a9XnN+y nzEC03m7cYIQzsSxmeaAQPnsLRTt9O7QstjxI2m3Fnb6Gwy0AU1gMnKHYx8z77gxYUR6 JGetMEbQpyLRKWR6YrNoTbFl/nP7eGqrn0Wi02jARIYDGwvWAduKNvns8gP2/fwSu84m tRFmhgkKFT4GxhII7kjNits6daiIBoyelMuK5ezxkiYT2BqNald3jHTS0j+8gieiChaj WA+w== X-Gm-Message-State: AIVw112aX63UFWrmUwSzxZ3EstKcHyhCVEr8T1bvDvxg1Po6WXuMU9BV tnsutRx7l9Q09d/2BFnWrzjP1hg79kEdlzU= X-Received: by 10.237.47.39 with SMTP id l36mr24162384qtd.181.1499536320995; Sat, 08 Jul 2017 10:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.157 with HTTP; Sat, 8 Jul 2017 10:52:00 -0700 (PDT) In-Reply-To: <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@kitterman.com> References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org> <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@kitterman.com> From: Peter Goldstein Date: Sat, 8 Jul 2017 10:52:00 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0d03babdb7ca0553d2014e" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 08 Jul 2017 17:52:09 -0000 --94eb2c0d03babdb7ca0553d2014e Content-Type: text/plain; charset="UTF-8" I agree with Scott. I'm not sure what all this talk about future proofing is about. In this case hashing is a hack to work around DNS crudware that doesn't properly support strings in excess of 255 bytes. Unless I'm misreading RFC 8032 (certainly possible), the base 64 encoded public key itself for Ed25519 is going to be just 64 characters. Throw in the version string and a couple of other tags and we'll be lucky to hit a max size of 90 octets for the record. That's well below the 255 byte limit imposed by DNS crudware. Even if future signature algorithms had 2x or 3x bytes in the key, we'd still come in under the 255 byte limit. Using a fingerprinted representation for Ed25519 just creates more work with absolutely no benefit. With fingerprinting the key itself needs to be included in every single email message (consuming space) and the fingerprint check needs to be done on each DKIM check (consuming time/CPU). And the whole verification process is just more complex. We might, at some point in the future, have a non-RSA algorithm that requires records that exceed 255 bytes. But that's by no means a given, or even a likelihood. And per Scott's email, in that case we're still going to need to define a new RFC, write new code, etc. Best, Peter On Sat, Jul 8, 2017 at 3:00 AM, Scott Kitterman wrote: > > > On July 8, 2017 3:40:50 AM EDT, Jon Callas wrote: > > > >> On Jul 7, 2017, at 7:24 PM, Salz, Rich wrote: > >> > >>> For what it's worth, I agree with Jim and Ekr. Hashing is just fine. > >> > >> Is it fine, or is it a required or just good? > > > >Fine. Into just good. > > > >> > >> Nobody is saying there is anything wrong with hashing. Several are > >saying that, given the limitations of some DNS deployments, it is > >useful to avoid the indirection and just put the key when we can. > > > >Yeah, I know. They've mentioned the limitations of some DNS > >implementations going back to the original DKIM work. It's true, but I > >tend to be on the side of just sucking it up and doing a big DNS query > >over TCP or whatever. > > > >I'm also with Jim Fenton that I think the fingerprints make things more > >future-proof, and I'd make some trivial encoding to put the algorithm > >along with it for even more future-proofing. > > Let's imagine we go down the path of hashing everything. When we want to > add another new algorithm, how does having hashed the ECC key record help? > > It will still need a new RFC to define the new algorithm usage. > > It will still need new code to use the new algorithm. > > What future proofing does it buy? > > Also, you don't need to futz with the DNS record format to specify the > algorithm. That's already in the signature, so the verifier has that > information before they even do the DNS lookup. > > 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 --94eb2c0d03babdb7ca0553d2014e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Scott.=C2=A0 I'm not sure what all this t= alk about future proofing is about.=C2=A0 In this case hashing is a hack to= work around DNS crudware that doesn't properly support strings in exce= ss of 255 bytes.

Unless I'm misreading RFC 8032 (cer= tainly possible), the base 64 encoded public key itself for Ed25519 is goin= g to be just 64 characters.=C2=A0 Throw in the version string and a couple = of other tags and we'll be lucky to hit a max size of 90 octets for the= record.=C2=A0 That's well below the 255 byte limit imposed by DNS crud= ware.=C2=A0 Even if future signature algorithms had 2x or 3x bytes in the k= ey, we'd still come in under the 255 byte limit.=C2=A0

Using a fingerprinted representation for Ed25519 just creates more= work with absolutely no benefit.=C2=A0 With fingerprinting the key itself = needs to be included in every single email message (consuming space) and th= e fingerprint check needs to be done on each DKIM check (consuming time/CPU= ).=C2=A0 And the whole verification process is just more complex.
<= br>
We might, at some point in the future, have a non-RSA al= gorithm that requires records that exceed 255 bytes.=C2=A0 But that's b= y no means a given, or even a likelihood.=C2=A0 And per Scott's email, = in that case we're still going to need to define a new RFC, write new c= ode, etc.

Best,

Peter
= <= /font>

On Sat, Jul 8, 2017 at 3:00 AM, Scott Kitterman <sklist@ki= tterman.com> wrote:


On July 8, 2017 3:40:50 AM EDT, Jon Callas <jon@callas.org> wrote:
>
>> On Jul 7, 2017, at 7:24 PM, Salz, Rich <rsalz@akamai.com> wrote:
>>
>>> For what it's worth, I agree with Jim and Ekr. Hashing is = just fine.
>>
>> Is it fine, or is it a required or just good?
>
>Fine. Into just good.
>
>>
>> Nobody is saying there is anything wrong with hashing.=C2=A0 Sever= al are
>saying that, given the limitations of some DNS deployments, it is
>useful to avoid the indirection and just put the key when we can.
>
>Yeah, I know. They've mentioned the limitations of some DNS
>implementations going back to the original DKIM work. It's true, bu= t I
>tend to be on the side of just sucking it up and doing a big DNS query<= br> >over TCP or whatever.
>
>I'm also with Jim Fenton that I think the fingerprints make things = more
>future-proof, and I'd make some trivial encoding to put the algorit= hm
>along with it for even more future-proofing.

Let's imagine we go down the path of hashing everything.=C2=A0 W= hen we want to add another new algorithm, how does having hashed the ECC ke= y record help?

It will still need a new RFC to define the new algorithm usage.

It will still need new code to use the new algorithm.

What future proofing does it buy?

Also, you don't need to futz with the DNS record format to specify the = algorithm.=C2=A0 That's already in the signature, so the verifier has t= hat information before they even do the DNS lookup.

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>
--94eb2c0d03babdb7ca0553d2014e-- From nobody Sat Jul 8 13:15: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 CA243131538 for ; Sat, 8 Jul 2017 13:15:05 -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 EPqKbc_8MZR4 for ; Sat, 8 Jul 2017 13:15:04 -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 633CA12706D for ; Sat, 8 Jul 2017 13:15:04 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id 9B78E1E199; Sat, 8 Jul 2017 20:15:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1499544902; bh=4QycO4WQTFVCKP99uBXQN3+trUgTVbd3Q44ioYl+CxY=; h=From:To:Subject:In-Reply-To:References:Date:From; b=qynkKiy9SYARdPegd0CnyrYWgAL25GTAdRdP0N9vrHiDalLRxgCuG2+RfGh7GKJ8i HGpZnj+yq+ShzU61S6HQUpT+NFX6fY9jzz13A/aebXexTre4+tiEtItw6E/6bNM8oz 8opMtMIse7OrjUre/SyDdldFUzBN1+Ne0x+1jQGlWszpuDO9vHrFbP4zpxauBM8Jkk a9oYDZeosxuh3jhVh87U5mTScXTy+WdLl8pmVsJrUl4529hyaY73E3ahAjl6MKCTxC k3kj3KocRk9R5wsusYXS2wRS/04D1DIkhEU7LsMRLD5nG2/nvUd1ILCiNMe8jM3u7Q kYnHqJkrsDGzg== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 24B91107B7BE1; Sat, 8 Jul 2017 20:14:28 +0000 (UTC) From: James Cloos To: dcrup@ietf.org In-Reply-To: <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@kitterman.com> (Scott Kitterman's message of "Sat, 08 Jul 2017 10:00:47 +0000") References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> <5F68DFD3-9F87-4CE1-87C2-AA08B0A62338@callas.org> <1C19FCE7-6AA3-4339-8BDE-F75C810505F2@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: Sat, 08 Jul 2017 16:14:28 -0400 Message-ID: Lines: 10 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:170708:dcrup@ietf.org::Bw7CMN/5cl8WkwqG:009jmI0 Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 08 Jul 2017 20:15:06 -0000 I haven't written about this because it seemed to be going ok, but I have to agree that hashing 256-bit keys or signatures with a 256 bit hash makes no sense. If there is an attack which such hashing could avoid, that would be a reason to do it. Absent any such attack, hashing only adds fragility. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Sun Jul 9 03:52: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 8C32D128961 for ; Sun, 9 Jul 2017 03:52:19 -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 AG52FQrTRdlP for ; Sun, 9 Jul 2017 03:52:18 -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 ECC351242F5 for ; Sun, 9 Jul 2017 03:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 21A1B300466 for ; Sun, 9 Jul 2017 06:52:17 -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 MxlWi-wlpLkV for ; Sun, 9 Jul 2017 06:52:15 -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 96726300258; Sun, 9 Jul 2017 06:52:15 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A1292331-2405-4637-9E98-759EA25C7B34" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 9 Jul 2017 06:52:14 -0400 In-Reply-To: Cc: dcrup@ietf.org To: Jim Fenton References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 10:52:20 -0000 --Apple-Mail=_A1292331-2405-4637-9E98-759EA25C7B34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I tend to agree with Jim Fenton on this. > I'm supporting publishing key fingerprints because I think it's = slightly more future-proof, and having been burned by that once already, = I don't want to make the same mistake again. But if rough consensus = decides otherwise, we go with that of course. While I recognize that a new RFC will be needed to roll out a different = ECC mechanism, using fingerprints in all cases seems like there would be = less impact on an implementation to support that new ECC algorithm, = especially if the crypto library already includes the curve. This seems = likely if we were to go from ECDSA P256 to ECDSA P384, for example. > I still haven't heard an answer to the following question I posed = about the fingerprints, though: Will the fingerprints always be sha256, = or do we need to specify the fingerprint algorithm in the DNS record? In = other words, will we assume that sha256 will be strong enough for the = life of this protocol? RFC 7093 include the use of SHA-256 for fingerprints, and I am unaware = of any reason that it cannot be used for the foreseeable future. Russ= --Apple-Mail=_A1292331-2405-4637-9E98-759EA25C7B34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I tend to agree with Jim Fenton on this.

I'm = supporting publishing key fingerprints because I think it's slightly = more future-proof, and having been burned by that once already, I don't = want to make the same mistake again. But if rough consensus decides = otherwise, we go with that of course.

While I recognize that a new RFC will be needed to roll = out a different ECC mechanism, using fingerprints in all cases seems = like there would be less impact on an implementation to support that new = ECC algorithm, especially if the crypto library already includes the = curve.  This seems likely if we were to go from ECDSA P256 to ECDSA = P384, for example.

I still haven't heard an answer to the = following question I posed about the fingerprints, though: Will the = fingerprints always be sha256, or do we need to specify the fingerprint = algorithm in the DNS record? In other words, will we assume that sha256 = will be strong enough for the life of this = protocol?

RFC 7093 include the use of SHA-256 for fingerprints, and I = am unaware of any reason that it cannot be used for the foreseeable = future.

Russ
= --Apple-Mail=_A1292331-2405-4637-9E98-759EA25C7B34-- From nobody Sun Jul 9 13:27: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 DB8FA129B3A for ; Sun, 9 Jul 2017 13:27:32 -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 V58K-coC4Ldm for ; Sun, 9 Jul 2017 13:27:31 -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 9CD2012EB8C for ; Sun, 9 Jul 2017 13:27:31 -0700 (PDT) Received: (qmail 44544 invoked from network); 9 Jul 2017 20:27:28 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jul 2017 20:27:28 -0000 Date: 9 Jul 2017 20:27:06 -0000 Message-ID: <20170709202706.90375.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: jon@callas.org In-Reply-To: <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 20:27:33 -0000 In article <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> you write: >For what it's worth, I agree with Jim and Ekr. Hashing is just fine. Can't do it. Unhashed RSA has been in DKIM for a decade and it's not going away. R's, John From nobody Sun Jul 9 13:34: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 0E50512F27C for ; Sun, 9 Jul 2017 13:34:39 -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 fLC2a_ncW9iy for ; Sun, 9 Jul 2017 13:34:37 -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 83DE112EC4B for ; Sun, 9 Jul 2017 13:34:37 -0700 (PDT) Received: (qmail 45081 invoked from network); 9 Jul 2017 20:34:36 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jul 2017 20:34:36 -0000 Date: 9 Jul 2017 20:34:14 -0000 Message-ID: <20170709203414.90415.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: rsalz@akamai.com In-Reply-To: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.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] I do not like the dcrup ECC document 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, 09 Jul 2017 20:34:39 -0000 In article <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> you write: >Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wrong. > >It specifies curve P256 and ECDSA. Here's what -03 says: 3. EdDSA-SHA256 Signing Algorithm The eddsa-sha256 signing algorithm computes a message hash as defined in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA algorithm using the edwards25519 curve, as defined in in RFC 8032 section 5.1 [RFC8032]. The signing algorithm is PureEdDSA as defined in RFC 8032 section 4, since the input to the signing algorithm has already been hashed. The DNS record for the verification public key MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather than RSA key. If that's not right, please send text. R's, John From nobody Sun Jul 9 13:45: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 705C512F280 for ; Sun, 9 Jul 2017 13:45:55 -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 9LHYGV9wr_cu for ; Sun, 9 Jul 2017 13:45:54 -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 3F43312FEE2 for ; Sun, 9 Jul 2017 13:45:54 -0700 (PDT) Received: (qmail 45748 invoked from network); 9 Jul 2017 20:45:53 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jul 2017 20:45:53 -0000 Date: 9 Jul 2017 20:45:31 -0000 Message-ID: <20170709204531.90481.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: housley@vigilsec.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] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 20:45:55 -0000 In article you write: >While I recognize that a new RFC will be needed to roll out a different ECC mechanism, using fingerprints in all cases seems like >there would be less impact on an implementation to support that new ECC algorithm, especially if the crypto library already includes >the curve. This seems likely if we were to go from ECDSA P256 to ECDSA P384, for example. I don't understand what you are proposing here. All current DKIM signatures use unhashed RSA keys. Is the suggestion that we change the spec so that all signatures must use hashed keys, so existing unhashed RSA signatures are no longer valid? Assuming that's not what you mean, we will have unhashed RSA signatures for a long time, probably forever. Given that we have both hashed and unhashed RSA keys, why hash ECC keys? Why not just hash when it's useful? R's, John PS: By the way, the de facto single-string TXT records limit on key sizes is about 1100 bits. An unhashed 384 bit key or even an unhashed 1024 bit key would work fine. From nobody Sun Jul 9 13:49: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 F2C2912FEEB for ; Sun, 9 Jul 2017 13:49:33 -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 TzKSmhEHcSgU for ; Sun, 9 Jul 2017 13:49:32 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 395E712EC18 for ; Sun, 9 Jul 2017 13:49:32 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id a12so28864758ywh.3 for ; Sun, 09 Jul 2017 13:49:32 -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=pBdI1IhkVZyjZGT8/S+3KP2gW2IpmG0tmrAfsvKRA4s=; b=Khlbc6gb9tOFjmzakoB+4IOn0yYQnfW8y/J2gL8U1FZPnS2Vt8VmQWHaUc8Nm37y5T m9RIU/AkHC4m4sYdmriqFBiPW9B5FGr2yP6uGOYd7JjKa+eWbNC/lpz6tDKa3fC303oA 80QPjAVv+TaxPxk5hR9Ezb4GokYw8ckSnx9WVfSmCcsmbggfvI5y8tbwrFH0QNUKRRdg 7PIbwON6wdx5zSv9bnj6ehpbvWm88g1L6mdw2u0l67R+Ho52W+rtke+Yy561JL+QTkVk iQnQYHwNJSXN/eplmXua3VR/PFoqops11XP+VxHL2BFy9hp1/fA7+RR7RfspUwcdCMEu zq2g== 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=pBdI1IhkVZyjZGT8/S+3KP2gW2IpmG0tmrAfsvKRA4s=; b=icfih1fM3YDMq3WabVcJVEtuYu4BCc/Thq4u91e7FFiGZlFxrF/4LvA/4zYB9G6IJM FA9P3Qg18aF04BEfP13+2Ubk00F8dGlPNLwvMfxir1AHtmsDZOIV7EqfD3QmRG/V7Gph lZvYjqcpFJmhLsMIptgGSL5tapey33AJ/c9j8O2g9QPfu9yjMuhJy7MFcM3t7lRaV6bg gBLzFdWcyKsL95AEuhoSe3SQOkYKOzOZcszZ9OagBtdHWKKmWRw7PEZFfogodnsZzOei 24Ar4xR7yrHRATac1q/DlrZ77unUmfZrqyFcljcN51BsBttV5Sa4pn/CfSG2rH04otmq +WNg== X-Gm-Message-State: AIVw111ym4Az61YU8CspRGpcvnz57X82quykcYGTradGZHh3D/NQMRDB qi5F9t6n1WADe85cwvm+bDZm9UX6UKtvyfA= X-Received: by 10.129.202.71 with SMTP id y7mr9419880ywk.74.1499633371511; Sun, 09 Jul 2017 13:49:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 13:48:50 -0700 (PDT) In-Reply-To: <20170709203414.90415.qmail@ary.lan> References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <20170709203414.90415.qmail@ary.lan> From: Eric Rescorla Date: Sun, 9 Jul 2017 13:48:50 -0700 Message-ID: To: John Levine Cc: dcrup@ietf.org, "Salz, Rich" Content-Type: multipart/alternative; boundary="089e082597806712ac0553e89add" Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 09 Jul 2017 20:49:34 -0000 --089e082597806712ac0553e89add Content-Type: text/plain; charset="UTF-8" Just as a technical point: ECDSA works with P-256, P-384, and P-521 EdDSA works with Curve25519 and Curve448 I read the text above as using EdDSA with Curve25519. -Ekr On Sun, Jul 9, 2017 at 1:34 PM, John Levine wrote: > In article <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp. > akamai.com> you write: > >Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wrong. > > > >It specifies curve P256 and ECDSA. > > Here's what -03 says: > > 3. EdDSA-SHA256 Signing Algorithm > > The eddsa-sha256 signing algorithm computes a message hash as defined > in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA > algorithm using the edwards25519 curve, as defined in in RFC 8032 > section 5.1 [RFC8032]. The signing algorithm is PureEdDSA as defined > in RFC 8032 section 4, since the input to the signing algorithm has > already been hashed. The DNS record for the verification public key > MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather > than RSA key. > > If that's not right, please send text. > > R's, > John > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --089e082597806712ac0553e89add Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just as a technical point:

ECDSA works = with P-256, P-384, and P-521
EdDSA works with Curve25519 and Curv= e448

I read the text above as using EdDSA with Cur= ve25519.

-Ekr


On Sun, Jul 9, 2017 at = 1:34 PM, John Levine <johnl@taugh.com> wrote:
In article <14cd0f4ff663= 48e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> = you write:
>Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wro= ng.
>
>It specifies curve P256 and ECDSA.

Here's what -03 says:

3.=C2=A0 EdDSA-SHA256 Signing Algorithm

=C2=A0 =C2=A0The eddsa-sha256 signing algorithm computes a message hash as = defined
=C2=A0 =C2=A0in section 3 of [RFC6376], and signs it with Ed25519, the EdDS= A
=C2=A0 =C2=A0algorithm using the edwards25519 curve, as defined in in RFC 8= 032
=C2=A0 =C2=A0section 5.1 [RFC8032].=C2=A0 The signing algorithm is PureEdDS= A as defined
=C2=A0 =C2=A0in RFC 8032 section 4, since the input to the signing algorith= m has
=C2=A0 =C2=A0already been hashed.=C2=A0 The DNS record for the verification= public key
=C2=A0 =C2=A0MUST have a "k=3Deddsa" tag to indicate that the key= is an EdDSA rather
=C2=A0 =C2=A0than RSA key.

If that's not right, please send text.

R's,
John

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

--089e082597806712ac0553e89add-- From nobody Sun Jul 9 13:51: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 66DAC12FEEB for ; Sun, 9 Jul 2017 13:51:42 -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 BTF51ntiXMzi for ; Sun, 9 Jul 2017 13:51:41 -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 4CCF312EC18 for ; Sun, 9 Jul 2017 13:51:41 -0700 (PDT) Received: (qmail 46183 invoked from network); 9 Jul 2017 20:51:40 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jul 2017 20:51:40 -0000 Date: 9 Jul 2017 20:51:18 -0000 Message-ID: <20170709205118.90504.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] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 20:51:42 -0000 In article you write: >On PSS: I think that the idea is to retain the existing primitive with >the fingerprint-based mode, so we should define "rsafp" as using >PKCS#1v1.5 and accept the shortcomings of that. I would support the >addition of a PSS-based scheme. Sorry, I looked at RFC 2313 and have no idea how this would apply to DKIM other than that there seems to be a redundant message digest code in the signature. Starting with the existing message signing defined in RFC 6376, can you explain what would be different? R's, John From nobody Sun Jul 9 13:55: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 C1ED3130019 for ; Sun, 9 Jul 2017 13:55:56 -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 vbnl6g5fdzEQ for ; Sun, 9 Jul 2017 13:55:55 -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 465DF12FEEB for ; Sun, 9 Jul 2017 13:55:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 615E2300545 for ; Sun, 9 Jul 2017 16:55:54 -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 vb6DFZCi4Ap4 for ; Sun, 9 Jul 2017 16:55:53 -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 1B69F300268; Sun, 9 Jul 2017 16:55:53 -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: <20170709204531.90481.qmail@ary.lan> Date: Sun, 9 Jul 2017 16:55:51 -0400 Cc: dcrup@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <809A045B-C518-4D36-9C47-A3B8B85E5EDF@vigilsec.com> References: <20170709204531.90481.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 20:55:57 -0000 > On Jul 9, 2017, at 4:45 PM, John Levine wrote: >=20 > In article you = write: >> While I recognize that a new RFC will be needed to roll out a = different ECC mechanism, using fingerprints in all cases seems like >> there would be less impact on an implementation to support that new = ECC algorithm, especially if the crypto library already includes >> the curve. This seems likely if we were to go from ECDSA P256 to = ECDSA P384, for example. >=20 > I don't understand what you are proposing here. All current DKIM > signatures use unhashed RSA keys. Is the suggestion that we change > the spec so that all signatures must use hashed keys, so existing > unhashed RSA signatures are no longer valid? No, that is not what I am suggesting. > Assuming that's not what you mean, we will have unhashed RSA > signatures for a long time, probably forever. Given that we have both > hashed and unhashed RSA keys, why hash ECC keys? Why not just hash > when it's useful? I was just trying to answer Jim's questions, not change the proposal. Russ From nobody Sun Jul 9 13:57: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 9AF8C12F290 for ; Sun, 9 Jul 2017 13:57:42 -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 LpedITqlPSlK for ; Sun, 9 Jul 2017 13:57:41 -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 73EEA12EC18 for ; Sun, 9 Jul 2017 13:57:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D4B41300545 for ; Sun, 9 Jul 2017 16:57:40 -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 ERX9M5fEFMuJ for ; Sun, 9 Jul 2017 16:57:39 -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 4C4E7300268; Sun, 9 Jul 2017 16:57:39 -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: <20170709203414.90415.qmail@ary.lan> Date: Sun, 9 Jul 2017 16:57:37 -0400 Cc: dcrup@ietf.org, Rich Salz Content-Transfer-Encoding: quoted-printable Message-Id: <3A2ECF01-E8A0-4E11-9E3F-6A67C5198ACC@vigilsec.com> References: <20170709203414.90415.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 09 Jul 2017 20:57:43 -0000 John: > In article = <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> = you write: >> Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is = wrong. >>=20 >> It specifies curve P256 and ECDSA. >=20 > Here's what -03 says: >=20 > 3. EdDSA-SHA256 Signing Algorithm >=20 > The eddsa-sha256 signing algorithm computes a message hash as = defined > in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA > algorithm using the edwards25519 curve, as defined in in RFC 8032 > section 5.1 [RFC8032]. The signing algorithm is PureEdDSA as = defined > in RFC 8032 section 4, since the input to the signing algorithm has > already been hashed. The DNS record for the verification public key > MUST have a "k=3Deddsa" tag to indicate that the key is an EdDSA = rather > than RSA key. >=20 > If that's not right, please send text. PureEdDSA does not take a hash as input, it takes the whole to-be-signed = content. Russ From nobody Sun Jul 9 13:59: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 B650112EC18 for ; Sun, 9 Jul 2017 13:59:25 -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 (1536-bit key) header.d=iecc.com header.b=JCERmAzX; dkim=pass (1536-bit key) header.d=taugh.com header.b=WKgFKGp9 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 jbpssKOSEt2G for ; Sun, 9 Jul 2017 13:59: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 E40E1126CB6 for ; Sun, 9 Jul 2017 13:59:23 -0700 (PDT) Received: (qmail 46615 invoked from network); 9 Jul 2017 20:59:22 -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=b615.5962992a.k1707; bh=TORqivd7uH4Q5NgcFyi5Gtq5gz9pW6twfNdxvr01tcc=; b=JCERmAzXLDUSChbA0+ydimWAkXxB1YHQpPa0z2QBR5Xz+6v+GE7rwqHROrC7AFRvGIU7jI1ND5DT13VNqkOi+PzLNNebFRdGGsxCsKV9IE7tFy2l8Edhk2v5WKYd7zS8xhnFJU0ACvc2VJ1BzKA4NRLbUM/Af4+5Uj92JeCILiHfdWWzHjsluSVmP37/W4raExOHyEhOLWSI5D+RwUXMcaRdSmNvkuwEumbhaGbDderYfV7bI3Y4dgPfmZJKJ5Vt 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=b615.5962992a.k1707; bh=TORqivd7uH4Q5NgcFyi5Gtq5gz9pW6twfNdxvr01tcc=; b=WKgFKGp9kGKj5wcHaOKGxgshChEPM4cktteggVY74unDONiio/yTTHCWc6jzcjv2OZI7cxIFxn8caop2VVtPzn2OdcAxD5MrFr1PImZ5oEm8s0rsgIRS2E4GJUNKJrFL6sqAhx5RSn2Depg0AOPCS/WvYPSNmRSUkZt18W0PBYIKksEyR08mErH0jeqwsuvjll5t5KogCHDMw5kahcnbEQEm9xMjn4jQLY2EIzsinI4Ws9/8z2xDOvkHC9VArQSu 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; 09 Jul 2017 20:59:22 -0000 Date: 9 Jul 2017 16:59:22 -0400 Message-ID: From: "John R Levine" To: "Eric Rescorla" Cc: dcrup@ietf.org In-Reply-To: References: <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp.akamai.com> <20170709203414.90415.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] I do not like the dcrup ECC document 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, 09 Jul 2017 20:59:26 -0000 > ECDSA works with P-256, P-384, and P-521 > EdDSA works with Curve25519 and Curve448 > > I read the text above as using EdDSA with Curve25519. That's what I intended. Not being a crypto geek, I was hoping the people who are crypto geeks could let me know if I haven't cribbed the right parts from RFC 8032. > > -Ekr > > > On Sun, Jul 9, 2017 at 1:34 PM, John Levine wrote: > >> In article <14cd0f4ff66348e495e0a7d0da8adc0e@usma1ex-dag1mb1.msg.corp. >> akamai.com> you write: >>> Speaking as an individual, I think the draft-ietf-dcrup-dkim-ecc is wrong. >>> >>> It specifies curve P256 and ECDSA. >> >> Here's what -03 says: >> >> 3. EdDSA-SHA256 Signing Algorithm >> >> The eddsa-sha256 signing algorithm computes a message hash as defined >> in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA >> algorithm using the edwards25519 curve, as defined in in RFC 8032 >> section 5.1 [RFC8032]. The signing algorithm is PureEdDSA as defined >> in RFC 8032 section 4, since the input to the signing algorithm has >> already been hashed. The DNS record for the verification public key >> MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather >> than RSA key. >> >> If that's not right, please send text. >> >> R's, >> John >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > 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 Jul 9 14:02: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 3A83912EC18 for ; Sun, 9 Jul 2017 14:01:59 -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 (1536-bit key) header.d=iecc.com header.b=pZKpoBhn; dkim=pass (1536-bit key) header.d=taugh.com header.b=RCEpYEId 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 fSYoldo3W-Te for ; Sun, 9 Jul 2017 14:01:58 -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 EEF96126CB6 for ; Sun, 9 Jul 2017 14:01:57 -0700 (PDT) Received: (qmail 46925 invoked from network); 9 Jul 2017 21:01: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=b74b.596299c5.k1707; bh=kkfxzdt4jMZMp8txXZ4xlrPD1ecahX/BjnKy/ZhIBq4=; b=pZKpoBhnnsuyDcS1JhY5wCakqqzNlWlydo+wNoNmKdm7bQxmCfK70I3itA/E1OEd+KBYB0Y/bRKgqlif510eCPiQPF3IsJLPJmI761Cknuwmd+TSZQq2rAjlddozFJAy/Kom1V38O2cx2WHzfS34DApUAF5EUAjOK3fVDS2nCxyB7Iv85uzBtsMVn3Usbk6ClmzHuBJ6zwigIfwCDI8QMkErzmj6Ft4qcgC7GR44PUiKMlwFgk2LsGv5gXv+kg3F 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=b74b.596299c5.k1707; bh=kkfxzdt4jMZMp8txXZ4xlrPD1ecahX/BjnKy/ZhIBq4=; b=RCEpYEIdx3+1AsgNHMbLnFgRgpPP/slYt0Jq9rpvLakYwycPU8ixEc0F2M0+8U4Yof2CF+pDwSXSBpU7eep59BRfzUIgbl+DWM1K0d4u6IlXDj3lPfqkT2Op+DTmxhCxDEAAEPhsFn9uqz8itUDweHqyfmvPVnQz8Gb36mYKb8cgqPeSdKLiKmE1r2RBK8Tta6uXpJwNFVCJ0sDRqn60yQlKLoCWvIhwD1Dekyj2iZ6xwNQmbzRVUKsvCiu2KojU 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; 09 Jul 2017 21:01:56 -0000 Date: 9 Jul 2017 17:01:56 -0400 Message-ID: From: "John R Levine" To: "Russ Housley" Cc: dcrup@ietf.org In-Reply-To: <809A045B-C518-4D36-9C47-A3B8B85E5EDF@vigilsec.com> References: <20170709204531.90481.qmail@ary.lan> <809A045B-C518-4D36-9C47-A3B8B85E5EDF@vigilsec.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] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 21:01:59 -0000 On Sun, 9 Jul 2017, Russ Housley wrote: >> Assuming that's not what you mean, we will have unhashed RSA >> signatures for a long time, probably forever. Given that we have both >> hashed and unhashed RSA keys, why hash ECC keys? Why not just hash >> when it's useful? > > I was just trying to answer Jim's questions, not change the proposal. Oh, OK. I still don't get the point, though. Signers and verifiers will all have code to handle both hashed and unhashed keys, since unhashed RSA isn't going away. Since we have the code to do both, why hash keys when they are already small enough? R's, John From nobody Sun Jul 9 14: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 6294F12EC18 for ; Sun, 9 Jul 2017 14:06:19 -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 LVWqHsUyxDLZ for ; Sun, 9 Jul 2017 14:06:18 -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 03556126CB6 for ; Sun, 9 Jul 2017 14:06: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 9B253C4005E for ; Sun, 9 Jul 2017 16:06:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499634374; bh=KwnKORkINr9xwFhyqEs6OXONtZv/w+SvF1MRydqcFr8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=FC6EGWVaGQLw6UxGy02B5TgWe3Ek1AqIgVEBk5GswxwPE1d8gZvQiYVbCuHdJ4oY8 uIQfvAzggzvtBQH+zRE1Yzm6PO0FYgtmyD3u4beJD7n3zsdoDusdnnRIZkLTgUYYvn CnHP6qqKXa+f+JQyq2hkyy/HNyriQND/tZYLjImg= From: Scott Kitterman To: dcrup@ietf.org Date: Sun, 09 Jul 2017 17:06:13 -0400 Message-ID: <6250733.dllmP4se25@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20170709204531.90481.qmail@ary.lan> References: <20170709204531.90481.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 21:06:19 -0000 On Sunday, July 09, 2017 08:45:31 PM John Levine wrote: > In article you write: > >While I recognize that a new RFC will be needed to roll out a different ECC > >mechanism, using fingerprints in all cases seems like there would be less > >impact on an implementation to support that new ECC algorithm, especially > >if the crypto library already includes the curve. This seems likely if we > >were to go from ECDSA P256 to ECDSA P384, for example. > I don't understand what you are proposing here. All current DKIM > signatures use unhashed RSA keys. Is the suggestion that we change > the spec so that all signatures must use hashed keys, so existing > unhashed RSA signatures are no longer valid? > > Assuming that's not what you mean, we will have unhashed RSA > signatures for a long time, probably forever. Given that we have both > hashed and unhashed RSA keys, why hash ECC keys? Why not just hash > when it's useful? > > R's, > John > > PS: By the way, the de facto single-string TXT records limit on key > sizes is about 1100 bits. An unhashed 384 bit key or even an unhashed > 1024 bit key would work fine. The technical case for hashing RSA key records is very clear: It provides a mechanism to continue using RSA with larger keys that exceed the size limits many domains are able to publish in DNS. I still haven't seen any technical argument for hashing ecdsa key records. The most I've seen is 'seems nice'. The technical argument against is, I think quite clear: 1. Solves no actual problem. 2. Increases protocol complexity. 3. Increases protocol fragility. 4. Increases implementation requirements. 5. Increases the size of every single signed message. If there's some technical argument for hashing ecdsa key records now beyond it may be useful someday for some other signing algorithm, I'd appreciate it if someone would make it. I've entirely missed it. Scott K From nobody Sun Jul 9 14:14: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 1BF9B12EC11 for ; Sun, 9 Jul 2017 14:14: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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=yK/NjRtJ; dkim=pass (1536-bit key) header.d=taugh.com header.b=mRXtqlUV 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 mzZ5x1cUZNZI for ; Sun, 9 Jul 2017 14:14: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 BABD1126CB6 for ; Sun, 9 Jul 2017 14:14:16 -0700 (PDT) Received: (qmail 47724 invoked from network); 9 Jul 2017 21:14:14 -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=ba6a.59629ca6.k1707; bh=gelu0/G9Cyol2nqd7l+0fPO26J+2BP6J3RTpW1caee8=; b=yK/NjRtJaov5bTPKXU5152PsvYamkaoNwo5EoCJspoGNoEu9wZDTRJY/nxU3gyRBbXfc1MpKkdwHqsmIKKLQjDSj7CaEKdk+e0UXk7gaP5o1XlMWxAX+So2+fMP1Kj+oRbTgZ1v6JZxa2b73dkHJOQ31VYS3RP0jmUp7yiP7fzi7/u9Qn220PEDd7UTdChI4em+1tSZLmlGcxuD5l3OswMoVN2WUY4mG6cWoGDmLuIKo22VLrVCXMNY2Z3bSyF/K 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=ba6a.59629ca6.k1707; bh=gelu0/G9Cyol2nqd7l+0fPO26J+2BP6J3RTpW1caee8=; b=mRXtqlUViD6MzvaCY/5Ixlh3rlN7bfgXe8PlZEUwQTYCLzJUF9X2U8fl+yIXpNJGkvIlxfQxrHWjsKSmk2QApLIEMMyWWIB6JW9+XVu0nocphv57x2VH9tk9pXhdkNwzQ31eYzVV7dNDqkFjAVYY8GkPBgxDbcohUvl6ixf1ixVUweifLFPeAecX9ElUF3YE+doYz5oITPHWYn5Abk/XfA3R6YAUGkO38nCgLwfm8XprL0hyWsIntDUzUVeOmPf3 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; 09 Jul 2017 21:14:14 -0000 Date: 9 Jul 2017 17:14:13 -0400 Message-ID: From: "John R Levine" To: "Russ Housley" Cc: dcrup@ietf.org In-Reply-To: <3A2ECF01-E8A0-4E11-9E3F-6A67C5198ACC@vigilsec.com> References: <20170709203414.90415.qmail@ary.lan> <3A2ECF01-E8A0-4E11-9E3F-6A67C5198ACC@vigilsec.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 do not like the dcrup ECC document 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, 09 Jul 2017 21:14:18 -0000 >> 3. EdDSA-SHA256 Signing Algorithm >> >> The eddsa-sha256 signing algorithm computes a message hash as defined >> in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA >> algorithm using the edwards25519 curve, as defined in in RFC 8032 >> section 5.1 [RFC8032]. The signing algorithm is PureEdDSA as defined >> in RFC 8032 section 4, since the input to the signing algorithm has >> already been hashed. The DNS record for the verification public key >> MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather >> than RSA key. >> >> If that's not right, please send text. > > PureEdDSA does not take a hash as input, it takes the whole to-be-signed content. RFC 6376 describes in great detail in section 3.7 how to create the material to be signed. What it ends up with is a sha-256 hash, but that's not the signing algorithm's problem. I say PureEdDSA to emphasize that it doesn't get hashed again. As it stands now, the RSA and EdDSA signing algorithms sign the same thing. I suppose I could extensively rewrite the signing instructions so that stuff to be signed by RSA is hashed while stuff to be signed by EdDSA is not because it'll use HashEdDSA, but that seems a lot of work and a lot of code changes for no benefit. R's, John From nobody Sun Jul 9 14:22: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 383A1127180 for ; Sun, 9 Jul 2017 14:22: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, 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 KTrcldZU3ff3 for ; Sun, 9 Jul 2017 14:22:14 -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 232D8126CB6 for ; Sun, 9 Jul 2017 14:22:14 -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 EB5D4C4005E for ; Sun, 9 Jul 2017 16:22:12 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499635333; bh=jt0IxGC3uYHnpujVBU1E2Yt8mbTJCGkB/3HR9AyoDfg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=mLWEYE7z3iEDlR0VOeMJ441tMLUnChklnuxWPxW/QSkpRQ6ahnXaPFD+SU4vdpKck NmG50vXWrv/nl3waevwI2G6M1FA+okJjz951qvSbTS3dmG6V/B+m+ByJoWqQKwqy2E dvB4mvUQXIMYteXY44g1SgtqSFXlTfswfWWeE5m8= From: Scott Kitterman To: dcrup@ietf.org Date: Sun, 09 Jul 2017 17:22:12 -0400 Message-ID: <2578584.laa3YatE2f@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170709203414.90415.qmail@ary.lan> <3A2ECF01-E8A0-4E11-9E3F-6A67C5198ACC@vigilsec.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 09 Jul 2017 21:22:15 -0000 On Sunday, July 09, 2017 05:14:13 PM John R Levine wrote: > >> 3. EdDSA-SHA256 Signing Algorithm > >> > >> The eddsa-sha256 signing algorithm computes a message hash as defined > >> in section 3 of [RFC6376], and signs it with Ed25519, the EdDSA > >> algorithm using the edwards25519 curve, as defined in in RFC 8032 > >> section 5.1 [RFC8032]. The signing algorithm is PureEdDSA as defined > >> in RFC 8032 section 4, since the input to the signing algorithm has > >> already been hashed. The DNS record for the verification public key > >> MUST have a "k=eddsa" tag to indicate that the key is an EdDSA rather > >> than RSA key. > >> > >> If that's not right, please send text. > > > > PureEdDSA does not take a hash as input, it takes the whole to-be-signed > > content. > RFC 6376 describes in great detail in section 3.7 how to create the > material to be signed. What it ends up with is a sha-256 hash, but that's > not the signing algorithm's problem. I say PureEdDSA to emphasize that it > doesn't get hashed again. > > As it stands now, the RSA and EdDSA signing algorithms sign the same > thing. I suppose I could extensively rewrite the signing instructions so > that stuff to be signed by RSA is hashed while stuff to be signed by EdDSA > is not because it'll use HashEdDSA, but that seems a lot of work and a lot > of code changes for no benefit. The python crypto library I plan to use for this (python-nacl) supports both. Given the current structure of the dkimpy code, it would be much simpler to support PureEdDSA. Having looked at how I would implement this (but not having done it yet) I agree with your contention about implementation complexity. Scott K From nobody Sun Jul 9 14:38: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 C5B6E127180 for ; Sun, 9 Jul 2017 14:38:43 -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 ZZ8QJXg5COQf for ; Sun, 9 Jul 2017 14:38:42 -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 2BB481242F5 for ; Sun, 9 Jul 2017 14:38:42 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id f194so22922360yba.3 for ; Sun, 09 Jul 2017 14:38: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=1N4XI5l9oqclABY/8RVp8MbWdbkA9qRDEDfWnFrrZr8=; b=bGvMJ4yZriVRLs8LO2vVv7XpT0Qpfj1sS6BUX8TpDN021nqNPJgtdVR5l+89284GPn qfT16kd4oWEGWCAqo93cCf8X+UrFCJpaCIc88AobVucFa6YApktTcELBxZ5V43moXQaj 5BuBNojI9oJngrm9B2JnS/QTvbOiqVFhJfPmWcA1UVX5vlIYHeId3Wb3ojTG4sae86Ql 9GlXcB0jdrxgoohRDHjWiKiSxOs0fvop+1ZYimTXKwAZqDKJcKBiybKK6lo4ailglJO4 UuyuAdaO8wmESxSXjtU821pzNJzEZE/4X1CL9und5OFNxF5cF2CsqcgKLnVGHge1uAAG 6K/Q== 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=1N4XI5l9oqclABY/8RVp8MbWdbkA9qRDEDfWnFrrZr8=; b=rckwdUUan50etJgMt73G/ovFm0gjQ49g4KF242FONA3fzkkGemsXWDo3SkKHdzcEzC 6N+bfeyJLBloR2c236d6+eVi5zZzlFbeqYVgz4D7kNMragKQV50b2ij5Dlmf+RSpt8GN K3WSn+0Ie+s7LxTf53IdodHbU34EEAH9auHgrhHfJ1iTTw323t37D/XVb3ui6M9kUtgu 1T2CykhjNIDWhcZG3UorhAhhIQm5OkLMVWewpgrOA1FLC8RkX3MRm1ezeX3H0SMKaOFY quZbWladoMXo+w14Zc7Z4VXTCXHgaWdDfw/HyqFf6b6U4/JrtNBb2XAfhPbEXj/isRUY A+iA== X-Gm-Message-State: AIVw110aSR1etpKd7tZfTWt7m3aMNJxl5m8IuylFmP/1NRdeXdJf7hJI Hnug7r93L+MpaZ3gZW0iJwxxwf3ty9SZdJs= X-Received: by 10.37.162.104 with SMTP id b95mr12361372ybi.29.1499636321361; Sun, 09 Jul 2017 14:38:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 14:38:00 -0700 (PDT) In-Reply-To: <6250733.dllmP4se25@kitterma-e6430> References: <20170709204531.90481.qmail@ary.lan> <6250733.dllmP4se25@kitterma-e6430> From: Eric Rescorla Date: Sun, 9 Jul 2017 14:38:00 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c19fcf83a44420553e94a67" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 21:38:44 -0000 --94eb2c19fcf83a44420553e94a67 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 2:06 PM, Scott Kitterman wrote: > On Sunday, July 09, 2017 08:45:31 PM John Levine wrote: > > In article you > write: > > >While I recognize that a new RFC will be needed to roll out a different > ECC > > >mechanism, using fingerprints in all cases seems like there would be > less > > >impact on an implementation to support that new ECC algorithm, > especially > > >if the crypto library already includes the curve. This seems likely if > we > > >were to go from ECDSA P256 to ECDSA P384, for example. > > I don't understand what you are proposing here. All current DKIM > > signatures use unhashed RSA keys. Is the suggestion that we change > > the spec so that all signatures must use hashed keys, so existing > > unhashed RSA signatures are no longer valid? > > > > Assuming that's not what you mean, we will have unhashed RSA > > signatures for a long time, probably forever. Given that we have both > > hashed and unhashed RSA keys, why hash ECC keys? Why not just hash > > when it's useful? > > > > R's, > > John > > > > PS: By the way, the de facto single-string TXT records limit on key > > sizes is about 1100 bits. An unhashed 384 bit key or even an unhashed > > 1024 bit key would work fine. > > The technical case for hashing RSA key records is very clear: It provides a > mechanism to continue using RSA with larger keys that exceed the size > limits > many domains are able to publish in DNS. > > I still haven't seen any technical argument for hashing ecdsa key records. > The most I've seen is 'seems nice'. That going forward it would be better to have one way of doing things rather than two, with the sole exception being the legacy RSA version. And then at some point when the majority of signatures are hashed, one can simply delete the old code path. > The technical argument against is, I > think quite clear: > > 1. Solves no actual problem. > 2. Increases protocol complexity. > 3. Increases protocol fragility. > 4. Increases implementation requirements. > I don't believe that any of these things are true to any significant extent. > 5. Increases the size of every single signed message. > By a trivial amount, unless your key is very big, in which case hashing was a good idea. -Ekr > > If there's some technical argument for hashing ecdsa key records now > beyond it > may be useful someday for some other signing algorithm, I'd appreciate it > if > someone would make it. I've entirely missed it. > > Scott K > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c19fcf83a44420553e94a67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 2:06 PM, Scott Kitterman <<= a href=3D"mailto:sklist@kitterman.com" target=3D"_blank">sklist@kitterman.c= om> wrote:
On Sunday, July 09, 2017 08:45:31 PM John Levine wrote:
> In article <AF49D563-0F63-4DD8-BFAA-DCFFF154D152@vigilsec.com>= ; you write:
> >While I recognize that a new RFC will be needed to roll out a diff= erent ECC
> >mechanism, using fingerprints in all cases seems like there would = be less
> >impact on an implementation to support that new ECC algorithm, esp= ecially
> >if the crypto library already includes the curve.=C2=A0 This seems= likely if we
> >were to go from ECDSA P256 to ECDSA P384, for example.
> I don't understand what you are proposing here.=C2=A0 All current = DKIM
> signatures use unhashed RSA keys.=C2=A0 Is the suggestion that we chan= ge
> the spec so that all signatures must use hashed keys, so existing
> unhashed RSA signatures are no longer valid?
>
> Assuming that's not what you mean, we will have unhashed RSA
> signatures for a long time, probably forever.=C2=A0 Given that we have= both
> hashed and unhashed RSA keys, why hash ECC keys?=C2=A0 Why not just ha= sh
> when it's useful?
>
> R's,
> John
>
> PS: By the way, the de facto single-string TXT records limit on key > sizes is about 1100 bits.=C2=A0 An unhashed 384 bit key or even an unh= ashed
> 1024 bit key would work fine.

The technical case for hashing RSA key records is very clear: It pro= vides a
mechanism to continue using RSA with larger keys that exceed the size limit= s
many domains are able to publish in DNS.

I still haven't seen any technical argument for hashing ecdsa key recor= ds.
The most I've seen is 'seems nice'.=C2=A0

=
That going forward it would be better to have one way of doing t= hings rather
than two, with the sole exception being the legacy R= SA version. And then
at some point when the majority of signature= s are hashed, one can simply
delete the old code path.
=
=C2=A0
The technical ar= gument against is, I
think quite clear:

1.=C2=A0 Solves no actual problem.
2.=C2=A0 Increases protocol complexity.
3.=C2=A0 Increases protocol fragility.
4.=C2=A0 Increases implementation requirements.

I don't believe that any of these things are true to any signi= ficant
extent.=C2=A0

=C2=A0
5.=C2=A0 Increases the size of every single signed message.

By a trivial amount, unless your key is very big, in w= hich case hashing
was a good idea.

-Ekr<= /div>
=C2=A0

If there's some technical argument for hashing ecdsa key records now be= yond it
may be useful someday for some other signing algorithm, I'd appreciate = it if
someone would make it.=C2=A0 I've entirely missed it.

Scott K



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

--94eb2c19fcf83a44420553e94a67-- From nobody Sun Jul 9 14:49: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 5BB9C129B2C for ; Sun, 9 Jul 2017 14:49: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_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 uE6ni9w--DOM for ; Sun, 9 Jul 2017 14:49:39 -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 CE4261300BC for ; Sun, 9 Jul 2017 14:49:33 -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 C615DC4005E for ; Sun, 9 Jul 2017 16:49:31 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499636971; bh=rp7xL2JAthtrInl2iaM8usB9Bwoxt+zIFQ053obP08k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=u+pnfeaPOYmGiCeQF1YuQhdHRCtcqItxQEq8VWjXM7CrHAr3TCzayWb/evzzfAT3j +OuHIuFp2VKYHV3h/9DhiWztgHRC3jsLMjxGGD35/VfdoHQSeZU3d7HCKC+t6hHt0Q GSia5euGqbUuiGygxeVNiPbaXHBQPhGBlky1PyxA= From: Scott Kitterman To: dcrup@ietf.org Date: Sun, 09 Jul 2017 17:49:31 -0400 Message-ID: <14043482.U1dYDYAKmz@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <20170709204531.90481.qmail@ary.lan> <6250733.dllmP4se25@kitterma-e6430> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 21:49:40 -0000 On Sunday, July 09, 2017 02:38:00 PM Eric Rescorla wrote: > On Sun, Jul 9, 2017 at 2:06 PM, Scott Kitterman > > wrote: > > On Sunday, July 09, 2017 08:45:31 PM John Levine wrote: > > > In article you > > > > write: > > > >While I recognize that a new RFC will be needed to roll out a different > > > > ECC > > > > > >mechanism, using fingerprints in all cases seems like there would be > > > > less > > > > > >impact on an implementation to support that new ECC algorithm, > > > > especially > > > > > >if the crypto library already includes the curve. This seems likely if > > > > we > > > > > >were to go from ECDSA P256 to ECDSA P384, for example. > > > > > > I don't understand what you are proposing here. All current DKIM > > > signatures use unhashed RSA keys. Is the suggestion that we change > > > the spec so that all signatures must use hashed keys, so existing > > > unhashed RSA signatures are no longer valid? > > > > > > Assuming that's not what you mean, we will have unhashed RSA > > > signatures for a long time, probably forever. Given that we have both > > > hashed and unhashed RSA keys, why hash ECC keys? Why not just hash > > > when it's useful? > > > > > > R's, > > > John > > > > > > PS: By the way, the de facto single-string TXT records limit on key > > > sizes is about 1100 bits. An unhashed 384 bit key or even an unhashed > > > 1024 bit key would work fine. > > > > The technical case for hashing RSA key records is very clear: It provides > > a > > mechanism to continue using RSA with larger keys that exceed the size > > limits > > many domains are able to publish in DNS. > > > > I still haven't seen any technical argument for hashing ecdsa key records. > > The most I've seen is 'seems nice'. > > That going forward it would be better to have one way of doing things rather > than two, with the sole exception being the legacy RSA version. And then at > some point when the majority of signatures are hashed, one can simply > delete the old code path. > > > The technical argument against is, I > > think quite clear: > > > > 1. Solves no actual problem. > > 2. Increases protocol complexity. > > 3. Increases protocol fragility. > > 4. Increases implementation requirements. > > I don't believe that any of these things are true to any significant > extent. > > > 5. Increases the size of every single signed message. > > By a trivial amount, unless your key is very big, in which case hashing > was a good idea. > > -Ekr > > > If there's some technical argument for hashing ecdsa key records now > > beyond it > > may be useful someday for some other signing algorithm, I'd appreciate it > > if > > someone would make it. I've entirely missed it. > > > > Scott K That very much sounds to me like seems nice, maybe someday it would be helpful. I don't see the notional of eventual "all key records are hashed" as having any value whatsoever. If you want implementers to implement new algorithms, I don't think it makes it more likely to add pointless additional requirements. I get my implementation concerns aren't a worry to you, so I don't know how to bridge the gap. Scott K From nobody Sun Jul 9 14:57: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 E81F2127180 for ; Sun, 9 Jul 2017 14:57: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 jDjxfxO_Qgyo for ; Sun, 9 Jul 2017 14:57:23 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 8F9051242F5 for ; Sun, 9 Jul 2017 14:57:23 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id v193so29123760ywg.2 for ; Sun, 09 Jul 2017 14:57: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=q/gXguWgBujsxm7G+Lm7oE5cDhxhxE/jfisiudFQn1U=; b=HA8iSPN+Ef0L+tWDpramcF/g10/tSejP09SR6A7xVAY+9qE6KAcExXR08ad0oJnvcW opy5eLc2cPxlu6UPf9eQtbACFndSS+PJMiDS5MbFh/KACwJcSP+esAy1b2tdR6mdr20D afQOYHFbu95ZTzbCO80CjHBvM0pp58RWpT7mU1i3TIfChCRrYWPmfvAo7pQCscAxFMGd 5iLeWef3/LDpi/x30VslE+nNIfJzWV/IvktK1AaR0pTiCrKw3TTF0CjuurBcaE5zr+td Wx5uxnSOckzAC7hoPGMRxftDdyxpKwHN7py/OfSlt7dZtFwtLs3mNMB9VyQx3NLoiD7d YNLg== 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=q/gXguWgBujsxm7G+Lm7oE5cDhxhxE/jfisiudFQn1U=; b=QjP7O3x0tiED2IQFBNHW6S5s83M0UPI9eHoxAe6Jyeju2clcN4NIXK1qrJrbAlOd8f tu+Yqg/3Rhbk4wCVpg/DmlUnvV+Ropyt3hLE5zZxuv4snblt3dfl09fTt2azBpySbGDp GE/lKqrABRL/icpjwBeJqI/0W74ztdQ8kan07KqzQX39LMgdb2J7VsNqwmr5VO330J83 P2QUepM3DRaAWAni62TWZjp4US5xzHgvVEyl+zYRjSlfHFDF7UUn7Yi+e/T42dGp8wor oxKiFE0MvoupWur4uHbB3/tQ4lXQYx33f1BZ2nmk+ziac8MigbIrgC0ID/js+1xHV3qy uZdA== X-Gm-Message-State: AIVw112J8Mexl+JGDlImFof9SnFsT7FTZeALRqB96jwkBIUoDix5lX7N K2kA1+ab8sFT5TUqbj7QUDQwAe/kXo/Sx7onmA== X-Received: by 10.129.202.71 with SMTP id y7mr9564660ywk.74.1499637442789; Sun, 09 Jul 2017 14:57:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 14:56:42 -0700 (PDT) In-Reply-To: <14043482.U1dYDYAKmz@kitterma-e6430> References: <20170709204531.90481.qmail@ary.lan> <6250733.dllmP4se25@kitterma-e6430> <14043482.U1dYDYAKmz@kitterma-e6430> From: Eric Rescorla Date: Sun, 9 Jul 2017 14:56:42 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="089e0825978011ddfb0553e98d06" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 09 Jul 2017 21:57:26 -0000 --089e0825978011ddfb0553e98d06 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 2:49 PM, Scott Kitterman wrote: > On Sunday, July 09, 2017 02:38:00 PM Eric Rescorla wrote: > > On Sun, Jul 9, 2017 at 2:06 PM, Scott Kitterman > > > > wrote: > > > On Sunday, July 09, 2017 08:45:31 PM John Levine wrote: > > > > In article you > > > > > > write: > > > > >While I recognize that a new RFC will be needed to roll out a > different > > > > > > ECC > > > > > > > >mechanism, using fingerprints in all cases seems like there would be > > > > > > less > > > > > > > >impact on an implementation to support that new ECC algorithm, > > > > > > especially > > > > > > > >if the crypto library already includes the curve. This seems > likely if > > > > > > we > > > > > > > >were to go from ECDSA P256 to ECDSA P384, for example. > > > > > > > > I don't understand what you are proposing here. All current DKIM > > > > signatures use unhashed RSA keys. Is the suggestion that we change > > > > the spec so that all signatures must use hashed keys, so existing > > > > unhashed RSA signatures are no longer valid? > > > > > > > > Assuming that's not what you mean, we will have unhashed RSA > > > > signatures for a long time, probably forever. Given that we have > both > > > > hashed and unhashed RSA keys, why hash ECC keys? Why not just hash > > > > when it's useful? > > > > > > > > R's, > > > > John > > > > > > > > PS: By the way, the de facto single-string TXT records limit on key > > > > sizes is about 1100 bits. An unhashed 384 bit key or even an > unhashed > > > > 1024 bit key would work fine. > > > > > > The technical case for hashing RSA key records is very clear: It > provides > > > a > > > mechanism to continue using RSA with larger keys that exceed the size > > > limits > > > many domains are able to publish in DNS. > > > > > > I still haven't seen any technical argument for hashing ecdsa key > records. > > > The most I've seen is 'seems nice'. > > > > That going forward it would be better to have one way of doing things > rather > > than two, with the sole exception being the legacy RSA version. And then > at > > some point when the majority of signatures are hashed, one can simply > > delete the old code path. > > > > > The technical argument against is, I > > > think quite clear: > > > > > > 1. Solves no actual problem. > > > 2. Increases protocol complexity. > > > 3. Increases protocol fragility. > > > 4. Increases implementation requirements. > > > > I don't believe that any of these things are true to any significant > > extent. > > > > > 5. Increases the size of every single signed message. > > > > By a trivial amount, unless your key is very big, in which case hashing > > was a good idea. > > > > -Ekr > > > > > If there's some technical argument for hashing ecdsa key records now > > > beyond it > > > may be useful someday for some other signing algorithm, I'd appreciate > it > > > if > > > someone would make it. I've entirely missed it. > > > > > > Scott K > > That very much sounds to me like seems nice, maybe someday it would be > helpful. > > I don't see the notional of eventual "all key records are hashed" as having > any value whatsoever. > You're certainly entitled to that opinion. Equally, I disagree. > If you want implementers to implement new algorithms, I don't think it > makes > it more likely to add pointless additional requirements. > What I'm trying to do is reduce the additional complexity of adding new algorithms in the future by having a consistent approach going forward. I get my implementation concerns aren't a worry to you, so I don't know how > to > bridge the gap. > Well, it's not like I haven't implemented cryptographic protocols before (as has Martin Thomson), so I do think I have a reasonably informed opinion about how much additional implementation complexity is involved here. As above, you are free to feel differently. -Ekr > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --089e0825978011ddfb0553e98d06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 2:49 PM, Scott Kitterman <<= a href=3D"mailto:sklist@kitterman.com" target=3D"_blank">sklist@kitterman.c= om> wrote:
On Sunday, July 09, = 2017 02:38:00 PM Eric Rescorla wrote:
> On Sun, Jul 9, 2017 at 2:06 PM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > On Sunday, July 09, 2017 08:45:31 PM John Levine wrote:
> > > In article <AF49D563-0F63-4DD8-BFAA-DCFFF154D152@vigilsec.= com> you
> >
> > write:
> > > >While I recognize that a new RFC will be needed to roll = out a different
> >
> > ECC
> >
> > > >mechanism, using fingerprints in all cases seems like th= ere would be
> >
> > less
> >
> > > >impact on an implementation to support that new ECC algo= rithm,
> >
> > especially
> >
> > > >if the crypto library already includes the curve.=C2=A0 = This seems likely if
> >
> > we
> >
> > > >were to go from ECDSA P256 to ECDSA P384, for example. > > >
> > > I don't understand what you are proposing here.=C2=A0 Al= l current DKIM
> > > signatures use unhashed RSA keys.=C2=A0 Is the suggestion th= at we change
> > > the spec so that all signatures must use hashed keys, so exi= sting
> > > unhashed RSA signatures are no longer valid?
> > >
> > > Assuming that's not what you mean, we will have unhashed= RSA
> > > signatures for a long time, probably forever.=C2=A0 Given th= at we have both
> > > hashed and unhashed RSA keys, why hash ECC keys?=C2=A0 Why n= ot just hash
> > > when it's useful?
> > >
> > > R's,
> > > John
> > >
> > > PS: By the way, the de facto single-string TXT records limit= on key
> > > sizes is about 1100 bits.=C2=A0 An unhashed 384 bit key or e= ven an unhashed
> > > 1024 bit key would work fine.
> >
> > The technical case for hashing RSA key records is very clear: It = provides
> > a
> > mechanism to continue using RSA with larger keys that exceed the = size
> > limits
> > many domains are able to publish in DNS.
> >
> > I still haven't seen any technical argument for hashing ecdsa= key records.
> > The most I've seen is 'seems nice'.
>
> That going forward it would be better to have one way of doing things = rather
> than two, with the sole exception being the legacy RSA version. And th= en at
> some point when the majority of signatures are hashed, one can simply<= br> > delete the old code path.
>
> > The technical argument against is, I
> > think quite clear:
> >
> > 1.=C2=A0 Solves no actual problem.
> > 2.=C2=A0 Increases protocol complexity.
> > 3.=C2=A0 Increases protocol fragility.
> > 4.=C2=A0 Increases implementation requirements.
>
> I don't believe that any of these things are true to any significa= nt
> extent.
>
> > 5.=C2=A0 Increases the size of every single signed message.
>
> By a trivial amount, unless your key is very big, in which case hashin= g
> was a good idea.
>
> -Ekr
>
> > If there's some technical argument for hashing ecdsa key reco= rds now
> > beyond it
> > may be useful someday for some other signing algorithm, I'd a= ppreciate it
> > if
> > someone would make it.=C2=A0 I've entirely missed it.
> >
> > Scott K

That very much sounds to me like seems nice, maybe someday it w= ould be
helpful.

I don't see the notional of eventual "all key records are hashed&q= uot; as having
any value whatsoever.

You're certai= nly entitled to that opinion. Equally, I disagree.

=C2=A0
If you want implementers to implement new algorithms, I don't think it = makes
it more likely to add pointless additional requirements.

What I'm trying to do is reduce the additional comple= xity of adding new algorithms
in the future by having a consisten= t approach going forward.


I get my implementation concerns aren't a worry to you, so I don't = know how to
bridge the gap.

Well, it's not like= I haven't implemented cryptographic protocols before (as has
Martin Thomson), so I do think I have a reasonably informed opinion about<= /div>
how much additional implementation complexity is involved here. A= s above,
you are free to feel differently.

-Ekr


Scott K

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

--089e0825978011ddfb0553e98d06-- From nobody Sun Jul 9 17:01: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 A66AF12EB4A for ; Sun, 9 Jul 2017 17:01:54 -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 6Vl5OhmgSo26 for ; Sun, 9 Jul 2017 17:01:53 -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 B6802126B7F for ; Sun, 9 Jul 2017 17:01:52 -0700 (PDT) Received: (qmail 63867 invoked from network); 10 Jul 2017 00:01:51 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 Jul 2017 00:01:51 -0000 Date: 10 Jul 2017 00:01:29 -0000 Message-ID: <20170710000129.90943.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: ekr@rtfm.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] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 00:01:55 -0000 In article you write: >What I'm trying to do is reduce the additional complexity of adding new >algorithms in the future by having a consistent approach going forward. Given that we will always have code for both hashed and unhashed keys, since unhashed RSA isn't going away, my minimal complexity approach is to add an algorithm with unhashed keys if the keys are small, and with hashed keys if the keys are large. Since DKIM has no opportunity for algorithm negotiation, verifiers have to implement every algorithm that signers might use, so the main goal is to minimize the number of algorithms, regardless of what they are. At this point I'm inclined to take out hashed RSA, since the problem it solves only exists due to stupid configuration software, and anyone who implements hashed RSA would also implent EdDSA which doesn't have the configuration key size problem. As I read RFC 8032, the chances are pretty good that ed25519 will last as long as DKIM does, so we won't have to do this again. R's, John From nobody Sun Jul 9 18:38: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 F371312EC13 for ; Sun, 9 Jul 2017 18:38:36 -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 Kx3lAu_7hUhN for ; Sun, 9 Jul 2017 18:38:35 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002: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 7322212955F for ; Sun, 9 Jul 2017 18:38:35 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id a12so30031158ywh.3 for ; Sun, 09 Jul 2017 18:38:35 -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=x3WokAiZ2w+66bjSh/o1RiezbByKZfkiGYoWgFa/3VA=; b=E9oOJdjl3TkmwvRRmrnTJPaK5jCJmeGmVH1hEK/HlU6ACfq3JghV2hQ5GYPE6F80OV knxWIIn6J6GIvokwYjy7EE1iWa0ej9X8jdiUWQR1HNPNc6Idjcrtsb5do49Pgn59nV7K 8U2ckjKoHdrQSgxE8AtthjTDBsTh2LcxccLVFotaJV1Dxbk8SaV3GCIBFtzzHiZHd0N+ 5g4VS++12CRqtP3OXv3KR+TGSi2LzCnmEfnXULuxbHcxIMr3R3XslWpOqB0cnACy+j2h k51+vnIsKiwlqpoNI91ijEdN6NDnC4MP3HJNfV67AEAZyTRNl1IYCffIuJll7lSSQLHF t6Ow== 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=x3WokAiZ2w+66bjSh/o1RiezbByKZfkiGYoWgFa/3VA=; b=aVTEIyTxR9Jzv0Bk7zbKOS+nbVlXhxwoFHO1qhywBQr7vZCo5dvAGyxPT4hMXXO+2o cb2ZkFRAnUdJLcyC9CDqsSeYxfI11FgcljlLxn8hUIpC2uV3hpgO7zhJ83dcaR0zdQsT QjRZEdjdXEWvSMXSUPBUwv9qvAPQoXk+0mFLI8Jro6uU2t9U3fxulCMLI2Mr1amgOhYv iFV2IShtvvTE2kNslRL/dde5yBBg6sS7REMu0f17ogTPwbOWsEVforWeRutO/92kRS1U +U0BLUjzHbRnRAbJL/PhC7nhKTMSw7VlQBmyiGnWNFU6ymowpY4m9hCmUI9vGfrHxQcD 1+hA== X-Gm-Message-State: AIVw111FZ5nMQgpJVWPv/9VnJLr6etbhxuOME4KCQaN6yQ8kLTrtRWac MYnzsmkPsB05aM+Kgfg1RA0OcIIj/I/BRSk7sw== X-Received: by 10.129.50.140 with SMTP id y134mr9876489ywy.312.1499650714684; Sun, 09 Jul 2017 18:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 18:37:54 -0700 (PDT) In-Reply-To: <20170710000129.90943.qmail@ary.lan> References: <20170710000129.90943.qmail@ary.lan> From: Eric Rescorla Date: Sun, 9 Jul 2017 18:37:54 -0700 Message-ID: To: John Levine Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1140932a22e2520553eca400" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 01:38:37 -0000 --001a1140932a22e2520553eca400 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 5:01 PM, John Levine wrote: > In article mail.gmail.com> you write: > >What I'm trying to do is reduce the additional complexity of adding new > >algorithms in the future by having a consistent approach going forward. > > Given that we will always have code for both hashed and unhashed keys, > since unhashed RSA isn't going away, my minimal complexity approach is > to add an algorithm with unhashed keys if the keys are small, and with > hashed keys if the keys are large. > > Since DKIM has no opportunity for algorithm negotiation, verifiers > have to implement every algorithm that signers might use, so the > main goal is to minimize the number of algorithms, regardless of > what they are. > > At this point I'm inclined to take out hashed RSA, since the problem > it solves only exists due to stupid configuration software, and anyone > who implements hashed RSA would also implent EdDSA which doesn't > have the configuration key size problem. > Moreover, not having hashed RSA basically commits to EC-only and I know there are people who would like to keep RSA viable. Moreover, as I think I've mentioned before, this is a charter item and it was a basic assumption when the WG was formed. As I read RFC 8032, the chances are pretty good that ed25519 will last > as long as DKIM does, so we won't have to do this again. > Again, absent Quantum Computers. Anyway, I think we're past the point where mailing list discussion is helpful, so I suggest we simply pick it up in Prague. -Ekr R's, > John > --001a1140932a22e2520553eca400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 5:01 PM, John Levine <johnl@taugh.com> wrote:
In article <CABcZeBMaZ-q5kVTLF2qK+tqtgf2qA= yZFsydZrXzYTLuwC2Ecag@mail.gmail.com> you write:
>What I'm trying to do is reduce the additional complexity of adding= new
>algorithms in the future by having a consistent approach going forward.=

Given that we will always have code for both hashed and unhashed key= s,
since unhashed RSA isn't going away, my minimal complexity approach is<= br> to add an algorithm with unhashed keys if the keys are small, and with
hashed keys if the keys are large.

Since DKIM has no opportunity for algorithm negotiation, verifiers
have to implement every algorithm that signers might use, so the
main goal is to minimize the number of algorithms, regardless of
what they are.

At this point I'm inclined to take out hashed RSA, since the problem it solves only exists due to stupid configuration software, and anyone
who implements hashed RSA would also implent EdDSA which doesn't
have the configuration key size problem.

Moreover, not having hashed RSA basically commits to EC-only and
I know there are people who would like to keep RSA viable. Mor= eover,
as I think I've mentioned before, this is a charter it= em and it was a basic
assumption when the WG was formed.


=C2=A0As I read RFC 8032, the chances are pretty good that ed25519 wi= ll last
as long as DKIM does, so we won't have to do this again.

Again, absent Quantum Computers.=C2=A0

=
Anyway, I think we're past the point where mailing list disc= ussion is helpful,
so I suggest we simply pick it up in Prague.

-Ekr

R's,
John

--001a1140932a22e2520553eca400-- From nobody Sun Jul 9 19:21: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 6C925131474 for ; Sun, 9 Jul 2017 19:21:44 -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 yfE72qyqLMNU for ; Sun, 9 Jul 2017 19:21:42 -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 201A012ECCB for ; Sun, 9 Jul 2017 19:21:42 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x125so30438097ywa.0 for ; Sun, 09 Jul 2017 19:21: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=KMnHgPi4HuK6O3uLkFCeIvdrJPPcLuvLTjq+4Mm4eTQ=; b=b2HIizsZfLY7hz6sTBWYV8qYgm7d1zfmEN6lFXGQQEwpNepH30CgWNraIfssKgIDcB e9FpS83u0JYdrwbA278W/rBgHBg5eHSElLbQTmgVTo2ln3/Y6HDbKKiTvsAgamIK5+80 sKos9OBVZ/ql3rdTuID6kmQoMIj/MIzXh57TN2mz6cEvLHGSkHwG63a8JRr5MqBzyxVz d2KBxnhS2cghsYGy7t77EQluiQnnIH8m7KB0d9FspeXmn5Z9xOcycCAbir7hJojCfLyr NpdzQXnpsXgiFIZXLiRTYZD7mNMKlEkH6NBvhYyHwAP7Haa0cpBxwha5/vsWvEVLfm// YpXQ== 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=KMnHgPi4HuK6O3uLkFCeIvdrJPPcLuvLTjq+4Mm4eTQ=; b=UDO4mShLf6LH42fSW4rlhU/zws2iK5Ihf/1vROcwFaQbZNg0/b4/9q/RpqowHtphnV quOtdMziAvkJj+aToUUdxFAyZu2M2Q5cg9OqZOsM9D4krMrngnHeqdMFXwBdt8zwOH3u p0jAd0k5I1G65h9Y9FJvD37glVZdT0R5CrRVSgT6IPNuXZgNFbae0M1Za8dhzqWPtOsn 6i5Xr1D77Aj0BLJjPDXaJ0vSmFekBUvNALYpDTED5BL9B0kLp6MCL01jgquNPSt1I4i9 aVYcZWPo5E/hDmRIBaccHjijwc89SueY6gCRnHbEM+KPH1QtqW3fExL9o//cRe2ALOhI drCg== X-Gm-Message-State: AIVw113gDrNHFT6i4biiC/IVTHCI9+nLm7PkWu/pE19odQN468RQ2rMD uCO1JdoobUnW5YW4DzKmozmoGPV/Ug== X-Received: by 10.129.86.11 with SMTP id k11mr10255028ywb.154.1499653301369; Sun, 09 Jul 2017 19:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.173.203 with HTTP; Sun, 9 Jul 2017 19:21:40 -0700 (PDT) In-Reply-To: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> From: denis bider Date: Sun, 9 Jul 2017 20:21:40 -0600 Message-ID: To: Jim Fenton Cc: "Salz, Rich" , "dcrup@ietf.org" , Eric Rescorla , Martin Thomson , Jon Callas Content-Type: multipart/alternative; boundary="001a11431a1c50884e0553ed3e47" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 02:21:44 -0000 --001a11431a1c50884e0553ed3e47 Content-Type: text/plain; charset="UTF-8" We can break down the following levels of future proofing: (1) Future event occurs, and no changes are needed by anyone. The event is already accounted for by configurations, implementations, and specifications. (2) Future event occurs, and changes are needed to configurations. The event is already accounted for by implementations and specifications. (3) Future event occurs, and changes are needed to implementations, which must then be deployed. The event is already accounted for by specifications. (4) Future event occurs, and changes are needed to specifications, which must then be implemented and deployed. The event is not accounted for. In this case, when we're talking about "future proofing", we are dealing with category (4). We cannot do (1), (2), or (3) because although we know what the future event might be (quantum computing), we do not have a solution we can specify at this time. Therefore, we can have no future proofing. All talk of future proofing is pointless because we cannot future proof for this event until we AT LEAST can move to category 3 instead of 4. And to move to category 3, we need to be able to specify something that explicitly addresses the future event. Requiring fingerprints for ECDSA or EdDSA does nothing for future proofing. If the future event occurs, we will still be dealing with a category 4 event that requires new specifications, new implementations, and new deployments. No work will be spared. On Sat, Jul 8, 2017 at 1:08 AM, Jim Fenton wrote: > On Jul 7, 2017, at 4:24 PM, Salz, Rich wrote: > > >> For what it's worth, I agree with Jim and Ekr. Hashing is just fine. > > > > Is it fine, or is it a required or just good? > > > > Nobody is saying there is anything wrong with hashing. Several are > saying that, given the limitations of some DNS deployments, it is useful to > avoid the indirection and just put the key when we can. > > What DNS deployment limitation would be adversely affected by the use of a > hash? I can't think of any. > > "Avoid the indirection" makes it sound like more network round-trips would > be required if a hash is used. No more network traffic is involved; the > verifier only needs to compute the hash of the key included in the message > and compare that with the fingerprint included in the key lookup response > from DNS. The verifier can even check the signature prior to receiving the > DNS response, if it wants. > > I'm supporting publishing key fingerprints because I think it's slightly > more future-proof, and having been burned by that once already, I don't > want to make the same mistake again. But if rough consensus decides > otherwise, we go with that of course. > > I still haven't heard an answer to the following question I posed about > the fingerprints, though: Will the fingerprints always be sha256, or do we > need to specify the fingerprint algorithm in the DNS record? In other > words, will we assume that sha256 will be strong enough for the life of > this protocol? > > -Jim > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a11431a1c50884e0553ed3e47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We can break down the following levels of future proofing:=

(1) Future event occurs, and no changes are needed by a= nyone. The event is already accounted for by configurations, implementation= s, and specifications.

(2) Future event occurs, an= d changes are needed to configurations. The event is already accounted for = by implementations and specifications.

(3) Future = event occurs, and changes are needed to implementations, which must then be= deployed. The event is already accounted for by specifications.
=
(4) Future event occurs, and changes are needed to specifica= tions, which must then be implemented and deployed. The event is not accoun= ted for.

In this case, when we're talking abou= t "future proofing", we are dealing with category (4). We cannot = do (1), (2), or (3) because although we know what the future event might be= (quantum computing), we do not have a solution we can specify at this time= .

Therefore, we can have no future proofing. All t= alk of future proofing is pointless because we cannot future proof for this= event until we AT LEAST can move to category 3 instead of 4. And to move t= o category 3, we need to be able to specify something that explicitly addre= sses the future event.

Requiring fingerprints for = ECDSA or EdDSA does nothing for future proofing. If the future event occurs= , we will still be dealing with a category 4 event that requires new specif= ications, new implementations, and new deployments. No work will be spared.=


On Sat, Jul 8, 2017 at 1:08 AM, Jim Fenton <= fenton@bluepopc= orn.net> wrote:
On Jul 7, 2017, at 4:24 PM, Salz, Rich <rsalz@akamai.com> wrote:

>> For what it's worth, I agree with Jim and Ekr. Hashing is just= fine.
>
> Is it fine, or is it a required or just good?
>
> Nobody is saying there is anything wrong with hashing.=C2=A0 Several a= re saying that, given the limitations of some DNS deployments, it is useful= to avoid the indirection and just put the key when we can.

What DNS deployment limitation would be adversely affected by the us= e of a hash? I can't think of any.

"Avoid the indirection" makes it sound like more network round-tr= ips would be required if a hash is used. No more network traffic is involve= d; the verifier only needs to compute the hash of the key included in the m= essage and compare that with the fingerprint included in the key lookup res= ponse from DNS. The verifier can even check the signature prior to receivin= g the DNS response, if it wants.

I'm supporting publishing key fingerprints because I think it's sli= ghtly more future-proof, and having been burned by that once already, I don= 't want to make the same mistake again. But if rough consensus decides = otherwise, we go with that of course.

I still haven't heard an answer to the following question I posed about= the fingerprints, though: Will the fingerprints always be sha256, or do we= need to specify the fingerprint algorithm in the DNS record? In other word= s, will we assume that sha256 will be strong enough for the life of this pr= otocol?

-Jim
_____________________= __________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup

--001a11431a1c50884e0553ed3e47-- From nobody Sun Jul 9 19:27: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 DC06113148C for ; Sun, 9 Jul 2017 19:27:23 -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 WWwBilSZfcWz for ; Sun, 9 Jul 2017 19:27:22 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 2BF50131488 for ; Sun, 9 Jul 2017 19:27:22 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id a12so30287436ywh.3 for ; Sun, 09 Jul 2017 19:27:22 -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=LFEb9O7OUEzNXkBUQcg2ASHXf4hm0wZmHkZkyMyELZ8=; b=Rj6KMEnhReei/JJdSzudZx2sJOBey+anfjS5Jh3Y6DnlE34q1izjZHbML8r21CioI4 NGJW5niILwsGhteeBs9PVc3OFx09GHt0rBhBpPgt/6QaRrCXKbvHLqBBHaQdd+gi7kEC O0jaL3FCH+MqWB9cJtZ+lIlokwRuQ/Yq5qm1C1eaJ6LHWUsoDycpin36QdCxbrBFg6kF ne1PjKgiy3qnd5tv9n24Pr4w+h+gZX1ObH+O0tmWMBMSEAziFP/N7Ld29uy4TT06UK08 LxprKIVDr58PG/maIEHL1UIG73HyjLFsW5exBYWoWyognPgbgcMI3L6NbmoPUzKFD03V VdtQ== 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=LFEb9O7OUEzNXkBUQcg2ASHXf4hm0wZmHkZkyMyELZ8=; b=P+LWLADgtsZu8Cf68c6bSFB6PCnYNTFHinP5DH6IN+ArA5BQ+rSaAywL7RIywojS4D BcVTb9LLUFcgsC/O7xDlox574MUbsFY1/2qLjBwf3owFLQk8dXXXXcfriZ/g6rPL9Qse ZRiLOVy7Vq1nIn8nM7yiOXuB6ot/RsO+gCVEX9aFz0Msk6UzOcWukLgZ8IuVsHDWZi5/ Dilrf+bGkYwZiYFX7nTU4GPriv+8dU2441dA2GxYWQUD8yEkZPMpsLhPn65r81QHEdOC xUCdHnGOkbr67leWXVqd/5F+zsGXpj/nu+PoNUNBstME/LKxrCPUhfv6q/njuqpb7Sno JqZg== X-Gm-Message-State: AIVw110RSbOlHFk/9HUZhxqbEc62ZLeeo0p3Ic12IqaaVPbb98MzElaC LYCaOeWqtRW/v8Ju9RAPxO3QAvzq+Ips X-Received: by 10.129.50.140 with SMTP id y134mr9988215ywy.312.1499653641449; Sun, 09 Jul 2017 19:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 19:26:40 -0700 (PDT) In-Reply-To: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> From: Eric Rescorla Date: Sun, 9 Jul 2017 19:26:40 -0700 Message-ID: To: denis bider Cc: Jim Fenton , "Salz, Rich" , "dcrup@ietf.org" , Martin Thomson , Jon Callas Content-Type: multipart/alternative; boundary="001a1140932a95c5400553ed52d7" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 02:27:24 -0000 --001a1140932a95c5400553ed52d7 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 7:21 PM, denis bider wrote: > We can break down the following levels of future proofing: > > (1) Future event occurs, and no changes are needed by anyone. The event is > already accounted for by configurations, implementations, and > specifications. > > (2) Future event occurs, and changes are needed to configurations. The > event is already accounted for by implementations and specifications. > > (3) Future event occurs, and changes are needed to implementations, which > must then be deployed. The event is already accounted for by specifications. > > (4) Future event occurs, and changes are needed to specifications, which > must then be implemented and deployed. The event is not accounted for. > > In this case, when we're talking about "future proofing", we are dealing > with category (4). We cannot do (1), (2), or (3) because although we know > what the future event might be (quantum computing), we do not have a > solution we can specify at this time. > Actually, this isn't entirely true. We could presumably deploy hash signatures, they're just not very efficient. In fact, the one thing that we do know with high probability about any PQ algorithm is that it is likely to be less efficient than the existing algorithms, and one of the ways in which it might be less efficient is large public keys, in which case having hashes will be useful. Moreover, QC isn't the only possible event that could cause us to wish to have larger keys. There might be a modest improvement in dlog that would make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, this is how we got to the point where we wish to have RSA keys > 1024). Requiring fingerprints for ECDSA or EdDSA does nothing for future proofing. > If the future event occurs, we will still be dealing with a category 4 > event that requires new specifications, new implementations, and new > deployments. No work will be spared. > I don't agree with this for the reasons above. -Ekr > > > On Sat, Jul 8, 2017 at 1:08 AM, Jim Fenton wrote: > >> On Jul 7, 2017, at 4:24 PM, Salz, Rich wrote: >> >> >> For what it's worth, I agree with Jim and Ekr. Hashing is just fine. >> > >> > Is it fine, or is it a required or just good? >> > >> > Nobody is saying there is anything wrong with hashing. Several are >> saying that, given the limitations of some DNS deployments, it is useful to >> avoid the indirection and just put the key when we can. >> >> What DNS deployment limitation would be adversely affected by the use of >> a hash? I can't think of any. >> >> "Avoid the indirection" makes it sound like more network round-trips >> would be required if a hash is used. No more network traffic is involved; >> the verifier only needs to compute the hash of the key included in the >> message and compare that with the fingerprint included in the key lookup >> response from DNS. The verifier can even check the signature prior to >> receiving the DNS response, if it wants. >> >> I'm supporting publishing key fingerprints because I think it's slightly >> more future-proof, and having been burned by that once already, I don't >> want to make the same mistake again. But if rough consensus decides >> otherwise, we go with that of course. >> >> I still haven't heard an answer to the following question I posed about >> the fingerprints, though: Will the fingerprints always be sha256, or do we >> need to specify the fingerprint algorithm in the DNS record? In other >> words, will we assume that sha256 will be strong enough for the life of >> this protocol? >> >> -Jim >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup >> > > --001a1140932a95c5400553ed52d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jul 9, 2017 at 7:21 PM, denis bider <denisbider.ietf@gmail.com= > wrote:
W= e can break down the following levels of future proofing:

(1) Future event occurs, and no changes are needed by anyone. The event i= s already accounted for by configurations, implementations, and specificati= ons.

(2) Future event occurs, and changes are need= ed to configurations. The event is already accounted for by implementations= and specifications.

(3) Future event occurs, and = changes are needed to implementations, which must then be deployed. The eve= nt is already accounted for by specifications.

(4)= Future event occurs, and changes are needed to specifications, which must = then be implemented and deployed. The event is not accounted for.

In this case, when we're talking about "future pro= ofing", we are dealing with category (4). We cannot do (1), (2), or (3= ) because although we know what the future event might be (quantum computin= g), we do not have a solution we can specify at this time.

Actually, this isn't entirely true. We coul= d presumably deploy hash signatures, they're just not very efficient. I= n fact, the one thing that we do know with high probability about any PQ al= gorithm is that it is likely to be less efficient than the existing algorit= hms, and one of the ways in which it might be less efficient is large publi= c keys, in which case having hashes will be useful.

Moreover, QC isn't the only possible event that could cause us to wis= h to have larger keys. There might be a modest improvement in dlog that wou= ld make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, t= his is how we got to the point where we wish to have RSA keys > 1024).


Requiring fingerprints for ECDSA or EdDSA does nothing for fu= ture proofing. If the future event occurs, we will still be dealing with a = category 4 event that requires new specifications, new implementations, and= new deployments. No work will be spared.

=
I don't agree with this for the reasons above.
-Ekr
=C2=A0


On Sat, Jul 8, 2017 at 1:08 AM, Jim= Fenton <fenton@bluepopcorn.net> wrote:
=
On Jul 7, 2017,= at 4:24 PM, Salz, Rich <rsalz@akamai.com> wrote:

>> For what it's worth, I agree with Jim and Ekr. Hashing is just= fine.
>
> Is it fine, or is it a required or just good?
>
> Nobody is saying there is anything wrong with hashing.=C2=A0 Several a= re saying that, given the limitations of some DNS deployments, it is useful= to avoid the indirection and just put the key when we can.

What DNS deployment limitation would be adversely affected by the us= e of a hash? I can't think of any.

"Avoid the indirection" makes it sound like more network round-tr= ips would be required if a hash is used. No more network traffic is involve= d; the verifier only needs to compute the hash of the key included in the m= essage and compare that with the fingerprint included in the key lookup res= ponse from DNS. The verifier can even check the signature prior to receivin= g the DNS response, if it wants.

I'm supporting publishing key fingerprints because I think it's sli= ghtly more future-proof, and having been burned by that once already, I don= 't want to make the same mistake again. But if rough consensus decides = otherwise, we go with that of course.

I still haven't heard an answer to the following question I posed about= the fingerprints, though: Will the fingerprints always be sha256, or do we= need to specify the fingerprint algorithm in the DNS record? In other word= s, will we assume that sha256 will be strong enough for the life of this pr= otocol?

-Jim
_______________________= ________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup


--001a1140932a95c5400553ed52d7-- From nobody Sun Jul 9 20:02: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 5FD4613148D for ; Sun, 9 Jul 2017 20:02:37 -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 txEMJ3RW3OvX for ; Sun, 9 Jul 2017 20:02:35 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 7DBE913148C for ; Sun, 9 Jul 2017 20:02:35 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id 32so62712464qtv.1 for ; Sun, 09 Jul 2017 20:02:35 -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=c+P62gObLvb6y+D7qoYH6A5PzT3Luq4rIufFMM71n2s=; b=HuBiNLWWost9l7YMa5Bh02oNbEN+ygFUO+Xv4zS/kaB6oGm7KQhwfRZUq5tqGCyg8r ElIOxCXilLtniMUzahYWWxvq36Sy07KoHiQS8l2jR9ViaHko1snsyW1ztLzxXR862alY rD9eUJFEUVq57p85v+Bb+2W4LfhL5UG92vsh8sqgA0GzYVR6fffKNuQeZAKfa8vtHzmQ uC+Kv7QqR4DBiiJJkJEtS836hkteah6axettg/4khJTZioHtIqGd9XJfFBYGkjqQyd9f ILjfmdKr7jbbz73qtAVBllcT/HMg8Jkz7JRl8ITF6wHbXM5TVYTiTjQkXp+rmTXV0/FV 5krA== 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=c+P62gObLvb6y+D7qoYH6A5PzT3Luq4rIufFMM71n2s=; b=oZ7i8tR6cumMahLRBp8PXh7ZW1hbvLr5vy64gmxbv4qqCXSZlCrFvSOgGuvx7hYIei HSLmrjcqK7IE3gplARbFIxEAYpzj3mhL1novpsTtMU+oBR8Q+vo+rC7KeS2keKaLertB 7ZPH+cFaZCukvvHXVhySu2CIBtPdEotKbClKpaXlkVUlNK7tCH1nL+RmzMKb90Abde8/ I2sFrgkvVAwT1Sy95j1083CgQK8wZTAZpdyh9NSvzjt5ScyvfQbKteUHUDbYfcfvgtv3 x7u9/XBWiooaaE4ZRiBANYnG5a2NeopB5azkoB8lzZBTkA/dVVeioYUZnB5iYJPkJCer hVSA== X-Gm-Message-State: AIVw1134teKu77fhLdyW/d5oHmoL5pU976tCvbexFta7hcDNHRiaMpun Yn2TgA/N+uXnls3FjfrIaEd5SBNYRvyt X-Received: by 10.237.45.67 with SMTP id h61mr1652739qtd.246.1499655754696; Sun, 09 Jul 2017 20:02:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.157 with HTTP; Sun, 9 Jul 2017 20:02:34 -0700 (PDT) In-Reply-To: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> From: Peter Goldstein Date: Sun, 9 Jul 2017 20:02:34 -0700 Message-ID: To: Eric Rescorla Cc: denis bider , Jim Fenton , "Salz, Rich" , "dcrup@ietf.org" , Martin Thomson , Jon Callas Content-Type: multipart/alternative; boundary="94eb2c124a888b5efc0553edd00b" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 03:02:37 -0000 --94eb2c124a888b5efc0553edd00b Content-Type: text/plain; charset="UTF-8" > > Moreover, QC isn't the only possible event that could cause us to wish to > have larger keys. There might be a modest improvement in dlog that would > make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, this > is how we got to the point where we wish to have RSA keys > 1024). > Support for larger keys isn't the issue at hand. The issue is the 255 character limit imposed by the DNS crudware. And I think keys for each of those curves easily fit under the limit. Based on my math (with 24 additional bytes allocated for version tag/value and any other key/value pairs), then we've got (assuming my key sizes are correct): Curve448 - 114 bytes (key) + 24 bytes = 138 bytes maximum P-521 - 212 bytes (key) + 24 bytes = 236 bytes maximum I don't do much low level crypto these days, so if I'm off on my base 64 public key sizes, please let me know. But in both cases it looks like there's room to spare. As for QC, I think John's point earlier in the thread isn't that QC will require larger keys - but rather than real QC would require fundamental reconsideration of DKIM as a whole. Best, Peter -- [image: logo for sig file.png] Bringing Trust to Email Peter Goldstein | CTO & Co-Founder peter@valimail.com +1.415.793.5783 --94eb2c124a888b5efc0553edd00b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Moreover= , QC isn't the only possible event that could cause us to wish to have = larger keys. There might be a modest improvement in dlog that would make Cu= rve25519 problematic but Curve448 or P-521 comfortable (indeed, this is how= we got to the point where we wish to have RSA keys > 1024).


Support for larger keys isn't the issue at = hand.=C2=A0 The issue is the 255 character limit imposed by the DNS crudwar= e.=C2=A0 And I think keys for each of those curves easily fit under the lim= it.

Based on my math (with 24 additional bytes all= ocated for version tag/value and any other key/value pairs), then we've= got (assuming my key sizes are correct):

Curve448= - 114 bytes (key) + 24 bytes =3D 138 bytes maximum
P-521 - 212 b= ytes (key) + 24 bytes =3D 236 bytes maximum

I don&= #39;t do much low level crypto these days, so if I'm off on my base 64 = public key sizes, please let me know.=C2=A0 But in both cases it looks like= there's room to spare.

As for QC, I think Joh= n's point earlier in the thread isn't that QC will require larger k= eys - but rather than real QC would require fundamental reconsideration of = DKIM as a whole.

Best,

Pe= ter

--
<= div dir=3D"ltr">


3D"logo

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783
--94eb2c124a888b5efc0553edd00b-- From nobody Sun Jul 9 20:06: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 F213313148C for ; Sun, 9 Jul 2017 20:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, 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 WNXxG4A9Ii12 for ; Sun, 9 Jul 2017 20:06:34 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 75BEB131443 for ; Sun, 9 Jul 2017 20:06:34 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id x125so30675122ywa.0 for ; Sun, 09 Jul 2017 20:06:34 -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=Qn+CNZ+bOVnStrTS1zRNUZHAhcDGlbBHrlqsqGkgAEE=; b=anGIHrG5SGL+FzCxGVaogVUWSgg5uV4VsIwkeCQT60mKZFfPiv3B5LprBRzQLoPBtF SgIcQfYpJdOAYNt4MRBB+xR4pFfmhOkEig19Y8ApiO5URGToBJyEhvL53vADidqd2nQb 4Ym2TY2QQuoAFIqUFJ1nu2v/DIMZPmAAymN4mvEMOi7MDtIu77bNcLcADoX+NTKoAKel jrc0g0e3nnCXJfnVMPlkmPjelg3XRrHxrLB060GwVA4Sb/LIdvcQFTA47AK8IJ2e9hHK MRS9c+Uz0n2Uvk9YfEutZ9r1DYUXlLLgW9o/w2ozTOpg2Gx7IF0l33XqvvYBffvhwnw5 OYBA== 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=Qn+CNZ+bOVnStrTS1zRNUZHAhcDGlbBHrlqsqGkgAEE=; b=ENAVfzRU43lCRtvhNmoEt+rqBcRvKuDHVeR2dQBON0m2hvfDh3+BjdEZzD4/7QqxXf WqZYioLNRVC5dUqSCs3/PMicY4RMPxLJ4KkG0RTu0eBPs02vBR1yJ5fAjik/8CSGA91k ukjeG3hCcE9CyU7DiCt8DG1FiTqd8Yu3FmZVYIYTWW1cUdWlckzJ4jbL1JRK0go5S81M 7k7fmpEaevZDfymHskgBZApG9ehGwWkN9GkNiv7mVgYO/cRczHVkUmTniaBXT8OPO9lk DWmHdyvi3rb93kSdnLpH35ooRC8N6n+aHkHobKzjrJIc6smia3ImDpOdbxGL1UdoZDS+ iROg== X-Gm-Message-State: AIVw111ro4KdHV11CB+xoyNcdISA3TtEKmERPlgerzaY6bzlgmm1yPb+ Mz7fp9R0elwILnHvor08/Z2GDs1xTQoL X-Received: by 10.129.71.69 with SMTP id u66mr10677016ywa.270.1499655993762; Sun, 09 Jul 2017 20:06:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 20:05:53 -0700 (PDT) In-Reply-To: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> From: Eric Rescorla Date: Sun, 9 Jul 2017 20:05:53 -0700 Message-ID: To: Peter Goldstein Cc: denis bider , Jim Fenton , "Salz, Rich" , "dcrup@ietf.org" , Martin Thomson , Jon Callas Content-Type: multipart/alternative; boundary="001a114d71eccb42450553eddebe" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 03:06:36 -0000 --001a114d71eccb42450553eddebe Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 8:02 PM, Peter Goldstein wrote: > Moreover, QC isn't the only possible event that could cause us to wish to >> have larger keys. There might be a modest improvement in dlog that would >> make Curve25519 problematic but Curve448 or P-521 comfortable (indeed, this >> is how we got to the point where we wish to have RSA keys > 1024). > > >> > Support for larger keys isn't the issue at hand. The issue is the 255 > character limit imposed by the DNS crudware. And I think keys for each of > those curves easily fit under the limit. > I'm referring to the claim that hashing doesn't provide any value. For any curve > 256 bits, it does. As for QC, I think John's point earlier in the thread isn't that QC will > require larger keys - but rather than real QC would require fundamental > reconsideration of DKIM as a whole. > It's not clear to me why that would be true, given that the target for post-quantum algorithms is to have them be drop-in replacements for the existing algorithms, albeit with inferior performance. -Ekr > 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> > --001a114d71eccb42450553eddebe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 8:02 PM, Peter Goldstein <<= a href=3D"mailto:peter@valimail.com" target=3D"_blank">peter@valimail.com> wrote:
Moreover, Q= C isn't the only possible event that could cause us to wish to have lar= ger keys. There might be a modest improvement in dlog that would make Curve= 25519 problematic but Curve448 or P-521 comfortable (indeed, this is how we= got to the point where we wish to have RSA keys > 1024).


Support for larger keys isn't the issue= at hand.=C2=A0 The issue is the 255 character limit imposed by the DNS cru= dware.=C2=A0 And I think keys for each of those curves easily fit under the= limit.

I'm ref= erring to the claim that hashing doesn't provide any value. For any cur= ve > 256 bits, it does.


As = for QC, I think John's point earlier in the thread isn't that QC wi= ll require larger keys - but rather than real QC would require fundamental = reconsideration of DKIM as a whole.

It's not clear to me why that would be true, given tha= t the target for post-quantum algorithms is to have them be drop-in replace= ments for the existing algorithms, albeit with inferior performance.
<= div>
-Ekr

=

Best,<= /div>

Peter

--
=


Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

peter@valimail.com

+1.415.793.5783

--001a114d71eccb42450553eddebe-- From nobody Sun Jul 9 20:49: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 7D9C1131540 for ; Sun, 9 Jul 2017 20:49:20 -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 ApwFzQzHqSWv for ; Sun, 9 Jul 2017 20:49:18 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 B19AF126CB6 for ; Sun, 9 Jul 2017 20:49:18 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id i2so63147445qta.3 for ; Sun, 09 Jul 2017 20:49: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 :cc; bh=h8rYWVIaL8OzIv9C/EucSHVGhQlj4W8uIKSnZXIO/HQ=; b=aIjY3/1ecUEUWOlM7jUCswdhkOgnRj6QuHMrp+9yStFM28Bv5rWf4ZdVMWFbQdQoo2 XxHUWa4Zv7JkCWpq0McMVy5CqgA7o4Mptn65dAlRXg10OWXeEQk/movJFeUrPv3BMXmC aSFcwB5BFRnp+OK9l4lZN/rE43RCUZMYuZJNgIhiNVziwQe1jNG/3tN++PomjDZC6C1W SqgHtNFvtybqs5UKT0CQYrFbu/1WHA73nrETzjVKmMGRkU/KtDKswSj0FM9MnWjKd0bI b0djv1XpmqUv8/4r0m5xUEUhD9Pjk0jL2Qv6osxtg86QvBLOtxC+SRZv3Pg6fPwNy5qA vu5g== 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=h8rYWVIaL8OzIv9C/EucSHVGhQlj4W8uIKSnZXIO/HQ=; b=hTt/0o3WU5YISWCbB6HQ5wP22ORqvLDs+aYMQs9tnqCzQKNkJCS/kUpfdTCn0psF82 08TaG9TBRYtKHzQpvU6ZxAGdRTwmAkxMAjT+b/cN+OzB+/RZbrcME8D0aHDo/AVh/HJ1 1tmMYcd57gQnlPD1D39coAOCp5J+FtKkF5DmMyfhEW7KPDcEezdvqsI5zSUYo0TqZqfY leN1FZBkLhqUYlnlnxmLgUnzkS+hdge/PjtRSUSyQMqkuomXV5w+kwS7wVTz89519d++ QWqlonFT3PHF2VTBKCjE7SrndcBYyDz9quNzl0zRnsjvmwdPeiXZgWG+8lq4so3MAUWL 4uQQ== X-Gm-Message-State: AIVw1131Ju6qmqXiN/BnfB7RhU2Ol8nj/uD/RYjKQ0d8tsq2HdHqNzO/ sFCgnoyioLVqK2uzICIx0VYWaGGa17oG X-Received: by 10.200.53.151 with SMTP id k23mr1839264qtb.104.1499658557772; Sun, 09 Jul 2017 20:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.185.157 with HTTP; Sun, 9 Jul 2017 20:49:16 -0700 (PDT) In-Reply-To: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> From: Peter Goldstein Date: Sun, 9 Jul 2017 20:49:16 -0700 Message-ID: To: Eric Rescorla Cc: denis bider , Jim Fenton , "Salz, Rich" , "dcrup@ietf.org" , Martin Thomson , Jon Callas Content-Type: multipart/alternative; boundary="001a113eced49ee9450553ee7738" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 03:49:20 -0000 --001a113eced49ee9450553ee7738 Content-Type: text/plain; charset="UTF-8" > > Support for larger keys isn't the issue at hand. The issue is the 255 >> character limit imposed by the DNS crudware. And I think keys for each of >> those curves easily fit under the limit. >> > > I'm referring to the claim that hashing doesn't provide any value. For any >> curve > 256 bits, it does. > > Nope, that's the wrong limit in this case. By itself we have no interest in whether the hashed key is smaller than the key itself. Using a hashed key is always a loss on space (need to include the full key on each message), time/CPU (computing the hash) and complexity - even when the hashed key is smaller than the key itself. It's always a loss - the question is whether the loss has any offsetting value. Hashing only provides value if the base64 encoded public key pushes the record over the 255 byte limit. The point of my math was to show that the larger key size EC algorithms work fine within this limit without hashing. There is a limit, but it's higher than the key size for all plausible EC algorithms likely to be introduced in the next decade. If we didn't have to deal with the 255 limit, we wouldn't be talking about hashing RSA 2048. We'd just use a bigger key with the existing format and algorithm and be done with it. We wouldn't even need a new RFC (support for 2048 bit keys is required by RFC 6376 https://tools.ietf.org/html/rfc6376#section-3.3.3). There was zero interest in adding fingerprinting for RSA 1024 bit keys - even though the fingerprint would be much smaller than the key. The existing format works fine for these keys. So it's safe to say we could handle any EC curve <= 1024 bits without fingerprinting. The value of the hashing is entirely in its ability to help DNS administrators avoid this 255 byte limit. And my point is that for the likely alternatives that would be added in the future, larger key RSA aside, hashing adds no value. Best, Peter --001a113eced49ee9450553ee7738 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support for larger keys isn't the issue at hand.=C2=A0 The issue= is the 255 character limit imposed by the DNS crudware.=C2=A0 And I think = keys for each of those curves easily fit under the limit.
<= /div>
=C2=A0
I'm referring to the claim that hashing doesn't provide any valu= e. For any curve > 256 bits, it does.
Nope, that's the wrong limit in t= his case.=C2=A0 By itself we have no interest in whether the hashed key is = smaller than the key itself.=C2=A0 Using a hashed key is always a loss on s= pace (need to include the full key on each message), time/CPU (computing th= e hash) and complexity - even when the hashed key is smaller than the key i= tself.=C2=A0 It's always a loss - the question is whether the loss has = any offsetting value.

Hashing only provides value if the base64 encoded public k= ey pushes the record over the 255 byte limit.=C2=A0 The point of my math wa= s to show that the larger key size EC algorithms work fine within this limi= t without hashing.=C2=A0 There is a limit, but it's higher than the key= size for all plausible EC algorithms likely to be introduced in the next d= ecade.

If we didn't have to deal with the 255 limit, we wouldn't be = talking about hashing RSA 2048.=C2=A0 We'd just use a bigger key with t= he existing format and algorithm and be done with it.=C2=A0 We wouldn't= even need a new RFC (support for 2048 bit keys is required by RFC 6376 https://tools.ie= tf.org/html/rfc6376#section-3.3.3).

There was = zero interest in adding fingerprinting for RSA 1024 bit keys - even though = the fingerprint would be much smaller than the key.=C2=A0 The existing form= at works fine for these keys.=C2=A0 So it's safe to say we could handle= any EC curve <=3D 1024 bits without fingerprinting.

The value of the hashing is entirely in its ability to help DNS admin= istrators avoid this 255 byte limit.=C2=A0 And my point is that for the lik= ely alternatives that would be added in the future, larger key RSA aside, h= ashing adds no value.

Best,

Peter


--001a113eced49ee9450553ee7738-- From nobody Sun Jul 9 20:56: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 9E2BB131547 for ; Sun, 9 Jul 2017 20:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, 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 aFMuQBiIx2-r for ; Sun, 9 Jul 2017 20:56:50 -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 CAE7E131544 for ; Sun, 9 Jul 2017 20:56:49 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x125so30925826ywa.0 for ; Sun, 09 Jul 2017 20:56:49 -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=bOy6Pr/umObFw8DMV0BwT5uhNpKdWZOyRXrs2E+lB1E=; b=uhvKRQ+H2t8kPUzJnnNTUdkykBYigW4fgE100GMi3zlbYpSwjUn/fmc3aTsJUf14QE 3y5BsJ0uH/tODcthIufvpo4dZ7paEEiVBPwlDZ1OncqXXfj5771lHumPgvez2kgI84+T oelhpra08QjV4V1a0OWpykEhdtFuY9zlyjm5e75eyD5bwnqJ5CfSiZTxMeOsMfCQM6XQ wI3dmTz/7KgMWin/8Ph4AIEqG+mZQTG5dEVKbuz5QjCg7sSQls43fOJHwdejzTxBUAad OKXe4Z29+wwqcrxLXwRX5siX5GAjlF4ih79JrQYiikyyYxWB4zfO0a8u3Elo7fNa8Kic jAqQ== 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=bOy6Pr/umObFw8DMV0BwT5uhNpKdWZOyRXrs2E+lB1E=; b=OKXy7G7Tpz9PtWS1LhvA85Ehi2Bt4qi33ZFsplh6cqSX7k48diWP8EPuSAjTFNjsez ZoyIogyg0NU4VmoXFHYgYaQt38q8nvN6eW9BxMsOAlIxutC1nPlUNU0OMvWGKb9ys/Bk 2lFowUEJtQcpq5ygxuusPCP3MdFPyDc5CZ9nuOhWzh8XwhG6gI0Afp0rsu1L50xuIwur GAGeQ874/i42E/Hvbj8+baFYStY4yM0lVR/CxQtfshQgV5e5nkpIptSTiPbP6WYfx79p AfpR4/REkPec4ciib1MqL4jITcjCydVREcvupHkvZW/2RSi2hX+x3ut2yYJgypraNw7B kTOw== X-Gm-Message-State: AIVw1130nxI4i4r5VQgYzoemgTZzqqMfKVXJ3diNV0aRpmghSa/0+roh NsxhOabqYwoQ2RYwwwwhfFFnD5TqD7eZ X-Received: by 10.129.50.140 with SMTP id y134mr10196588ywy.312.1499659009034; Sun, 09 Jul 2017 20:56:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 9 Jul 2017 20:56:08 -0700 (PDT) In-Reply-To: References: <6d4b76c9b42848f1b18c42ba22895993@usma1ex-dag1mb1.msg.corp.akamai.com> <564f297f17424f34b4ba1e118ab6f62c@usma1ex-dag1mb1.msg.corp.akamai.com> <220DB06A-E06D-4DAF-ADE6-7536B6E43630@callas.org> From: Eric Rescorla Date: Sun, 9 Jul 2017 20:56:08 -0700 Message-ID: To: Peter Goldstein Cc: denis bider , Jim Fenton , "Salz, Rich" , "dcrup@ietf.org" , Martin Thomson , Jon Callas Content-Type: multipart/alternative; boundary="001a1140932a84a5e80553ee92a2" Archived-At: Subject: Re: [Dcrup] Review of draft-ietf-dcrup-dkim-crypto-03 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, 10 Jul 2017 03:56:52 -0000 --001a1140932a84a5e80553ee92a2 Content-Type: text/plain; charset="UTF-8" I was going to respond, but I'd just be repeating myself. As I said earlier, it's probably just easier to discuss this in Prague. -Ekr On Sun, Jul 9, 2017 at 8:49 PM, Peter Goldstein wrote: > Support for larger keys isn't the issue at hand. The issue is the 255 >>> character limit imposed by the DNS crudware. And I think keys for each of >>> those curves easily fit under the limit. >>> >> > >> I'm referring to the claim that hashing doesn't provide any value. For >>> any curve > 256 bits, it does. >> >> Nope, that's the wrong limit in this case. By itself we have no interest > in whether the hashed key is smaller than the key itself. Using a hashed > key is always a loss on space (need to include the full key on each > message), time/CPU (computing the hash) and complexity - even when the > hashed key is smaller than the key itself. It's always a loss - the > question is whether the loss has any offsetting value. > > Hashing only provides value if the base64 encoded public key pushes the > record over the 255 byte limit. The point of my math was to show that the > larger key size EC algorithms work fine within this limit without hashing. > There is a limit, but it's higher than the key size for all plausible EC > algorithms likely to be introduced in the next decade. > > If we didn't have to deal with the 255 limit, we wouldn't be talking about > hashing RSA 2048. We'd just use a bigger key with the existing format and > algorithm and be done with it. We wouldn't even need a new RFC (support > for 2048 bit keys is required by RFC 6376 https://tools.ietf.org/html/ > rfc6376#section-3.3.3). > > There was zero interest in adding fingerprinting for RSA 1024 bit keys - > even though the fingerprint would be much smaller than the key. The > existing format works fine for these keys. So it's safe to say we could > handle any EC curve <= 1024 bits without fingerprinting. > > The value of the hashing is entirely in its ability to help DNS > administrators avoid this 255 byte limit. And my point is that for the > likely alternatives that would be added in the future, larger key RSA > aside, hashing adds no value. > > Best, > > Peter > > > --001a1140932a84a5e80553ee92a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was going to respond, but I'd just be repeating= myself. As I said earlier, it's probably just easier to discuss this i= n Prague.

-Ekr


On Sun, Jul 9, 2017 at 8:4= 9 PM, Peter Goldstein <peter@valimail.com> wrote:
Supp= ort for larger keys isn't the issue at hand.=C2=A0 The issue is the 255= character limit imposed by the DNS crudware.=C2=A0 And I think keys for ea= ch of those curves easily fit under the limit.
=C2=A0
<= div dir=3D"ltr">
I'm r= eferring to the claim that hashing doesn't provide any value. For any c= urve > 256 bits, it does.
Nope, that's the wrong limit in this case= .=C2=A0 By itself we have no interest in whether the hashed key is smaller = than the key itself.=C2=A0 Using a hashed key is always a loss on space (ne= ed to include the full key on each message), time/CPU (computing the hash) = and complexity - even when the hashed key is smaller than the key itself.= =C2=A0 It's always a loss - the question is whether the loss has any of= fsetting value.

Hashing only provides value if the base64 encoded public key push= es the record over the 255 byte limit.=C2=A0 The point of my math was to sh= ow that the larger key size EC algorithms work fine within this limit witho= ut hashing.=C2=A0 There is a limit, but it's higher than the key size f= or all plausible EC algorithms likely to be introduced in the next decade.<= /div>

I= f we didn't have to deal with the 255 limit, we wouldn't be talking= about hashing RSA 2048.=C2=A0 We'd just use a bigger key with the exis= ting format and algorithm and be done with it.=C2=A0 We wouldn't even n= eed a new RFC (support for 2048 bit keys is required by RFC 6376 https= ://tools.ietf.org/html/rfc6376#section-3.3.3).

There was zero interest in adding fingerprinting for RSA 1024 bit key= s - even though the fingerprint would be much smaller than the key.=C2=A0 T= he existing format works fine for these keys.=C2=A0 So it's safe to say= we could handle any EC curve <=3D 1024 bits without fingerprinting.

The value of the hashing is entirely in its ability t= o help DNS administrators avoid this 255 byte limit.=C2=A0 And my point is = that for the likely alternatives that would be added in the future, larger = key RSA aside, hashing adds no value.

Best,
<= div>
Peter



--001a1140932a84a5e80553ee92a2-- From nobody Sun Jul 9 21:50: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 8B0B81201FA for ; Sun, 9 Jul 2017 21:50: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, 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 MqKg2XE98awp for ; Sun, 9 Jul 2017 21:50:35 -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 BA5F01200F3 for ; Sun, 9 Jul 2017 21:50:35 -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 87918C4021C for ; Sun, 9 Jul 2017 23:50:34 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499662234; bh=JT/hMYgw5f23A8oycedtH0RrNvJU9WfrZ+y+yvMRtoE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=GiaF71F3UX99kluwddiJn1zAxI1N4nHSccNyylycuyKQPPWk6AFebuB5+uuMa/UXb URYfSa7tnu7VPFHaO++yQ1nkJTjxWaHpV5dKiUAuouTAw0PD2wQErCgDFSbNZHZN6k 0b4VPJhNCvJcDxymokYW/9umPnm7bAJr7GlsB0zo= From: Scott Kitterman To: "dcrup@ietf.org" Date: Mon, 10 Jul 2017 00:50:34 -0400 Message-ID: <2111048.dxWtyJcX9G@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-121-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Draft agenda for DCRUP at IETF 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, 10 Jul 2017 04:50:37 -0000 On Thursday, July 06, 2017 04:10:25 PM Salz, Rich wrote: > We have 30 minutes in the agenda, but there seems to be nothing scheduled > for the last 30 minutes. ... > Scott Kitterman, draft-ietf-dcrup-dkim-usage 5 minutes > - Changing RSA key size, moving to sha256 > - Still RSA PKCS1.5; do we need RSA-PSS? I will not be at the IETF meeting. The only question that I think needs addressing is does the group want to pursue a separate draft that ups the minimum key size and moves to sha256 or would the group prefer to have it in one larger draft. This part should be easy for the WG to dispose of. If it looks like the group will come to closure quickly on the other issues, then we don't need this draft. If not, then I think it makes sense to get this done and out of the way. My sense over the last few days is that we aren't getting anywhere close to consensus that would make it reasonable to believe the other arguments will be wrapped up in short order and we ought to go ahead with my draft, but that's just one person's view. I spend any of the meeting time on the exact content of the draft, if we conclude that the draft is needed, I don't think the content is particularly controversial. Scott K P.S. My answer to the RSA-PSS question is no. RSA-PSS is only mandated for new implementations. If we added RSA-PSS, we'd still have to support PKCS1.5 and implementers would have to implement both for it to be useful. Much better to focus implementation resources on new cryptographic algorithms. From nobody Sun Jul 9 23:50: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 ADA5E12708C for ; Sun, 9 Jul 2017 23:50:44 -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 uB5JoOCoGY6R for ; Sun, 9 Jul 2017 23:50:43 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 18C8C126CBF for ; Sun, 9 Jul 2017 23:50:43 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id r126so42230052vkg.0 for ; Sun, 09 Jul 2017 23:50: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=PTjoCZRVn0g16v+/Tsw+k1vtrSlWMs841MiIYG07CoA=; b=aobF8jpHxh/l6KFhxK/YjIO6eQeFFsKV+gN1VnKiOKSyDD+vGHCIC+Nz2ULIdCUFPw nqDSTaWZ0GfTEJD4T9+6OuJeQTebtZvVwT8+rxRy7rnytui2t9C7dtlEKP7oPvfw0ECM Fwgax1fXRDEpFSLcgj0/lMc+L1z9tyjWAc1ZtiSz7aHDyQn1Wayp5Ev2UxaCnYSBFc1k 5Z3DgqSNCF3r7dHQNdEEG367LsEx9qFc4rxAUoj8SnGI8hOxOeiLzK7lOk4GTzNV1C4t rvkF4YMVrjKntVcr+YfwL3vzf+C4Pk1ZOKfoje/kvyuhB1sa2f+Bk9mMzPQ22giq2Ccg 7xDQ== 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=PTjoCZRVn0g16v+/Tsw+k1vtrSlWMs841MiIYG07CoA=; b=sqBCWydq7TZLS3qTOcGdPyhXOEletBQ4My2LFIijwpG73mp00r10qltSMm9BOsfVKC t4oNHe6Tx9XlzOItmIxX117sCtTjGyONzfxYcNNKiez5mvOZ5sasfoTk0pKn281HiZ7o dHCbfRWy/QRN90AmXx0jqWWZjMJUgovTXHeIV/6m39hkk0LgdaQD96R5aL3ooSl3WdAA z/t8hPSXdSdumn0h9efN6ue1VAYWYQUGvVVkxXy+F0CJ+z+RWchsACT48Net6U5GQ53o jZxQ8zgbetqfiZDkcfI5IWZ5IXpESQT+dpJsqjQy70qWkBTY2ZKjx5gS3M7JEIAFX+sT qsVA== X-Gm-Message-State: AIVw112D/Uq62Sq7URTqfrmmoL4m04d2JOnIxPwsebA+Q1fLnHWfbbdi sUxES8KLbzSioIIMOcdTFlJOdaoY8/gT X-Received: by 10.31.154.150 with SMTP id c144mr3958350vke.125.1499669442083; Sun, 09 Jul 2017 23:50:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Sun, 9 Jul 2017 23:50:41 -0700 (PDT) In-Reply-To: References: <20170709203414.90415.qmail@ary.lan> <3A2ECF01-E8A0-4E11-9E3F-6A67C5198ACC@vigilsec.com> From: "Murray S. Kucherawy" Date: Sun, 9 Jul 2017 23:50:41 -0700 Message-ID: To: John R Levine Cc: Russ Housley , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1140f7106042190553f100d7" Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 10 Jul 2017 06:50:45 -0000 --001a1140f7106042190553f100d7 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 2:14 PM, John R Levine wrote: > RFC 6376 describes in great detail in section 3.7 how to create the > material to be signed. What it ends up with is a sha-256 hash, but that's > not the signing algorithm's problem. I say PureEdDSA to emphasize that it > doesn't get hashed again. > > As it stands now, the RSA and EdDSA signing algorithms sign the same > thing. I suppose I could extensively rewrite the signing instructions so > that stuff to be signed by RSA is hashed while stuff to be signed by EdDSA > is not because it'll use HashEdDSA, but that seems a lot of work and a lot > of code changes for no benefit. > +1, unless there is such benefit and someone could describe it (or point us to a reference that does so). -MSK, participatin' --001a1140f7106042190553f100d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jul 9, 2017 at 2:14 PM, John R Levine <johnl@taugh.= com> wrote:
RFC 6376 describes in great detail i= n section 3.7 how to create the material to be signed.=C2=A0 What it ends u= p with is a sha-256 hash, but that's not the signing algorithm's pr= oblem.=C2=A0 I say PureEdDSA to emphasize that it doesn't get hashed ag= ain.

As it stands now, the RSA and EdDSA signing algorithms sign the same thing.= =C2=A0 I suppose I could extensively rewrite the signing instructions so th= at stuff to be signed by RSA is hashed while stuff to be signed by EdDSA is= not because it'll use HashEdDSA, but that seems a lot of work and a lo= t of code changes for no benefit.

+1, u= nless there is such benefit and someone could describe it (or point us to a= reference that does so).

-MSK, participatin&#= 39;
--001a1140f7106042190553f100d7-- From nobody Mon Jul 10 00:38: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 136F81275AB for ; Mon, 10 Jul 2017 00:37:59 -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_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 6fL9GJQt7VdK for ; Mon, 10 Jul 2017 00:37:57 -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 B01C1126B72 for ; Mon, 10 Jul 2017 00:37:57 -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 v6A7bSwV023905; Mon, 10 Jul 2017 08:37:56 +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=g//4f+qZfABBFsVP6/KsPi1ZHacmbW3TyBdx7Gc9jDA=; b=mwj+M3rxMqBJ8MLBYaAgj8ZibQumtTxS992J3AuJ6zTfz1odOxTcyeYrzYFuSBnkb6bT DV3R8zf9au6mDQhQca0epwl//x8FRzxTd3W6bpRXEcmfS7h8CiRv6JOiksruZpSdhgeh rutBxYtk5LWD3uDnm+GVQ3dlNVhCNhoSi47mG4CZKb6HGqOwduckIWLdBGjI9kjuOCIj S6wEV3O57J/itr8FORknj8Oo9VMGbztxNpr02HwgKOdMHTKjfyHZeqIfNJ4mmCY0Cr5r qkViVGYULmsQvdNs/O6J9jHGF7CLustvmgBJR5MuMla4PSiwNRy2AGlktrIvgleidP/m zg== 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 2bjtp3evkp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 10 Jul 2017 08:37:55 +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 v6A7aIYh019244; Mon, 10 Jul 2017 03:37:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bjtqu3p66-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 10 Jul 2017 03:37:54 -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; Mon, 10 Jul 2017 03:37:53 -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, 10 Jul 2017 03:37:53 -0400 From: "Salz, Rich" To: Scott Kitterman , "dcrup@ietf.org" Thread-Topic: [Dcrup] Draft agenda for DCRUP at IETF Thread-Index: AdL2cmBUfpDyr5qUTfWga+NmtT/8OQC5zdkAAAKMhcA= Date: Mon, 10 Jul 2017 07:37:53 +0000 Message-ID: References: <2111048.dxWtyJcX9G@kitterma-e6430> In-Reply-To: <2111048.dxWtyJcX9G@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.152.101] 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-07-10_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-1707100136 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-10_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707100137 Archived-At: Subject: Re: [Dcrup] Draft agenda for DCRUP at IETF 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, 10 Jul 2017 07:37:59 -0000 > My sense over the last few days is that we aren't getting anywhere close = to > consensus that would make it reasonable to believe the other arguments wi= ll > be wrapped up in short order and we ought to go ahead with my draft, but > that's just one person's view. And on co-chair's :) From nobody Mon Jul 10 16:08: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 DB049131946 for ; Mon, 10 Jul 2017 16:08:26 -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 cVfX-d7rwKA0 for ; Mon, 10 Jul 2017 16:08:25 -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 6A72413193D for ; Mon, 10 Jul 2017 16:08:25 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id z22so64011325uah.1 for ; Mon, 10 Jul 2017 16:08:25 -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=4vEpSuU+Pre8bFPvkrbgBa8shlSJHAV5TQ19ibiuFkQ=; b=BUGnaN7/svNQ4ynnK3x0iyaQwmYq2NPGACA6Yo3CqTQLn+ZYXRSMCcatYFsEntY07O gv+asOBZ3szwzsZW3u/FeAl9TzPzJc0+v4gUe4h9g4avurLA3Bzvwzkmss2+9y7KSjS6 hWlMq3pnUny9DQKTBGOPqzbLfeq8qxjs1urF23Vt5REvzCyc2j6Pl+A8VYnEd/kDIlLM TAQ6Or1Stbs9E3rhJFOb2XgCHcI1Y2EZCTD8Q+UBdW003kVHQzXAY3vzC771xsc/Q8FA 4+Ze35aPA3lQF+g7XzZJydwlsLZqW0CQ2K4kvbBHQeh7O3r+oxnfEe/5xhGNtNQA7dbb YXPw== 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=4vEpSuU+Pre8bFPvkrbgBa8shlSJHAV5TQ19ibiuFkQ=; b=Uyl3zYeFh/sx/hKUoJgzvmAbKgf3sgW33wBu3iH40Opnt7vkVzSLNg/ilFd6UhzyAP jv1xLGOME/xrqHLZvzJpj/rc782zT7P1utTZ51k3ENjj2P3ES53o/W0di0/mcj7cM82v oGvaxTXRRwH9ptq4T37FV9OyWfDQuJrTckPCsq7Gi7GROuCqq/26Oo+c8b0koIdeD+Xy o14JxybOLm33z/wMoTNrfv6uIrYRRm65gA8/BL2cjnHN1A9juvVsBhNGhHyUpYpMjj0I v9DBkTnbTddtYpgvnPsnRb0a97FvXVSaZJISnxbNQiKBZLffRHHNwn58iPcGROeAXbjP X9ag== X-Gm-Message-State: AIVw113S0s6sBKmUsoWiVgqgFJXB5/egwNEupt2g9lQJBzCgZcAs9d0x 7TwvLkxiA99nS1Wz36TaoEtyLvwLhTyy X-Received: by 10.176.27.141 with SMTP id k13mr10415078uai.93.1499728104118; Mon, 10 Jul 2017 16:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.140.1 with HTTP; Mon, 10 Jul 2017 16:08:23 -0700 (PDT) In-Reply-To: References: <20170709203414.90415.qmail@ary.lan> <3A2ECF01-E8A0-4E11-9E3F-6A67C5198ACC@vigilsec.com> From: Brandon Long Date: Mon, 10 Jul 2017 16:08:23 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: John R Levine , dcrup@ietf.org, Russ Housley Content-Type: multipart/alternative; boundary="94eb2c13be6ee850af0553fea81a" Archived-At: Subject: Re: [Dcrup] I do not like the dcrup ECC document 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, 10 Jul 2017 23:08:27 -0000 --94eb2c13be6ee850af0553fea81a Content-Type: text/plain; charset="UTF-8" On Sun, Jul 9, 2017 at 11:50 PM, Murray S. Kucherawy wrote: > On Sun, Jul 9, 2017 at 2:14 PM, John R Levine wrote: > >> RFC 6376 describes in great detail in section 3.7 how to create the >> material to be signed. What it ends up with is a sha-256 hash, but that's >> not the signing algorithm's problem. I say PureEdDSA to emphasize that it >> doesn't get hashed again. >> >> As it stands now, the RSA and EdDSA signing algorithms sign the same >> thing. I suppose I could extensively rewrite the signing instructions so >> that stuff to be signed by RSA is hashed while stuff to be signed by EdDSA >> is not because it'll use HashEdDSA, but that seems a lot of work and a lot >> of code changes for no benefit. >> > > +1, unless there is such benefit and someone could describe it (or point > us to a reference that does so). > Is there any cryptographic reason why doing this is worse? Brandon --94eb2c13be6ee850af0553fea81a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jul 9, 2017 at 11:50 PM, Murray S. Kucherawy = <superuser@gmai= l.com> wrote:
On Sun, Jul 9, 2017 at 2:14 PM, John R Levine <johnl@ta= ugh.com> wrote:
RFC 6376= describes in great detail in section 3.7 how to create the material to be = signed.=C2=A0 What it ends up with is a sha-256 hash, but that's not th= e signing algorithm's problem.=C2=A0 I say PureEdDSA to emphasize that = it doesn't get hashed again.

As it stands now, the RSA and EdDSA signing algorithms sign the same thing.= =C2=A0 I suppose I could extensively rewrite the signing instructions so th= at stuff to be signed by RSA is hashed while stuff to be signed by EdDSA is= not because it'll use HashEdDSA, but that seems a lot of work and a lo= t of code changes for no benefit.

+1, unless there is such benefit and someone could describe it (or point = us to a reference that does so).
<= br>
Is there any cryptographic reason why doing this is worse?

Brandon=C2=A0
--94eb2c13be6ee850af0553fea81a-- From nobody Mon Jul 10 16:23: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 331E0131945 for ; Mon, 10 Jul 2017 16:23:34 -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 B6X4U76gZHpi for ; Mon, 10 Jul 2017 16:23:32 -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 8FE2C131757 for ; Mon, 10 Jul 2017 16:23:32 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w19so64601567uac.0 for ; Mon, 10 Jul 2017 16:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OkUemNH3wBWTbREz1wsYl2R30OCEKMiYOk28T4FrB5o=; b=q6G2FPTojNqadQghvgT765fc9EWjXoxGOSgmtVmYyNAS6BJZfZRXEu1vVHO6WIAZRZ qILdELkK5RBIEFb9L7QhOao3R9Nm+RHGKUNyhBhwCULrj4uF7qnuB9a0N1aNU+2Tdug7 d7p7BDL2XOK+G/9XzuGIgyvQJrBih3dyCFRyYhqEMefi9cSOw0eYxHXfwhrmoyDbvZYr Pukakgdt5kfCMfExSI1WtHQtsx8wioVPVS1gPW5WUeeudFiHEPecn+Glmi5iRsBuq1ny 7lLTpIDX2F3qwHsKjdw7RvrxJovw6Cce5XtNhuH/IlceG7JIf1G+sfT8+pfYEhcH03IN EdZQ== 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=OkUemNH3wBWTbREz1wsYl2R30OCEKMiYOk28T4FrB5o=; b=SWOuvrVI/NK0JGFDtYlvBONawhyyMiUvjFtpuKGGz3h5U+X5vCtIfI12xBiPWSxnrK UjKk42ou2h9/8JIs8tFQkS534q2AZ2c6wegL1EZReBxDdaWIzkhClFQ1ml4mw2NhVQV5 +THCuBhEmreKPpsplj7am4GmQQtPj29+ybDHPmG5PA884BsBXDeWxiXtYgpg3/Muiigg 62QRAv+4TZukBLrY628JT9nvBI2/kWkDiXsue2QBx+IXUsQS+E/iiIg3JzrQlTujP8M3 mNmNYk0qgAYXJUVjtsRokkKwVGmCM87liJZNlBHWVxvDcftO8FPpJ9VLBb+GUIjbauxp RzTw== X-Gm-Message-State: AIVw112rTZiRBMqfI1R6MJb9tJJyrIpVllj2n68qIlGSDUk2T6sRg/iF o7K2dKjx2CUkzjVsm87/ET0ClXE/Dm9Xrhk= X-Received: by 10.176.16.75 with SMTP id g11mr10327076uab.40.1499729011104; Mon, 10 Jul 2017 16:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.140.1 with HTTP; Mon, 10 Jul 2017 16:23:30 -0700 (PDT) From: Brandon Long Date: Mon, 10 Jul 2017 16:23:30 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f403045e1d20f7d3930553fedea6" Archived-At: Subject: [Dcrup] hashing and privacy 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, 10 Jul 2017 23:23:34 -0000 --f403045e1d20f7d3930553fedea6 Content-Type: text/plain; charset="UTF-8" There has been a concern that long term DKIM keys allow for some type of possibly privacy violation by allowing leaked data to be verified. I'm not sure I share this concern, but if take it as a given, then the following occurs to me for the new proposed hashing schemes. The schemes propose that the key be always included, and the hash of they key be available in DNS. On rotation, the hash will be gone... but, one would be able to verify that the key was the "right" key by looking at any other mail from the same system at the same time. Now, it's possible that people are already logging DKIM keys in DNS for long term retrieval for the next one of these leaks, in which case, that cat is already out of the bag anyways. Brandon --f403045e1d20f7d3930553fedea6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There has been a concern that long term DKIM keys allow fo= r some type of possibly privacy violation by allowing leaked data to be ver= ified.

I'm not sure I share this concern, but if tak= e it as a given, then the following occurs to me for the new proposed hashi= ng schemes.

The schemes propose that the key be always includ= ed, and the hash of they key be available in DNS.

= On rotation, the hash will be gone... but, one would be able to verify that= the key was the "right" key by looking at any other mail from th= e same system at the same time.

Now, it's poss= ible that people are already logging DKIM keys in DNS for long term retriev= al for the next one of these leaks, in which case, that cat is already out = of the bag anyways.

Brandon
--f403045e1d20f7d3930553fedea6-- From nobody Mon Jul 10 16: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 C6402131953 for ; Mon, 10 Jul 2017 16:26:56 -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 fxCJe58-aiaM for ; Mon, 10 Jul 2017 16:26:55 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 6C6A013194C for ; Mon, 10 Jul 2017 16:26:55 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id v193so42254062ywg.2 for ; Mon, 10 Jul 2017 16:26:55 -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=YdQ/S6nEsbTQ7BY4u9f0CRQxQzRv1HPnCr+folqklsU=; b=aIe1vB4qD5q5FpjuZ31EcNZc0YfEN1esZge11EKVOilyJJrC+dHghGt/KIK2TprDKz 2wbfqBaP1mO+KVBrLOGaSPMIc1O+5XkXvgLipk/g+EWxKj3dZNTo1IdNh2BBMc9ra8tN ocYVnJVMuC9WVBru8TIoBFCY6bexM90Tdf+7Tg9F6X5nrstv0zsrcAuZCgnGa1nagkOJ GjKGCJLz6Mgm7cO6DhBKmKiA5sOdpPBFJz11KHobeoKdCtiEZZgbfTSgO9KttBC25433 yVt0yGNbHz5/DGktKiCqi7SbqkBL39/FG7dhLtSZXPO7aE/3dJLkWS5l5rYPJg96EBIT zJEA== 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=YdQ/S6nEsbTQ7BY4u9f0CRQxQzRv1HPnCr+folqklsU=; b=HzQ4UiWIg6bgJulqmgSDRKDapH/oux5XaattBAqnO1NQU6cvvdbywqrgstbRc2QJpi SeMhlalxDWqoW29r6YhqR1GLs/JzM7L8pktIKiDtPYOkEnbYfNh7hEZH7fEImiULUlmG OmO5VoAJgNE3CQ+8+7AdbYEw+Pg4ohzrs3SAzsnyJrfyfft8MaubNSWPVRQr9a5D2D7V XyAw/FmQ5uPDzagSmUHshYMgYSEVObVsArx9pVnc9Z7LJk2rUi5v3GX0XZ2Jjm6YR6LR /wZFgPNXT0e+Pis87PpjQ7HZvrsOl0lP0SPBQgWaYObDcGaoygq4M+4TdnTf2/mPE5ZS ilIQ== X-Gm-Message-State: AIVw113xLXoTLUhIcMHYsY0UTQAqO4BOlVq0Oap4SbBeCiJ1k2Yyjy6I FU8FhAv4ZLlak7O1c/n1dFKGS0mAvTFk X-Received: by 10.129.156.2 with SMTP id t2mr2632317ywg.44.1499729214775; Mon, 10 Jul 2017 16:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 10 Jul 2017 16:26:14 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 10 Jul 2017 16:26:14 -0700 Message-ID: To: Brandon Long Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b78921b3f5c0553feeb5c" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 10 Jul 2017 23:26:57 -0000 --94eb2c0b78921b3f5c0553feeb5c Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 4:23 PM, Brandon Long wrote: > There has been a concern that long term DKIM keys allow for some type of > possibly privacy violation by allowing leaked data to be verified. > > I'm not sure I share this concern, but if take it as a given, then the > following occurs to me for the new proposed hashing schemes. > > The schemes propose that the key be always included, and the hash of they > key be available in DNS. > > On rotation, the hash will be gone... but, one would be able to verify > that the key was the "right" key by looking at any other mail from the same > system at the same time. > I'm not sure I follow the attack you are proposing here. Can you walk me through the exact flow? -Ekr > Now, it's possible that people are already logging DKIM keys in DNS for > long term retrieval for the next one of these leaks, in which case, that > cat is already out of the bag anyways. > > Brandon > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --94eb2c0b78921b3f5c0553feeb5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 4:23 PM, Brandon Long <blong@google.com>= wrote:
There has= been a concern that long term DKIM keys allow for some type of possibly pr= ivacy violation by allowing leaked data to be verified.

= I'm not sure I share this concern, but if take it as a given, then the = following occurs to me for the new proposed hashing schemes.

= The schemes propose that the key be always included, and the hash of they k= ey be available in DNS.

On rotation, the hash will= be gone... but, one would be able to verify that the key was the "rig= ht" key by looking at any other mail from the same system at the same = time.

I'm not sure I follow= the attack you are proposing here. Can you walk me through the exact flow?=

-Ekr


Now, it's possible that peo= ple are already logging DKIM keys in DNS for long term retrieval for the ne= xt one of these leaks, in which case, that cat is already out of the bag an= yways.

<= div>Brandon

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


--94eb2c0b78921b3f5c0553feeb5c-- From nobody Mon Jul 10 16:40: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 7E3CF131757 for ; Mon, 10 Jul 2017 16:40:45 -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 h1qmSpqIcbpQ for ; Mon, 10 Jul 2017 16:40:43 -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 B9B291200ED for ; Mon, 10 Jul 2017 16:40:43 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id l130so88611105oib.1 for ; Mon, 10 Jul 2017 16:40:43 -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=M3fh3V5p82ytAoLxX7y6Ik1REZ2v3yD9jLlpLfekaz8=; b=Tx8M8jqKgZvohI5MYxGv/4z3TQYvcF1sfVfi3EkG9GgWZ9CPa8XeimpINwD6qUod/9 OWEizm3lN6PweNYsRvROB5TmjOLdVKdbl4C89wiEygOvt8AwqefohoNV5wlrqZ2rBEJX uyyAFjxc50EvfNKzkoaH6bHfo1nVE1Qs6q5ft16MYoy5riynws6RnbMQdQ/zdIFOyvU+ 7ASohDGtMZmJkMEVhJmjmi9cojSV/FxyM2DNyK1NeNWnZ++kKVlxGsZML1zOxTyliaOV tERMhMMBRPrqSTE6Z6jcjSmxPtJ563Yp9FLFLvK/00pe/g79F5d1E2SiEx/kw0FLesit DSWg== 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=M3fh3V5p82ytAoLxX7y6Ik1REZ2v3yD9jLlpLfekaz8=; b=H0qMKlQIYT8Td+uFyhIEdtjxriSoit+sQCmwpewqtGtDCkuFOIpGZSCSuMYLBBAEkm HAA23Cz4BzjQ8XZ79zN8XfMucqTDLvIv9Lb1xspyAjxsJ4ah5BgeY2qWh+VVO+7HITQ3 dbqWZkRxEdVYfi0ykJgRHvgaHuW+xhbSVU8FaQMbIsMAzsFjUpAIWLHRiOmHWWCV24g/ 1NjLuLJ8IC8wC2Cd1Th9SI0+/s+pK+2XoeKvUuDPbzci+dfQgOsYooOUu1VAg5Z+V92p P4BTWFflhdhZGpbVDHgAxl3+bO1uAa/APYMEzjJIg2zu2uAsz04uL4rk9pfzEx7Ztdmq W8wg== X-Gm-Message-State: AIVw111DID5z0sYH/wcDP6d18MxzBGyGO+EedLxI2UdbmQTCN17mWhDD KLJ4pX1nFoq8M5g44mhUKgADFubA6YZbR4k= X-Received: by 10.202.225.132 with SMTP id y126mr11644928oig.38.1499730042752; Mon, 10 Jul 2017 16:40:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.131.17 with HTTP; Mon, 10 Jul 2017 16:40:42 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Mon, 10 Jul 2017 16:40:42 -0700 Message-ID: To: Eric Rescorla Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113d5aba75aeaa0553ff1cc5" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 10 Jul 2017 23:40:45 -0000 --001a113d5aba75aeaa0553ff1cc5 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 4:26 PM, Eric Rescorla wrote: > > > On Mon, Jul 10, 2017 at 4:23 PM, Brandon Long wrote: > >> There has been a concern that long term DKIM keys allow for some type of >> possibly privacy violation by allowing leaked data to be verified. >> >> I'm not sure I share this concern, but if take it as a given, then the >> following occurs to me for the new proposed hashing schemes. >> >> The schemes propose that the key be always included, and the hash of they >> key be available in DNS. >> >> On rotation, the hash will be gone... but, one would be able to verify >> that the key was the "right" key by looking at any other mail from the same >> system at the same time. >> > > I'm not sure I follow the attack you are proposing here. Can you walk me > through the exact flow? > Wikileaks drops a large number of raw email messages with DKIM signatures using a hashed algorithm. Each message has the key in it, which can be used to verify the individual message has not been tampered with. If the DKIM key was rotated, then the hash in DNS no longer matches the key in the messages, so all that can be proven is that they match the DKIM signature on the message. If, however, the domain had been already widely emailing with individuals, then you can look at your own message archive to find out that all of the messages in that time frame also had the same DKIM key in the message. You could even verify this with a large collection of people who also received such messages. Does that answer your question? Or are you asking about why this is a privacy attack? Brandon --001a113d5aba75aeaa0553ff1cc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 4:26 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Mon, Ju= l 10, 2017 at 4:23 PM, Brandon Long <blong@google.com> wrote:=
There has been a concer= n that long term DKIM keys allow for some type of possibly privacy violatio= n by allowing leaked data to be verified.

I'm not su= re I share this concern, but if take it as a given, then the following occu= rs to me for the new proposed hashing schemes.

The schemes pr= opose that the key be always included, and the hash of they key be availabl= e in DNS.

On rotation, the hash will be gone... bu= t, one would be able to verify that the key was the "right" key b= y looking at any other mail from the same system at the same time.

I'm not sure I follow the at= tack you are proposing here. Can you walk me through the exact flow?
<= /div>

Wikileaks drops a large n= umber of raw email messages with DKIM signatures using a hashed algorithm.= =C2=A0 Each message has the key in it, which can be used to verify the indi= vidual message has not been tampered with.=C2=A0 If the DKIM key was rotate= d, then the hash in DNS no longer matches the key in the messages, so all t= hat can be proven is that they match the DKIM signature on the message.

If, however, the domain had been already widely email= ing with individuals, then you can look at your own message archive to find= out that all of the messages in that time frame also had the same DKIM key= in the message.=C2=A0 You could even verify this with a large collection o= f people who also received such messages.

Does tha= t answer your question?=C2=A0 Or are you asking about why this is a privacy= attack?

Brandon=C2=A0
--001a113d5aba75aeaa0553ff1cc5-- From nobody Mon Jul 10 17:09: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 094B5127201 for ; Mon, 10 Jul 2017 17:09:40 -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 IHlDMzhuLnae for ; Mon, 10 Jul 2017 17:09:38 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 5FE001204DA for ; Mon, 10 Jul 2017 17:09:38 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id 84so33191915ybe.0 for ; Mon, 10 Jul 2017 17:09: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=fI458qYlZDcZHNM71BZb5dg88c7ONOoPRETC1FxFWic=; b=NA1aGq7QQ/O6iL2fyuOlbH3QQ2ogmMtyEdQLn0yK8B0lKI4+8CbEJgHFXAzIy+mv1w tJIk/KeXPl5qasV8YHIoISuWwJsTu1oZth8t8vstx7cNxUy5koKBhHSC/6P+WvoYJ6IZ 838fePNjLmMlYExese3Rqf9A94p1joz6i8zB5qyKmXihhQhAmlBREyrZXEm6sjNO/AIK HBuR/Pw2OYYRQtrYjnT3G3UeofWLTBuSjhn82qe8rMBDkdZJAOD2r/4nvCPH/h/Y364x N4/vrNA5+4pXh4EA4LUt6uAWmr3bdoP2c9mA2QEl/q70GD5cR8RJ7w3kO5EVnopNksqz OzEQ== 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=fI458qYlZDcZHNM71BZb5dg88c7ONOoPRETC1FxFWic=; b=TCskI57UneIMJ57mm7qUwVAeY/NgS3ZP6Z9MQ8/HtFK3m9wLYFyF9nDBHj+LY1KQkR xTcbFvcK2Q07UtMn1mbsu209grRQGvDYLxHhppJBYgdg2OOfIL6RhMsD/Fstj8bzEnYN NDhx5eks6AibACwO4DzClv8ZAnHbof4/kX6ozec8hj6JlO+j/bLokDIX3Oe9ElDjUga+ YljhLnsvArP8e4ROjh0aGFqCAGI/iZtr73NUQ77i8vmWngO6rvIPBppVb2BXrdLkKfp4 nc9HKYoYqDNXqBOAOX3yvwkQMQdzC4Fv9MfKJesHZrVpwxwkHT/PN24NWgNz0/7Q58hv u1aQ== X-Gm-Message-State: AIVw110PHE9aCzaL7uBIxtqAOFlhnmGLDVsZaKOExJN6ahe8JGyJB+F6 rHtWI0uBV94zEHt2GSIpQvlutDZjUQ== X-Received: by 10.37.193.135 with SMTP id r129mr5296391ybf.215.1499731777724; Mon, 10 Jul 2017 17:09:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.173.203 with HTTP; Mon, 10 Jul 2017 17:09:37 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Mon, 10 Jul 2017 18:09:37 -0600 Message-ID: To: Brandon Long Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114d7688deb3f10553ff8349" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 11 Jul 2017 00:09:40 -0000 --001a114d7688deb3f10553ff8349 Content-Type: text/plain; charset="UTF-8" I think an ability to verify the authenticity of leaked messages is a feature, not a bug. If the "leakee" is honest, it protects them more than it hurts them. It is easy to show if a "leaked" message was tampered with to try and make it more damaging. And if the "leakee" is dishonest, it benefits society more if they do not have "protection". On Mon, Jul 10, 2017 at 5:23 PM, Brandon Long wrote: > There has been a concern that long term DKIM keys allow for some type of > possibly privacy violation by allowing leaked data to be verified. > > I'm not sure I share this concern, but if take it as a given, then the > following occurs to me for the new proposed hashing schemes. > > The schemes propose that the key be always included, and the hash of they > key be available in DNS. > > On rotation, the hash will be gone... but, one would be able to verify > that the key was the "right" key by looking at any other mail from the same > system at the same time. > > Now, it's possible that people are already logging DKIM keys in DNS for > long term retrieval for the next one of these leaks, in which case, that > cat is already out of the bag anyways. > > Brandon > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a114d7688deb3f10553ff8349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think an ability to verify the authenticity of leaked me= ssages is a feature, not a bug.

If the "leakee"= ; is honest, it protects them more than it hurts them. It is easy to show i= f a "leaked" message was tampered with to try and make it more da= maging.

And if the "leakee" is dishonest= , it benefits society more if they do not have "protection".


On Mon, Jul 10, 2017 at 5:23 PM, Brandon Long <blong@google.com>= ; wrote:
There ha= s been a concern that long term DKIM keys allow for some type of possibly p= rivacy violation by allowing leaked data to be verified.

I'm not sure I share this concern, but if take it as a given, then the= following occurs to me for the new proposed hashing schemes.
The schemes propose that the key be always included, and the hash of they = key be available in DNS.

On rotation, the hash wil= l be gone... but, one would be able to verify that the key was the "ri= ght" key by looking at any other mail from the same system at the same= time.

Now, it's possible that people are alre= ady logging DKIM keys in DNS for long term retrieval for the next one of th= ese leaks, in which case, that cat is already out of the bag anyways.
=

Brandon<= /div>

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


--001a114d7688deb3f10553ff8349-- From nobody Mon Jul 10 17:17: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 5E21212EC19 for ; Mon, 10 Jul 2017 17:17:09 -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 WJWtmIBcVhiN for ; Mon, 10 Jul 2017 17:17:07 -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 8FF6312EC30 for ; Mon, 10 Jul 2017 17:17:07 -0700 (PDT) Received: from [10.95.93.81] (mobile-166-173-60-213.mycingular.net [166.173.60.213]) (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 1D47BC4005E; Mon, 10 Jul 2017 19:17:06 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1499732226; bh=d6NAW/1wtuWDYUrVscTHIaclyH2pV1Pg9vJ+MlqvhZU=; h=Date:In-Reply-To:References:Subject:To:From:From; b=DQEwIZlaKS3zweCLvaEylF3pfuRzNw0Dsz/Da/F6lQe1QtCL5zfgyw7QBTAHlKbSO h9EzH/X7ZrDBOVxEvQZnlVeuCf23pabG24hprdyL+NDRKAztEv1lLeKynUBNEN1FRI OfzbLc2x/QGNtNbDGTBDMyL0ZINjPCPJHv1ixF3s= Date: Tue, 11 Jul 2017 00:17:03 +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: Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 11 Jul 2017 00:17:09 -0000 True or not, that doesn't make it a not a privacy concern=2E Scott K On July 10, 2017 6:09:37 PM MDT, denis bider wrote: >I think an ability to verify the authenticity of leaked messages is a >feature, not a bug=2E > >If the "leakee" is honest, it protects them more than it hurts them=2E It >is >easy to show if a "leaked" message was tampered with to try and make it >more damaging=2E > >And if the "leakee" is dishonest, it benefits society more if they do >not >have "protection"=2E > > >On Mon, Jul 10, 2017 at 5:23 PM, Brandon Long wrote: > >> There has been a concern that long term DKIM keys allow for some type >of >> possibly privacy violation by allowing leaked data to be verified=2E >> >> I'm not sure I share this concern, but if take it as a given, then >the >> following occurs to me for the new proposed hashing schemes=2E >> >> The schemes propose that the key be always included, and the hash of >they >> key be available in DNS=2E >> >> On rotation, the hash will be gone=2E=2E=2E but, one would be able to >verify >> that the key was the "right" key by looking at any other mail from >the same >> system at the same time=2E >> >> Now, it's possible that people are already logging DKIM keys in DNS >for >> long term retrieval for the next one of these leaks, in which case, >that >> cat is already out of the bag anyways=2E >> >> Brandon >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dcrup >> >> From nobody Mon Jul 10 17:20: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 30E6B12EC51 for ; Mon, 10 Jul 2017 17:20:39 -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 ktDhOn8WBrSt for ; Mon, 10 Jul 2017 17:20:37 -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 6D49C12EC19 for ; Mon, 10 Jul 2017 17:20:37 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id x125so42787093ywa.0 for ; Mon, 10 Jul 2017 17:20:37 -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=23+Rtke05mONc2K2Qo4oDSR7wnnfBDwhnzaka9jwjcA=; b=SLNHEa8O6+jdOTt3RLIFT6xnyMh61iZ4+vZz11YT8n0jjBjjloydZjHNk/LCg/LTow qmWssXh6TWyH/YKjbBlKEw41mwVvPCo1sRXlRQQTgKg0V+1eThGiMNTWVG164K7U0AC4 yKNDIw8VjJ9VvWyVaYJA218PL5IHGouD0dsZF4p8sXaPZTwuqhsKTpdQcnJzI971zeIC EHY7Ptjeet/G3uV/8onapAjzZixyc/Bd6pTNVdi1NGuRcnTv7KygqqyZJqKF9xGA6TGJ zrqJBfFvIRG6AVMH1zE30NYZMZppGdC+YlCf8SUxIGSE00WmwoPttuJajPAphNXWse9F wt3A== 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=23+Rtke05mONc2K2Qo4oDSR7wnnfBDwhnzaka9jwjcA=; b=rlJ58SA2LBDrXFcN06ToKy/eJwX5LT0RWdpZWb915hcDpInkUaXvRYHjT2JN4jW2+S 13m66YhAngPQ0aoL7z/D+2M7XO5q8ZC3Sk7CAR0f2Mtlywd6bjBWSfN/aZpJ2UZtdgci vGW3BxHUA4os/wDqq7objtnO/QdStDWMBqfGvS7qcoCPy/44XQ09OCLLKBMB4Ji3rSeJ IQ+lWwrTK/Hu/HD/XotLncoV9d4aHDU2ed3ZZNnj/0lXR3PcYDwz+ULLv+8sT9lGNg49 ceOA+oy8qfea12r3LVVFdzz1/rNBy3B+6dsDnSQkYsl9htlqhPJCTeMUfXyln/8FgBRq zmaQ== X-Gm-Message-State: AIVw110zByc96pOHalvwUsKMoe1iMVuR5K0kvrUiUXlXlcg9iFlk7IoA jc4uxr9ugChx1TrAQTfmyy8fwzJ4hogV X-Received: by 10.129.156.2 with SMTP id t2mr2755146ywg.44.1499732436583; Mon, 10 Jul 2017 17:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 10 Jul 2017 17:19:56 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 10 Jul 2017 17:19:56 -0700 Message-ID: To: Brandon Long Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b78922423c70553ffab26" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 11 Jul 2017 00:20:39 -0000 --94eb2c0b78922423c70553ffab26 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 4:40 PM, Brandon Long wrote: > > > On Mon, Jul 10, 2017 at 4:26 PM, Eric Rescorla wrote: > >> >> >> On Mon, Jul 10, 2017 at 4:23 PM, Brandon Long wrote: >> >>> There has been a concern that long term DKIM keys allow for some type of >>> possibly privacy violation by allowing leaked data to be verified. >>> >>> I'm not sure I share this concern, but if take it as a given, then the >>> following occurs to me for the new proposed hashing schemes. >>> >>> The schemes propose that the key be always included, and the hash of >>> they key be available in DNS. >>> >>> On rotation, the hash will be gone... but, one would be able to verify >>> that the key was the "right" key by looking at any other mail from the same >>> system at the same time. >>> >> >> I'm not sure I follow the attack you are proposing here. Can you walk me >> through the exact flow? >> > > Wikileaks drops a large number of raw email messages with DKIM signatures > using a hashed algorithm. Each message has the key in it, which can be > used to verify the individual message has not been tampered with. If the > DKIM key was rotated, then the hash in DNS no longer matches the key in the > messages, so all that can be proven is that they match the DKIM signature > on the message. > > If, however, the domain had been already widely emailing with individuals, > then you can look at your own message archive to find out that all of the > messages in that time frame also had the same DKIM key in the message. You > could even verify this with a large collection of people who also received > such messages. > > Does that answer your question? Or are you asking about why this is a > privacy attack? > And your point is you would need to otherwise archive the key out of the DNS to verify that two messages were sent by the same person? In that case, I would want to be sure that that's actually a property that digital signatures have. -Ekr --94eb2c0b78922423c70553ffab26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 4:40 PM, Brandon Long <blong@google.com>= wrote:


On Mo= n, Jul 10, 2017 at 4:26 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Jul 10, 2017 at 4:23 PM,= Brandon Long <blong@google.com> wrote:
There has been a concern that long term DKIM= keys allow for some type of possibly privacy violation by allowing leaked = data to be verified.

I'm not sure I share this conce= rn, but if take it as a given, then the following occurs to me for the new = proposed hashing schemes.

The schemes propose that the key be= always included, and the hash of they key be available in DNS.
<= br>
On rotation, the hash will be gone... but, one would be able = to verify that the key was the "right" key by looking at any othe= r mail from the same system at the same time.
=
I'm not sure I follow the attack you are proposin= g here. Can you walk me through the exact flow?

Wikileaks drops a large number of raw e= mail messages with DKIM signatures using a hashed algorithm.=C2=A0 Each mes= sage has the key in it, which can be used to verify the individual message = has not been tampered with.=C2=A0 If the DKIM key was rotated, then the has= h in DNS no longer matches the key in the messages, so all that can be prov= en is that they match the DKIM signature on the message.

If, however, the domain had been already widely emailing with indivi= duals, then you can look at your own message archive to find out that all o= f the messages in that time frame also had the same DKIM key in the message= .=C2=A0 You could even verify this with a large collection of people who al= so received such messages.

Does that answer your q= uestion?=C2=A0 Or are you asking about why this is a privacy attack?
<= /div>

And your point is you wou= ld need to otherwise archive the key out of the DNS to verify that two mess= ages were sent by the same person?

In that case, I= would want to be sure that that's actually a property that digital sig= natures have.=C2=A0

-Ekr

<= /div>
--94eb2c0b78922423c70553ffab26-- From nobody Mon Jul 10 18:31: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 AB2BB1200C1 for ; Mon, 10 Jul 2017 18:31:37 -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 PgrmxMJxW7qz for ; Mon, 10 Jul 2017 18:31:36 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 4D744120454 for ; Mon, 10 Jul 2017 18:31:36 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id v202so50157523itb.0 for ; Mon, 10 Jul 2017 18:31: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=1gwRfDM99z2JyxzzyvEuMLtr83a5JVZ0A581ISNajPk=; b=rsucoEi9LcQGDBiwYL4BVyEvSNdxI3x0iIPlQtsIPQmSR9LmMyaVWTmDfOLphweWBh 5FSxo7TZg/3sKgctg+A4jKMWUth5oBTSIwkI/y6n2FJmZtezmAEv5qh3hU3SmkKZdj4D TmDMbu7Bn2mQ+M355HVmkKh0Vo59gay7S+hvg/PU6mOczp4QJD/zBjs+h1Bx8AfOueE8 osV/cLsxtnCk/S0Mt2+WzgWV953s6bWzEFAuyCwBbcwcsiPpPTG/zrzH7atuxfrJv/IB z9CEMn0LHlp38CjZzC0rW1TFvLFzXRNFrYn3Jj7GESh2orEVIzkLut5wSr1CyN+NQbRz tmUA== 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=1gwRfDM99z2JyxzzyvEuMLtr83a5JVZ0A581ISNajPk=; b=cni9beEABQlDzgc/odJB1h0A82e4yLdNhzZWLtnDvflZgsGJSrFFKSWK4EjGyh5AYf 8hW0j9outBBAyWzLJ8U4LMqjO3YZP2NcLmRzhOEIElXjXwYvi00v9IFx0F2uTBNdrTYC D/nNK4BUlOL9U5MKtjZQzezus+PiZZGHgkXPg2aA1hd454i6l0VQuOuEduJqXkf8poVh XNf75G7ITE0/0Pc7ZWXUDba9PUvqbrFc93u4Lvsp66n8hkX9YDPQweEdmXTolI+DV7vU 6RAOrMw0WPULNDdiZ1Rfx+2u8RriNdhduAIZgzDfX7ED9aT0BeNLpzGg5nWm4ZVIJMja aEXw== X-Gm-Message-State: AIVw111eGiBANuoSPTVyz3meDp553CDNxG9mcpDUbXXNEzkRZyKpylIA MtEVqIPpfSLqN6niZsknRQUG8f6PUEgn X-Received: by 10.107.12.18 with SMTP id w18mr5884198ioi.201.1499736695697; Mon, 10 Jul 2017 18:31:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Mon, 10 Jul 2017 18:31:35 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 11 Jul 2017 11:31:35 +1000 Message-ID: To: Eric Rescorla Cc: Brandon Long , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 11 Jul 2017 01:31:38 -0000 On 11 July 2017 at 10:19, Eric Rescorla wrote: > In that case, I would want to be sure that that's actually a property that > digital signatures have. My understanding is that (for RSA at least) given a message and signature it is possible to create a key that will produce the same signature. See the attacks on ACME. The absence of key might lead to some uncertainty about whether the message was originally signed by X, or someone else. Including the key removes that ambiguity, because it is included under the signature. From nobody Tue Jul 11 05:55: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 8D70D1316D7 for ; Tue, 11 Jul 2017 05:55:31 -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 6YPjeaqOF-DR for ; Tue, 11 Jul 2017 05:55:30 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 31387127010 for ; Tue, 11 Jul 2017 05:55:30 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id a12so48327415ywh.3 for ; Tue, 11 Jul 2017 05:55:30 -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=fdqVXxeiuOtZf6U4z71QJwdgIlrloCVb0c5DMPkaiSw=; b=kzd54PcYoKUvTKBVR2yyEgrYER08k/qSvHkRq7Dsn4tWdRHBnyhb9kCtc5OPoAOO0I SX/+vZhU8r9XZ+9Y9//p+rRZnFWyB93vQxzRMlk8PIzWfCIuq3DIZnmAC5zX8SpPaL7b WqcqIoO/uhnRPac0q615hcgZCgf0fFKXiRGNR+eg6Xb3n+Wtm6TkuQvMeT88a991N1bY 5NH6vFb2ZZLMWb49Qb1OTqbAf/JbX41A4xIesOcNeFhjxfL3geUEPqLv+tCe1x6PnwNa SO8/PKyIeqKhnvMvGKlhDRHu74wkiYK5NzvLRIT4Y46Nhpkr29u65eKL19tIdrrA/pZ5 2gxg== 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=fdqVXxeiuOtZf6U4z71QJwdgIlrloCVb0c5DMPkaiSw=; b=TrRVmo/6rJm9+yXMeetrQ5f3hK4Ac9dICG++fhWc7WpcAxBl6Scd7yhhLdGngXj/yb dlXFJTIOYcSql9ZsIHgesg3WRd7ssKiZSvT4cdqH2aMJfJYsOHQZOHOqz/kjql5smjm3 PuMqu2b35hYHyl0RU+WvVwlaNXnbgkrl/Rsa+ODl1z4aX6in2UoYjepSPVLKGU6RDtn3 uDVHM7CPsVlzZj8j6KY76YwIpxkZG3Gve82uvO7BBurYx2lJEVPFCvGZqYPyupJLTT8x 7MfQFM/uRunVlb8M8Wuvdf/JgUzHHG1U0RFeqqD5pbS1ro42u06Hw/K1n5kaAk91VZ// JLkw== X-Gm-Message-State: AIVw1119nStHDyz/McjPIs66b2zAYretkYGUivVVjcy5NtE0nNOyAynr feVkRy+/O8oKKmDWABUoC80HpI7wlq+t X-Received: by 10.129.156.2 with SMTP id t2mr4451821ywg.44.1499777729471; Tue, 11 Jul 2017 05:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 11 Jul 2017 05:54:48 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 11 Jul 2017 05:54:48 -0700 Message-ID: To: Martin Thomson Cc: Brandon Long , dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0b7892cee68005540a363f" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 11 Jul 2017 12:55:31 -0000 --94eb2c0b7892cee68005540a363f Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 6:31 PM, Martin Thomson wrote: > On 11 July 2017 at 10:19, Eric Rescorla wrote: > > In that case, I would want to be sure that that's actually a property > that > > digital signatures have. > > My understanding is that (for RSA at least) given a message and > signature it is possible to create a key that will produce the same > signature. See the attacks on ACME. The absence of key might lead to > some uncertainty about whether the message was originally signed by X, > or someone else. Including the key removes that ambiguity, because it > is included under the signature. > I wonder if that property holds for >1 signatures. -Ekr --94eb2c0b7892cee68005540a363f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 10, 2017 at 6:31 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 11 July 2017 at 10:19, Eric Rescorla <ekr@rtfm.com> wrote:
> In that case, I would want to be sure that that's actually a prope= rty that
> digital signatures have.

My understanding is that (for RSA at least) given a message and
signature it is possible to create a key that will produce the same
signature.=C2=A0 See the attacks on ACME.=C2=A0 The absence of key might le= ad to
some uncertainty about whether the message was originally signed by X,
or someone else.=C2=A0 Including the key removes that ambiguity, because it=
is included under the signature.

I wond= er if that property holds for >1 signatures.

-E= kr


--94eb2c0b7892cee68005540a363f-- From nobody Tue Jul 11 09: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 CF3E51201F2 for ; Tue, 11 Jul 2017 09:51:27 -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 O3HukMH6K0_T for ; Tue, 11 Jul 2017 09:51:26 -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 91E7C131763 for ; Tue, 11 Jul 2017 09:51:26 -0700 (PDT) Received: (qmail 21838 invoked from network); 11 Jul 2017 16:51:25 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jul 2017 16:51:25 -0000 Date: 11 Jul 2017 16:51:03 -0000 Message-ID: <20170711165103.98321.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: blong@google.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] hashing and privacy 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, 11 Jul 2017 16:51:28 -0000 In article you write: >Now, it's possible that people are already logging DKIM keys in DNS for >long term retrieval for the next one of these leaks, in which case, that >cat is already out of the bag anyways. Given the existence of long term passive DNS, I am quite certain that people are logging DKIM keys in the DNS for long term retrieval, with or without wikileaks, so I don't think hashing makes things any worse. Two other observations: One is that in practice hardly anyone ever rotates DKIM keys, so this is currently a largely hypothetical issue. When Wikileaks released the gmail messages from DNC staff, it was easy to verify the DKIM signatures because gmail was still using the same DKIM key a year later. The other, due I think to Stephen Farrell, is that if you want to invalidate a key, you can poison it by publishing the public key. Since the point of that is to prevent interoperation it's not something that would go in a standards track document, but I suppose we could informally suggest that when you revoke a key by blanking out the p= public key tag you add a pk= tag with the public key. R's, John PS: I know the public key will not fit in 256 octets, but tough. From nobody Tue Jul 11 19:38: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 2C51F12EB4A for ; Tue, 11 Jul 2017 19:38:07 -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, 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 eAKpnVkeWMAv for ; Tue, 11 Jul 2017 19:38:05 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 B073112762F for ; Tue, 11 Jul 2017 19:38:05 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id m68so5194900ith.1 for ; Tue, 11 Jul 2017 19:38: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=/mS0sqjDu8SsuwjIOGpNUtoI3MTyThRj7JPHuFmHR5M=; b=me77zTaufGMUB4epmwbRYkW3kufleL6dqI5+luap0+Vnvs9eWoG/wOSDDkyPKNjXQJ ecTkZvBeS1o71j273hMcL762gBPZdmA/6CbzKHEcqDhPVsBgB0Ol0Pwz2Y6FW7S6QVi7 A+BZLseMsGIkqruPkoFGZdhh/LYUGCFn/aJOHSDz7tLYIe0vpyKC8NTMFl8h5ZKanraY ju36L8kcfmk41gNt8tivaIUk2xTgjJasylOYRFYp3EVqGzl7eosB4anV+LzUFkhVAxXj iqCHJiZ74Lvf3E4OZq3qmZ+7nYBEe21UVjDX4Rw6HpR7k8fw8m4LGlEJJS7W2szG6Xt0 YXkQ== 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=/mS0sqjDu8SsuwjIOGpNUtoI3MTyThRj7JPHuFmHR5M=; b=NuhJVul2VGq+6LZyXi0waMH74sn0mCqT+YWQyjNzfmA7U+uYZDnBuH+lGhbRigmxl0 f9c4pKJWfavbF1SgFIPYQemrZxwv289e8EAF1Jv0RvpJfDJdWnzSnlvtHv+B6/cWh0Ty 6ucIgseFeWSB/SvsBjiBWzkpcODD1fsAVYtHzxrC55gACJCw2QFKkcyiblE7B5U4WSRS a1Ye0PzdWmpEEIHeXtDmh/0urX/5hWHFz+fCZ0jyzHmtv1Zm2l4BELWveAKEjLFIJ8C+ fIwm+iCQlQTI6JnCbpWqzTf63PtLoZ88SzANKXo3frDjSFX7gOsH3f3PKetN8aJHjrq4 Khgg== X-Gm-Message-State: AIVw110EYFG/UgZjIMRY2wZ/mmTIvJgQzBEYes7LPGcKyc3+dSbOvdcG mX4k8JA+2veutLlvFDT/ndvjzAeVaQ== X-Received: by 10.36.110.23 with SMTP id w23mr20762924itc.24.1499827085078; Tue, 11 Jul 2017 19:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Tue, 11 Jul 2017 19:38:04 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 12 Jul 2017 12:38:04 +1000 Message-ID: To: Eric Rescorla Cc: Brandon Long , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 12 Jul 2017 02:38:07 -0000 On 11 July 2017 at 22:54, Eric Rescorla wrote: >> My understanding is that (for RSA at least) given a message and >> signature it is possible to create a key that will produce the same >> signature. See the attacks on ACME. The absence of key might lead to >> some uncertainty about whether the message was originally signed by X, >> or someone else. Including the key removes that ambiguity, because it >> is included under the signature. > > > I wonder if that property holds for >1 signatures. I don't know. My intuition is that it is hard, but I can't really back that up. Whether that matters depends on what you are trying to defend. If I give you a collection of messages with the claim that they are all from the same sender, it would be hard for an attacker to include a message that was signed by another entity even if the key wasn't signed. On the other hand, anyone can claim that they signed any one of those messages unless the key was covered. From nobody Tue Jul 11 19:39: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 4464412EC02 for ; Tue, 11 Jul 2017 19:39:51 -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 RNyN3hou1IHs for ; Tue, 11 Jul 2017 19:39:50 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 1807012762F for ; Tue, 11 Jul 2017 19:39:50 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id k192so5829099ith.1 for ; Tue, 11 Jul 2017 19:39: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=1kfABMc/sYiO6jwv24qHhByxo/6VfpRTlkDwgQ1zoaI=; b=LosKoTP6q5ZWnkt9H+gnl4n6L95V0zUropOvr6gTF0Wb0kjwmSvL7bOjU76N1Jck7J GFCCnEpkL3ZCF6/96hR9jRK6AL4q8j2UIMG/tQmx5111/5FkN0xRsyrhaHRTQBpkO6q2 IZCRL3quGdUV/f0vxWRQg9SVySSSnbl1pWQGZpxuHJF26ZUhTa3ApV9mr44/C0KZUQtA eKxjIbvD81H3rfJZCV1qnB9uXRCo9J54/0zz5+6sMxmBrAbFxefgi4+p+VCEeGw48yMR 4wHSdnQ4ngreU+Uiu/CJiZ5r4VfHMGsy1cMJaW0CM5UO5fHcFrePoiD3nt63UAyNtM5e kCKQ== 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=1kfABMc/sYiO6jwv24qHhByxo/6VfpRTlkDwgQ1zoaI=; b=GHmlNPNbk6GaNMyFc9FhGZvQ1CBi3rh5d6wKs2QEZZ0Aq1/OSdrf8jyexqhiN8uLyC Q8Qd2YThOsfieiQ0wkGypPPLmteHY+pXUEUho4VQT9MH/M6pynzqsUm1obNGd/Ivgnhk Fxlm5Wa+XbhaCgZtQVENqL3O5S48NAJm2ADf4jD89LPVwr4xKW9RXDWCbd5yNRkUPAbI kImHsrWEyIrCJDKV/ichHRiOuDFpJg6WDqcOGGJdPrg3j43W7+H+DEtsJCcMhbei9foY D+HivFiZFCxpfulqlerJpUW7iiSXg5LJ2dUts0fx89nyXZf1Q1/wpCD2BkP6lANvpKkq b6Gg== X-Gm-Message-State: AIVw110ns/9brh7kT6OthQPJTckVv7WKTNSSM9cms3KMAEw0033RApno FUulKeuay9JiDIVlk6IavP7c+2ieSA== X-Received: by 10.36.175.73 with SMTP id l9mr6911044iti.102.1499827189485; Tue, 11 Jul 2017 19:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Tue, 11 Jul 2017 19:39:48 -0700 (PDT) In-Reply-To: <20170711165103.98321.qmail@ary.lan> References: <20170711165103.98321.qmail@ary.lan> From: Martin Thomson Date: Wed, 12 Jul 2017 12:39:48 +1000 Message-ID: To: John Levine Cc: dcrup@ietf.org, Brandon Long Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 12 Jul 2017 02:39:51 -0000 On 12 July 2017 at 02:51, John Levine wrote: > The other, due I think to Stephen Farrell, is that if you want to > invalidate a key, you can poison it by publishing the public key. > Since the point of that is to prevent interoperation it's not > something that would go in a standards track document, but I suppose > we could informally suggest that when you revoke a key by blanking > out the p= public key tag you add a pk= tag with the public key. I assume that pk= private key? > PS: I know the public key will not fit in 256 octets, but tough. Private key here as well? From nobody Wed Jul 12 09:22:59 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 8221D1250B8; Wed, 12 Jul 2017 09:22:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: dcrup-chairs@ietf.org, dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> Date: Wed, 12 Jul 2017 09:22:52 -0700 Archived-At: Subject: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 12 Jul 2017 16:22:53 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-dcrup-01-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-dcrup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm fine with doing this, without external review. I'm a Yes for this one, but Alexey needs to be a Yes before it's approved, of course. But definitely the right thing to do. I did see 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 I may be unaware of a well-known term of art, but I'm guessing "context transport security" is missing "of" (so, "context of transport security")? less severe. Still, the community wishes to discourage its continued use in the DKIM context. From nobody Wed Jul 12 17:13: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 E68F912EC48; Wed, 12 Jul 2017 17:13: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 kWGL71I6T396; Wed, 12 Jul 2017 17:13:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 EAE8B12EC49; Wed, 12 Jul 2017 17:13:40 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id m84so28562257ita.0; Wed, 12 Jul 2017 17:13: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=ZunFEHtPn1PviIlSSqxugrm8SOi3NK5uZ8h8GCsgRW0=; b=b6JHhmjqL+yYhc/7LkJn7KFzjgE7Wfa4VZRn9GKLy+I/U1fGUJXT6xrVE4IyRpiyWF 0bkY8xP0wLy/RqrO2eKpJCjSPB85Ji27WwbOM+YMzmZ44cEcxCbuoqEmo3DN/qtbEikm gTorv5ePHG1GiMT1FOWJhT07DXFFsq5Ksx2niDwzcpiGL0Xs2ugJ3xX0yGkRj/CZ43JF SDwa37eVvAb1bx7POBAybxuXBf+cKdCbraMYKO9ffQU9FZGtBDEFh4NWUwkqfjU/ZUs8 mGMMlSQ7cVCaLW2snUnZeL8aQWyGFQ/DJOek9qxfRwJNWmluEl1JxDBaENXKE+fd/VS9 Dmgg== 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=ZunFEHtPn1PviIlSSqxugrm8SOi3NK5uZ8h8GCsgRW0=; b=aIngOP8ABs5cTOcSzklEEzuSbhyQk8ZZhrvUAxgPbJOWSg98H0nSpSnPuxpFsyXmPg KtQT0BWMUzgrU3KRN7tBOf3R5E/t82TUjWODfFT5gqxX/hcZdCmuP76bbxgg20+IlzVE q6a1xh/wMaIHwgodgRBn+Z4yPPe3P8PB5jm4rFcumMbaPcarY92dGAs06m/uWs67WK7n txV+GYw+qMHvmTYJ6rsGZaHxs5hRlJxhMKM1PlpkJFW5A26nFZ+zbxonYlFEXRCVZC0C Ut9K9fZd1eeQvL9gPpYrhqwEeA/x+LRToG+Mo34ug6G/0KaDIGRzqQhomGNV4Hb+iz+j Ncqw== X-Gm-Message-State: AIVw113aIBx7DqGKUgFNE0XNs6+x6nolUgadaQ71otB1DN7WLOOaPiuQ R3qJgxOk7oAZzLGRRT+Z3KGkk48SQFYgx3I= X-Received: by 10.107.39.205 with SMTP id n196mr1118820ion.37.1499904820332; Wed, 12 Jul 2017 17:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Wed, 12 Jul 2017 17:13:39 -0700 (PDT) In-Reply-To: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 13 Jul 2017 10:13:39 +1000 Message-ID: To: Spencer Dawkins , dcrup@ietf.org Cc: dcrup-chairs@ietf.org, The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 13 Jul 2017 00:13:43 -0000 On 13 July 2017 at 02:22, Spencer Dawkins wrote: > [...] Spencer was lucky enough to highlight some text that is incorrect, possibly in multiple ways. > 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. The use of SHA-1 for transport security (here I believe this means TLS), is for three things. The first of these is in the context of record protection, which is HMAC SHA-1. The second is the PRF, which also uses HMAC. To the best of my knowledge, use of SHA-1 with HMAC isn't completely and utterly busted. Not to say that I would trust it, of course. The other use of SHA-1 is with signatures. In that context, it is very much busted. And the use of SHA-1 in signatures in TLS is quite similar to the use of SHA-1 in DKIM. Also, the attack on SHA-1 is a collision attack. My understanding is that first and second preimage attacks are still a ways from being practical. (Hence HMAC remaining vaguely usable.) The text specifically uses the word "preimage", which is wrong. Well, unless there is an unwritten assertion that preimage attacks are necessary to attack DKIM, which would need better substantiation. Finally, it's not clear what context the text refers to when it talks about the risk being less severe. However, I think that the weak point in both cases is roughly the same. That TLS has a use of SHA-1 that isn't as busted doesn't make it any less a problem. Drop the tail of the sentence. That is, everything after the comma. My suggestion: > SHA1 has been formally deprecated due to weakness in numerous contexts. From nobody Sun Jul 16 03:28: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 7CB5D12EBF9; Sun, 16 Jul 2017 03:28:42 -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 kK7lfQJATpRn; Sun, 16 Jul 2017 03:28:41 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 4C9AB126B6E; Sun, 16 Jul 2017 03:28:41 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id v202so38244222itb.0; Sun, 16 Jul 2017 03:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=sgZZ1ewuEIfpvbmrwlW/het3gskfd4J/Bjm1gd2Mn14=; b=u5ov6mavMQgGlqtykLOPjOeC77wmLr/z9rYPO43dGvKGM2rSJ3JYzkRmTdncHM87Un vR7AuRR5qZgCfw+1Mxb0ow5mCAJpxOSgcID8Mz2+s+P6Pn7przB0cGhuiFmXUZcu3Cor zQjvwMior1/5MWJMrCmNq8ZfML7UrodCsrl9SUvfd47MJnxypLCljgswo6fo98ibSkEg s1kOL8Wtug20J8Nn3MTKQ/xrNLWAYGrdxI9RfABDNmvCaZy2VBl1q72F5OKsVkW+kX32 zNFxn1jjavsY7/uroCRKYZMDDRK0tDwQTPPP36LF+nel4syo1jnQffKWyWtLOwqXDAFY oluw== 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:from:date:message-id:subject :to; bh=sgZZ1ewuEIfpvbmrwlW/het3gskfd4J/Bjm1gd2Mn14=; b=RiHBZGWM25HSkiescGn9enMxwCXt/ghy3Fd5/xxrBnnngUCDeEoG6pnkSPsrf33R4X i0YLFOg0Ifk7h9tM26dIuXvHm/zlQjbqdQWxDSMtWkNodj5TKN+4rs0FTfk696KvkonZ zqRE0sv3KgplazM721qqVGwo1pYNuaIQi6gndlXUyyNH6ErRxCpNiQhGVghKyVFxTKtI iROdpzIcWceWlvvVdR1CjtMiJHE0ADw2IEV0iTPxMtWMSMJMT+bKm9erY9l+VI+AHas0 7iqzCKOVAEcHFcdlObFZ+6aD69Nvb8YhjR4CEtW4odPw6fOj94RV1i1kXA7A9D4lbvrA iB1Q== X-Gm-Message-State: AIVw113kgmZdmYcAwMy8jFgwp0yrMhjnBRq2HvWUpYLT+WCJ6WmVkwYV 7LnijsjhDTxu45ZL9FK2o6DslTjofIs6 X-Received: by 10.36.40.196 with SMTP id h187mr1098451ith.43.1500200920406; Sun, 16 Jul 2017 03:28:40 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.152.80 with HTTP; Sun, 16 Jul 2017 03:28:39 -0700 (PDT) From: Barry Leiba Date: Sun, 16 Jul 2017 12:28:39 +0200 X-Google-Sender-Auth: lmzgE1BUPZtb0Yu8xY797Qdyukg Message-ID: To: "dmarc@ietf.org" , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dcrup] Reducing the gap between the DMARC and DCRUP sessions on Thursday at IETF 99 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, 16 Jul 2017 10:28:42 -0000 The DMARC and DCRUP working groups share the morning session on Thursday, with DKIM scheduled from 9:30 to 10:30, and DCRUP scheduled to start at 11:00. To avoid having people hanging out for half an hour, we have reduced the time between the sessions to 10 minutes. The DCRUP session will now start at 10:40 and end at 11:10. The 10 minutes will allow time for chair changes and setup, and for Meetecho to end the DMARC recording and begin DCRUP. So, again, the change: The DCRUP session in the Berlin/Brussels room on Thursday is moved 20 minutes earlier, now 10:40 to 11:10. -- Barry From nobody Tue Jul 18 07:30: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 E45E6127136; Tue, 18 Jul 2017 07:30: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 WR8xRqsqLUsC; Tue, 18 Jul 2017 07:30:29 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 59B5D13167B; Tue, 18 Jul 2017 07:30:29 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 35so25407069uax.3; Tue, 18 Jul 2017 07:30:29 -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=V8xIkCSQYecAq9aFjRKkGE7jAy3JMLBzTm+/usH7bhw=; b=pfyqHtRuApg3BwXeOCuVoxKVSpkVK8z0PVyJXCCOXN0Tg3UzG0fnrkf/yCDwGi8uQz go9DhDOsOIVUzToWvRh44U17FZFCY3+kbe/ywQ/xK1M8FzBHmcFCSxK0WTT52wv6XCxk beOAvR/OepkDp7akRhp9XzxI1H3mbFeuuCyzvuVoo/Sh+TP81aHkHLH+ez7VRVYIOf9G /KOHDax1CHkfEA3LbcZt+vAwbep0XP/YDHnrLxhjfJ4++bfHOt7yTALPCzi4oFkrNBr9 nsJmv0fyoKLZyKz6Ru12KRzmmGauLhVW5utM3B7sxK06atiiSv3MynsCZDZtsohJ9AjC EixA== 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=V8xIkCSQYecAq9aFjRKkGE7jAy3JMLBzTm+/usH7bhw=; b=TkgGF1YBTrhg/lyqI+y+fIH3u/aX/TINE1Tw0deZvK+ggk+W7zQ6J5RK7Oe6N4HtOB faWqlvhwtnz4CZVbTUcn+3G11qsDSuQrxh8itXwTcb4+wqEQJHxwD+SyaKsJ92BqzZ30 tE4O5c1ubTEtvPUUi5tEmYMbw2akW4EnqbU4bormwuTu9hUum3z0xgD1HxsPJjlHrkb3 1nwy05klogdN+EAHOv4zRXt3x6r22mI+8ALGOJQ+vwSaD4CRCgrF8+b1IQHSA0mEBIhv 8YLO8NVyxGYWbVW/Yo/0IcVJR5uSg8wtIT4bfp0XQ/5fdDc9OrVLqemAnKldFWWJN6Fr 0e9Q== X-Gm-Message-State: AIVw111XBCX7fEq54QWN+sTUMJpruaKEnCjIUjweMe9IJBna7bjiy3dj u7WzOwlFMAkVlEMMV12lWY2WTGEzmw== X-Received: by 10.176.76.96 with SMTP id d32mr992356uag.4.1500388228473; Tue, 18 Jul 2017 07:30:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 18 Jul 2017 07:30:27 -0700 (PDT) In-Reply-To: References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Tue, 18 Jul 2017 16:30:27 +0200 Message-ID: To: Martin Thomson Cc: Spencer Dawkins , dcrup@ietf.org, dcrup-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="f403043615366228e20554985b93" Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 18 Jul 2017 14:30:31 -0000 --f403043615366228e20554985b93 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 13, 2017 at 2:13 AM, Martin Thomson wrote: > On 13 July 2017 at 02:22, Spencer Dawkins > wrote: > > [...] > > Spencer was lucky enough to highlight some text that is incorrect, > possibly in multiple ways. > > > 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. > > The use of SHA-1 for transport security (here I believe this means > TLS), is for three things. The first of these is in the context of > record protection, which is HMAC SHA-1. The second is the PRF, which > also uses HMAC. To the best of my knowledge, use of SHA-1 with HMAC > isn't completely and utterly busted. Not to say that I would trust > it, of course. > > The other use of SHA-1 is with signatures. In that context, it is > very much busted. And the use of SHA-1 in signatures in TLS is quite > similar to the use of SHA-1 in DKIM. > I provided the cited text, and I recall it was based on something I think Eric said along the lines of "there are no known preimage attacks against SHA1 (yet)." It's totally possible I misunderstood him, not being a security expert. Also, the attack on SHA-1 is a collision attack. My understanding is > that first and second preimage attacks are still a ways from being > practical. (Hence HMAC remaining vaguely usable.) The text > specifically uses the word "preimage", which is wrong. Well, unless > there is an unwritten assertion that preimage attacks are necessary to > attack DKIM, which would need better substantiation. > Given DKIM signatures are just classic encrypt-the-digest kind of thing, and the keys and most other properties can be controlled or are constant, I assumed that the only possible attack is a preimage attack on the digest function. And if there are no known preimage attacks on SHA1 (yet), then I took Eric's remark to mean there's not much to worry about here; of course, the WG is free to decide to deprecate SHA1 out of an abundance of caution anyway, which is what I was trying to convey in that language. > Finally, it's not clear what context the text refers to when it talks > about the risk being less severe. However, I think that the weak > point in both cases is roughly the same. That TLS has a use of SHA-1 > that isn't as busted doesn't make it any less a problem. > > Drop the tail of the sentence. That is, everything after the comma. > My suggestion: > > > SHA1 has been formally deprecated due to weakness in numerous contexts. > That's fine with me, I guess, conceding apparent ignorance of the deeper details. -MSK --f403043615366228e20554985b93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jul 13, 2017 at 2:13 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 13 July 2017= at 02:22, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
> [...]

Spencer was lucky enough to highlight some text that is incorrect,
possibly in multiple ways.

> SHA1 has been formally deprecated due to weakness especially when used= in the context transport security, though the risk of a successful preimag= e attack is less severe.

The use of SHA-1 for transport security (here I believe this means
TLS), is for three things.=C2=A0 The first of these is in the context of record protection, which is HMAC SHA-1.=C2=A0 The second is the PRF, which<= br> also uses HMAC.=C2=A0 To the best of my knowledge, use of SHA-1 with HMAC isn't completely and utterly busted.=C2=A0 Not to say that I would trus= t
it, of course.

The other use of SHA-1 is with signatures.=C2=A0 In that context, it is
very much busted. And the use of SHA-1 in signatures in TLS is quite
similar to the use of SHA-1 in DKIM.

I = provided the cited text, and I recall it was based on something I think Eri= c said along the lines of "there are no known preimage attacks against= SHA1 (yet)."=C2=A0 It's totally possible I misunderstood him, not= being a security expert.

Also, the attack on SHA-1 is a collision attack.=C2=A0 My understanding is<= br> that first and second preimage attacks are still a ways from being
practical.=C2=A0 (Hence HMAC remaining vaguely usable.)=C2=A0 The text
specifically uses the word "preimage", which is wrong.=C2=A0 Well= , unless
there is an unwritten assertion that preimage attacks are necessary to
attack DKIM, which would need better substantiation.
<= br>
Given DKIM signatures are just classic encrypt-the-digest kin= d of thing, and the keys and most other properties can be controlled or are= constant, I assumed that the only possible attack is a preimage attack on = the digest function.=C2=A0 And if there are no known preimage attacks on SH= A1 (yet), then I took Eric's remark to mean there's not much to wor= ry about here; of course, the WG is free to decide to deprecate SHA1 out of= an abundance of caution anyway, which is what I was trying to convey in th= at language.
=C2=A0
Finally, it's not clear what context the text refers to when it talks about the risk being less severe.=C2=A0 However, I think that the weak
point in both cases is roughly the same.=C2=A0 That TLS has a use of SHA-1<= br> that isn't as busted doesn't make it any less a problem.

Drop the tail of the sentence.=C2=A0 That is, everything after the comma. My suggestion:

> SHA1 has been formally deprecated due to weakness in numerous contexts= .

That's fine wit= h me, I guess, conceding apparent ignorance of the deeper details.

<= /div>
-MSK
--f403043615366228e20554985b93-- From nobody Tue Jul 18 07:45: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 96AD2131545; Tue, 18 Jul 2017 07:45:01 -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 7w9UOKU9lh9b; Tue, 18 Jul 2017 07:45:00 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 3F13E127601; Tue, 18 Jul 2017 07:45:00 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id a62so21558115itd.1; Tue, 18 Jul 2017 07:45: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=iLlvaUV8xKtDc6BTniAemRj7OTvymEauhGcGGXXgkCQ=; b=ZUOZeY8aEIchAePIjrNGZ8D0u5d4RBkIKmiiCKDOXGeqYzeFIYKVSlriNMIXdo3bKM 52LaYfnVpfyANuA+jrhUtkrU9frCIUQdpYsRoQ2neWynj6g1as9kLMQvcAlmbVWA6mPt FK+CDOPRuC7va0mbFWenB2U4sR9NJuB06gjCX9sGxS/Nna0G8KUDOIGqJmJSK5G3KRsb NWu6hgPNp0Ec9k80osfzFqM47NIB4woPB/xbWNSFR6IpvsQcnp0jlX71UXiymO//FFwr CpUJwM4Rg8b6QI8Lb8jRKNP4FWTk5iCdvOfvNG/kMk93qmM7AR7ZFINx2diSzESDwtv2 crIg== 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=iLlvaUV8xKtDc6BTniAemRj7OTvymEauhGcGGXXgkCQ=; b=OMvwkImh6K7Voa7h6EarzTAijKhLwC+Ky38HepQK+WamvqT2PyYj4onHixt5dR1WC9 V4MV04retI9KBx/nbC5n4O6X9r4kHquGriLFXl1C4l6y51JdjOtRR3nqCyoxNuiYAFuT 0rHXqekWa+wQs05rwll0CuUeuv+7nyWkB1JX05BR2xtfJXl+9JpqY0885qoPh0RfqP/N RTe9pQ0obvhXxWDT1NCVdUBKvrhMWyHCDcOgFHuQ+2pGgGSQS8Px4EvvR+5ZpO3RG7Zt btnYPedeG+4Tmcb4PQOi3gcBUaNM8vRzp2mdZgG5YX/Xc09fMOShazl7VH8Myp9dc2Kh G89Q== X-Gm-Message-State: AIVw113K84GId4TKdjmiVTOcbqlZuD9yT+5dTfwRIE/7V20DG+OWGOCu uCjCQhwEmbIbpi2shcYXEc9lH7djNNRRFXo= X-Received: by 10.36.10.19 with SMTP id 19mr3000232itw.97.1500389099623; Tue, 18 Jul 2017 07:44:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Tue, 18 Jul 2017 07:44:58 -0700 (PDT) In-Reply-To: References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 18 Jul 2017 16:44:58 +0200 Message-ID: To: "Murray S. Kucherawy" Cc: Spencer Dawkins , dcrup@ietf.org, dcrup-chairs@ietf.org, The IESG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 18 Jul 2017 14:45:02 -0000 On 18 July 2017 at 16:30, Murray S. Kucherawy wrote: > I provided the cited text, and I recall it was based on something I think > Eric said along the lines of "there are no known preimage attacks against > SHA1 (yet)." It's totally possible I misunderstood him, not being a > security expert. He is right, as of today, there are no known, practical preimage attacks (either first or second) against SHA-1. This is perhaps why certain uses of SHA-1 are OK(ish), like HMAC. > And if there are no known preimage attacks on SHA1 (yet), then I took Eric's remark to mean there's not much to worry about here [...] Second preimage attacks would be a real problem, yeah. That doesn't mean that a collision can't be exploited (but I am not a cryptographer). > That's fine with me, I guess, conceding apparent ignorance of the deeper > details. :) From nobody Tue Jul 18 07:53: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 8748C1317BE for ; Tue, 18 Jul 2017 07:53:50 -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=[AC_DIV_BONANZA=0.001, 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 KCJM5TqMj8oP for ; Tue, 18 Jul 2017 07:53:49 -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 84FF4129459 for ; Tue, 18 Jul 2017 07:53:46 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id z22so26057054uah.1 for ; Tue, 18 Jul 2017 07:53:46 -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=yIbl2f1fqzk8ojQnCtKrL5HcOQf+rWUM5xmdWgsNQ6I=; b=dDIicDMihcE9NQGum6b6VRPbS/4X/jDZoGnflO7RTRsABuAcpz1nv/9v68C5UJYQ5k TarenRs2PfRU+5e4myh1HKFk95RTq2pR8cS/YqqABiy8CkgjwPj53kNTZagZajIuabrn 6FxEaCYPFqWuPm2frvnnPEca57hRGrUZoNTuQ3ggLu9bVSFehcqoUE9h8iik/wPfasHO a4kS/Cr4pPNiKS7ZMOfyFfrwYe8GFQcDp125kBEwOPnyLV1Q3721t+h0vP+vVMl3cRDv gew3o4pzpCZq0qhFEF4YQc6IhqcVO/q4xrf/TI/dcfJacJhz/lH8J2uruQl5mqj3uyE1 zWaA== 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=yIbl2f1fqzk8ojQnCtKrL5HcOQf+rWUM5xmdWgsNQ6I=; b=ozaj7UEWYwFRaIlBU91ZGxbROZxlibw6hUbxUaMLa21SwE8wV262bZY/xSZrVhOny5 oVpW4/j42Dlo2eD0UIWIjRpUN4JfzqzoPTp+dnzQWWbVkTPOwh/S+An6poH8uw6J51rd u/8PcWW7tM/DyRHSrEfwvnW4gZwVemVcNmQTQ/9Khw3EZQLTzxx5h00mNSnnDjTD+gwM NCQAxyr1HekuGxNjTzm8kLvudAiLkA1iQ+Bypdl/9vb4NXl2F03hngklmwKXo0pVjuzq LX6zprloYhltNlTGo3V5h2nLMrslUAz7B4gcKaugEjQ3K6bw5dnIQAXT891qUokCq9Pm +Zhg== X-Gm-Message-State: AIVw113KFf5oK9SlQEPPgQKjD4iaOeNK2sLYBwuyRc0P/uGmlKPTsvLp ck929As0wSN5UvphCbLMqjjBu06Owk62Zrg= X-Received: by 10.159.38.129 with SMTP id 1mr1260651uay.64.1500389624396; Tue, 18 Jul 2017 07:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 18 Jul 2017 07:53:43 -0700 (PDT) From: "Murray S. Kucherawy" Date: Tue, 18 Jul 2017 16:53:43 +0200 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0479c696463e055498aeab" Archived-At: Subject: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 18 Jul 2017 14:53:50 -0000 --94eb2c0479c696463e055498aeab Content-Type: text/plain; charset="UTF-8" Having talked to a few others here at IETF 99 I'm abandoning my push against using MUST NOT with respect to discouraging use of "rsa-sha1". Scott, you're free to restore that language at your discretion, and I believe consensus on that other thread supports that decision. Thanks for everyone's patience while we worked through that one. We're going to appoint Seth Blank as the document shepherd for this one. I'll help him through the process. Unless there's anything controversial in here or in the two things on the agenda regarding this document, I intend to start Working Group Last Call on it after the session on Thursday. I've reviewed the document (as a participant) and I have the following additional feedback, in my role as a reviewing participant. Abstract: - Remove the last sentence. It's already there in the header of the document. Section 1: - The discussion venue thing should be marked "[RFC EDITOR: Please remove before publication.]" In fact, it's probably a good idea to make that its own subsection. - This section should also mention that SHA1 is being deprecated (and give references explaining why). Section 3: - "One algorithms" should be "One algorithm" at least; we could also say "Two algorithms are defined, but only one is currently supported", and have a subsection acknowledging that "rsa-sha1" did exist but it is obsolete and no longer supported. I would prefer the latter. Section 3.2: - There's an errant comma after "DKIM" near the end of the section. - Should we say verifiers SHOULD NOT verify signatures with keys smaller than 1024? Section 4: - The ABNF should allow "rsa-sha256", not "sha256". Section 6: - Errand double period at the end. Appendix A: - I would remove the specific draft reference, unless you want this draft to wait for that one to be published. Acknowledging John for a lot of source material separately is at your discretion. -MSK --94eb2c0479c696463e055498aeab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Having talked to a few others her= e at IETF 99 I'm abandoning my push against using MUST NOT with respect= to discouraging use of "rsa-sha1".=C2=A0 Scott, you're free = to restore that language at your discretion, and I believe consensus on tha= t other thread supports that decision.=C2=A0 Thanks for everyone's pati= ence while we worked through that one.

We're going to appoint Se= th Blank as the document shepherd for this one.=C2=A0 I'll help him thr= ough the process.=C2=A0 Unless there's anything controversial in here o= r in the two things on the agenda regarding this document, I intend to star= t Working Group Last Call on it after the session on Thursday.

I've reviewed the document (as a participant) and I have the following= additional feedback, in my role as a reviewing participant.

<= /div>
Abstract:
- Remove the last sentence.=C2=A0 It's al= ready there in the header of the document.

Section 1:
- The discussion venue thing should be marked "[RFC EDITOR: Please re= move before publication.]"=C2=A0 In fact, it's probably a good ide= a to make that its own subsection.
- This section should also ment= ion that SHA1 is being deprecated (and give references explaining why).
=
Section 3:
- "One algorithms" should be "= One algorithm" at least; we could also say "Two algorithms are de= fined, but only one is currently supported", and have a subsection ack= nowledging that "rsa-sha1" did exist but it is obsolete and no lo= nger supported.=C2=A0 I would prefer the latter.

Section 3.2:<= br>
- There's an errant comma after "DKIM" near the end = of the section.
- Should we say verifiers SHOULD NOT verify signat= ures with keys smaller than 1024?

Section 4:
- The AB= NF should allow "rsa-sha256", not "sha256".

Section 6:
- Errand double period at the end.

Appen= dix A:
- I would remove the specific draft reference, unless you w= ant this draft to wait for that one to be published.=C2=A0 Acknowledging Jo= hn for a lot of source material separately is at your discretion.

-MSK
--94eb2c0479c696463e055498aeab-- From nobody Tue Jul 18 07:56: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 CA63D131A93; Tue, 18 Jul 2017 07:56:22 -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 t3cy-iBjhgdn; Tue, 18 Jul 2017 07:56:21 -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 AB02C1317BE; Tue, 18 Jul 2017 07:56:21 -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 v6IEpo1a016797; Tue, 18 Jul 2017 15:56:18 +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=HquUQ4srUgSilxnlBK7yDL0R8ahAB4Lxu8TVLOdETz4=; b=Z0WjO+TmUGtJNv2L4Lht0pZ+bQ6mciJRMaTGPBWztXfna/Av5tO/bizEqFPBG1Nt8t2N jOMYXG3tdUDbd76qcl38GlqOvMbrcCkcGNfVOfVahMq8LR5hq4GEq0HLSkCgvuG0tXIr YdKl3w17DyYG0jr5q+rhj522DFGzSmyUbaY3yMzwNvSBfEgea2DFw3nly/IiFHSYSTO5 ju9yWgHNhheChHtM/q+S7rNoCQE1STArsJB/GyoxMpzpxWe7ZvozNSwdKsPHZKr4At4K 0jzdIFpfgLXAubVuUrI/YlJuMjcILkAkECAf+8gaZnMZ9Z3zlPWcZQ48X9a4Hdp76Tb/ /g== 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 2bsjvggh5g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 15:56:18 +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 v6IEpGWh032481; Tue, 18 Jul 2017 10:56:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecurgec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 10:56:17 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 18 Jul 2017 10:56:10 -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; Tue, 18 Jul 2017 10:56: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; Tue, 18 Jul 2017 10:56:10 -0400 From: "Salz, Rich" To: Martin Thomson , "Murray S. Kucherawy" CC: Spencer Dawkins , "dcrup@ietf.org" , "dcrup-chairs@ietf.org" , The IESG Thread-Topic: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) Thread-Index: AQHS+ystpVxiosKpKEmDW2xK+YK6EKJRJniAgAjLDICAAAQOAP//v7HA Date: Tue, 18 Jul 2017 14:56:09 +0000 Message-ID: <101ca50524af442cb1305b3dcf06b6ef@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> 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.153.157] 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-07-18_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-1706020000 definitions=main-1707180235 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_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-1706020000 definitions=main-1707180234 Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 18 Jul 2017 14:56:23 -0000 RXZlcnlvbmUncyBtb3ZpbmcgYXdheSBmcm9tIFNIQTEgaW4gYW50aWNpcGF0aW9uIG9mIGl0IGZh bGxpbmcuICBUaGUgY2hhcnRlciBjaGFuZ2UganVzdCB3YW50cyB0byBsZXQgREtJTSBqb2luIHRo ZSBjb29sIGtpZHMuICBUaGlzIGlzIGVhc2llciwgcmF0aGVyIHRoYW4gcmVxdWlyaW5nIEROUyBw ZW9wbGUgdG8gcmVwZWF0ZWRseSBleHBsYWluIHdoeSAiaXQncyBva2F5IHdlIGRvbid0IGhhdmUg dG8gZG8gaXQiDQoNCg== From nobody Tue Jul 18 07:56: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 9AD49131A7D; Tue, 18 Jul 2017 07:56:39 -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 et4DXSwqxW3z; Tue, 18 Jul 2017 07:56:38 -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 79080129482; Tue, 18 Jul 2017 07:56:38 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so26434818uax.3; Tue, 18 Jul 2017 07:56: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=kFcGRO90t9OgoVtWLVLcBAe1FQA/e5+ikBZMnWiTrUs=; b=Vsaki6tUr6GYH9dscAcElbTj9O2vdzQKj6al3bjkLFOHYu6QtIQk8vvGRVnDcbPWMo NoVQfRNexcZljQ1Hq+m1jOPs9gSjFmNUicHOwZ4rQat6tIAYzG8eBZTo0e/DB4AXVbsI tuWDutNn1XdQOAVd52SztJQZwQ79+gFmeOpiYXGgXr62eVc4VA0f+TDLG74dr/4C9gPy VA7BRfTYgzcdCAq6KxU6HNSFFIP7J2aaXkwbQCwoBPBIx5be414jT5VAWRpdp7Q02CKi 6eKgeWkGa/xEsL3SJ5ocfRv8E0b8ZQnWOnewl63Sv4ftwYfdAUO1jzk5tya0dQIekgnk 6AOw== 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=kFcGRO90t9OgoVtWLVLcBAe1FQA/e5+ikBZMnWiTrUs=; b=mp5boAn6/88/YqInHohygVydRwr2t9SpFMpBi5Vxl2RC79vH5Ih06tP7NGknKV9uqK wBCu/4Trlta7Ms1I2s+viwmah8hvJG9ZQqEwjUwUs7AJcoMwjedf2RgneNKK2t3fQrXS sUH0hbDiDf2yOdFBPYD5XdomZ1WCuH33jytn1kXlQKQfZhdxzj7Xoc05QEQ6Kkb1ZlgO fKhmOWzDU3Bd0fPmDuztQoTor90MYWZOoTLtHkwbVWx+Ok4d4ZwCXzKP9g1hzURzZR3K lR3X8qf3Ty7SEqIeo3IjHpdvoraUua99YkLeMb+FbZYpUwNyARZR1jS57ztzhl4TUuYl KlGw== X-Gm-Message-State: AIVw110PG/5rxuKZQIAlJRAgaixx3+YJGtWCl9TMteavInaaMzyXIhip /EjsfjjlFrHgCBkNJrkqUw/kZ2ebQw== X-Received: by 10.159.38.129 with SMTP id 1mr1268522uay.64.1500389797672; Tue, 18 Jul 2017 07:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 18 Jul 2017 07:56:37 -0700 (PDT) In-Reply-To: References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Tue, 18 Jul 2017 16:56:37 +0200 Message-ID: To: Martin Thomson Cc: Spencer Dawkins , dcrup@ietf.org, dcrup-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="94eb2c0479c6ea47f6055498b820" Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 18 Jul 2017 14:56:40 -0000 --94eb2c0479c6ea47f6055498b820 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 4:44 PM, Martin Thomson wrote: > Second preimage attacks would be a real problem, yeah. That doesn't > mean that a collision can't be exploited (but I am not a > cryptographer). > I infer from this that "preimage attack" and "collision" are in fact different things, which isn't what I believed before. Time to go do some reading. -MSK --94eb2c0479c6ea47f6055498b820 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 18, 2017 at 4:44 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
Second preimage= attacks would be a real problem, yeah.=C2=A0 That doesn't
mean that a collision can't be exploited (but I am not a
cryptographer).

I infer from this that "preimage attack" and "collision&quo= t; are in fact different things, which isn't what I believed before.=C2= =A0 Time to go do some reading.

-MSK
--94eb2c0479c6ea47f6055498b820-- From nobody Tue Jul 18 08:06: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 28D5E1317CA for ; Tue, 18 Jul 2017 08:06:52 -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=unavailable 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 MmYahIvxcJMa for ; Tue, 18 Jul 2017 08:06:50 -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 759EE1318A8 for ; Tue, 18 Jul 2017 08:06:43 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id a12so8637699ywh.3 for ; Tue, 18 Jul 2017 08:06:43 -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=lbgjjs043/236LLncsYF7cwj5npoM2YWmlqSQyEwpTc=; b=fVT6y9+l4sdyg47CBXHy/wY6nYwEp2Z2JMwRO6FF6046L7CyTzrgpiN0CaYlaBtaqF dR0h1ZWaqJi6RG/7yB7fegpdHi4VWu19wqc8wrSV4oFfPx3uCOcGjubvXU4jf3Zhh+FE vjQ4ui/D4vtq7gyBmQ3aoyfitfeB7XU5QMgSG9Kc2F13CLksewqJ37tKbvl9HLSxHydo Llq60U1dGmlWlL6i+1kYsa6FluhPbP3H64NBncIxXRpSjgLPX0WVlgENM8SjMMBbY8r5 8NrIeZXMcbfearo01zJuF4/QYGemjhX5GMrNfmOj1opmffoio4Ah2x/UoHCrmKlTierf E6mQ== 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=lbgjjs043/236LLncsYF7cwj5npoM2YWmlqSQyEwpTc=; b=r1XbXFgjc8YmsK0lFsnlUaECTnDYQZQQ1Kk3joO/y8JWIoza8TGgECEVx0ChGwWh3j FNXyi3BhX4JVmOPcPqDWoCeDJMkWAJvzKM47OvCAZ/ck7NUwyQlL49YIoe9DXRxs++U4 n8hEARVzPeGdOtBHpYRNkJAbOsKfI2JbiYgu5l9YFOMIb6A6g1UK4G44TrjA/o5L6bcB LzAkHmLPrhQdCcaSnYEpUy+sRRtShcRfy4Mg6VwwOvXcitueCGjaiCWbb+K9jON5woA2 +dE/Eh7sKFsU6IZ0Ohl4vp2YwLBNJ2xd4heobwiPanZGsWrHdzvY0AwN8mhZNaxYZT15 9opg== X-Gm-Message-State: AIVw110a97sAz0yl2PWE2sNRZ0lJMQHBGg/vCmrz8pwEPKmUQ4MuKtih vVG+OXLQ+dL16gq1fFRGyxMBZ20Kx073 X-Received: by 10.129.80.68 with SMTP id e65mr1512726ywb.289.1500390402661; Tue, 18 Jul 2017 08:06:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Tue, 18 Jul 2017 08:06:02 -0700 (PDT) In-Reply-To: References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 18 Jul 2017 08:06:02 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Martin Thomson , dcrup@ietf.org, dcrup-chairs@ietf.org, Spencer Dawkins , The IESG Content-Type: multipart/alternative; boundary="001a1147fa24f9cda4055498dc1f" Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 18 Jul 2017 15:06:52 -0000 --001a1147fa24f9cda4055498dc1f Content-Type: text/plain; charset="UTF-8" Correct. Collision refers to finding two messages M1 and M2 st. H(M1) == H(M2) First preimage refers to starting with some value X and computing a message M st. H(M) == X Second preimage refers to starting with some message M and computing a new message M' st. H(M') == HJ(M) -Ekr On Tue, Jul 18, 2017 at 7:56 AM, Murray S. Kucherawy wrote: > On Tue, Jul 18, 2017 at 4:44 PM, Martin Thomson > wrote: > >> Second preimage attacks would be a real problem, yeah. That doesn't >> mean that a collision can't be exploited (but I am not a >> cryptographer). >> > > I infer from this that "preimage attack" and "collision" are in fact > different things, which isn't what I believed before. Time to go do some > reading. > > -MSK > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > --001a1147fa24f9cda4055498dc1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct.

Collision refers to finding tw= o messages M1 and M2 st. H(M1) =3D=3D H(M2)
First preimage refers= to starting with some value X and computing a message M st. H(M) =3D=3D X<= /div>
Second preimage refers to starting with some message M and comput= ing a new message M' st. H(M') =3D=3D HJ(M)

-Ekr


On Tue, Jul 18, 2017 at 7:56 AM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
=
On Tue, Jul 18, 2017 at 4:44 PM, Martin T= homson <martin.thomson@gmail.com> wrote:
Second preimage attacks would be a real problem, y= eah.=C2=A0 That doesn't
mean that a collision can't be exploited (but I am not a
cryptographer).

I i= nfer from this that "preimage attack" and "collision" a= re in fact different things, which isn't what I believed before.=C2=A0 = Time to go do some reading.<= br>
<= div>-MSK

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


--001a1147fa24f9cda4055498dc1f-- From nobody Tue Jul 18 08:16: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 CF3151318A8 for ; Tue, 18 Jul 2017 08:16: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 (2048-bit key) header.d=andreasschulze.de 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 Nc7PIKbejYuT for ; Tue, 18 Jul 2017 08:16:15 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:470:77b3:100::7]) (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 B8273131A69 for ; Tue, 18 Jul 2017 08:16:13 -0700 (PDT) Received: from [IPv6:2001:67c:370:128:8065:284d:b25b:4e40] (unknown [IPv6:2001:67c:370:128:8065:284d:b25b:4e40]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3xBkJV1WZNzMsV8c for ; Tue, 18 Jul 2017 17:16:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1500390970; bh=ZSwRu0iJFGtW/xUxZtpAD7fh605j9IkgR6pP5+Rmvks=; h=Subject:To:References:From:Date:In-Reply-To; b=diOzb8RgOiQVwi1Laqgi4mlcdIoFAInauZmFV7DA2B83lSXwyK8/dNwbgKbiws8t3 TJcAFKS5j+9GIGYYOQyMtq2CtZEK5K/eDw3QWzFQTUjgdFL1YfiS0g9g7L92/CF5pq WbuNcMLTgqGzisyntSdsQZegy6QTOYjgRGZBf1VNZA5ddm3j3l9OuOiPGx5DhYFiSJ nr8yHU+VxGqYvKqSK7k044FAC76Hn3sW9UDlgITYrYF5dsoPLnp3sFwMkQrIArE5JU Ck1fe32hrqkpGKv9BeE3/rzzRsIJPsKCU+pPe18k1QfFAdKzjke52zXL42t1u7j/yc AzP9l9BiT+0dQ== To: dcrup@ietf.org References: <20170711165103.98321.qmail@ary.lan> From: "A. Schulze" Message-ID: Date: Tue, 18 Jul 2017 17:13:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170711165103.98321.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 18 Jul 2017 15:16:18 -0000 Am 11.07.2017 um 18:51 schrieb John Levine: > The other, due I think to Stephen Farrell, is that if you want to > invalidate a key, you can poison it by publishing the public key. s/public/private/ ? that make all future signatures denyable, or does it also capture old sigs? > Since the point of that is to prevent interoperation it's not > something that would go in a standards track document, but I suppose > we could informally suggest that when you revoke a key by blanking > out the p= public key tag you add a pk= tag with the public key. what does the standard say about unknown key "pk=", "key must be not used" or "key must be ignored"? > PS: I know the public key will not fit in 256 octets, but tough. Yea, a published private key is no longer under operational restriction Andreas From nobody Tue Jul 18 08:21: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 75F14131686 for ; Tue, 18 Jul 2017 08:20:58 -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 6NJCQ2_ZU0m1 for ; Tue, 18 Jul 2017 08:20:57 -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 81073128DE5 for ; Tue, 18 Jul 2017 08:20:57 -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 v6IFHAu6006848; Tue, 18 Jul 2017 16:20:43 +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=BcDzOBPOvLBJxjtAfGQtS9pwJcv349Xh4oEP5kAoawk=; b=jLbQYLU87aqieQFgiUEF9QX1jU26g/4zhGrG3IWsT2261zVlYN9XLIwO9cXR5WmxrwCK LH065GaE4yTZRgkhA+ymf+tSxtrMgCbG9s1XX42341SB4XoP2C9UUQtuXlnbjCDDm3XT Gg/kGvYfloiqzTgzt5/9mGL1g1/vC7l4QHkO55sNE+8KoQDQ/CSgKD+03Rj/woCOv8Hz jx+dGVtgIunz7bOVEPLtfkmH1AkJVL5vE5SqLBVf/xIROnKoqeUq4XIpJZO3oYbIwkK6 po00AbKRmUZEmm5HXOof0axw+o+SqO76O0JvJjRCQgYGL/zaYJSZPE2C8uvt1Eclt2hT 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 2bsjvggnfx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 16:20:43 +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 v6IFFk53017586; Tue, 18 Jul 2017 11:20:43 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecurk5b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 11:20:43 -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, 18 Jul 2017 11:20:42 -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, 18 Jul 2017 11:20:42 -0400 From: "Salz, Rich" To: "A. Schulze" , "dcrup@ietf.org" Thread-Topic: [Dcrup] hashing and privacy Thread-Index: AQHS+dOPMAXGXa4y1kSYEQ6WroaesqJPGyqAgArlEgD//76F0A== Date: Tue, 18 Jul 2017 15:20:41 +0000 Message-ID: References: <20170711165103.98321.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.153.157] 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-07-18_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-1706020000 definitions=main-1707180242 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_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-1706020000 definitions=main-1707180242 Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 18 Jul 2017 15:20:58 -0000 Once the private key is published, all signatures can be forged. From nobody Tue Jul 18 08:23:48 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 8AE24131B5D; Tue, 18 Jul 2017 08:23:45 -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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VyIcFjCP2a_D; Tue, 18 Jul 2017 08:23:44 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 DD0B612EC19; Tue, 18 Jul 2017 08:23:43 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id v193so8887895ywg.2; Tue, 18 Jul 2017 08:23: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=WUhkG/A8SCc68gBmBi4GZdTDNU907YckW4uRjODo8EI=; b=Ol5S9XfFlmVDI7a32geHS/dnaomjRwcws9leTUl/27pcgJzb/zwsj8F9F6CXDCXzwB rPythrZjBZBp1DImlOyt70ac0mcmN6VpeoiPQhryuYcuAbeYL5XDS1MFneIllOXTiets b0mU8g3zp4A19fWKv94o3FzOhAcF/wJaeHP+ez6kPK+hPtX6KxHmKW9sv2raxPDfs3LD 9IAmLtK/fl5dQp7tTyTnvUp0uFlC6U8g2sWDSkAkTqr/BcGpYptiA5b9Q3H9jkSNFVXg ftCtP58v5G44bQZokuC5dparqCDQBpllLJf0gMnhRY/iVewK41MU++JASD2tFQffMSPg VW2Q== 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=WUhkG/A8SCc68gBmBi4GZdTDNU907YckW4uRjODo8EI=; b=YLtzpsvDV5lNMZjp2WJ75cGnQuYBXkdnjGbfnsvYk2GA/YebZ85uzhcqVnaizV6r51 o55sGEpJ80lkIwitejo7r85nbUV7WAFSc6tFDQ2jSBTZbaiTG7i16DFYXGBL9IVMkuno wwG9EUOeuwDDhziu0Djn+PY2v7Rs7Phy5WOjU5GDyWdnKb4L7Bqq3mYOeMFP8flfCeKu CaeRDtrXNMVHjk+KUs/emlSG0uXmKzfvvrBX4cNL+gDh/P9KBkMwuPbyaudssId/uscE /aMrCouExNflBTLly8i9pXnV/XjZYCuxbFCVoEj26BLVv6sprMf0xnhcRTl5gQ3ZwsX9 jZcw== X-Gm-Message-State: AIVw111PYYs8iwreZo2KE3jcLo6X1nbpdyZxZUvTHuEPgCHwgk3JjAbG 8a6RSwalyvM8kWj/b1PzMy58JXAgEA== X-Received: by 10.13.227.132 with SMTP id m126mr1593788ywe.151.1500391423069; Tue, 18 Jul 2017 08:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.131 with HTTP; Tue, 18 Jul 2017 08:23:42 -0700 (PDT) In-Reply-To: References: <149987657244.17860.1774146221643214145.idtracker@ietfa.amsl.com> From: denis bider Date: Tue, 18 Jul 2017 09:23:42 -0600 Message-ID: To: Eric Rescorla Cc: "Murray S. Kucherawy" , dcrup-chairs@ietf.org, dcrup@ietf.org, Martin Thomson , Spencer Dawkins , The IESG Content-Type: multipart/alternative; boundary="94eb2c07630ccbfd870554991983" Archived-At: Subject: Re: [Dcrup] Spencer Dawkins' No Objection on charter-ietf-dcrup-01-00: (with COMMENT) 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, 18 Jul 2017 15:23:46 -0000 --94eb2c07630ccbfd870554991983 Content-Type: text/plain; charset="UTF-8" To elaborate a bit - collision allows things like an adversary submitting a specially crafted certificate signing request for my.example.com, which happens to have the same hash as a hidden twin crafted request for google.com. The CA signs the certificate for my.example.com, but because of the weakness of the hash, the same signature is now also valid for the hidden twin crafted request. The adversary combines the signature with the hidden request, and gets a valid certificate for google.com. DKIM does not fatally suffer from this because the entity generating the messages also signs them. If someone wants to fool around and generate M and M' with same hash, and sign them using DKIM, there is no real consequence for DKIM's main security objective (which is to verify the message is from the domain it claims it is). But, if someone were to discover a preimage attack, DKIM's main security objective would no longer be met, since other people besides the original signer would be able to generate messages M', M'', M''' that appear to be sent from the signer's domain. On Tue, Jul 18, 2017 at 9:06 AM, Eric Rescorla wrote: > Correct. > > Collision refers to finding two messages M1 and M2 st. H(M1) == H(M2) > First preimage refers to starting with some value X and computing a > message M st. H(M) == X > Second preimage refers to starting with some message M and computing a new > message M' st. H(M') == HJ(M) > > -Ekr > > > On Tue, Jul 18, 2017 at 7:56 AM, Murray S. Kucherawy > wrote: > >> On Tue, Jul 18, 2017 at 4:44 PM, Martin Thomson > > wrote: >> >>> Second preimage attacks would be a real problem, yeah. That doesn't >>> mean that a collision can't be exploited (but I am not a >>> cryptographer). >>> >> >> I infer from this that "preimage attack" and "collision" are in fact >> different things, which isn't what I believed before. Time to go do some >> reading. >> >> -MSK >> >> _______________________________________________ >> 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 > > --94eb2c07630ccbfd870554991983 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To elaborate a bit - collision allows things like an adver= sary submitting a specially crafted certificate signing request for my.example.com, which happens to have the sa= me hash as a hidden twin crafted request for = google.com. The CA signs the certificate for my.example.com, but because of the weakness of the hash, the sa= me signature is now also valid for the hidden twin crafted request. The adv= ersary combines the signature with the hidden request, and gets a valid cer= tificate for google.com.=C2=A0

DKIM does not fatally suffer from this because the entity generati= ng the messages also signs them. If someone wants to fool around and genera= te M and M' with same hash, and sign them using DKIM, there is no real = consequence for DKIM's main security objective (which is to verify the = message is from the domain it claims it is).

But, = if someone were to discover a preimage attack, DKIM's main security obj= ective would no longer be met, since other people besides the original sign= er would be able to generate messages M', M'', M'''= that appear to be sent from the signer's domain.

<= /div>

On Tue, Jul = 18, 2017 at 9:06 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Correct.

Coll= ision refers to finding two messages M1 and M2 st. H(M1) =3D=3D H(M2)
=
First preimage refers to starting with some value X and computing a me= ssage M st. H(M) =3D=3D X
Second preimage refers to starting with= some message M and computing a new message M' st. H(M') =3D=3D HJ(= M)

-Ekr


On Tue, Ju= l 18, 2017 at 7:56 AM, Murray S. Kucherawy <superuser@gmail.com><= /span> wrote:
On Tue, Jul 18, 2017 at 4:44 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
Second preimage attacks would be a real problem, yeah.=C2=A0 Tha= t doesn't
mean that a collision can't be exploited (but I am not a
cryptographer).

I i= nfer from this that "preimage attack" and "collision" a= re in fact different things, which isn't what I believed before.=C2=A0 = Time to go do some reading.

-MSK
=

_____________________________________= __________
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


--94eb2c07630ccbfd870554991983-- From nobody Tue Jul 18 12:35: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 29398131456 for ; Tue, 18 Jul 2017 12:35:21 -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 jAKng4zC0BL2 for ; Tue, 18 Jul 2017 12:35:12 -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 BF388128AB0 for ; Tue, 18 Jul 2017 12:35:12 -0700 (PDT) Received: (qmail 54914 invoked from network); 18 Jul 2017 19:35:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 18 Jul 2017 19:35:11 -0000 Date: 18 Jul 2017 19:34:49 -0000 Message-ID: <20170718193449.14371.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 review and progress 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, 18 Jul 2017 19:35:21 -0000 It seems likely that we can hash out the few remaining issues on Thursday, so are we doing one document or two? R's, John In article you write: >Having talked to a few others here at IETF 99 I'm abandoning my push >against using MUST NOT with respect to discouraging use of "rsa-sha1". >Scott, you're free to restore that language at your discretion, and I >believe consensus on that other thread supports that decision. Thanks for >everyone's patience while we worked through that one. > >We're going to appoint Seth Blank as the document shepherd for this one. >I'll help him through the process. Unless there's anything controversial >in here or in the two things on the agenda regarding this document, I >intend to start Working Group Last Call on it after the session on Thursday. > >I've reviewed the document (as a participant) and I have the following >additional feedback, in my role as a reviewing participant. > >Abstract: >- Remove the last sentence. It's already there in the header of the >document. > >Section 1: >- The discussion venue thing should be marked "[RFC EDITOR: Please remove >before publication.]" In fact, it's probably a good idea to make that its >own subsection. >- This section should also mention that SHA1 is being deprecated (and give >references explaining why). > >Section 3: >- "One algorithms" should be "One algorithm" at least; we could also say >"Two algorithms are defined, but only one is currently supported", and have >a subsection acknowledging that "rsa-sha1" did exist but it is obsolete and >no longer supported. I would prefer the latter. > >Section 3.2: >- There's an errant comma after "DKIM" near the end of the section. >- Should we say verifiers SHOULD NOT verify signatures with keys smaller >than 1024? > >Section 4: >- The ABNF should allow "rsa-sha256", not "sha256". > >Section 6: >- Errand double period at the end. > >Appendix A: >- I would remove the specific draft reference, unless you want this draft >to wait for that one to be published. Acknowledging John for a lot of >source material separately is at your discretion. > >-MSK > >-=-=-=-=-=- >[Alternative: text/html] >-=-=-=-=-=- From nobody Tue Jul 18 14:47: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 B4AC81294A2 for ; Tue, 18 Jul 2017 14:47:57 -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 eQIDCikBqDyC for ; Tue, 18 Jul 2017 14:47:55 -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 03F48131B05 for ; Tue, 18 Jul 2017 14:47:54 -0700 (PDT) Received: from [10.143.225.216] (mobile-166-170-29-53.mycingular.net [166.170.29.53]) (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 ABD9AC403A8; Tue, 18 Jul 2017 16:47:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1500414472; bh=JHUoOxPQnr0QWTXcJUBHyKcxp3KkOy9vCWMjjRFTAno=; h=Date:In-Reply-To:References:Subject:To:From:From; b=eUAEQD/1X45yXMyHshbkKO59j5ftTjrDj+q4eWQcOF2vEcAmuFFFXMM+VnP74Vd+j aYYF5m5j9uNektCZpFkPYBYW2wBbxhL8QWeSNPO0gueQ3feNtVaRrmXiM2KL6B1/Nk CyMog+Pq1jO4i4nLJfSFbDhvv1wkYhENGm7Ttzyc= Date: Tue, 18 Jul 2017 21:47:18 +0000 In-Reply-To: <20170718193449.14371.qmail@ary.lan> References: <20170718193449.14371.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 review and progress 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, 18 Jul 2017 21:47:58 -0000 I think that depends on Thursday=2E Unless we manage to stop going in circ= les over hashed key records I think it should be two=2E Let's see where yo= u all get to at the meeting=2E Scott K On July 18, 2017 3:34:49 PM EDT, John Levine wrote: >It seems likely that we can hash out the few remaining issues on >Thursday, >so are we doing one document or two? > >R's, >John > > >In article > >you write: >>Having talked to a few others here at IETF 99 I'm abandoning my push >>against using MUST NOT with respect to discouraging use of "rsa-sha1"=2E >>Scott, you're free to restore that language at your discretion, and I >>believe consensus on that other thread supports that decision=2E Thanks >for >>everyone's patience while we worked through that one=2E >> >>We're going to appoint Seth Blank as the document shepherd for this >one=2E >>I'll help him through the process=2E Unless there's anything >controversial >>in here or in the two things on the agenda regarding this document, I >>intend to start Working Group Last Call on it after the session on >Thursday=2E >> >>I've reviewed the document (as a participant) and I have the following >>additional feedback, in my role as a reviewing participant=2E >> >>Abstract: >>- Remove the last sentence=2E It's already there in the header of the >>document=2E >> >>Section 1: >>- The discussion venue thing should be marked "[RFC EDITOR: Please >remove >>before publication=2E]" In fact, it's probably a good idea to make that >its >>own subsection=2E >>- This section should also mention that SHA1 is being deprecated (and >give >>references explaining why)=2E >> >>Section 3: >>- "One algorithms" should be "One algorithm" at least; we could also >say >>"Two algorithms are defined, but only one is currently supported", and >have >>a subsection acknowledging that "rsa-sha1" did exist but it is >obsolete and >>no longer supported=2E I would prefer the latter=2E >> >>Section 3=2E2: >>- There's an errant comma after "DKIM" near the end of the section=2E >>- Should we say verifiers SHOULD NOT verify signatures with keys >smaller >>than 1024? >> >>Section 4: >>- The ABNF should allow "rsa-sha256", not "sha256"=2E >> >>Section 6: >>- Errand double period at the end=2E >> >>Appendix A: >>- I would remove the specific draft reference, unless you want this >draft >>to wait for that one to be published=2E Acknowledging John for a lot of >>source material separately is at your discretion=2E >> >>-MSK >> >>-=3D-=3D-=3D-=3D-=3D- >>[Alternative: text/html] >>-=3D-=3D-=3D-=3D-=3D- > > >_______________________________________________ >Dcrup mailing list >Dcrup@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dcrup From nobody Tue Jul 18 14:55: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 C2BB8129A9C for ; Tue, 18 Jul 2017 14:55:32 -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, 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=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 YJ7zEJ6EpPHM for ; Tue, 18 Jul 2017 14:55:31 -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 9F997126C2F for ; Tue, 18 Jul 2017 14:55:31 -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 v6ILg2mP022490; Tue, 18 Jul 2017 22:55:29 +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=BLRZzoGky+X5IN6LJtoWwgkHUuwZjj0Hzn225k/Uos4=; b=Xrx+YA0rwCdq9Uz6KCNxMhv6enD92O7XDM5MwoMS/FhzQXpUSuorm7vu9IUITEDJVl3x NDdkkhK9mpNN0IBVmzcCAuOkGaYmB4H5Jk4DpM2WN9I42OwMzF/mFgzuIq2xG6esqgwu Crar8rNNVjkq9tqo/wFALMrWLh9zsfHWEAy3fbOzpnj2GrUBBk2B51YeytbgoA9+KUBc 4OHe9DfIPhY6eedguPTpR3PzQZd5VG9DoMRqA+baXuObV96tQp8MPULDMki1CVkwHlN7 2/mNcrCZN7N/RMDYE4S0DPnTPESdrEnbFKfSs8JWdxlIR95ck92V1yJ1ZY/48q8xI02q xA== 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 2bqak4xxwj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 22:55:29 +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 v6ILeXvT010703; Tue, 18 Jul 2017 17:55:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecu9vec-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Jul 2017 17:55:28 -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, 18 Jul 2017 17:55:27 -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, 18 Jul 2017 17:55:27 -0400 From: "Salz, Rich" To: John Levine , "dcrup@ietf.org" CC: "superuser@gmail.com" Thread-Topic: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress Thread-Index: AQHS/9WxWe7hhT9Q6EOs+TNN7dMnKqJaPTmA///joCA= Date: Tue, 18 Jul 2017 21:55:26 +0000 Message-ID: <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170718193449.14371.qmail@ary.lan> In-Reply-To: <20170718193449.14371.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.152.105] 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-07-18_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-1706020000 definitions=main-1707180340 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-18_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707180340 Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 18 Jul 2017 21:55:33 -0000 I would like to see 1. One document that says don't use SHA1 and do use larger RSA key sizes; t= his exists 2. One document that talks about how to put key identifiers/key digests int= o DNS records and how to put them in DKIM data 3. One document that says how to use Ed25519 signatures (per the EdDSA RFC)= for DKIM data #1 exists #2 and #3 also exists as a single document, but I would like to see them sp= lit. Does this make sense? From nobody Tue Jul 18 21:01: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 0F037127076 for ; Tue, 18 Jul 2017 21:01:28 -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 7Lgrn0pixjwC for ; Tue, 18 Jul 2017 21:01:26 -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 A34B3126D85 for ; Tue, 18 Jul 2017 21:01:26 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id y70so4045775vky.3 for ; Tue, 18 Jul 2017 21:01:26 -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=XG/LrgQNtGxaRnKXrCSUuY68XjJV4GlrdrSdhm0/E4U=; b=U/3xyVkzu1qekNdbXRsF2wwINgdjek3D6HZBPy7d9MJ3ZRDBelQk8qRpoFQ3xFEtDW /PKqtVmScQ6CCsxC4kN3TcaSVbNZTP4lsegvMdin0E1mQJu4ugZdRiyHjc4jDS1DQZfI H4aRt3m0Qgs/D8ACtktTQ8fjlSD+8TUF+GHyeozTktMkhVqqGP039JhDRfBjQH1jnGq5 Bz3xlgxPcefBFO+78V40/rSP4IxLeV8WySZeuSHIWgCtQRddF2A8kpFpCQ+7OdU0VTDv LkRmbf8g7kPlTpebqXUYZ3a6H4AaGtLg84tNxO53Xje5y2iKZ9pGzbMVnBLK9bdDQ1Cy b8/A== 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=XG/LrgQNtGxaRnKXrCSUuY68XjJV4GlrdrSdhm0/E4U=; b=YyPrxKvZkL3craDt4f5RYkTjdn82M0G5zOa4KjsaQyiPZJiFpRGJeGnnWZQjHAnz+5 yBa+kn0ocrfKVejOeXh8/z/aG+/HmD8gVJw82N+HiBYvSGQLs9hdLQ+ehTV+2jtgrW+l GagBBMvS6E454DW6etRkMoQYL69iMzC30kkG/mIi77s/1qnIx+yWygicw7yv9RNenUp6 nQInHvst8/kXFYNanTbpXTYnAX0DIi+A0MqZaVB7OINILdeAf7ehwG0wSCMl04XL0pat cktSCbYiqZmedkxuubfoNQMBom7b9JCx6xmbc/5YoAw89wnUABCZD19XYQkT+qEXa+en gKOA== X-Gm-Message-State: AIVw111bvzRMrLivSgS434CJ7srHlQQic9PFzwKHJN4dLT88n3KHyTPm qMr14zzef5qz7yChJ/Bjc5qQe1/a6w== X-Received: by 10.31.148.17 with SMTP id w17mr429404vkd.91.1500436885831; Tue, 18 Jul 2017 21:01:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 18 Jul 2017 21:01:25 -0700 (PDT) In-Reply-To: <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170718193449.14371.qmail@ary.lan> <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Murray S. Kucherawy" Date: Wed, 19 Jul 2017 06:01:25 +0200 Message-ID: To: "Salz, Rich" Cc: John Levine , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a114259da96867f0554a3af4e" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 04:01:28 -0000 --001a114259da96867f0554a3af4e Content-Type: text/plain; charset="UTF-8" On Tue, Jul 18, 2017 at 11:55 PM, Salz, Rich wrote: > I would like to see > 1. One document that says don't use SHA1 and do use larger RSA key sizes; > this exists > 2. One document that talks about how to put key identifiers/key digests > into DNS records and how to put them in DKIM data > 3. One document that says how to use Ed25519 signatures (per the EdDSA > RFC) for DKIM data > > #1 exists > #2 and #3 also exists as a single document, but I would like to see them > split. > > Does this make sense? > Exactly the vision I have. -MSK --001a114259da96867f0554a3af4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 18, 2017 at 11:55 PM, Salz, Rich <rsalz@akamai= .com> wrote:
I would like to see
1. One document that says don't use SHA1 and do use larger RSA key size= s; this exists
2. One document that talks about how to put key identifiers/key digests int= o DNS records and how to put them in DKIM data
3. One document that says how to use Ed25519 signatures (per the EdDSA RFC)= for DKIM data

#1 exists
#2 and #3 also exists as a single document, but I would like to see them sp= lit.

Does this make sense?

Exactly the vision = I have.

-MSK
--001a114259da96867f0554a3af4e-- From nobody Tue Jul 18 21:06: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 5F88C127076 for ; Tue, 18 Jul 2017 21:06:29 -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 BLeqyQ9Y433x for ; Tue, 18 Jul 2017 21:06:28 -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 E6C72126D85 for ; Tue, 18 Jul 2017 21:06:27 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id y47so26872061uag.0 for ; Tue, 18 Jul 2017 21:06:27 -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=InTjYq5GtTGxiqEj5IKN8lPBSjM/Hw1A2B2yg2Xf67E=; b=aHY6CE472T+zvdUElPBuojGKbae4YheDoktqARwuK26w4LCH8wKNBiqFOJv+/SdEm6 rhGVboSAz65mJShtl2JEunhj6T4ByNmHuPnBWs5QJ54vC7VYLzYp2XVOW7yHDJRyihsO zebi3XURldDxi5qVETJ+zIvNaNDDM6jrYqfdwzwJIMGm9vFmgaRJn0oSo54jD6x5GQOT U91SC0a1FYTdNHXdRhf05twJUcc43Gelp7Q5iiBJ22xfi+aGvYOu2/frTlsRmCltP/0J qjJNT3PayK6jQIvMWGNw6yROVscUMhLwqenAyjZrhaO86PolHg1+9VjKyo7D220wLjXs 7dDQ== 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=InTjYq5GtTGxiqEj5IKN8lPBSjM/Hw1A2B2yg2Xf67E=; b=f1h9VWxTpWt2nygMCg5+4BfNdSPYxH6dZHDpQWj5ViBvkfC9gFIkLl4x6KYpDJe7oz 3M1Fkn/NgCM5cz0p3gEHcRhKSjzxOpPYKs1wKBbRJjbZhue9ZMsxQobnTKIXg962gikd XSdhAmaam8iB8mCsjDb9ZZ/ZGKvXJBHPZifqDyHR6DBISrVfNP9CFV4kJ8dn8xjpycyH 27VpFo7MkPh78FrqUGCU/zc2VUn+5VqDMBXmIZrh5Zp2pZoxPdvhb055mC6ytIGA5WV+ 5r/IlWDsEqvCXKCvey72V+5sN1SsEEPkRn9ctOHk3SZK3jOhiEEX3U17OrNVr3NJhZx9 NKzQ== X-Gm-Message-State: AIVw1118Hq4jzvGtkCI2bbD2GMrfUH3jXqfXBK/oRf9Bn5IS1GtIDzsm rxCmcFpLALDeteYRIvCsbagIN/gywTYE X-Received: by 10.176.7.215 with SMTP id d23mr508615uaf.61.1500437187112; Tue, 18 Jul 2017 21:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Tue, 18 Jul 2017 21:06:26 -0700 (PDT) In-Reply-To: References: <2111048.dxWtyJcX9G@kitterma-e6430> From: "Murray S. Kucherawy" Date: Wed, 19 Jul 2017 06:06:26 +0200 Message-ID: To: "Salz, Rich" Cc: Scott Kitterman , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="f403045f8ab48bb5010554a3c14b" Archived-At: Subject: Re: [Dcrup] Draft agenda for DCRUP at IETF 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, 19 Jul 2017 04:06:29 -0000 --f403045f8ab48bb5010554a3c14b Content-Type: text/plain; charset="UTF-8" On Mon, Jul 10, 2017 at 9:37 AM, Salz, Rich wrote: > > My sense over the last few days is that we aren't getting anywhere close > to > > consensus that would make it reasonable to believe the other arguments > will > > be wrapped up in short order and we ought to go ahead with my draft, but > > that's just one person's view. > > And on co-chair's :) > Two. I just took an admittedly-brief look on relevant threads for evidence that we have outstanding issues here, and I didn't see anything. What issues are you concerned about? -MSK --f403045f8ab48bb5010554a3c14b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 10, 2017 at 9:37 AM, Salz, Rich <rsalz@akamai.= com> wrote:
> My sense over the last fe= w days is that we aren't getting anywhere close to
> consensus that would make it reasonable to believe the other arguments= will
> be wrapped up in short order and we ought to go ahead with my draft, b= ut
> that's just one person's view.

And on co-chair's :)

Two.=C2= =A0 I just took an admittedly-brief look on relevant threads for evidence t= hat we have outstanding issues here, and I didn't see anything.=C2=A0 W= hat issues are you concerned about?

-MSK
<= /div>
--f403045f8ab48bb5010554a3c14b-- From nobody Tue Jul 18 21:40: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 D58B01274D0 for ; Tue, 18 Jul 2017 21:40:23 -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 tL3wuPve7CXs for ; Tue, 18 Jul 2017 21:40:22 -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 37A5E126B6E for ; Tue, 18 Jul 2017 21:40:22 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id p193so2436600vkd.0 for ; Tue, 18 Jul 2017 21:40:22 -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=GcJPj2MsbYMOzGl9S0e0/nbrsBTZRXwAnF0dskwaW8E=; b=HENFHiM1HXXnrqe9kmZX8B3a/fjQJ4F/dgd38+RAOfhsEGrdFk+d4puiHAveBaK29+ 4EnuT2iddSQeYSmUkQPpOWG63bTnBwUfR75mVdaWyNx/05d1xfDiFFGiFiKOD1wl5/He TxDOSaY07DU6yoYtUNQaa3Xzgcd1OY4Wnb6Ws= 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=GcJPj2MsbYMOzGl9S0e0/nbrsBTZRXwAnF0dskwaW8E=; b=q/j23TbAVKrw7A0GA8t+vuTkfMUCKTFiAdh/tGwQGIYwHZHVFyWO1xbmatHi6UNBq5 0rngo9J1Q+rHOXPUaT1v5vGBCVwSXZDZgQRvTcMdEOcHzDgjz1PIldFyJcdGbXYh8RbK f9Q1rXUk6fYxUzOrNZSPNyjsjiPl5AFKzgWkplujrbQACU/usuxwLY8FoL+gB11C/LFi eplj0fF5TkdK4iY/pB6Ex2Jpb7yJgoWL3Kg/qEWBYUyiAnD3g/1Bmu3p+JwLX16D+eQj JkhdiQWwchH2NJIQM/6AweFr6isjU336ehXLpDj6NHjnQ3HcCizXZSpXAnbWbbHXKLyp FwKA== X-Gm-Message-State: AIVw112eUXOjtOS81Y/1whktYpK4Huzk7LZ4WBSP4llcQcMfhux+Gs8B tQpStC2pfON/PchJ/BLQ36qZ3H9+AfLm X-Received: by 10.31.252.65 with SMTP id a62mr533307vki.60.1500439221138; Tue, 18 Jul 2017 21:40:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Tue, 18 Jul 2017 21:40:20 -0700 (PDT) In-Reply-To: References: <20170718193449.14371.qmail@ary.lan> <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> From: Kurt Andersen Date: Wed, 19 Jul 2017 06:40:20 +0200 Message-ID: To: "Murray S. Kucherawy" Cc: "Salz, Rich" , "dcrup@ietf.org" , John Levine Content-Type: multipart/alternative; boundary="94eb2c1493e4c88b160554a43ad5" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 04:40:24 -0000 --94eb2c1493e4c88b160554a43ad5 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 6:01 AM, Murray S. Kucherawy wrote: > On Tue, Jul 18, 2017 at 11:55 PM, Salz, Rich wrote: > >> I would like to see >> 1. One document that says don't use SHA1 and do use larger RSA key sizes; >> this exists >> 2. One document that talks about how to put key identifiers/key digests >> into DNS records and how to put them in DKIM data >> 3. One document that says how to use Ed25519 signatures (per the EdDSA >> RFC) for DKIM data >> >> #1 exists >> #2 and #3 also exists as a single document, but I would like to see them >> split. >> >> Does this make sense? >> > > Exactly the vision I have. > After hallway discussions earlier in the week, I agree as well with the trilogy approach. --Kurt --94eb2c1493e4c88b160554a43ad5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 19, 2017 at 6:01 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Jul 18, 2017 at 11:55 PM, Salz, Rich <rsalz@akamai.com= > wrote:
I would like to see
1. One document that says don't use SHA1 and do use larger RSA key size= s; this exists
2. One document that talks about how to put key identifiers/key digests int= o DNS records and how to put them in DKIM data
3. One document that says how to use Ed25519 signatures (per the EdDSA RFC)= for DKIM data

#1 exists
#2 and #3 also exists as a single document, but I would like to see them sp= lit.

Does this make sense?

Exactly the = vision I have.

After hallway di= scussions earlier in the week, I agree as well with the trilogy approach.

--Kurt=C2=A0
--94eb2c1493e4c88b160554a43ad5-- From nobody Tue Jul 18 23:48: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 9AFC512ECC8 for ; Tue, 18 Jul 2017 23:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.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, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.723, MISSING_MIMEOLE=1.899, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=25Fb6O6b; dkim=pass (1536-bit key) header.d=taugh.com header.b=JN/phORG 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 F_SYAoU2FrgS for ; Tue, 18 Jul 2017 23:48:56 -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 73B7612ECB4 for ; Tue, 18 Jul 2017 23:48:56 -0700 (PDT) Received: (qmail 5426 invoked from network); 19 Jul 2017 06:48:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1530.596f00d7.k1707; i=johnl-iecc.com@submit.iecc.com; bh=Gb8kql2ow7PjbRBs8OiBJ/TasOsx9+IGT4pzfWTN7fo=; b=25Fb6O6bmOcOzzcJl+h1xggYHYrPIMTNLwDCQaN9hYGSZ6o8bA5HbVqWjZ+jmGEpHI5X1W9nlus4pYO+/ccopmfHbCJMrWJGApVRfUe2+hUtV2NX9PKOad9ujBjJPHjOS8KAUPhi5FCfqFC1HdD/A1OcKykIcCxY9JzM4vF/0yJeQCQil66fivWw3iRttwMxFYgeb0zsqz4P9SpyJ8ALfosQl27jG3DkXz8mbD/uzsRjM+X+8cRI/xu7CVlw1VyB DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1530.596f00d7.k1707; olt=johnl-iecc.com@submit.iecc.com; bh=Gb8kql2ow7PjbRBs8OiBJ/TasOsx9+IGT4pzfWTN7fo=; b=JN/phORGqLqtNkJB3/HbkOhk/KGpX9MEZ4PvPeZQGoQ0BfczxK95e9Mj7aTq4byoxcH94Dpc/Cbegm9QdSKXmNzAaDGRhEoe6k90YAXRsTfIgON/Ct9ZSFQiT1mQE0tyD3h4lJvdF8kPO9OEMRs/zFof+UJUwL+xO++3s1RThoVW5YKH5/v7OvZ9YbKvrDHMXRbPB7ImGoX6R49l+WNAtCvo2xA4rjRlFUCRcJeEXlmJWYnGpv6LHVDibeIjhBoB Received: from IPv6:2001:67c:1232:144:394e:5c5f:4f9:68ac ([IPv6:2001:67c:1232:144:394e:5c5f:4f9:68ac]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2/X.509/AEAD, johnl@iecc.com) via TCP6; 19 Jul 2017 06:48:54 -0000 Date: 19 Jul 2017 08:48:49 +0200 Message-ID: From: "John Levine" To: "Salz, Rich" Cc: "Murray S. Kucherawy" , dcrup@ietf.org X-Android-Message-ID: In-Reply-To: <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 06:48:58 -0000 PGRpdiBkaXI9J2F1dG8nPkkgc3VwcG9zZSwgYnV0IHRocmVlIG9uZS1wYWdlIFJGQ3Mgc2VlbSBv ZGQuIEhvdyB0byB1c2UgZWQyNTUxOSBpcyBsaXRlcmFsbHkgdHdvIHNlbnRlbmNlcy48YnI+PGJy PjxkaXYgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+QXV0b2NvcnJlY3RseSw8YnI+ Sm9objwvZGl2PjwvZGl2Pg== From nobody Wed Jul 19 00:47: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 2D6B7131C05 for ; Wed, 19 Jul 2017 00:47: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, 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 ZrDQWE_evR8X for ; Wed, 19 Jul 2017 00:47:37 -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 40204131BFD for ; Wed, 19 Jul 2017 00:47:37 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id f68so6107147vkg.2 for ; Wed, 19 Jul 2017 00:47:37 -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=+lldZpi7wxF7La80iYqNX+LU8zejzAa0x6Fp2VX1lfI=; b=TKqQA+UezhizJfVjEGJezFHWpVdQ8v+Uvqbk/saCj3zBV8n8Ev+C6ZVTInFL6FyLxx 48YljzUwgpvL2X56QINM0OwGtPm+OwXg+NWjU+rnzybGyLSgoavbCADX7z8Z0VlVdZYa Y4DE20c6Ilb8Bc8b/5VM+iHP81Fr8yQ9fzmGI= 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=+lldZpi7wxF7La80iYqNX+LU8zejzAa0x6Fp2VX1lfI=; b=DBGb4gShFFHPVSZj50v1S0xvGb16l/yvUMSohzKjhHGiFW7TvKkI9llBNfLFcaPBAe nMCg4yHDztMGljgR+CGu/i6NwfPMgqa542pcpTR+v/yJIVSB5rdn84DbCZneNfM4ij3G 7+dzq3IUfXSXpOn+iPtVSsiaIvVZHa39HxGmvdfxhOfEyRq7lYV0XfsauaEjAS/rAum0 VIkOWMaBpuOUI56WHeXJB+rHdVW8Z2Jb0gjhoGacXdgCgV/AaBq+WA1vuUABeaorFvlV ke78fjM60rVoyd5jLEI4SUUAu+1WF/QoIYcLYG5I6VumOBS9htkF4dPjCklYp6yacpzv YHPg== X-Gm-Message-State: AIVw111TdlhaNs2xtYYC5/nuphtdlnuWogqRSrMlcvTU1e0DoHBSmvxY CvoRGLuFBcPxp4oCS9r1gkFsdsavu5cA X-Received: by 10.31.220.199 with SMTP id t190mr835663vkg.132.1500450456097; Wed, 19 Jul 2017 00:47:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Wed, 19 Jul 2017 00:47:35 -0700 (PDT) In-Reply-To: References: <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> From: Kurt Andersen Date: Wed, 19 Jul 2017 09:47:35 +0200 Message-ID: To: John Levine Cc: "Salz, Rich" , dcrup@ietf.org, "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary="94eb2c07cc7e706b040554a6d88b" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 07:47:39 -0000 --94eb2c07cc7e706b040554a6d88b Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 8:48 AM, John Levine wrote: > I suppose, but three one-page RFCs seem odd. How to use ed25519 is > literally two sentences. > A significant part of it is to facilitate change tracking for the IANA registries. That's an insight that I discovered in the hallway conversations earlier this week. --Kurt --94eb2c07cc7e706b040554a6d88b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 19, 2017 at 8:48 AM, John Levine <johnl@taugh.com> wro= te:
I suppose, but thre= e one-page RFCs seem odd. How to use ed25519 is literally two sentences.

A significant part of it is to facilita= te change tracking for the IANA registries. That's an insight that I di= scovered in the hallway conversations earlier this week.

--Kurt=C2=A0

--94eb2c07cc7e706b040554a6d88b-- From nobody Wed Jul 19 00:58: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 C5605131C14 for ; Wed, 19 Jul 2017 00:58:12 -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, 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=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 QooQ1jQAZUiw for ; Wed, 19 Jul 2017 00:58:08 -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 C8490131C18 for ; Wed, 19 Jul 2017 00:58:08 -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 v6J7uvGA020287; Wed, 19 Jul 2017 08:58:06 +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=tm6pMw34HQoHGpO1isTTR+I0BXtLRkmArzY6oSmGpko=; b=IKgSlFyBLXUtSzMAhO0rQsAAtCtSxlPEf85Ow6jva7j+NQ6GHQp8xUw+Y8d3x/3II7wc ywJAg8tH0/MymQQShFQaXXNGanKSs69VzOnQQ4nGsVPkM0GPcUObvshHmUpPqKPNhYgH eDC8yJqohZtbav53QG2tRB5QrDXFhJ3cRRKGT04DjLT41aScEU01+a4n8mFE78xzK7lb ABEoo8U0z623sOhAKitdN5ZgmaPOgcK+aTtpUZ1Z+8eSLpgTLqofblEnhMhk76o0/w5u wnGq3tsCmjpfE+ZzcglJxmq6pXv69czqNg8XZw2G3KMHqWfUBDXBoG1QeFa1CPbu1x8K Wg== 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 2bt1abrcxp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 08:58:06 +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 v6J7tk6x011306; Wed, 19 Jul 2017 03:58:05 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bqecuuawn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 19 Jul 2017 03:58:05 -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; Wed, 19 Jul 2017 03:58: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, 19 Jul 2017 03:58:04 -0400 From: "Salz, Rich" To: Kurt Andersen , John Levine CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress Thread-Index: AQHS/9WxWe7hhT9Q6EOs+TNN7dMnKqJaPTmA///joCCAANiwgIAAEGuA//+9sBA= Date: Wed, 19 Jul 2017 07:58:04 +0000 Message-ID: <475b1097dc6e409287c28a1ed07c1a2f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> 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.153.3] 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-07-19_05:, , 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-1706020000 definitions=main-1707190131 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-19_05:, , 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-1706020000 definitions=main-1707190132 Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 07:58:13 -0000 Sm9obiBMZXZpbmU6DQo+SSBzdXBwb3NlLCBidXQgdGhyZWUgb25lLXBhZ2UgUkZDcyBzZWVtIG9k ZC4gSG93IHRvIHVzZSBlZDI1NTE5IGlzIGxpdGVyYWxseSB0d28gc2VudGVuY2VzLg0KDQpLdXJ0 IEFuZGVyc2VuOg0KPiBBIHNpZ25pZmljYW50IHBhcnQgb2YgaXQgaXMgdG8gZmFjaWxpdGF0ZSBj aGFuZ2UgdHJhY2tpbmcgZm9yIHRoZSBJQU5BIHJlZ2lzdHJpZXMuIFRoYXQncyBhbiBpbnNpZ2h0 IHRoYXQgSSBkaXNjb3ZlcmVkIGluIHRoZSBoYWxsd2F5IGNvbnZlcnNhdGlvbnMgZWFybGllciB0 aGlzIHdlZWsuDQoNCkkgYWdyZWUuDQoNCkknbSBub3Qgd29ycmllZCBhYm91dCAicHVzaGluZyB0 aGUgZWRnZXMiIG9mIHRoZSBSRkMgZm9ybWF0LiANCg== From nobody Wed Jul 19 01:11: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 22EC213167A for ; Wed, 19 Jul 2017 01:11:19 -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 (1536-bit key) header.d=iecc.com header.b=bR2Rjsrs; dkim=pass (1536-bit key) header.d=taugh.com header.b=lhEIa76f 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 6m09ZaYyFpeQ for ; Wed, 19 Jul 2017 01:11:12 -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 C378F131600 for ; Wed, 19 Jul 2017 01:11:12 -0700 (PDT) Received: (qmail 14526 invoked from network); 19 Jul 2017 08:11:11 -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=38bc.596f141f.k1707; bh=zIq7+RehrYZTaRrVxlp40HA1Vx5+7Xb79JzRBB5RO+Q=; b=bR2Rjsrs80Y/xc6dbVdUnD1uRvon6dWbZZ0KO6xbNL/K7//ECYIDSlLCo6FjsW3rvrlG4iXG2zYhPqxb9/iYD5qXStczQyY73CIImg6Pu9pyK55GKJ9U2zSJzm1SHAjczpaZYiw4YKyoPchC2h1OdIMQb4Y0yc8AaY/9mULxujlVjSoJvDcfaE7hxjbo8Fv+tMCmVN21/kF/0SmhWvVCCh54tZju/NtXevJQ9cEmdNzQd3E5UEH/LbiewoQpwlQ3 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=38bc.596f141f.k1707; bh=zIq7+RehrYZTaRrVxlp40HA1Vx5+7Xb79JzRBB5RO+Q=; b=lhEIa76fcL3QGfPJ2ao2zR8hyK3OM/n44RRAQM3AjWlej1m3HevzFq/XnZPXJ5U53DmMVKZr1LOSjrbDhTdQt6zT8USnu6lbMxwGsNSgSvPjmK1k7lgGMLzn9OdtZdi4bM2FT+FAaSPWy9xUEPCf/MmzlWEIuFElIevAztWQk4TE7HsQHoZzaQANosPMVungQzbRCd3F29g7YrmU/86W7ko6OfIC3FiWKKTW/oAV62L1EXnlyYN2OlVNmQK6uZSW 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; 19 Jul 2017 08:11:11 -0000 Date: 19 Jul 2017 10:11:11 +0200 Message-ID: From: "John R Levine" To: "Kurt Andersen" Cc: dcrup@ietf.org In-Reply-To: References: <16b2e791889d441f9ef5ef00b4cffb27@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] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 08:11:19 -0000 > >> I suppose, but three one-page RFCs seem odd. How to use ed25519 is >> literally two sentences. > > A significant part of it is to facilitate change tracking for the IANA > registries. That's an insight that I discovered in the hallway > conversations earlier this week. Oh, we certainly have to say the two sentences. The question is whether they should be bulked up into a separate document. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jul 19 01:31: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 D59EE131C28 for ; Wed, 19 Jul 2017 01:31:45 -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 BW7jMPx5hxq5 for ; Wed, 19 Jul 2017 01:31:44 -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 70638131C1E for ; Wed, 19 Jul 2017 01:31:44 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 35so45008845uax.3 for ; Wed, 19 Jul 2017 01:31: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=JbNuW1CpgPPm1c3cdtVSVYkw0Doqet8ugwuFbZrbwSs=; b=aeUIdn3RNmzqEd4DXqtlExpiX9HY1jVXiMfGE2UXB6ahfEPV4kPyoV58tL4htYuIFJ yEM4WVA+9gwRW2bHBbEmQ7XXaTZ7C2JogMbPnqAurjw99cMNXRjnk+TWwgK9egeicCOJ b+9skqcdXnuHrBcpgNDFqsq5cYvNkb+HlOIeRzHjWi9PPwpMjYLt17O4J/meHP+nmpQU i2lzGLraBPrq3JKydn5GX89jYpPVOqwjmE9b6A6uysReL5FLzmULDv1Qn9ZK2bSKiHHQ yyJQDL/phXkvbrorwsdbtrmgboQwPQ+SAGR/a4SEIPen8mEeGV5SGOy8FGe40tsJ7YLH cYsg== 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=JbNuW1CpgPPm1c3cdtVSVYkw0Doqet8ugwuFbZrbwSs=; b=gi4yhZZXiDImQZtHS5wToPFBg1wu7GCeEME3D6kyK9eDMBzJe6OEdPdRrXkbJRTKnK ck5D7IB8f2AzLyh8YDGksL4sH2vLXNMvB3dlCvXG++j07S489i2MiYIMjWh/BIvWduTr acz/tS1ys88vVApKwBNnJAzNl4ON9GfQcCzmjnyUiMjRNLxGGkObyORDDlgrvlJkG1yd x57Nf+t1Kt4s2XsotbNoSBJnWgODOMOhwDaq6+N2I34p3szl9iTufoFo4pRF7IEiPtIY lLvnXxfoc2dC3XrKTcWsFDbYpHYpQZJulEU0/nNT37C4aj4oYB437sfEQlhtYmTJQyQG CR6w== X-Gm-Message-State: AIVw111KH34hPfNU0MgNqE9O334Fn1VJ35A0JVwpVg4ZO9ud6PufOMQD tHf8yfwikkv41hHCJc11Hgeb1UCNhA== X-Received: by 10.176.64.164 with SMTP id i33mr1036108uad.55.1500453103616; Wed, 19 Jul 2017 01:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 19 Jul 2017 01:31:43 -0700 (PDT) In-Reply-To: References: <20170718193449.14371.qmail@ary.lan> <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Murray S. Kucherawy" Date: Wed, 19 Jul 2017 10:31:43 +0200 Message-ID: To: Kurt Andersen Cc: "Salz, Rich" , "dcrup@ietf.org" , John Levine Content-Type: multipart/alternative; boundary="94eb2c1235de3e4aa40554a77696" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 08:31:46 -0000 --94eb2c1235de3e4aa40554a77696 Content-Type: text/plain; charset="UTF-8" As for why make this three documents: On Wed, Jul 19, 2017 at 6:40 AM, Kurt Andersen wrote: > On Wed, Jul 19, 2017 at 6:01 AM, Murray S. Kucherawy > wrote: > >> On Tue, Jul 18, 2017 at 11:55 PM, Salz, Rich wrote: >> >>> I would like to see >>> 1. One document that says don't use SHA1 and do use larger RSA key >>> sizes; this exists >>> >> That's ready to go, because there's no change to operation at all in terms of new code. > 2. One document that talks about how to put key identifiers/key digests >>> into DNS records and how to put them in DKIM data >>> 3. One document that says how to use Ed25519 signatures (per the EdDSA >>> RFC) for DKIM data >>> >> Both of these involve new code that we haven't tried yet at any scale that I know of. I would really (repeat several times) like not to drive those to publication until the "haven't tried yet" goes away. I don't think we need to hold up the first one while we get at least trivially comfortable with the other two. -MSK, participatin' --94eb2c1235de3e4aa40554a77696 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As for why make this three documents:

On Wed, Jul 19, 2017 at 6:40 AM, K= urt Andersen <kurta@drkurt.com> wrote:
On Wed, Jul 19, 2017 at 6:01 AM, Murray S. Kuche= rawy <superuser@gmail.com> wrote:
On Tue, Jul 18, 2017 at 11:55 PM, Salz, Ri= ch <rsalz@akamai.com> wrote:
I would like to see=
1. One document that says don't use SHA1 and do use larger RSA key size= s; this exists

That's ready to go,= because there's no change to operation at all in terms of new code.=C2=A0
2. One document that talks about how to put key identifiers/key digests int= o DNS records and how to put them in DKIM data
3. One document that says how to use Ed25519 signatures (per the EdDSA RFC)= for DKIM data

Both of these involve n= ew code that we haven't tried yet at any scale that I know of.=C2=A0 I = would really (repeat several times) like not to drive those to publication = until the "haven't tried yet" goes away.

I = don't think we need to hold up the first one while we get at least triv= ially comfortable with the other two.

-MSK, pa= rticipatin'
--94eb2c1235de3e4aa40554a77696-- From nobody Wed Jul 19 01:39: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 A0186131C2D for ; Wed, 19 Jul 2017 01:39:34 -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 (1536-bit key) header.d=iecc.com header.b=HuCb2LwC; dkim=pass (1536-bit key) header.d=taugh.com header.b=BzOeazkg 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 hUYmHDknkme0 for ; Wed, 19 Jul 2017 01:39:33 -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 47CA0131C2C for ; Wed, 19 Jul 2017 01:39:33 -0700 (PDT) Received: (qmail 34060 invoked from network); 19 Jul 2017 08:39:32 -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=850a.596f1ac4.k1707; bh=qWTeMLAlwV5SrtWUbekmw/lBOhjs50b8bn/6aQFgJQE=; b=HuCb2LwCJAyDAVw28qaUd8qS084vXY79PYGFBsK4k+65WIsmD6/Tw7njsfWRYITNp+ThCEq3Ip5iL44imuObQhn7PASCrIx4a4s/4hZAni7XayNYYMUKt333e7fkItVYYmO8TFtPjufbq1uantHu4QtL6DahUa+nMPQ2RnklHKTzF5I71y6lbqQIIvzZL0tDm24U4tiaNTwL4blQeoqIVp0TwrFaxhmScVf6ShdiPt6Jy9bE5TKv2mGZTqrE/Qao 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=850a.596f1ac4.k1707; bh=qWTeMLAlwV5SrtWUbekmw/lBOhjs50b8bn/6aQFgJQE=; b=BzOeazkg+ZvI9It2AqpPxwfuv/S0EJx6CXd84fpHqIm54hW+co+V7iW3I9HPNJ7qktupblIHuwueHwb59MqXBiXg/zj/mRxP/8I8/OpsBursfZOA0zWVHgLoHnm9QG8TEDW5c+mG8LeDbguikrCS+7HuzIxUfwBy7b7eT3N/RZiid4pub085ih9If1pNGsCiBvdmDvWUQhPrCVz5Ahb2o2tBE98w/hMYNDXxrwJFHIwlmsAaru8JG4mTz37f1NMM 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; 19 Jul 2017 08:39:32 -0000 Date: 19 Jul 2017 10:39:32 +0200 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" Cc: "dcrup@ietf.org" In-Reply-To: References: <20170718193449.14371.qmail@ary.lan> <16b2e791889d441f9ef5ef00b4cffb27@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] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 08:39:35 -0000 > Both of these involve new code that we haven't tried yet at any scale that > I know of. I would really (repeat several times) like not to drive those > to publication until the "haven't tried yet" goes away. > > I don't think we need to hold up the first one while we get at least > trivially comfortable with the other two. Part of my thinks that since we've been deprecating SHA-1 for a decade, another month or two until we drive in the final stake isn't going to matter, but whatever. When I get home I'll see about putting the the new stuff into the perl library I use. I gather Scott's already doing stuff to the python one. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Wed Jul 19 02:21: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 0BE76131C56 for ; Wed, 19 Jul 2017 02:21:31 -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 VwfvOnTJ2l5t for ; Wed, 19 Jul 2017 02:21:29 -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 9F3F9131C50 for ; Wed, 19 Jul 2017 02:21:29 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id f68so7174530vkg.2 for ; Wed, 19 Jul 2017 02:21:29 -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=uF94eoP0QXnL8LxlNiyeQ+QdaBEfBidSkqBMxIXFL2Q=; b=EBmp0ueXurjp/JVtI3T/2kL2+gQ2kYEIEsVKgAVM4fw5V3223RIFcLmmxwreV+24/s RFqyyTakiZOSpwIk5KlvwRCytQcrkYpekt3mRVtLEl17H4V1Ca105UIezV9fneTdcYem CngtCOrRN9WFA+LaNZPzVbjvvy1lacbFumTkcgnOAZz0XjV+sgzpqPOzZdk6eHTMu2dx DMEBzAInEqMIZzMKwfM6eHgAjsCCTDCJS/eEYmE2juCogyr3xGZsRRSc7AV70yuA3+1N hzldZtMo+ACL7dVgs8chOEOYfZIYGoyc9pDg77TdqjBaJy+dBvt7Lg01AjVx19DdDMiu iEtw== 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=uF94eoP0QXnL8LxlNiyeQ+QdaBEfBidSkqBMxIXFL2Q=; b=paMzyC59NqGOv8LEPkBD7KqcHZvYcnjRAB2g/kqMy57TLXYI82EV161c2sg7+3dKZ8 3cw2TLiiyXZMEXEmhq56GG960zDsn/NzzNrDmitZbKTRuu4CKR4QYv8q7vmpubrIf3u/ McLl3BkPbc5ohxwgyNU8NWPWY6WC87OGXlGKB1LzZ2BeXdBZpDUn2ipSosr07/dQghMY SirYK7m2tXGTyiHDRF6dVTG7YaTypdsHIYs7dMlMgbcwaHGGfqFRi84ZPJgz0Efi57DL lR4FEI6uuzIeZMULoXkK9lt30dIT72m64+ehF6qN8qDy3kTiTsUcGcYMbMN4GOeEalQS Pa/A== X-Gm-Message-State: AIVw112fGrTe2D5UIQNDYba7og5IkXSL+zIS09cc+fyJPOfkZjoJi4Vk gPvULyhRtzrQyc8e+vifr4cDnLscJR+9 X-Received: by 10.31.49.136 with SMTP id x130mr996844vkx.125.1500456088819; Wed, 19 Jul 2017 02:21:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.126.196 with HTTP; Wed, 19 Jul 2017 02:21:28 -0700 (PDT) In-Reply-To: References: <20170718193449.14371.qmail@ary.lan> <16b2e791889d441f9ef5ef00b4cffb27@usma1ex-dag1mb1.msg.corp.akamai.com> From: "Murray S. Kucherawy" Date: Wed, 19 Jul 2017 11:21:28 +0200 Message-ID: To: John R Levine Cc: "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="001a114386ae2cdc570554a82803" Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 09:21:31 -0000 --001a114386ae2cdc570554a82803 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 19, 2017 at 10:39 AM, John R Levine wrote: > Both of these involve new code that we haven't tried yet at any scale that >> I know of. I would really (repeat several times) like not to drive those >> to publication until the "haven't tried yet" goes away. >> >> I don't think we need to hold up the first one while we get at least >> trivially comfortable with the other two. >> > > Part of my thinks that since we've been deprecating SHA-1 for a decade, > another month or two until we drive in the final stake isn't going to > matter, but whatever. > > When I get home I'll see about putting the the new stuff into the perl > library I use. I gather Scott's already doing stuff to the python one. > I should be able to hack the fingerprinting into OpenDKIM in short order. -MSK --001a114386ae2cdc570554a82803 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 19, 2017 at 10:39 AM, John R Levine <johnl@tau= gh.com> wrote:
Both of these involve new code that we haven't tried yet at any scale t= hat
I know of.=C2=A0 I would really (repeat several times) like not to drive th= ose
to publication until the "haven't tried yet" goes away.

I don't think we need to hold up the first one while we get at least trivially comfortable with the other two.

 Part of my thinks that since we've been deprecating SHA-1 for a decade,= another month or two until we drive in the final stake isn't going to = matter, but whatever.

When I get home I'll see about putting the the new stuff into the perl = library I use.=C2=A0 I gather Scott's already doing stuff to the python= one.

I should be able to hack the fing= erprinting into OpenDKIM in short order.

-MSK
<= /div>
--001a114386ae2cdc570554a82803-- From nobody Wed Jul 19 03:43: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 C1E82131C63 for ; Wed, 19 Jul 2017 03:43:43 -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 8zOovbK76dcG for ; Wed, 19 Jul 2017 03:43:42 -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 20120131C8B for ; Wed, 19 Jul 2017 03:43:42 -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 29C1BC403A8; Wed, 19 Jul 2017 05:43:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1500461019; bh=1KInHZ1y2aylKE1SckuJzbQBz1r4qulFTwLYAUt68L0=; h=Date:In-Reply-To:References:Subject:To:From:From; b=DF3IWk9m9ALFmeHb75MRNHVPv3inOoDVFnWDeA3B+wrECefsmHjFRuCRINDRfsWSt sxtwpU4cMgpdFhuMNIMSiOeYhI3xbyGjOZGrrO+jUfV5gZ18AA3Ksw4JVOsrUO05+l EGQrOIvFvybfaivGtqIulyMHmB+VSAHYjghzY4Yg= Date: Wed, 19 Jul 2017 10:41:41 +0000 In-Reply-To: References: <20170718193449.14371.qmail@ary.lan> <16b2e791889d441f9ef5ef00b4cffb27@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: <189FCD44-F292-46CF-BFCF-D66CFB2C8764@kitterman.com> Archived-At: Subject: Re: [Dcrup] draft-ietf-dcrup-dkim-usage review and progress 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, 19 Jul 2017 10:43:44 -0000 On July 19, 2017 4:39:32 AM EDT, John R Levine wrote: >> Both of these involve new code that we haven't tried yet at any scale >that >> I know of=2E I would really (repeat several times) like not to drive >those >> to publication until the "haven't tried yet" goes away=2E >> >> I don't think we need to hold up the first one while we get at least >> trivially comfortable with the other two=2E > >Part of my thinks that since we've been deprecating SHA-1 for a decade, > >another month or two until we drive in the final stake isn't going to=20 >matter, but whatever=2E > >When I get home I'll see about putting the the new stuff into the perl=20 >library I use=2E I gather Scott's already doing stuff to the python one= =2E I started, but then got overwhelmed with paid work before I produced anyth= ing useful=2E I will get back to it, but it's not imminent=2E Scott K From nobody Thu Jul 20 01:23: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 7076E129B55 for ; Thu, 20 Jul 2017 01:23:16 -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 rY7RhSi0D0lc for ; Thu, 20 Jul 2017 01:23:15 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002: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 33CE2127337 for ; Thu, 20 Jul 2017 01:23:15 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id a12so9930038ywh.3 for ; Thu, 20 Jul 2017 01:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=R/PL4xQ6/Xl5w3ZHSIBekvw63iRmNHIxuQISfXKmb5c=; b=z4S+Rz+U072+QqQjl+I+e/MsRjxC2CDqvW2oN9bVA/5PUinPT5VeaqYhw3tblHRgqs NDG48cWIfUlnJ2P2VDxEsDq0z/xYBf+BixQ8iVjtlMhFi+urQTTcgGfCC5u/WXFdAkOG +DBwegpE7KHA6ckaZZTigj79MA5yrio7YKCzP8wvJ5+0+JtxKhAcA5PqRRb8QUDHbJOE jvGFgy5NAIrisSzN03raV6QAXDZx34/KDxUaPCe/d6tEGN9LiUI7L4xW9wLbN+/Zw0io 2NAmxog/5WrtPndkEKRmjXzUAXdyxRzSgECB5Wh7sFTckyfM7oKU2nQX1Vhl/Hvn+ZRs 2Zkw== 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=R/PL4xQ6/Xl5w3ZHSIBekvw63iRmNHIxuQISfXKmb5c=; b=lZfJkm0Xv7fwqBCnOYg9e3fY0+OsG81cq4RL2UUFaQRXrdaRb4eQJDkUNMBb4FT/bC uJPx8VrxG2NHvLA0EuNJaiHVPRo3i7CE/LMtT1HtdugtxqDPVDkI6ex61nd7KtA2iKt0 Z6lja2wMcm3u2vOb3aum5h7gvA2kH0cgi4whIEUQ6LbKqdJj4LQUEQatkGkIjbwBkWHS GxDQhhrL6t/kL2ECnqdeyycoseaTqHZ+vUfYo+f5yOzbXaWxgmvGL08HA40zzwSwXP8w QHw5d27NhdtMqbm3Tik7P/Xy4TKhNEDrlpHZRx7sqI6hLz18l3rSb1zKo9wYzK/QET/b zQKA== X-Gm-Message-State: AIVw113FHJOK/BkoiwUJ2dUSTxySmPAaiBvq5zHEatfYMXaVTJznnfCy M1F6fBAiP7zDj+4IcMRP+i+q9MhvgK2HLLG58A== X-Received: by 10.13.223.141 with SMTP id i135mr1756533ywe.37.1500538994331; Thu, 20 Jul 2017 01:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Thu, 20 Jul 2017 01:22:33 -0700 (PDT) From: Eric Rescorla Date: Thu, 20 Jul 2017 01:22:33 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114e407ebaa8ee0554bb75b4" Archived-At: Subject: [Dcrup] Naming in draft-ietf-dcrup-dkim-crypto 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, 20 Jul 2017 08:23:16 -0000 --001a114e407ebaa8ee0554bb75b4 Content-Type: text/plain; charset="UTF-8" I note two issues on how things are named in this draft: 1. The algorithm is named eddsa-sha256 (presumably by analogy to RSA), but the primary key here is the curve size, not the hash, so it should be named "eddsa25519" or "ed25519", as the keys themselves are not self-describing except by looking at the length, which is ungood. 2. For the same reason, the key label in the DNS should probably be "eddsa25519" or "ed25519". -Ekr --001a114e407ebaa8ee0554bb75b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I note two issues on how things are named in this draft:
1. The algorithm is named eddsa-sha256 (presumably by ana= logy to RSA), but
the primary key here is the curve size, not the= hash, so it should be named
"eddsa25519" or "ed25= 519", as the keys themselves are not self-describing
except = by looking at the length, which is ungood.

2. For = the same reason, the key label in the DNS should probably be
&quo= t;eddsa25519" or "ed25519".

-Ekr




--001a114e407ebaa8ee0554bb75b4-- From nobody Thu Jul 20 02:21: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 723F0126B72 for ; Thu, 20 Jul 2017 02:21:44 -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=unavailable 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 A_RqP0AOyrUR for ; Thu, 20 Jul 2017 02:21: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 B3F5412FB9C for ; Thu, 20 Jul 2017 02:21:40 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 35so18563038uax.3 for ; Thu, 20 Jul 2017 02:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:from:date:message-id:subject:to; bh=Ayu05NtVhQtnMCWsoePng3HTcTrnMK49+4w83Kyu7rw=; b=fqF7Pa5eb7e87nRoPtDA8xcWyKd4i2JGH8QgV8Ws/5qRHTF48LvOMHR+tmqVWEU54e 1O0vV/Ml2pEnEUcPoDzTxqU//MNHRzsNKJ00YJYL7phs6W1qd7XBdJpIUYB3hKbYoPYy k9Hp9qAwXoYFTDUYEh7K9g1v8bMbYbw8zMsZg= 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=Ayu05NtVhQtnMCWsoePng3HTcTrnMK49+4w83Kyu7rw=; b=Pb47oHvpCDi821D6x1zlAuhJX7lWYyICtSNfe2Fo++wu4X1jnMEOAvmnVVb59cJoaL TCAgNPiUVf89174ZHblM72IvsUqw52bBEA5KmbT1kkOj3snkYbQ2pgKpZD8GwkZ/u/w4 ynTJf7aJyvBhgUjKroZjG5tCRZrpS2vk6nHWd14rG2uj4bhp5rBBvrhYHB8IXufE769U uCCNXanoGUmDMaPh0oFMB+Rb3Svs2Ru25ERVy2yBUuNWgVEUGerAD1xsCIVCFCDgThhR bx301CLg+1FWs0EXZDpvsnFJcT09m7kXoGXoeF0eEKu2ok9lX8wzJftniT6yDvqrhG+8 j3tg== X-Gm-Message-State: AIVw110LpZTt9WnHLCxlyuPlKx8xcJske35vRD++Kea2rMnYdbD+uK5c 2AANV3F/k9hmHGOoZorYP7tnV6/x3w2/sGduQA== X-Received: by 10.31.206.5 with SMTP id e5mr1308355vkg.178.1500542499314; Thu, 20 Jul 2017 02:21:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.26.39 with HTTP; Thu, 20 Jul 2017 02:21:38 -0700 (PDT) From: Kurt Andersen Date: Thu, 20 Jul 2017 11:21:38 +0200 Message-ID: To: dcrup@ietf.org, dcrup-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a114e61d2a474b10554bc4646" Archived-At: Subject: [Dcrup] Notes from IETF99 dcrup meeting 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, 20 Jul 2017 09:21:44 -0000 --001a114e61d2a474b10554bc4646 Content-Type: text/plain; charset="UTF-8" (Apologies in advance for any names that I've mis-attributed) charter tweak - in flight John - hashing the key one open tech question: adding new signing ways one is to do hashing of keys straightforward to accomplish this add elliptic curves ED25519 open question: should we add the hash for EDDSA sigs? since there is no operational benefit, why do this? Martin Thomson - Potential benefit - by signing the public key in a header, it is possible in some situations to synthesize a key that will validate PHB - some games can be played with keys, has been a proponent of hashes, but don't think that they really provide benefit need some tooling to manage the hashes just wants to post the pub key into DNS Ynir - why not just do curves and not hashing? EKR - Martin's concern is key replacement in the zone the most consistent thing in the future is to always hash, but may not be critical MT - the future is bigger than the past a little concerned about signing over the key, but general EKR - don't have two versions of EDDSA pref order: hashed always/hash RSA only/non-hashed MT - post-quantum may require hashed keys regardless Rich : please post concerns about key swap to the list PHB - may very well be looking at all standards to be revised in post-quantum world MT - note to the list about preferring hashing ratholed; don't miss the other points that were raised in flight EKR - names --> take it to the list Scott - dkim usage raise the floor to 1024, deprecate sha1 updates ABNF pretty close to last call MT - concerns: PSS? don't do it here in the doc why does it take 5 pages to do two simple things? cut the text out which is copied from the DKIM RFC don't modify the ABNF - point taken EKR - what are the security properties? recapping sha1 attacks discussed on the list when should we advise receivers to stop accepting sha1? put into the security considerations: EKR accepted action need to move sha1 to historic in IANA - put into Scott's draft Barry - discussing "should (plus)" (from the room: don't go there) John - stopping acceptance is largely an operator evangelization issue Kurt - having this draft in flight has been beneficial to getting 3 largest senders of SHA1 to change Chris - must check key size should be added MT - doc should just say "MUST NOT" (send or accept) provides a good hammer to get change done PHB - objects to saying MUST NOT accept (only one in room) for message validity yes, it matters useful to follow appropriate phasing Seth - in 2007, sounded like "SHOULD NOT" - didn't move the needle "MUST NOT" was needed to get people to move MT - want the headline Rich - timetable is important vendors hate "MUST NOT implement" "MUST NOT use" is better andreas - should is justify to not change hums: for +++; against: +; need more info: barely Barry: did we just vote? Jim on jabber: too soon for MUST NOT accept Alexey - we got a sense of the room, but go to the list Scott Rose - doesn't think PC256 ECDSA is needed EDDSA should be sufficient when it gets into FIPS proposing to kill the doc --001a114e61d2a474b10554bc4646 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Apologies in advance for any names that I've mis-attr= ibuted)

charter tweak - in flight
John - hashing the key
=C2=A0 =C2=A0 one open tech question:=C2=A0
=C2=A0 =C2=A0 adding new signing ways=C2=A0
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 one is to do hashing of keys
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0 straightforw= ard to accomplish this
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 add elliptic curves ED25519
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 open question: should we add th= e hash for EDDSA sigs?
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 since there = is no operational benefit, why do this?
=C2=A0 =C2=A0 Martin Thomson - Potential benefit - by signing th= e public key in a header, it is possible in some situations to synthesize a= key that will validate
=C2=A0 =C2=A0 PHB - some games can be played with keys, has been= a proponent of hashes, but don't think that they really provide benefi= t
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 need some tooling to manage the= hashes
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 just wants to post the pub key = into DNS
=C2=A0 =C2=A0 Ynir - why not just do curves and not hashing?
=C2=A0 =C2=A0 EKR - Martin's concern is key replacement in t= he zone
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 the most consistent thing in th= e future is to always hash, but may not be critical
=C2=A0 =C2=A0 MT - the future is bigger than the past
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 a little concerned about signin= g over the key, but general=C2=A0
=C2=A0 =C2=A0 EKR - don't have two versions of EDDSA
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 pref order: hashed always/hash = RSA only/non-hashed
=C2=A0 =C2=A0 MT - post-quantum may require hashed keys regardle= ss
=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Rich : please post concerns abo= ut key swap to the list
=C2=A0 =C2=A0 PHB - may very well be looking at all standards to= be revised in post-quantum world
=C2=A0 =C2=A0 MT - note to the list about preferring hashing rat= holed; don't miss the other points that were raised in flight
=C2=A0 =C2=A0 EKR - names --> take it to the list

Scott - dkim usage
=C2=A0 =C2=A0 raise the floor to 1024, deprecate sha1
=C2=A0 =C2=A0 updates ABNF
=C2=A0 =C2=A0 pretty close to last call

=C2=A0 =C2=A0 MT - concerns: PSS? don't do it= here in the doc
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 why does it take 5 pages to do = two simple things?
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 cut the text out which is copie= d from the DKIM RFC
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 don't modify the ABNF - poi= nt taken
=C2=A0 =C2=A0 EKR - what are the security properties?=C2=A0
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 recapping sha1 attacks discusse= d on the list
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 when should we advise receivers= to stop accepting sha1?
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 put into the= security considerations: EKR accepted action
=C2=A0 =C2=A0 need to move sha1 to historic in IANA - put into S= cott's draft
=C2=A0 =C2=A0 Barry - discussing "should (plus)" (from= the room: don't go there)
=C2=A0 =C2=A0 John - stopping acceptance is largely an operator = evangelization issue
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 Kurt - having this draft in fli= ght has been beneficial to getting 3 largest senders of SHA1 to change=C2= =A0
=C2=A0 =C2=A0 Chris - must check key size should be added
=C2=A0 =C2=A0 MT - doc should just say "MUST NOT" (sen= d or accept)
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 provides a good hammer to get c= hange done
=C2=A0 =C2=A0 PHB - objects to saying MUST NOT accept (only one = in room)
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 for message validity yes, it ma= tters
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 useful to follow appropriate ph= asing
=C2=A0 =C2=A0 Seth - in 2007, sounded like "SHOULD NOT"= ; - didn't move the needle
=C2=A0=C2=A0 =C2=A0=C2=A0 =C2=A0 "MUST NOT" was needed= to get people to move
=C2=A0 =C2=A0 MT - want the headline
=C2=A0 =C2=A0 Rich - timetable is important
=C2=A0 =C2=A0 vendors hate "MUST NOT=C2=A0implement"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "MUST NOT=C2=A0use" is bet= ter
=C2=A0 =C2=A0 andreas - should is justify to not change
=C2=A0=C2=A0 =C2=A0
=C2=A0 =C2=A0 hums: for +++; against: +; need more info: barely<= br>
=C2=A0 =C2=A0 Barry: did we just vote?
=C2=A0 =C2=A0 Jim on jabber: too soon for MUST NOT accept
=C2=A0 =C2=A0 Alexey - we got a sense of the room, but go to the= list
=C2=A0=C2=A0 =C2=A0
Scott Rose - doesn't think PC256 ECDSA is needed
=C2=A0 =C2=A0 EDDSA should be sufficient when it gets into FIPS<= br>
=C2=A0 =C2=A0 proposing to kill the doc
--001a114e61d2a474b10554bc4646-- From nobody Thu Jul 20 03:31: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 5BF97131A92 for ; Thu, 20 Jul 2017 03:31: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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) 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 mp9sgQoTOlH6 for ; Thu, 20 Jul 2017 03:31:16 -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 77104131BFF for ; Thu, 20 Jul 2017 03:31:10 -0700 (PDT) Received: (qmail 5685 invoked from network); 20 Jul 2017 10:31:09 -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=1632.5970866d.k1707; bh=c2jr6PcF7Kp22TaRNlUmaHRZai0r+D5qe0wZ8Uvcrfs=; b=fbR451kMMD0URO0BpWtky+X7glS/CSZnLhuPlZPqFbCglrc6hlfmBY5S2YEopJyc1n2yyKmTSu2j0Gi7lpAIQ9jH4ycZDI86DPGPAWjKtD241FVKkNNoWbT9xOrCxJH0phGPf5TXvUSJPG+USyfg49aLntwtajn2n/yTYTc22lAi8J8ocLS9mx/KAoOXJtmVGAY2Kp43Tixz2hm+kqVCgL4oG9JasmVVTwdqwZE+z/BZUhJ/aI1PQguFtH9NrKlZ 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 Jul 2017 10:31:09 -0000 Date: 20 Jul 2017 12:31:07 +0200 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] hashing and privacy 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, 20 Jul 2017 10:31:17 -0000 On 11 July 2017 at 22:54, Eric Rescorla wrote: > My understanding is that (for RSA at least) given a message and > signature it is possible to create a key that will produce the same > signature. DKG pointed out that an easy way to divide the baby here is to make the k= tag optional for all signatures and mandatory for hashed ones. If you're worried about this attack, put the key in the dkim-signature header. If a verifier wants to check that it matches the key in the DNS, it can do so. R's, John From nobody Thu Jul 20 04:48: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 24B4D1315FF for ; Thu, 20 Jul 2017 04:48: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, 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 L4b-k1ae5F6U for ; Thu, 20 Jul 2017 04:48:04 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 C47D7131463 for ; Thu, 20 Jul 2017 04:48:04 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id a62so14830718itd.1 for ; Thu, 20 Jul 2017 04:48:04 -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=BgqlJGOXyOE+LCes7LCMS2oLVF1QXqnibaedNxfE8ZQ=; b=Eqrh+XXNqR4X2OVHvKSmzaeTcPs4mGOzpAYL+YsUwwoPFuTEAAorG7qydw8Z48hMDp O9YRHxCVxKIh7joho2LhOsiOBtBUZNaASHbRwf1B4r9cl0AI97Ov/oklMc5muMphGQFx 2Lf/MSxaDIaQdbC1PbuIb6gHksWS7b/lqgW6b81B0FHFGs6MRvJLzdLJYsqpDB3sgBxR 4aa5U6g1ruOD75aLdZGe304nsv59WExUDafkRHjOwb2xu/0pbhUnhIskliddq284czDT SaNLjQl4RrEDfISKKBonp4xF8jmIv3/3ASpOiNiWi7UDRd6r7Ia8MQsAKHAmS4zPKNIE Wg6Q== 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=BgqlJGOXyOE+LCes7LCMS2oLVF1QXqnibaedNxfE8ZQ=; b=Q0Ce7+YN3Ohx76Zi9xKmKv6lPdJL7f103EmPWmLJxGAsv5HHcbjUPkj5n5JLs6QnQU w91VAHk4R7CNSqxAIj6fQoSlXWscxybTtXYWWgrZ6k1hOy4As/qZpgQ+AjiJ61zc2hSM RdS2CsqUP0REJxnDMT7WIwpIUgKiH0dOPIkO7eZNAHfMnOd6dwct8Z6xq1e7U9H2Y/X6 s6JbkoDcFDk4sMWyUVGxuy9Uu2HMHesTUDFmvsOgSuKTMqWFGieIbOkqQfvlrjBxjxD5 SLeJsS5m7g5qxSlBvSwYa751M59KOOQQkV9w3c3C3ScgPm4vQ3st1uA67wngSz3KIviF 6xkA== X-Gm-Message-State: AIVw113tSGodzsxsYgShzyy5IwgLruuDrQx7AXF+rfSqZ5zSMk8LUshe SFQPoqRAfiIBWTvqzW9SjL8AhCtPx8dX X-Received: by 10.36.158.11 with SMTP id p11mr3099931itd.154.1500551284224; Thu, 20 Jul 2017 04:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.26 with HTTP; Thu, 20 Jul 2017 04:48:03 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 20 Jul 2017 13:48:03 +0200 Message-ID: To: "John R. Levine" Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] hashing and privacy 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, 20 Jul 2017 11:48:06 -0000 This is a fine suggestion. On 20 July 2017 at 12:31, John R. Levine wrote: > On 11 July 2017 at 22:54, Eric Rescorla wrote: >> >> My understanding is that (for RSA at least) given a message and signature >> it is possible to create a key that will produce the same signature. > > > DKG pointed out that an easy way to divide the baby here is to make the k= > tag optional for all signatures and mandatory for hashed ones. > > If you're worried about this attack, put the key in the dkim-signature > header. If a verifier wants to check that it matches the key in the DNS, it > can do so. > > R's, > John From nobody Thu Jul 20 10:50: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 414A8131D21; Thu, 20 Jul 2017 10:50: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=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 sFHGY2qbeC3k; Thu, 20 Jul 2017 10:50:38 -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 E2DF4131D20; Thu, 20 Jul 2017 10:50:38 -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 v6KHkW5q031282; Thu, 20 Jul 2017 18:50:38 +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=sOzMFFN3RGsquq4FnUKI0/65iq2XiVlo92/+OmXWiZw=; b=a+W6aiffHe4A97U87qCOZ07rZNtmT4HD4u2xtNYlDwfyPnVMUcspdMXtGNrixnUef1me dplqJsgAneLWFHzIZzouHQIn1LaurnKKUrChuiFljBzNkUFTDIVLRjugYRbQqSQaYN92 Et3P7mKgVkigPhRx7Fz/Xx+dm7NP/Y24lB/f8Y7+4I3Zv0wqvlJBVmR0QWw/AoCmZ8K7 dYP2r1AAWOwrhrI/MNSMXE0lYWvg+q4XOj9XmcTViJdavkQURVaIUw6mKTbegwIuiyrb AKLM7M3dhRkk2nL1jOcBNZPsoVy13oqJvbj7+kgqAcBLgw7pSbkerwQiQf0H/DEe5o/w Qg== 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 2bt1abykbm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 18:50:37 +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 v6KHje4g001718; Thu, 20 Jul 2017 13:50:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bqecuh47d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Jul 2017 13:50:36 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 20 Jul 2017 13:50:35 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 20 Jul 2017 13:50:35 -0400 From: "Salz, Rich" To: Kurt Andersen , "dcrup@ietf.org" , "dcrup-chairs@ietf.org" Thread-Topic: Notes from IETF99 dcrup meeting Thread-Index: AQHTATmcyP4sIVT+MkWUNHUYLDz27aJc/shA Date: Thu, 20 Jul 2017 17:50:34 +0000 Message-ID: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.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.152.146] Content-Type: multipart/alternative; boundary="_000_737c2948eae54ca49bb4fec3b7e64289usma1exdag1mb3msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_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-1706020000 definitions=main-1707200273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-20_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-1706020000 definitions=main-1707200273 Archived-At: Subject: Re: [Dcrup] Notes from IETF99 dcrup meeting 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, 20 Jul 2017 17:50:41 -0000 --_000_737c2948eae54ca49bb4fec3b7e64289usma1exdag1mb3msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S3VydCwNCg0KVGhhbmsgeW91IHZlcnkgdmVyeSBtdWNoIGZvciB0aGUgZGV0YWlsZWQgbm90ZXMh DQoNCkF0dGVuZGVlczogcGxlYXNlIHBvc3QgY29ycmVjdGlvbnMgYnkgbmV4dCB3ZWVrIQ0KDQot LQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NM IERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCkZy b206IEt1cnQgQW5kZXJzZW4gW21haWx0bzprdXJ0YUBkcmt1cnQuY29tXQ0KU2VudDogVGh1cnNk YXksIEp1bHkgMjAsIDIwMTcgMTE6MjIgQU0NClRvOiBkY3J1cEBpZXRmLm9yZzsgZGNydXAtY2hh aXJzQGlldGYub3JnDQpTdWJqZWN0OiBOb3RlcyBmcm9tIElFVEY5OSBkY3J1cCBtZWV0aW5nDQoN CihBcG9sb2dpZXMgaW4gYWR2YW5jZSBmb3IgYW55IG5hbWVzIHRoYXQgSSd2ZSBtaXMtYXR0cmli dXRlZCkNCg0KY2hhcnRlciB0d2VhayAtIGluIGZsaWdodA0KSm9obiAtIGhhc2hpbmcgdGhlIGtl eQ0KICAgIG9uZSBvcGVuIHRlY2ggcXVlc3Rpb246DQogICAgYWRkaW5nIG5ldyBzaWduaW5nIHdh eXMNCiAgICAgICAgb25lIGlzIHRvIGRvIGhhc2hpbmcgb2Yga2V5cw0KICAgICAgICAgICAgc3Ry YWlnaHRmb3J3YXJkIHRvIGFjY29tcGxpc2ggdGhpcw0KICAgICAgICBhZGQgZWxsaXB0aWMgY3Vy dmVzIEVEMjU1MTkNCiAgICAgICAgb3BlbiBxdWVzdGlvbjogc2hvdWxkIHdlIGFkZCB0aGUgaGFz aCBmb3IgRUREU0Egc2lncz8NCiAgICAgICAgICAgIHNpbmNlIHRoZXJlIGlzIG5vIG9wZXJhdGlv bmFsIGJlbmVmaXQsIHdoeSBkbyB0aGlzPw0KICAgIE1hcnRpbiBUaG9tc29uIC0gUG90ZW50aWFs IGJlbmVmaXQgLSBieSBzaWduaW5nIHRoZSBwdWJsaWMga2V5IGluIGEgaGVhZGVyLCBpdCBpcyBw b3NzaWJsZSBpbiBzb21lIHNpdHVhdGlvbnMgdG8gc3ludGhlc2l6ZSBhIGtleSB0aGF0IHdpbGwg dmFsaWRhdGUNCiAgICBQSEIgLSBzb21lIGdhbWVzIGNhbiBiZSBwbGF5ZWQgd2l0aCBrZXlzLCBo YXMgYmVlbiBhIHByb3BvbmVudCBvZiBoYXNoZXMsIGJ1dCBkb24ndCB0aGluayB0aGF0IHRoZXkg cmVhbGx5IHByb3ZpZGUgYmVuZWZpdA0KICAgICAgICBuZWVkIHNvbWUgdG9vbGluZyB0byBtYW5h Z2UgdGhlIGhhc2hlcw0KICAgICAgICBqdXN0IHdhbnRzIHRvIHBvc3QgdGhlIHB1YiBrZXkgaW50 byBETlMNCiAgICBZbmlyIC0gd2h5IG5vdCBqdXN0IGRvIGN1cnZlcyBhbmQgbm90IGhhc2hpbmc/ DQogICAgRUtSIC0gTWFydGluJ3MgY29uY2VybiBpcyBrZXkgcmVwbGFjZW1lbnQgaW4gdGhlIHpv bmUNCiAgICAgICAgdGhlIG1vc3QgY29uc2lzdGVudCB0aGluZyBpbiB0aGUgZnV0dXJlIGlzIHRv IGFsd2F5cyBoYXNoLCBidXQgbWF5IG5vdCBiZSBjcml0aWNhbA0KICAgIE1UIC0gdGhlIGZ1dHVy ZSBpcyBiaWdnZXIgdGhhbiB0aGUgcGFzdA0KICAgICAgICBhIGxpdHRsZSBjb25jZXJuZWQgYWJv dXQgc2lnbmluZyBvdmVyIHRoZSBrZXksIGJ1dCBnZW5lcmFsDQogICAgRUtSIC0gZG9uJ3QgaGF2 ZSB0d28gdmVyc2lvbnMgb2YgRUREU0ENCiAgICAgICAgcHJlZiBvcmRlcjogaGFzaGVkIGFsd2F5 cy9oYXNoIFJTQSBvbmx5L25vbi1oYXNoZWQNCiAgICBNVCAtIHBvc3QtcXVhbnR1bSBtYXkgcmVx dWlyZSBoYXNoZWQga2V5cyByZWdhcmRsZXNzDQogICAgICAgIFJpY2ggOiBwbGVhc2UgcG9zdCBj b25jZXJucyBhYm91dCBrZXkgc3dhcCB0byB0aGUgbGlzdA0KICAgIFBIQiAtIG1heSB2ZXJ5IHdl bGwgYmUgbG9va2luZyBhdCBhbGwgc3RhbmRhcmRzIHRvIGJlIHJldmlzZWQgaW4gcG9zdC1xdWFu dHVtIHdvcmxkDQogICAgTVQgLSBub3RlIHRvIHRoZSBsaXN0IGFib3V0IHByZWZlcnJpbmcgaGFz aGluZyByYXRob2xlZDsgZG9uJ3QgbWlzcyB0aGUgb3RoZXIgcG9pbnRzIHRoYXQgd2VyZSByYWlz ZWQgaW4gZmxpZ2h0DQogICAgRUtSIC0gbmFtZXMgLS0+IHRha2UgaXQgdG8gdGhlIGxpc3QNCg0K U2NvdHQgLSBka2ltIHVzYWdlDQogICAgcmFpc2UgdGhlIGZsb29yIHRvIDEwMjQsIGRlcHJlY2F0 ZSBzaGExDQogICAgdXBkYXRlcyBBQk5GDQogICAgcHJldHR5IGNsb3NlIHRvIGxhc3QgY2FsbA0K DQogICAgTVQgLSBjb25jZXJuczogUFNTPyBkb24ndCBkbyBpdCBoZXJlIGluIHRoZSBkb2MNCiAg ICAgICAgd2h5IGRvZXMgaXQgdGFrZSA1IHBhZ2VzIHRvIGRvIHR3byBzaW1wbGUgdGhpbmdzPw0K ICAgICAgICBjdXQgdGhlIHRleHQgb3V0IHdoaWNoIGlzIGNvcGllZCBmcm9tIHRoZSBES0lNIFJG Qw0KICAgICAgICBkb24ndCBtb2RpZnkgdGhlIEFCTkYgLSBwb2ludCB0YWtlbg0KICAgIEVLUiAt IHdoYXQgYXJlIHRoZSBzZWN1cml0eSBwcm9wZXJ0aWVzPw0KICAgICAgICByZWNhcHBpbmcgc2hh MSBhdHRhY2tzIGRpc2N1c3NlZCBvbiB0aGUgbGlzdA0KICAgICAgICB3aGVuIHNob3VsZCB3ZSBh ZHZpc2UgcmVjZWl2ZXJzIHRvIHN0b3AgYWNjZXB0aW5nIHNoYTE/DQogICAgICAgICAgICBwdXQg aW50byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnM6IEVLUiBhY2NlcHRlZCBhY3Rpb24NCiAg ICBuZWVkIHRvIG1vdmUgc2hhMSB0byBoaXN0b3JpYyBpbiBJQU5BIC0gcHV0IGludG8gU2NvdHQn cyBkcmFmdA0KICAgIEJhcnJ5IC0gZGlzY3Vzc2luZyAic2hvdWxkIChwbHVzKSIgKGZyb20gdGhl IHJvb206IGRvbid0IGdvIHRoZXJlKQ0KICAgIEpvaG4gLSBzdG9wcGluZyBhY2NlcHRhbmNlIGlz IGxhcmdlbHkgYW4gb3BlcmF0b3IgZXZhbmdlbGl6YXRpb24gaXNzdWUNCiAgICAgICAgS3VydCAt IGhhdmluZyB0aGlzIGRyYWZ0IGluIGZsaWdodCBoYXMgYmVlbiBiZW5lZmljaWFsIHRvIGdldHRp bmcgMyBsYXJnZXN0IHNlbmRlcnMgb2YgU0hBMSB0byBjaGFuZ2UNCiAgICBDaHJpcyAtIG11c3Qg Y2hlY2sga2V5IHNpemUgc2hvdWxkIGJlIGFkZGVkDQogICAgTVQgLSBkb2Mgc2hvdWxkIGp1c3Qg c2F5ICJNVVNUIE5PVCIgKHNlbmQgb3IgYWNjZXB0KQ0KICAgICAgICBwcm92aWRlcyBhIGdvb2Qg aGFtbWVyIHRvIGdldCBjaGFuZ2UgZG9uZQ0KICAgIFBIQiAtIG9iamVjdHMgdG8gc2F5aW5nIE1V U1QgTk9UIGFjY2VwdCAob25seSBvbmUgaW4gcm9vbSkNCiAgICAgICAgZm9yIG1lc3NhZ2UgdmFs aWRpdHkgeWVzLCBpdCBtYXR0ZXJzDQogICAgICAgIHVzZWZ1bCB0byBmb2xsb3cgYXBwcm9wcmlh dGUgcGhhc2luZw0KICAgIFNldGggLSBpbiAyMDA3LCBzb3VuZGVkIGxpa2UgIlNIT1VMRCBOT1Qi IC0gZGlkbid0IG1vdmUgdGhlIG5lZWRsZQ0KICAgICAgICAiTVVTVCBOT1QiIHdhcyBuZWVkZWQg dG8gZ2V0IHBlb3BsZSB0byBtb3ZlDQogICAgTVQgLSB3YW50IHRoZSBoZWFkbGluZQ0KICAgIFJp Y2ggLSB0aW1ldGFibGUgaXMgaW1wb3J0YW50DQogICAgdmVuZG9ycyBoYXRlICJNVVNUIE5PVCBp bXBsZW1lbnQiDQogICAgICAgICJNVVNUIE5PVCB1c2UiIGlzIGJldHRlcg0KICAgIGFuZHJlYXMg LSBzaG91bGQgaXMganVzdGlmeSB0byBub3QgY2hhbmdlDQoNCiAgICBodW1zOiBmb3IgKysrOyBh Z2FpbnN0OiArOyBuZWVkIG1vcmUgaW5mbzogYmFyZWx5DQogICAgQmFycnk6IGRpZCB3ZSBqdXN0 IHZvdGU/DQogICAgSmltIG9uIGphYmJlcjogdG9vIHNvb24gZm9yIE1VU1QgTk9UIGFjY2VwdA0K ICAgIEFsZXhleSAtIHdlIGdvdCBhIHNlbnNlIG9mIHRoZSByb29tLCBidXQgZ28gdG8gdGhlIGxp c3QNCg0KU2NvdHQgUm9zZSAtIGRvZXNuJ3QgdGhpbmsgUEMyNTYgRUNEU0EgaXMgbmVlZGVkDQog ICAgRUREU0Egc2hvdWxkIGJlIHN1ZmZpY2llbnQgd2hlbiBpdCBnZXRzIGludG8gRklQUw0KICAg IHByb3Bvc2luZyB0byBraWxsIHRoZSBkb2MNCg== --_000_737c2948eae54ca49bb4fec3b7e64289usma1exdag1mb3msgcorpak_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkt1cnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rIHlvdSB2ZXJ5 IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIG5vdGVzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BdHRlbmRl ZXM6IHBsZWFzZSBwb3N0IGNvcnJlY3Rpb25zIGJ5IG5leHQgd2VlayE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ LS0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ TWVtYmVyLCBPcGVuU1NMIERldiBUZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0 ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IEt1cnQgQW5kZXJzZW4gW21haWx0bzprdXJ0YUBkcmt1cnQuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdWx5IDIwLCAyMDE3IDExOjIyIEFNPGJyPg0KPGI+VG86 PC9iPiBkY3J1cEBpZXRmLm9yZzsgZGNydXAtY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IE5vdGVzIGZyb20gSUVURjk5IGRjcnVwIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KEFwb2xvZ2llcyBpbiBhZHZhbmNl IGZvciBhbnkgbmFtZXMgdGhhdCBJJ3ZlIG1pcy1hdHRyaWJ1dGVkKTxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNoYXJ0ZXIgdHdlYWsgLSBpbiBm bGlnaHQgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Kb2huIC0gaGFzaGluZyB0aGUga2V5IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBvbmUgb3BlbiB0ZWNoIHF1ZXN0aW9u OiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgYWRkaW5nIG5ldyBzaWduaW5nIHdheXMmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsgJm5ic3A7IG9uZSBpcyB0byBkbyBoYXNoaW5nIG9mIGtleXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyBzdHJhaWdodGZvcndhcmQgdG8g YWNjb21wbGlzaCB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyBhZGQgZWxsaXB0aWMg Y3VydmVzIEVEMjU1MTk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IG9wZW4gcXVlc3Rpb246 IHNob3VsZCB3ZSBhZGQgdGhlIGhhc2ggZm9yIEVERFNBIHNpZ3M/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgc2luY2UgdGhlcmUgaXMgbm8gb3BlcmF0aW9u YWwgYmVuZWZpdCwgd2h5IGRvIHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IE1hcnRpbiBUaG9tc29uIC0gUG90ZW50 aWFsIGJlbmVmaXQgLSBieSBzaWduaW5nIHRoZSBwdWJsaWMga2V5IGluIGEgaGVhZGVyLCBpdCBp cyBwb3NzaWJsZSBpbiBzb21lIHNpdHVhdGlvbnMgdG8gc3ludGhlc2l6ZSBhIGtleSB0aGF0IHdp bGwgdmFsaWRhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgUEhCIC0gc29tZSBnYW1lcyBjYW4gYmUgcGxheWVkIHdpdGgg a2V5cywgaGFzIGJlZW4gYSBwcm9wb25lbnQgb2YgaGFzaGVzLCBidXQgZG9uJ3QgdGhpbmsgdGhh dCB0aGV5IHJlYWxseSBwcm92aWRlIGJlbmVmaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7 IG5lZWQgc29tZSB0b29saW5nIHRvIG1hbmFnZSB0aGUgaGFzaGVzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5i c3A7ICZuYnNwOyBqdXN0IHdhbnRzIHRvIHBvc3QgdGhlIHB1YiBrZXkgaW50byBETlMgPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7IFluaXIgLSB3aHkgbm90IGp1c3QgZG8gY3VydmVzIGFuZCBub3QgaGFzaGluZz88bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgRUtSIC0gTWFydGluJ3MgY29uY2VybiBpcyBrZXkgcmVwbGFjZW1lbnQgaW4gdGhlIHpvbmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IHRoZSBtb3N0IGNvbnNpc3RlbnQgdGhpbmcgaW4g dGhlIGZ1dHVyZSBpcyB0byBhbHdheXMgaGFzaCwgYnV0IG1heSBub3QgYmUgY3JpdGljYWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgTVQgLSB0aGUgZnV0dXJlIGlzIGJpZ2dlciB0aGFuIHRoZSBwYXN0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7ICZuYnNwOyBhIGxpdHRsZSBjb25jZXJuZWQgYWJvdXQgc2lnbmluZyBvdmVyIHRo ZSBrZXksIGJ1dCBnZW5lcmFsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IEVLUiAtIGRvbid0IGhhdmUgdHdvIHZl cnNpb25zIG9mIEVERFNBPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyBwcmVmIG9yZGVyOiBo YXNoZWQgYWx3YXlzL2hhc2ggUlNBIG9ubHkvbm9uLWhhc2hlZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBNVCAtIHBvc3Qt cXVhbnR1bSBtYXkgcmVxdWlyZSBoYXNoZWQga2V5cyByZWdhcmRsZXNzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyAmbmJzcDtSaWNoIDogcGxlYXNlIHBvc3QgY29uY2VybnMgYWJvdXQga2V5IHN3YXAg dG8gdGhlIGxpc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgUEhCIC0gbWF5IHZlcnkgd2VsbCBiZSBsb29raW5nIGF0IGFs bCBzdGFuZGFyZHMgdG8gYmUgcmV2aXNlZCBpbiBwb3N0LXF1YW50dW0gd29ybGQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg TVQgLSBub3RlIHRvIHRoZSBsaXN0IGFib3V0IHByZWZlcnJpbmcgaGFzaGluZyByYXRob2xlZDsg ZG9uJ3QgbWlzcyB0aGUgb3RoZXIgcG9pbnRzIHRoYXQgd2VyZSByYWlzZWQgaW4gZmxpZ2h0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7IEVLUiAtIG5hbWVzIC0tJmd0OyB0YWtlIGl0IHRvIHRoZSBsaXN0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNjb3R0IC0gZGtpbSB1 c2FnZSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDsgcmFpc2UgdGhlIGZsb29yIHRvIDEwMjQsIGRlcHJlY2F0ZSBzaGExPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7IHVwZGF0ZXMgQUJORjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBwcmV0dHkgY2xvc2UgdG8gbGFzdCBjYWxsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgTVQgLSBjb25jZXJuczogUFNTPyBkb24ndCBkbyBpdCBoZXJlIGluIHRoZSBkb2M8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IHdoeSBkb2VzIGl0IHRha2UgNSBwYWdlcyB0byBk byB0d28gc2ltcGxlIHRoaW5ncz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7IGN1dCB0aGUg dGV4dCBvdXQgd2hpY2ggaXMgY29waWVkIGZyb20gdGhlIERLSU0gUkZDPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7ICZuYnNwOyBkb24ndCBtb2RpZnkgdGhlIEFCTkYgLSBwb2ludCB0YWtlbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyBFS1IgLSB3aGF0IGFyZSB0aGUgc2VjdXJpdHkgcHJvcGVydGllcz8mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsgJm5ic3A7IHJlY2FwcGluZyBzaGExIGF0dGFja3MgZGlzY3Vzc2VkIG9uIHRo ZSBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyB3aGVuIHNob3VsZCB3ZSBhZHZpc2Ug cmVjZWl2ZXJzIHRvIHN0b3AgYWNjZXB0aW5nIHNoYTE/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgcHV0IGludG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zOiA8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRkZGQUE1Ij4NCkVLUiBhY2NlcHRlZCBhY3Rp b248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7IG5lZWQgdG8gbW92ZSBzaGExIHRvIGhpc3RvcmljIGluIElBTkEg LSBwdXQgaW50byBTY290dCdzIGRyYWZ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IEJhcnJ5IC0gZGlzY3Vzc2luZyAmcXVv dDtzaG91bGQgKHBsdXMpJnF1b3Q7IChmcm9tIHRoZSByb29tOiBkb24ndCBnbyB0aGVyZSk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgSm9obiAtIHN0b3BwaW5nIGFjY2VwdGFuY2UgaXMgbGFyZ2VseSBhbiBvcGVyYXRvciBl dmFuZ2VsaXphdGlvbiBpc3N1ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgS3VydCAtIGhh dmluZyB0aGlzIGRyYWZ0IGluIGZsaWdodCBoYXMgYmVlbiBiZW5lZmljaWFsIHRvIGdldHRpbmcg MyBsYXJnZXN0IHNlbmRlcnMgb2YgU0hBMSB0byBjaGFuZ2UmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgQ2hyaXMg LSBtdXN0IGNoZWNrIGtleSBzaXplIHNob3VsZCBiZSBhZGRlZDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBNVCAtIGRvYyBz aG91bGQganVzdCBzYXkgJnF1b3Q7TVVTVCBOT1QmcXVvdDsgKHNlbmQgb3IgYWNjZXB0KTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5i c3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgcHJvdmlkZXMgYSBnb29kIGhhbW1lciB0byBnZXQgY2hh bmdlIGRvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgUEhCIC0gb2JqZWN0cyB0byBzYXlpbmcgTVVTVCBOT1QgYWNjZXB0 IChvbmx5IG9uZSBpbiByb29tKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgZm9yIG1lc3Nh Z2UgdmFsaWRpdHkgeWVzLCBpdCBtYXR0ZXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyB1 c2VmdWwgdG8gZm9sbG93IGFwcHJvcHJpYXRlIHBoYXNpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgU2V0aCAtIGluIDIw MDcsIHNvdW5kZWQgbGlrZSAmcXVvdDtTSE9VTEQgTk9UJnF1b3Q7IC0gZGlkbid0IG1vdmUgdGhl IG5lZWRsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJnF1b3Q7TVVTVCBOT1QmcXVvdDsg d2FzIG5lZWRlZCB0byBnZXQgcGVvcGxlIHRvIG1vdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgTVQgLSB3YW50IHRoZSBo ZWFkbGluZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyBSaWNoIC0gdGltZXRhYmxlIGlzIGltcG9ydGFudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyB2 ZW5kb3JzIGhhdGUgJnF1b3Q7TVVTVCBOT1QmbmJzcDtpbXBsZW1lbnQmcXVvdDsgPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJnF1b3Q7TVVTVCBOT1QmbmJzcDt1c2UmcXVvdDsgaXMgYmV0dGVyIDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBhbmRyZWFzIC0gc2hvdWxkIGlzIGp1c3RpZnkgdG8gbm90IGNoYW5nZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyBodW1zOiBmb3IgJiM0MzsmIzQzOyYjNDM7OyBhZ2FpbnN0OiAmIzQz OzsgbmVlZCBtb3JlIGluZm86IGJhcmVseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBCYXJyeTogZGlkIHdlIGp1c3Qgdm90 ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDsgSmltIG9uIGphYmJlcjogdG9vIHNvb24gZm9yIE1VU1QgTk9UIGFjY2VwdDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBBbGV4ZXkgLSB3ZSBnb3QgYSBzZW5zZSBvZiB0aGUgcm9vbSwgYnV0IGdvIHRvIHRo ZSBsaXN0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TY290dCBSb3NlIC0gZG9lc24ndCB0aGluayBQQzI1NiBFQ0RTQSBp cyBuZWVkZWQgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7IEVERFNBIHNob3VsZCBiZSBzdWZmaWNpZW50IHdoZW4gaXQgZ2V0 cyBpbnRvIEZJUFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgcHJvcG9zaW5nIHRvIGtpbGwgdGhlIGRvYzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_737c2948eae54ca49bb4fec3b7e64289usma1exdag1mb3msgcorpak_-- From nobody Fri Jul 21 13:52: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 97C4F129B35 for ; Fri, 21 Jul 2017 13:52:40 -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 VE7rzHL1vMVw for ; Fri, 21 Jul 2017 13:52:35 -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 DFA0C129AD3 for ; Fri, 21 Jul 2017 13:52:35 -0700 (PDT) Received: from [IPv6:2601:647:5500:1330:250a:b902:a697:f5d8] ([IPv6:2601:647:5500:1330:250a:b902:a697:f5d8]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6LKqSMl019576 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 21 Jul 2017 13:52:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1500670354; bh=4PajFNLh/zb9CpZMqZ1s2YAbc1CAjBibM4mMzcxTYq4=; h=Subject:To:References:From:Date:In-Reply-To; b=Glm6WVxl8Ghu/DZpFngVaqw/AYZ8NlpUyEohmKaO42m2qFWy0/H6XbxLwC1ARIydc nJWfiVHDyxVEhpk1A9+G6/tOY1srLZXqA1qYJIiqbyVakZuPf9FDAk6f6sgH4GrUEG zveqSSBfcJmj7PozANzN/PiojU6n6oqmrc+Beqwg= To: dcrup@ietf.org References: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.msg.corp.akamai.com> From: Jim Fenton Message-ID: <84372b7e-d037-3124-10c8-d2f4285059fa@bluepopcorn.net> Date: Fri, 21 Jul 2017 13:52:23 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------B4CE59E1F32ED0098BE00BBC" Content-Language: en-US Archived-At: Subject: Re: [Dcrup] Notes from IETF99 dcrup meeting 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, 21 Jul 2017 20:52:41 -0000 This is a multi-part message in MIME format. --------------B4CE59E1F32ED0098BE00BBC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 07/20/2017 10:50 AM, Salz, Rich wrote: > > Kurt, > > =20 > > Thank you very very much for the detailed notes! > > =20 > > Attendees: please post corrections by next week! > > =20 > > --=20 > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > =20 > > *From:*Kurt Andersen [mailto:kurta@drkurt.com] > *Sent:* Thursday, July 20, 2017 11:22 AM > *To:* dcrup@ietf.org; dcrup-chairs@ietf.org > *Subject:* Notes from IETF99 dcrup meeting > > =20 > > (Apologies in advance for any names that I've mis-attributed) > > =20 > > charter tweak - in flight > > John - hashing the key > > one open tech question:=20 > > adding new signing ways=20 > > one is to do hashing of keys > > straightforward to accomplish this > > add elliptic curves ED25519 > > open question: should we add the hash for EDDSA sigs? > > since there is no operational benefit, why do this? > > Martin Thomson - Potential benefit - by signing the public key in > a header, it is possible in some situations to synthesize a key that > will validate > > PHB - some games can be played with keys, has been a proponent of > hashes, but don't think that they really provide benefit > > need some tooling to manage the hashes > > just wants to post the pub key into DNS > > Ynir - why not just do curves and not hashing? > Yoav was channeling me from Jabber here. The actual question was, "If we are trying to minimize the number of things that need to interoperate, do we need both hashing and elliptic curve? Aren't they two ways of solving the same problem?" John's response was a shrug. -Jim > EKR - Martin's concern is key replacement in the zone > > the most consistent thing in the future is to always hash, but > may not be critical > > MT - the future is bigger than the past > > a little concerned about signing over the key, but general=20 > > EKR - don't have two versions of EDDSA > > pref order: hashed always/hash RSA only/non-hashed > > MT - post-quantum may require hashed keys regardless > > Rich : please post concerns about key swap to the list > > PHB - may very well be looking at all standards to be revised in > post-quantum world > > MT - note to the list about preferring hashing ratholed; don't > miss the other points that were raised in flight > > EKR - names --> take it to the list > > =20 > > Scott - dkim usage > > raise the floor to 1024, deprecate sha1 > > updates ABNF > > pretty close to last call > > =20 > > MT - concerns: PSS? don't do it here in the doc > > why does it take 5 pages to do two simple things? > > cut the text out which is copied from the DKIM RFC > > don't modify the ABNF - point taken > > EKR - what are the security properties?=20 > > recapping sha1 attacks discussed on the list > > when should we advise receivers to stop accepting sha1? > > put into the security considerations: EKR accepted action > > need to move sha1 to historic in IANA - put into Scott's draft > > Barry - discussing "should (plus)" (from the room: don't go there) > > John - stopping acceptance is largely an operator evangelization is= sue > > Kurt - having this draft in flight has been beneficial to > getting 3 largest senders of SHA1 to change=20 > > Chris - must check key size should be added > > MT - doc should just say "MUST NOT" (send or accept) > > provides a good hammer to get change done > > PHB - objects to saying MUST NOT accept (only one in room) > > for message validity yes, it matters > > useful to follow appropriate phasing > > Seth - in 2007, sounded like "SHOULD NOT" - didn't move the needle > > "MUST NOT" was needed to get people to move > > MT - want the headline > > Rich - timetable is important > > vendors hate "MUST NOT implement" > > "MUST NOT use" is better > > andreas - should is justify to not change > > =20 > > hums: for +++; against: +; need more info: barely > > Barry: did we just vote? > > Jim on jabber: too soon for MUST NOT accept > > Alexey - we got a sense of the room, but go to the list > > =20 > > Scott Rose - doesn't think PC256 ECDSA is needed > > EDDSA should be sufficient when it gets into FIPS > > proposing to kill the doc > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup --------------B4CE59E1F32ED0098BE00BBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 07/20/2017 10:50 AM, Salz, Rich wrote:

Kurt,

 

Thank you very very much for the detailed notes!

 

Attendees: please post corrections by next week!

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

 

From: Kurt Andersen [mailto:kurta@drkurt.com]
Sent: Thursday, July 20, 2017 11:22 AM
To: dcrup@ietf.org; dcrup-chairs@ietf.org
Subject: Notes from IETF99 dcrup meeting

 

(Apologies in advance for any names that I've mis-attributed)

 

charter tweak - in flight

John - hashing the key

    one open tech question: 

    adding new signing ways 

        one is to do hashing of keys

            straightforward to accomplish this

        add elliptic curves ED25519

        open question: should we add the hash for EDDSA sigs?

            since there is no operational benefit, why do this?

    Martin Thomson - Potential benefit - by signing the public key in a header, it is possible in some situations to synthesize a key that will validate

    PHB - some games can be played with keys, has been a proponent of hashes, but don't think that they really provide benefit

        need some tooling to manage the hashes

        just wants to post the pub key into DNS

    Ynir - why not just do curves and not hashing?


Yoav was channeling me from Jabber here. The actual question was, "If we are trying to minimize the number of things that need to interoperate, do we need both hashing and elliptic curve? Aren't they two ways of solving the same problem?" John's response was a shrug.

-Jim

    EKR - Martin's concern is key replacement in the zone

        the most consistent thing in the future is to always hash, but may not be critical

    MT - the future is bigger than the past

        a little concerned about signing over the key, but general 

    EKR - don't have two versions of EDDSA

        pref order: hashed always/hash RSA only/non-hashed

    MT - post-quantum may require hashed keys regardless

        Rich : please post concerns about key swap to the list

    PHB - may very well be looking at all standards to be revised in post-quantum world

    MT - note to the list about preferring hashing ratholed; don't miss the other points that were raised in flight

    EKR - names --> take it to the list

 

Scott - dkim usage

    raise the floor to 1024, deprecate sha1

    updates ABNF

    pretty close to last call

 

    MT - concerns: PSS? don't do it here in the doc

        why does it take 5 pages to do two simple things?

        cut the text out which is copied from the DKIM RFC

        don't modify the ABNF - point taken

    EKR - what are the security properties? 

        recapping sha1 attacks discussed on the list

        when should we advise receivers to stop accepting sha1?

            put into the security considerations: EKR accepted action

    need to move sha1 to historic in IANA - put into Scott's draft

    Barry - discussing "should (plus)" (from the room: don't go there)

    John - stopping acceptance is largely an operator evangelization issue

        Kurt - having this draft in flight has been beneficial to getting 3 largest senders of SHA1 to change 

    Chris - must check key size should be added

    MT - doc should just say "MUST NOT" (send or accept)

        provides a good hammer to get change done

    PHB - objects to saying MUST NOT accept (only one in room)

        for message validity yes, it matters

        useful to follow appropriate phasing

    Seth - in 2007, sounded like "SHOULD NOT" - didn't move the needle

        "MUST NOT" was needed to get people to move

    MT - want the headline

    Rich - timetable is important

    vendors hate "MUST NOT implement"

        "MUST NOT use" is better

    andreas - should is justify to not change

    

    hums: for +++; against: +; need more info: barely

    Barry: did we just vote?

    Jim on jabber: too soon for MUST NOT accept

    Alexey - we got a sense of the room, but go to the list

    

Scott Rose - doesn't think PC256 ECDSA is needed

    EDDSA should be sufficient when it gets into FIPS

    proposing to kill the doc



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


--------------B4CE59E1F32ED0098BE00BBC-- From nobody Fri Jul 21 14:18: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 423C7128A32 for ; Fri, 21 Jul 2017 14:18:40 -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 UlQjB7oahi03 for ; Fri, 21 Jul 2017 14:18:39 -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 48249124D68 for ; Fri, 21 Jul 2017 14:18:39 -0700 (PDT) Received: from [IPv6:2601:647:5500:1330:250a:b902:a697:f5d8] ([IPv6:2601:647:5500:1330:250a:b902:a697:f5d8]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6LLIaS0019921 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 21 Jul 2017 14:18:39 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1500671919; bh=I/597yiBM1ZuelOdNBJjc2Xitk1d38FayD43bf+YtCs=; h=To:From:Subject:Date; b=tdMz75DziUXytqts0kW5MKq0Db8Mrki1sHYhM79Bp1/CIq3LTiVNUlw+HkSDZ9+6J vVAZbkzXYHluq6svNfL0Kb8VSrf2mTBn3TiemK1OWMMe93lc58LnT0wvXIhhRIBaJY 76hT+taSdBDRhqzc2empDGxv1sW7swFB2CTnPTfQ= To: dcrup@ietf.org From: Jim Fenton Message-ID: Date: Fri, 21 Jul 2017 14:18:31 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 21 Jul 2017 21:18:40 -0000 This is a repeat of a question I asked via Jabber in the WG meeting yesterday, and didn't get much response probably because I worded it tersely for Jabber and couldn't expand on the question easily. At the outset of this WG's formation, it was noted that there are two approaches to the problem with DNS record length with large RSA keys: (1) hash the keys, put the public key into the message and the hash in DNS; and (2) use a different algorithm such as elliptic curve that has shorter public keys. In the discussion about supporting both hashed and unhashed keys (particularly the question of whether to hash the elliptic curve keys as well), John Levine said: "Since there is no negotiation between the sender and the receiver, a receiver must implement every possible crypto scheme that any sender might use to interoperate. I would rather minimize the number of schemes and just add two rather than three." I agree with John that keeping the number of schemes to a minimum is good. Given that (1) and (2) above solve the same problem, why do we have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the other, or are there good reasons for some signers to use hashed RSA and others to use EC? -Jim From nobody Fri Jul 21 14:57: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 5C3B6128A32 for ; Fri, 21 Jul 2017 14:57:34 -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 0Q78oCDBgjik for ; Fri, 21 Jul 2017 14:57:32 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002: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 CC6A7124B0A for ; Fri, 21 Jul 2017 14:57:31 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id g144so1460448yba.5 for ; Fri, 21 Jul 2017 14:57:31 -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=wr3HlProgxwsyaImV9DuZXaSx51b4/TGomtCTZNBi20=; b=LktvQu8vCG9R7N+F+yECO7iTLJYTAWQRBtv/EaouRtId/Yuu7p6zrVqrHrIBNDN+hZ kon7Y9BGoGwiL6VAvPbNZoOvmEhYLiEoZI9IEf362arvP1ND4gM+9+kyUBgflIv+JVTQ xh/96eo+EdyW+ob7aIbvHhUQ8Em4zakup6tMHmWdRrD4ImIXRTujjs5o4/ayo2ckTmOV qy5p3VP/HMtGbveivvtiO5V95cXxuURjEFYHty8KXlQSVOmxmzpGn6CFSoKfBbo+gTaV 8hzHxZx2bc5ZgOjs+9yZywQs1FSGszIyjW4/kDD/Ny8kAH80twk1bcZ9rXV7G6wJIOEU 3oWw== 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=wr3HlProgxwsyaImV9DuZXaSx51b4/TGomtCTZNBi20=; b=SwFioRrlHEK/VjGzaMf2YD9O+q5jrZKfnzOV23oUpYqfD4XlSlK5erHCS7qd6MmKwk d1YpjQ4xMuYRHwm8eOmfCVpvQeeTF+XNIOWcWC3codKIVf9OfOtiNMwvZykfd6OzDyoK fiXWhoERgw6Stz655bJYYin+26s4xS+h2453IGaIdY7viXhcAcar2zM7so7MDJUbhyZe sFjU/colffIa+zWYP4G0Ipq6LojLn2M9nFNGY2i/jyw4JfNPdf+W2Wy/kQkmsAsKN0MU QwyICuvr810JhOryyEV3JHNC/guvEgM5U2MKL41hIDu6kkHLBz6+O8OD7cxGAolSpuR0 s6fg== X-Gm-Message-State: AIVw110mDQ1FKbwBgmAoVmk4FFTQlRDaFFxLxyA8aMpXmq+6soRlbDQv MY1Qzi88D9DsEvCC43XOKG1gdjYOBg== X-Received: by 10.37.188.76 with SMTP id d12mr13982ybk.193.1500674251147; Fri, 21 Jul 2017 14:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.131 with HTTP; Fri, 21 Jul 2017 14:57:30 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Fri, 21 Jul 2017 15:57:30 -0600 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="089e08245680aa51e80554daf37b" Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 21 Jul 2017 21:57:34 -0000 --089e08245680aa51e80554daf37b Content-Type: text/plain; charset="UTF-8" I agree. Every algorithm added is: - an incremental improvement in options available to some senders, but - a substantial increase in cost for ALL receivers. If it's possible to address the needs of senders by adding only one of RSA-FP or EC, but not both, that would be welcome for implementers of receivers. On Fri, Jul 21, 2017 at 3:18 PM, Jim Fenton wrote: > This is a repeat of a question I asked via Jabber in the WG meeting > yesterday, and didn't get much response probably because I worded it > tersely for Jabber and couldn't expand on the question easily. > > At the outset of this WG's formation, it was noted that there are two > approaches to the problem with DNS record length with large RSA keys: > (1) hash the keys, put the public key into the message and the hash in > DNS; and (2) use a different algorithm such as elliptic curve that has > shorter public keys. > > In the discussion about supporting both hashed and unhashed keys > (particularly the question of whether to hash the elliptic curve keys as > well), John Levine said: > > "Since there is no negotiation between the sender and the receiver, a > receiver must implement every possible crypto scheme that any sender > might use to interoperate. I would rather minimize the number of schemes > and just add two rather than three." > > I agree with John that keeping the number of schemes to a minimum is > good. Given that (1) and (2) above solve the same problem, why do we > have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the > other, or are there good reasons for some signers to use hashed RSA and > others to use EC? > > -Jim > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --089e08245680aa51e80554daf37b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. Every algorithm added is:

- an= incremental improvement in options available to some senders, but

- a substantial increase in cost for ALL receivers.
<= div>
If it's possible to address the needs of senders by = adding only one of RSA-FP or EC, but not both, that would be welcome for im= plementers of receivers.


On Fri, Jul 21, 2017 at 3:18 PM, Jim Fent= on <fenton@bluepopcorn.net> wrote:
This is a repeat of a question I asked via Jabber in the WG= meeting
yesterday, and didn't get much response probably because I worded it tersely for Jabber and couldn't expand on the question easily.

At the outset of this WG's formation, it was noted that there are two approaches to the problem with DNS record length with large RSA keys:
(1) hash the keys, put the public key into the message and the hash in
DNS; and (2) use a different algorithm such as elliptic curve that has
shorter public keys.

In the discussion about supporting both hashed and unhashed keys
(particularly the question of whether to hash the elliptic curve keys as well), John Levine said:

"Since there is no negotiation between the sender and the receiver, a<= br> receiver must implement every possible crypto scheme that any sender
might use to interoperate. I would rather minimize the number of schemes and just add two rather than three."

I agree with John that keeping the number of schemes to a minimum is
good. Given that (1) and (2) above solve the same problem, why do we
have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the=
other, or are there good reasons for some signers to use hashed RSA and
others to use EC?

-Jim


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

--089e08245680aa51e80554daf37b-- From nobody Fri Jul 21 15:56: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 BC545131A66 for ; Fri, 21 Jul 2017 15:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 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, RCVD_IN_SORBS_SPAM=0.5, 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=fiction.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 x4rMbhb12o4D for ; Fri, 21 Jul 2017 15:56:25 -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 B0426120721 for ; Fri, 21 Jul 2017 15:56:25 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id p188so63168393oia.0 for ; Fri, 21 Jul 2017 15:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hLJQFiXrMVPxLeiJUebpDJzj7pO02p2QlyqRmV64RBo=; b=GJdjgCHCPTfclNVaIfpgaFfAO70zqaIROunnj4IfLdx/d9j+T/f/ahAnzD1aqKAfxk iMYMADjw2B6eRsADS56cgxgaFRUbjZPhI6VKiPXrkfr0dKQF/9gJQoroY04V3Q6Yfhxn o/BZDu+h/999yrRYAxgbUB4H7j0BHnXN3i+XSOFCHvT9kRbFofiyWbzoQqvowJH/2Ixy uGw2Q2KbfE4KZoVOqRxG5lMksks6z6kNzldPQjg2eb+uhQDaJleUYVYjCawwlwW/53XB 1AXUSUDGsL0u289LJtCNNSCd8cbT/UDmlcnmHGZIaUUdV4qkR0WHcCTIJm2pQ7BjBVa9 o8XA== 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=hLJQFiXrMVPxLeiJUebpDJzj7pO02p2QlyqRmV64RBo=; b=WMPQl6tDo/yBZmuSlC1ehe5JFV1eTpZyVpSYizIojFjpUCs2zpeBmMR8jK4kEbLuIZ grw1CRAr9JU5H+KjskdeGHee4LGmmO2AUifhcWK4h6UvVN8rd1l7o6gl1kDZWFXgDIca Vj9XB+hlZXPtk6nrwKgE4KdSIgQi7Q8D4eIoEu062kTiJJrIFOuEvJe/91nTp0j6Geva VlopFTiPXm/Fv6ZPNgYVQWzN34USONaSc1m8AENKzOPjwTgKm9dJ/oibTgq5tw5Q4psE ATkq9OTppNZPNxFV3Zr3TNPQ0/LyttqQD1eGQUWGP8aGAdF6/InIOUWfN5eAboBym23B MeRQ== X-Gm-Message-State: AIVw112ptk1//3to5gtQuJjD77N2lW2Fn2n2QOTWmwK9caAtkQBi+nuP 43p+5WEYFCAsOKOJxtg1qA== X-Received: by 10.202.75.199 with SMTP id y190mr3007241oia.199.1500677785027; Fri, 21 Jul 2017 15:56:25 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com. [209.85.218.47]) by smtp.gmail.com with ESMTPSA id u17sm3388049oif.52.2017.07.21.15.56.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 15:56:24 -0700 (PDT) Received: by mail-oi0-f47.google.com with SMTP id p188so63168104oia.0 for ; Fri, 21 Jul 2017 15:56:24 -0700 (PDT) X-Received: by 10.202.179.137 with SMTP id c131mr2942338oif.298.1500677783567; Fri, 21 Jul 2017 15:56:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.78.69 with HTTP; Fri, 21 Jul 2017 15:56:22 -0700 (PDT) In-Reply-To: References: From: Brandon Long Date: Fri, 21 Jul 2017 15:56:22 -0700 X-Gmail-Original-Message-ID: Message-ID: To: denis bider Cc: Jim Fenton , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113ce08c37001c0554dbc638" Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 21 Jul 2017 22:56:29 -0000 --001a113ce08c37001c0554dbc638 Content-Type: text/plain; charset="UTF-8" Although I'm leaning towards agreeing with only adding one of these, I disagree this is a substantial cost for ALL receivers. In reality, there are likely <20 implementations, and although it's an increase in cost for the implementations, it's not a heavy one. For receivers, the cost is going to be in upgrading, which is required if they want to support any new algorithms, regardless of how much new functionality is in that upgrade. Perhaps the increased cost of updating implementations will lead to some implementations not being updated, which means receivers would have to switch implementations, which is a higher cost than a simpler upgrade... but second order effects are going to be much smaller anyways. Also, if we're voting on choosing, I'd go with adding EC, as I feel that allowing different algorithms makes DKIM more robust in the face of the possibility of a breakthrough against an existing algorithm. Brandon On Fri, Jul 21, 2017 at 2:57 PM, denis bider wrote: > I agree. Every algorithm added is: > > - an incremental improvement in options available to some senders, but > > - a substantial increase in cost for ALL receivers. > > If it's possible to address the needs of senders by adding only one of > RSA-FP or EC, but not both, that would be welcome for implementers of > receivers. > > > On Fri, Jul 21, 2017 at 3:18 PM, Jim Fenton > wrote: > >> This is a repeat of a question I asked via Jabber in the WG meeting >> yesterday, and didn't get much response probably because I worded it >> tersely for Jabber and couldn't expand on the question easily. >> >> At the outset of this WG's formation, it was noted that there are two >> approaches to the problem with DNS record length with large RSA keys: >> (1) hash the keys, put the public key into the message and the hash in >> DNS; and (2) use a different algorithm such as elliptic curve that has >> shorter public keys. >> >> In the discussion about supporting both hashed and unhashed keys >> (particularly the question of whether to hash the elliptic curve keys as >> well), John Levine said: >> >> "Since there is no negotiation between the sender and the receiver, a >> receiver must implement every possible crypto scheme that any sender >> might use to interoperate. I would rather minimize the number of schemes >> and just add two rather than three." >> >> I agree with John that keeping the number of schemes to a minimum is >> good. Given that (1) and (2) above solve the same problem, why do we >> have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the >> other, or are there good reasons for some signers to use hashed RSA and >> others to use EC? >> >> -Jim >> >> >> _______________________________________________ >> 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 > > --001a113ce08c37001c0554dbc638 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Although I'm leaning towards agreeing with only adding= one of these, I disagree this is a substantial cost for
ALL receivers.=

In reality, there are likely <20 implementations, an= d although it's an increase in cost for the implementations,=C2=A0
it's not a heavy one.

For receivers, the= cost is going to be in upgrading, which is required if they want to suppor= t any new algorithms,
regardless of how much new functionality is= in that upgrade.

Perhaps the increased cost of up= dating implementations will lead to some implementations not being updated,= =C2=A0
which means receivers would have to switch implementations= , which is a higher cost than a simpler upgrade...
but second ord= er effects are going to be much smaller anyways.

A= lso, if we're voting on choosing, I'd go with adding EC, as I feel = that allowing different algorithms makes
DKIM more robust in the = face of the possibility of a breakthrough against an existing algorithm.

Brandon

On Fri, Jul 21, 2017 at 2:57 PM, denis bider <denisbider.ietf@gmail.com> wrote:
I agree. Every algorithm added is:

- an incremental improvement in options available to some senders, b= ut

- a substantial increase in cost for ALL receiv= ers.

If it's possible to address the needs of = senders by adding only one of RSA-FP or EC, but not both, that would be wel= come for implementers of receivers.


On Fri, Jul 21, 2017 at 3:18 PM, Jim Fenton <= ;fenton@bluepop= corn.net> wrote:
This is = a repeat of a question I asked via Jabber in the WG meeting
yesterday, and didn't get much response probably because I worded it tersely for Jabber and couldn't expand on the question easily.

At the outset of this WG's formation, it was noted that there are two approaches to the problem with DNS record length with large RSA keys:
(1) hash the keys, put the public key into the message and the hash in
DNS; and (2) use a different algorithm such as elliptic curve that has
shorter public keys.

In the discussion about supporting both hashed and unhashed keys
(particularly the question of whether to hash the elliptic curve keys as well), John Levine said:

"Since there is no negotiation between the sender and the receiver, a<= br> receiver must implement every possible crypto scheme that any sender
might use to interoperate. I would rather minimize the number of schemes and just add two rather than three."

I agree with John that keeping the number of schemes to a minimum is
good. Given that (1) and (2) above solve the same problem, why do we
have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the=
other, or are there good reasons for some signers to use hashed RSA and
others to use EC?

-Jim


_______________________________________________
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


--001a113ce08c37001c0554dbc638-- From nobody Fri Jul 21 16:24: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 6B620129468 for ; Fri, 21 Jul 2017 16:24:29 -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 PU8suwe8su91 for ; Fri, 21 Jul 2017 16:24:27 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 9B9F11270A7 for ; Fri, 21 Jul 2017 16:24:27 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id v128so3652945ywb.1 for ; Fri, 21 Jul 2017 16:24:27 -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=yuhDOsyL+r3W3zJDxki3LBsSccSH+a2MgcMtblCwOlg=; b=YptLzp4Fqai8cGvRHJtREBEb3wRhTjUFVXYf4U9fZFeuQXlNEkaD883IAbXvPTM4/v JQcq4cSWkyiheTHp5RGnWqAxEZesZqYcniaI1QK8zqxhpqzqa6uKL3TK0HykXYnl3L0l diZyOZyp2hoa3yqUD8YuH1XUD0C3TC+P1kXWBUayDrSpmpuWO6FdOCb+eBHGfRtvBbX3 ozzO+i+vPGNzHVcbA+0vDmGj5J7th/7pAmh5wmv8sXVcoZiyxSLPKoBv5jVQ8g2hNDZA +l1TUugwHvOw2OYvDVyrUvzlWk3zJylK+IiGRnIMC/Cc3M7emoN+d7sBPwWKLFMt8w91 pwBg== 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=yuhDOsyL+r3W3zJDxki3LBsSccSH+a2MgcMtblCwOlg=; b=AQmHPn/KKj8PSutg3J3aP2Zjqqivo6wvfe9SdztZdcH+ZCZWwY7U9I1rx0vXMkRIYC Hm5zIGQ6G6NRrM/+uBIdJBAHcLCT6cqafHRyqI4H6saxecUebSztu49C4WpKCPigepED zjTvetBek0gAJrIVk0IS0D+HTXd+VuKsialCwx9mFIPIcChUhPipctudyZRolA7YMGPc uWKyZ0JBaZj8EEsBCcXQzflerQCiqKt7aYSj4HTX4GtFQVZ5p0k+T9ADSELtVkcct/76 mYOEbGP6c3h/k/6KlR0m45ItpmsNvPLKCdfqghIzd27jAT12STCzrCj7uFKiQJfwKuqo 9brQ== X-Gm-Message-State: AIVw111pDBZEI8cYplb2QYKYHoAIT0DKQp88kJnBRgvEnKpOSBQ0gO2U OA8C6IYXTS7/F+u/z/j+omgeNE/HGA== X-Received: by 10.129.80.68 with SMTP id e65mr7760776ywb.371.1500679466946; Fri, 21 Jul 2017 16:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.215.131 with HTTP; Fri, 21 Jul 2017 16:24:26 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Fri, 21 Jul 2017 17:24:26 -0600 Message-ID: To: Brandon Long Cc: Jim Fenton , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1147fa248c99e00554dc2a46" Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 21 Jul 2017 23:24:29 -0000 --001a1147fa248c99e00554dc2a46 Content-Type: text/plain; charset="UTF-8" Only 20 implementations for DKIM...? Email, as we know it, is on the order of 40 years old. I would be very surprised if it has anything short of hundreds of implementations. Many of those implementations support DKIM, and more will do so in the future. If we want to one day be able to assume that DKIM is supported universally, it needs to be supported not just by major providers of email-as-a-service, and major publishers of email software; but also by the long tail. The long tail involves a large number of diverse implementations, many of them using obscure software. I would estimate, if we want to be able to assume DKIM is universal, the number of implementations needs to be closer to 100. That's a lot of receivers... On Fri, Jul 21, 2017 at 4:56 PM, Brandon Long wrote: > Although I'm leaning towards agreeing with only adding one of these, I > disagree this is a substantial cost for > ALL receivers. > > In reality, there are likely <20 implementations, and although it's an > increase in cost for the implementations, > it's not a heavy one. > > For receivers, the cost is going to be in upgrading, which is required if > they want to support any new algorithms, > regardless of how much new functionality is in that upgrade. > > Perhaps the increased cost of updating implementations will lead to some > implementations not being updated, > which means receivers would have to switch implementations, which is a > higher cost than a simpler upgrade... > but second order effects are going to be much smaller anyways. > > Also, if we're voting on choosing, I'd go with adding EC, as I feel that > allowing different algorithms makes > DKIM more robust in the face of the possibility of a breakthrough against > an existing algorithm. > > Brandon > > On Fri, Jul 21, 2017 at 2:57 PM, denis bider > wrote: > >> I agree. Every algorithm added is: >> >> - an incremental improvement in options available to some senders, but >> >> - a substantial increase in cost for ALL receivers. >> >> If it's possible to address the needs of senders by adding only one of >> RSA-FP or EC, but not both, that would be welcome for implementers of >> receivers. >> >> >> On Fri, Jul 21, 2017 at 3:18 PM, Jim Fenton >> wrote: >> >>> This is a repeat of a question I asked via Jabber in the WG meeting >>> yesterday, and didn't get much response probably because I worded it >>> tersely for Jabber and couldn't expand on the question easily. >>> >>> At the outset of this WG's formation, it was noted that there are two >>> approaches to the problem with DNS record length with large RSA keys: >>> (1) hash the keys, put the public key into the message and the hash in >>> DNS; and (2) use a different algorithm such as elliptic curve that has >>> shorter public keys. >>> >>> In the discussion about supporting both hashed and unhashed keys >>> (particularly the question of whether to hash the elliptic curve keys as >>> well), John Levine said: >>> >>> "Since there is no negotiation between the sender and the receiver, a >>> receiver must implement every possible crypto scheme that any sender >>> might use to interoperate. I would rather minimize the number of schemes >>> and just add two rather than three." >>> >>> I agree with John that keeping the number of schemes to a minimum is >>> good. Given that (1) and (2) above solve the same problem, why do we >>> have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the >>> other, or are there good reasons for some signers to use hashed RSA and >>> others to use EC? >>> >>> -Jim >>> >>> >>> _______________________________________________ >>> 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 >> >> > --001a1147fa248c99e00554dc2a46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Only 20 implementations for DKIM...?

Em= ail, as we know it, is on the order of 40 years old. I would be very surpri= sed if it has anything short of hundreds of implementations.

=
Many of those implementations support DKIM, and more will do so = in the future.

If we want to one day be able to as= sume that DKIM is supported universally, it needs to be supported not just = by major providers of email-as-a-service, and major publishers of email sof= tware; but also by the long tail.

The long tail in= volves a large number of diverse implementations, many of them using obscur= e software.

I would estimate, if we want to be abl= e to assume DKIM is universal, the number of implementations needs to be cl= oser to 100.

That's a lot of receivers...


On Fri, Jul 21, 2017 at 4:56 PM, Brandon Long <blong@fiction.net&= gt; wrote:
Althou= gh I'm leaning towards agreeing with only adding one of these, I disagr= ee this is a substantial cost for
ALL receivers.

In = reality, there are likely <20 implementations, and although it's an = increase in cost for the implementations,=C2=A0
it's not a he= avy one.

For receivers, the cost is going to be in= upgrading, which is required if they want to support any new algorithms,
regardless of how much new functionality is in that upgrade.
=

Perhaps the increased cost of updating implementations = will lead to some implementations not being updated,=C2=A0
which = means receivers would have to switch implementations, which is a higher cos= t than a simpler upgrade...
but second order effects are going to= be much smaller anyways.

Also, if we're votin= g on choosing, I'd go with adding EC, as I feel that allowing different= algorithms makes
DKIM more robust in the face of the possibility= of a breakthrough against an existing algorithm.

Brandon
<= div>

On Fri, Jul 21, 2017 at 2:57 PM, denis bider &l= t;denisbider= .ietf@gmail.com> wrote:
I agree. Every algorithm added is:

- an in= cremental improvement in options available to some senders, but
<= br>
- a substantial increase in cost for ALL receivers.

If it's possible to address the needs of senders by add= ing only one of RSA-FP or EC, but not both, that would be welcome for imple= menters of receivers.


On Fri, Jul 21, 2017 at 3:18 PM, Ji= m Fenton <fenton@bluepopcorn.net> wrote:
This is a repeat of a question I asked via Jabber in th= e WG meeting
yesterday, and didn't get much response probably because I worded it tersely for Jabber and couldn't expand on the question easily.

At the outset of this WG's formation, it was noted that there are two approaches to the problem with DNS record length with large RSA keys:
(1) hash the keys, put the public key into the message and the hash in
DNS; and (2) use a different algorithm such as elliptic curve that has
shorter public keys.

In the discussion about supporting both hashed and unhashed keys
(particularly the question of whether to hash the elliptic curve keys as well), John Levine said:

"Since there is no negotiation between the sender and the receiver, a<= br> receiver must implement every possible crypto scheme that any sender
might use to interoperate. I would rather minimize the number of schemes and just add two rather than three."

I agree with John that keeping the number of schemes to a minimum is
good. Given that (1) and (2) above solve the same problem, why do we
have both in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the=
other, or are there good reasons for some signers to use hashed RSA and
others to use EC?

-Jim


_______________________________________________
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



--001a1147fa248c99e00554dc2a46-- From nobody Sat Jul 22 01:51: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 CE0E6131C78 for ; Sat, 22 Jul 2017 01:50: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, SPF_HELO_PASS=-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=andreasschulze.de 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 Dtzvk62InNIC for ; Sat, 22 Jul 2017 01:50:57 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:470:77b3:100::7]) (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 ABEF7129B34 for ; Sat, 22 Jul 2017 01:50:57 -0700 (PDT) Received: from [IPv6:2001:470:77b3:50:dc3f:adfc:9e34:e35f] (unknown [IPv6:2001:470:77b3:50:dc3f:adfc:9e34:e35f]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3xF1Z64lHdzMrqNv for ; Sat, 22 Jul 2017 10:50:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1500713454; bh=lODBpZqFibmvOITF2LzNFihEvt0c9676azeUSzjKeqQ=; h=Subject:To:References:From:Date:In-Reply-To; b=royDlZxir0M/JRJrAFgxhgV5ZK+FWKrgKD2d+u+MKBRIYVzIm4Hb7D8w1NlkQUbU2 5fxFp3eElTlowHOBCxhplOhCmP+W584Qyw0iRjv6X6ziX9dAo+z0YvRIyMa3E06Z0S Q1DDOYoxhT6GnP9DL81B1fkm/lPdGQIIlsAc4mY9AjvTDUi6Tat1QhPiRVIrVE/NXe CQAYP3H3fVLd5K1fJV/ScGFQRQpMA4SNXooy6eRe68mOWAMjbgZki2F1X6lXLnucgG xHLe31VTIbVA+3mfy/EwOU0CHY5nIUflQbx5uTZPiJw0P+f7+/gTQiaFsN2vnXG5vy xRCSmeLs9HozA== To: dcrup@ietf.org References: From: "A. Schulze" Message-ID: <3ddaf701-f892-2c3e-feb5-92af12c38f8f@andreasschulze.de> Date: Sat, 22 Jul 2017 10:48:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 22 Jul 2017 08:51:00 -0000 Am 21.07.2017 um 23:18 schrieb Jim Fenton: > At the outset of this WG's formation, it was noted that there are two > approaches to the problem with DNS record length with large RSA keys: > (1) hash the keys, put the public key into the message and the hash in > DNS; and (2) use a different algorithm such as elliptic curve that has > shorter public keys. as DNS operator I prefer any mechanism that result in less DNS response sizes. as DKIM user I MUST wait if any new mechanism will be implemented some day. hashed RSA + smaller DNS response - no new algorithm - need to wait until software is updated - public key location change from dns -> every message unhashed EC Keys + smaller DNS response + new algorithm - need to wait until software is updated + public key stay in DNS only for me there are more + on unhashed elliptic curves. But I'm aware of Ekr's "Hash everything" that make me still a little bit uncertain. hashed EC Keys + smaller DNS response + new algorithm - need to wait until software is updated - public key location change from dns -> every message (+) Ekr is happy I'm sure, in neither case we need both. Andreas From nobody Sat Jul 22 07:37: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 C7E08131C1F for ; Sat, 22 Jul 2017 07:37:43 -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 QMJD2RuwNdkq for ; Sat, 22 Jul 2017 07:37:42 -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 935A5120227 for ; Sat, 22 Jul 2017 07:37:42 -0700 (PDT) Received: (qmail 28468 invoked from network); 22 Jul 2017 14:37:41 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 Jul 2017 14:37:41 -0000 Date: 22 Jul 2017 14:37:18 -0000 Message-ID: <20170722143718.9667.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] Do we need both hashed RSA and elliptic curves? 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, 22 Jul 2017 14:37:44 -0000 In article you write: >-=-=-=-=-=- > >Only 20 implementations for DKIM...? > >Email, as we know it, is on the order of 40 years old. I would be very >surprised if it has anything short of hundreds of implementations. ... >The long tail involves a large number of diverse implementations, many of >them using obscure software. I agree with Brandon: there are not a lot of DKIM libraries. I use an MTA you probably never heard of called Mailfront, but my DKIM plugin uses the same OpenDKIM library that Postfix and many other MTAs do. When OpenDKIM is upgraded, I get the new stuff it handles automagically. By the way, if we have to pick one, I'd pick EC because it's a lot faster, as well as having smaller keys. Its main disadvantage at this point is that it's only partly integrated into the usual crypto libraries (of which there are about three), but I expect that to be fixed pretty soon. R's, John From nobody Sat Jul 22 10:56: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 48AF2131C27 for ; Sat, 22 Jul 2017 10:56:39 -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 VJLfavyRDON0 for ; Sat, 22 Jul 2017 10:56: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 E0169131C15 for ; Sat, 22 Jul 2017 10:56:37 -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 v6MHqclD012077; Sat, 22 Jul 2017 18:56:30 +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=ItSkAiyaZWRTz1cKDDEQhcqR8CFm0VStsGI/acfRSUA=; b=KTazT+O6UBj4C9fLn+uqm4NsWbBJsLb/9HR+Q/3mUAenguXznJX9OIoi3KtQaePoNEqL 09XKgMoGZlXGxL9lzdqC+fwpXuXdoiLMS6laxaydn/ii8377tiwf+22OoheWhUo7bteW thyqHRTuabZLsVSJOSb6cW2zRaStwLwY9eD1CVETNGUURH+OkG8OfXod9l+nIrzZceUm Yb44e7E61TS9qlQxC6TVlEz0Zdg5CQWmDBp0EqHdZxkCQVGUzXiK7bxVeTDYwU9cG7Wp yGiSnHoAscq17Fcii1XG3DadpwkUKK8TBWPFcGgc1S27mSlh7LcARM1QFDkxZtW1Pyvi jg== 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 2buusatayn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Jul 2017 18:56:30 +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 v6MHth04008979; Sat, 22 Jul 2017 13:56:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21u946p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 22 Jul 2017 13:56:30 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 22 Jul 2017 13:56:29 -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; Sat, 22 Jul 2017 13:56:29 -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, 22 Jul 2017 13:56:29 -0400 From: "Salz, Rich" To: Jim Fenton , "dcrup@ietf.org" Thread-Topic: [Dcrup] Do we need both hashed RSA and elliptic curves? Thread-Index: AQHTAmbudSb+ICkG40aYh4ldsCaol6JgIosA Date: Sat, 22 Jul 2017 17:56:28 +0000 Message-ID: <9c0fb6988bb7415d8d4f1b1b19a69a6c@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.45.210] 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-07-22_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-1706020000 definitions=main-1707220290 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-22_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-1706020000 definitions=main-1707220289 Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 22 Jul 2017 17:56:39 -0000 > in draft-ietf-dcrup-dkim-crypto? Shouldn't we pick one or the other, or a= re > there good reasons for some signers to use hashed RSA and others to use > EC? The cost of computation of EC is significantly smaller. From nobody Sat Jul 22 12:27: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 F1B8E129B5E for ; Sat, 22 Jul 2017 12:27:25 -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, 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=sonnection.nl 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 N_1lLCWXRJDx for ; Sat, 22 Jul 2017 12:27:24 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4BB1270AC for ; Sat, 22 Jul 2017 12:27:23 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3xFHhV1fCGz5MgwF; Sat, 22 Jul 2017 21:27:22 +0200 (CEST) Received: from tiger.sonnection.nl (D57E1706.static.ziggozakelijk.nl [213.126.23.6]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3xFHhV0T7pz5MgwC; Sat, 22 Jul 2017 21:27:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tiger.sonnection.nl (Postfix) with ESMTP id F2AE4422288; Sat, 22 Jul 2017 21:27:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at tiger.sonnection.nl Received: from tiger.sonnection.nl ([127.0.0.1]) by localhost (tiger.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uH79WlnHXkCn; Sat, 22 Jul 2017 21:27:20 +0200 (CEST) Received: from [192.168.40.49] (unknown [192.168.40.49]) by tiger.sonnection.nl (Postfix) with ESMTPSA id D2D05422287; Sat, 22 Jul 2017 21:27:20 +0200 (CEST) To: Brandon Long , denis bider Cc: Jim Fenton , dcrup@ietf.org References: From: "Rolf E. Sonneveld" Organization: Sonnection B.V. Message-ID: <562a8d58-3740-18aa-c70f-c2fd07fbc082@sonnection.nl> Date: Sat, 22 Jul 2017 21:27:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1500751642; bh=t5ywCKCzXv+JK95CjCaop0DlWOual++AEzHBk6z963g=; h=Subject:To:From:Message-ID:Date:From; b=Z85BQ4tGOvHjJKARhiEXheQg7z15eCY4/lrpwMQFpLkUc2KhnscxvrtF/I1XuQhmw F8hZaUML7lZDbOiRGq5VVp9Hyk9ToXRCQjEQgkd+xl/j/K59w7d8+W3Fuf8BS5YADK o4gem+2B7BbJH+5yd9qt+QkzTI6vksrSHuxmds0I= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3xFHhV1fCGz5MgwF Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 22 Jul 2017 19:27:26 -0000 On 22-07-17 00:56, Brandon Long wrote: > Although I'm leaning towards agreeing with only adding one of these, I > disagree this is a substantial cost for > ALL receivers. > > In reality, there are likely <20 implementations, and although it's an > increase in cost for the implementations, > it's not a heavy one. > > For receivers, the cost is going to be in upgrading, which is required > if they want to support any new algorithms, > regardless of how much new functionality is in that upgrade. > > Perhaps the increased cost of updating implementations will lead to > some implementations not being updated, > which means receivers would have to switch implementations, which is a > higher cost than a simpler upgrade... > but second order effects are going to be much smaller anyways. > > Also, if we're voting on choosing, I'd go with adding EC, as I feel > that allowing different algorithms makes > DKIM more robust in the face of the possibility of a breakthrough > against an existing algorithm. Except when this breakthrough would be a breakthrough in Quantum Computing, as QC is likely to break ECC sooner than RSA, as was argued earlier this week by Kenny Paterson [1]. Having said that, I do think adding only EC is preferred, as it prevents the overhead of sending the public key, while leaving the domain owners a choice. /rolf [1] https://www.ietf.org/proceedings/99/slides/slides-99-saag-post-quantum-cryptography-01.pdf From nobody Mon Jul 24 01:53: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 D610412EC30 for ; Mon, 24 Jul 2017 01:53: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 (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 xpeRmPo9Lf42 for ; Mon, 24 Jul 2017 01:53:05 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 5A95912EACC for ; Mon, 24 Jul 2017 01:53:05 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id g6so51535766qkf.5 for ; Mon, 24 Jul 2017 01:53:05 -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=GkFah9F9zOvr8Fb3TsCT90Ob+muIgaAmjqf2RHmanfM=; b=PI95NZKo7bI/afG4gQfo2qiywaJCnFK1u57Pj6vRzbbIYK1O4kkPxtsWI3nKu/fHNz hBc0rMEKZDmeKcFNgjsTrOrw9xnVB0Y64yE/3QNq8B/wmDb9B9v6cD88M1k7Rs2lXNNQ Z7LQm3cdoN6/rd2vlNRCRVB7AfIV/qZGO3lECQkiPwkAISbAclzX5eCziZHy+YAb2tNy Qj/BDpr0PD98NbDJYKjm8s6rKCjd2TBbKc0Cl2cIfLeOXYFjZx/4JfTWeiO9FgVhbCoa SPh+SAyl1bxNJdug8WF371PG26Seux+YNpBhK2dyYSnybtpXMcDmIB7dNpTOAWL7vDMt bBNw== 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=GkFah9F9zOvr8Fb3TsCT90Ob+muIgaAmjqf2RHmanfM=; b=FjHDcSJlL8dcESMpUPgoa0c2FZzg0JLv3L7fgL9jAUGy7SKPm9dw+vynLtNId7+6Zp 4fEcRC3W4ws0gr16u7huuYgo0eLZ1IggDr004OkFXKC85JLNs23Y8S+oymhrVBKl0ia9 GfpTcKWx1Xi2AsAd12MpmqqOBLJYtAdNR+eEZCsIHrYmMv5+Cmc9hxEdKxaCnj+3fUZf kzrFG2oaR+dM/aeJoTqSzC15k01qDPnRcZg/OmKrNiDaZj77irm7SOVwpZjcelw9QoHO vlRpMAJEqsONnSwRoAeUFLLHhTmch+fByG+UfoAuJGW+cRwrubMvrok144hNRpCQwYjj BgDw== X-Gm-Message-State: AIVw113usNIoxENqDX2d44n9T2UFHG2Q8wYsdmLjb2EOacK8MTkyRCnb P4amfnuRYVNZGBCnQrp7cjrRmmmSWWd/dAk= X-Received: by 10.55.2.132 with SMTP id v4mr18257212qkg.313.1500886384205; Mon, 24 Jul 2017 01:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.43.33 with HTTP; Mon, 24 Jul 2017 01:52:43 -0700 (PDT) In-Reply-To: <20170722143718.9667.qmail@ary.lan> References: <20170722143718.9667.qmail@ary.lan> From: Seth Blank Date: Mon, 24 Jul 2017 10:52:43 +0200 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11449b70c77b3005550c5706" Archived-At: Subject: Re: [Dcrup] Do we need both hashed RSA and elliptic curves? 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, 24 Jul 2017 08:53:07 -0000 --001a11449b70c77b3005550c5706 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 22, 2017 at 4:37 PM, John Levine wrote: > By the way, if we have to pick one, I'd pick EC because it's a lot > faster, as well as having smaller keys. Its main disadvantage at this > point is that it's only partly integrated into the usual crypto > libraries (of which there are about three), but I expect that to be > fixed pretty soon. > I concur with John --001a11449b70c77b3005550c5706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jul 22, 2017 at 4:37 PM, John Levine <johnl@taugh.c= om> wrote:
By the way, if we have to pick one, I= 'd pick EC because it's a lot
faster, as well as having smaller keys.=C2=A0 Its main disadvantage at this=
point is that it's only partly integrated into the usual crypto
libraries (of which there are about three), but I expect that to be
fixed pretty soon.

I concur with John

--001a11449b70c77b3005550c5706-- From nobody Mon Jul 24 12:29: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 B1774131EEC for ; Mon, 24 Jul 2017 12:29:43 -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, 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=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 biANe8Mcvkdz for ; Mon, 24 Jul 2017 12:29:41 -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 C48A913178B for ; Mon, 24 Jul 2017 12:29:41 -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 v6OJQsPJ006645 for ; Mon, 24 Jul 2017 20:29:40 +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=4krfL5HH68Ky+6UyqzHF3HD2/r5MWTaW2Uf+obp/80w=; b=KJgsAktuXN5ExI6PlOZfX2i+74sI65ldWiQKfVWX4ifEUuTB7MjyhIPAWRihu/eqbbdi E3x+8+wKjYdhvp+2Y3DdvGF5wWHYe9eVihCiZQdXyKMBGbYCAzq3sxKzB92K3stkesC8 xp8YbPb8C+y9JOzXOn2w1l9pQ6iHBkvzVrdm0hniDoAUiqIZdqCBFPOjqtRUaSUI3hjN O6Hwyhtnb6Dth+IjgOEqLwJUaJONOmDvq60b5CWH4T7UxxpOo65ZU0k1xbktI1xzpw8m 5/19Br0eGv/Qei5d9K4mCw/6kz78kpIgPzIKorp0hREeDo7fdvnzrEPsdDpvysUGFOTN tQ== 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 2buwyqsgh7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Jul 2017 20:29:39 +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 v6OJQT0I008850 for ; Mon, 24 Jul 2017 15:29:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bv21uq5jc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 24 Jul 2017 15:29:38 -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, 24 Jul 2017 12:29:37 -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, 24 Jul 2017 15:29:37 -0400 From: "Salz, Rich" To: "dcrup@ietf.org" Thread-Topic: Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVA= Date: Mon, 24 Jul 2017 19:29:35 +0000 Message-ID: <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> 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.32.112] 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-07-24_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-1706020000 definitions=main-1707240296 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240296 Archived-At: Subject: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 19:29:44 -0000 QXQgbGFzdCB3ZWVrJ3MgSUVURiB3ZSBkaXNjdXNzaW9uICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRjcnVwLWRraW0tdXNhZ2UNCg0KVGhlIGJpZ2dlc3QgZGlz Y3Vzc2lvbiBwb2ludCB3YXMgYWJvdXQgdGhlIGRlcHJlY2F0aW9uLiAgQ29uc2Vuc3VzIGluIHRo ZSByb29tIHdhcyB0byB1c2UgTVVTVCBOT1QgZm9yIGJvdGggZ2VuZXJhdGluZyBhbmQgYWNjZXB0 aW5nIFNIQTEgYW5kIHNob3J0IFJTQSBrZXlzLg0KDQpJbiBvcmRlciB0byBtYWtlIHN1cmUgdGhh dCB3ZSBoYXZlIGhlYXJkIGFsbCBzaWRlcyBvZiB0aGlzIGlzc3VlLCAgd291bGQgdGhvc2Ugd2hv IHN1cHBvcnQgc29tZXRoaW5nIG90aGVyIHRoYW4gTVVTVCBOT1QgcGxlYXNlIHBvc3QgYnkgbmV4 dCBXZWRuZXNkYXk/DQoNClRoYW5rIHlvdSENCg0K From nobody Mon Jul 24 12:54: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 6312A131EEC for ; Mon, 24 Jul 2017 12:54:01 -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 KGsKJUI_oaAu for ; Mon, 24 Jul 2017 12:53:59 -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 A2FC3131461 for ; Mon, 24 Jul 2017 12:53:59 -0700 (PDT) Received: from [IPv6:2601:647:5500:1330:12f:5fc1:c6f9:793a] ([IPv6:2601:647:5500:1330:12f:5fc1:c6f9:793a]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6OJrueJ030659 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 24 Jul 2017 12:53:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1500926038; bh=nd8aII7Y8XHo4QxLx6B/sqIDjU1wjs2kw0GEnEDJUoI=; h=Subject:To:References:From:Date:In-Reply-To; b=DW9+xvJLbSdPxGu/ZU4/QVvJjnTu1XwOu26pbohpBcnPUeRuY1uCVjYJlVZkAdiuB Thq4g10Oc1jizqMWG7ethPqK4inQZp7oF+7uuDtjvbHlzG5Sye4IjL7BGhfwl3G9q7 J/Du730uuQWS1VhsKa18cry8TalRxBPCS/NOeFGQ= To: dcrup@ietf.org References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jim Fenton Message-ID: Date: Mon, 24 Jul 2017 12:53:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 19:54:01 -0000 On 07/24/2017 12:29 PM, Salz, Rich wrote: > At last week's IETF we discussion https://datatracker.ietf.org/doc/dra= ft-ietf-dcrup-dkim-usage > > The biggest discussion point was about the deprecation. Consensus in t= he room was to use MUST NOT for both generating and accepting SHA1 and sh= ort RSA keys. > > In order to make sure that we have heard all sides of this issue, woul= d those who support something other than MUST NOT please post by next Wed= nesday? As I have said before, I support MUST NOT sign but oppose MUST NOT accept. The argument for MUST NOT accept is that we need the force the issue to get people to stop signing with SHA1. I don't agree with this argument because: 1. While we want to get people off SHA1, it doesn't enable an attack and none is anticipated in the near (next several years) future. By "attack", here means that someone is able to sign a different message given an existing DKIM signed message (or many of them). I believe this would require somewhere between a first and second preimage attack. 2. In the absence of an anticipated successful attack, I lean toward interoperability. 3. MUST NOT sign should be sufficient to get domains to do the right thin= g. I am even more opposed to "MUST NOT implement SHA1". Our standards should be dictating what to do, not prohibiting code from existing in implementations. -Jim From nobody Mon Jul 24 12:56: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 DBC15131EFC for ; Mon, 24 Jul 2017 12:56:57 -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, 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=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 1jA0SzoEIB-u for ; Mon, 24 Jul 2017 12:56:56 -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 7E8F0131EFE for ; Mon, 24 Jul 2017 12:56:56 -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 v6OJqR7O029147; Mon, 24 Jul 2017 20:56: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=nGE7Fw63+sYTk6fHHoiHFadjYaxWT/FB8x42G04ZHHA=; b=J9AA8x6cKoP/8Fc2o5x9phkAYMViFmUUzICfQsHI796lSIroIHgFQzBPn49OsYnG0OOh LWQxmB/hPYqC2jfFkaWJMPRwjhIqzb/vGS9krKP2faD/VhliPHj08e6DAbKqkk5jCtvZ UCXThsgU9zyQnhZyf2lMHQXMdDKAulbgoOBMdhJbJvKPoGAUzJtMvWRQe03uj7fWol/U aENKSrIA6aPklf6eKHDzaZ5N8pNMdOsY65oQunfmg5dhv7eb/X0jIjOFBg87CQuriQPK AWN7TLswmB9jIdGy6XYLydTbcumgGQF8uSlMBDruSzwvQZAVoUjF6qT7VQ5wPN8D7NCS Bg== 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 2buwyqsmf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 20:56:50 +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 v6OJtdIP007742; Mon, 24 Jul 2017 15:56:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21uf884-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 15:56:49 -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, 24 Jul 2017 15:56:48 -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, 24 Jul 2017 15:56:48 -0400 From: "Salz, Rich" To: Jim Fenton , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg Date: Mon, 24 Jul 2017 19:56:47 +0000 Message-ID: References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> 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.32.112] 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-07-24_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-1706020000 definitions=main-1707240304 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240303 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 19:56:58 -0000 > I am even more opposed to "MUST NOT implement SHA1". Our standards > should be dictating what to do, not prohibiting code from existing in > implementations. We should not say MUST NOT implement. Do we? From nobody Mon Jul 24 13:04: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 05782131F01 for ; Mon, 24 Jul 2017 13:04: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, 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 CvxTXrnzJsuZ for ; Mon, 24 Jul 2017 13:04:51 -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 B09BF131EFE for ; Mon, 24 Jul 2017 13:04:51 -0700 (PDT) Received: from [IPv6:2601:647:5500:1330:12f:5fc1:c6f9:793a] ([IPv6:2601:647:5500:1330:12f:5fc1:c6f9:793a]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.4/8.14.4/Debian-8+deb8u1) with ESMTP id v6OK4oa7030776 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 24 Jul 2017 13:04:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1500926691; bh=/ticdMkLAYJWrXJHZsm3PCiJu3OvYIM2QKPUS4rpdpY=; h=Subject:To:References:From:Date:In-Reply-To; b=OtzH3qm6JAMmnB+JGSqdxshIqCg7OzfuQQV2vhLbVwBVRuByxpl4gLxqA4uMEytJF vSImrFUN7vVHsxhk62rbEjcXYkIYPP8rNQWmMzkGI056Q9mCUeTrtfQmgYpTlb0YVy yIRtIQlHFUyQHhzuRnnp3MEz6Iy4aUIWTc4DgCh4= To: dcrup@ietf.org References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jim Fenton Message-ID: <0b4fc045-93d6-1ce7-2abb-464c8dcc46df@bluepopcorn.net> Date: Mon, 24 Jul 2017 13:04:44 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 20:04:53 -0000 On 07/24/2017 12:56 PM, Salz, Rich wrote: >> I am even more opposed to "MUST NOT implement SHA1". Our standards >> should be dictating what to do, not prohibiting code from existing in >> implementations. > We should not say MUST NOT implement. Do we? > Other IETF standards say MUST NOT implement, RFC 6944 for example. I thought I heard someone mention that wording in the WG meeting the other day which is why I brought it up. From nobody Mon Jul 24 13:06: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 BE220131F03 for ; Mon, 24 Jul 2017 13:06: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, 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=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 s_grwehOytqr for ; Mon, 24 Jul 2017 13:05:57 -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 BAA91131EFE for ; Mon, 24 Jul 2017 13:05:57 -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 v6OK2Wi8022803; Mon, 24 Jul 2017 21:05:53 +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=HHuFaAjD1sWw1wEQzPLMQXjD98wTCx5nxJZw0TFyht8=; b=h3/Dm5r2IlDSCwWLkXi6Sc5HDb1W9yw58C+Onfbu9sYt5DPe/U30/tu4Basu1BZlGbkC 13juVSbql8gvv0visqWqZNwWtyQWMUwsqXPrVC2ECzN+2xab1BUO2U63TXNSVV85dGDV GDsexYUI96v+fwlt+dFFcZ/jv4ZcYMgC+XuOgs8g4iqbnvRi2zR0+3gC+Vain8Y7tP7B M7jQEK/tNveJ57PD4LjVf+qduHT2DZyi0zwx03iaTgwry18UUxY2swT34qhq1F12RlGG /fWAvByndaU1Ufu7W3eZt9JA/no9/mzsoSo/Zsu4eAZmhF0Ro7+YyT+u6ui+M7tCa6m8 Zw== 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 2bux87sn4v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 21:05:52 +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 v6OK14XN011609; Mon, 24 Jul 2017 16:05:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21uf95k-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 16:05:51 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 16:05:50 -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; Mon, 24 Jul 2017 16:05:50 -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, 24 Jul 2017 16:05:49 -0400 From: "Salz, Rich" To: Jim Fenton , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///AsQCAAELkkA== Date: Mon, 24 Jul 2017 20:05:49 +0000 Message-ID: <0e476f6c27df47939f8c2c288637f78b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> <0b4fc045-93d6-1ce7-2abb-464c8dcc46df@bluepopcorn.net> In-Reply-To: <0b4fc045-93d6-1ce7-2abb-464c8dcc46df@bluepopcorn.net> 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.32.112] 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-07-24_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-1706020000 definitions=main-1707240306 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707240307 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 20:06:01 -0000 > Other IETF standards say MUST NOT implement, RFC 6944 for example. I > thought I heard someone mention that wording in the WG meeting the > other day which is why I brought it up. Timo brought it up and said that it cause[sd] problems for IPsec and that w= e shouldn't do it. From nobody Mon Jul 24 13:36: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 5EF84131F1B for ; Mon, 24 Jul 2017 13:36: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 (2048-bit key) header.d=andreasschulze.de 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 dlDsKlUR8uv9 for ; Mon, 24 Jul 2017 13:36:49 -0700 (PDT) Received: from mail.somaf.de (mail.somaf.de [IPv6:2001:470:77b3:100::7]) (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 BEE62131F1A for ; Mon, 24 Jul 2017 13:36:49 -0700 (PDT) Received: from [IPv6:2001:470:77b3:50:f1b9:55af:90a:a491] (unknown [IPv6:2001:470:77b3:50:f1b9:55af:90a:a491]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: sca@andreasschulze.de) by mail.somaf.de (Postfix) with ESMTPSA id 3xGY7d6wQRzMs5Xh for ; Mon, 24 Jul 2017 22:36:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andreasschulze.de; s=ybz; t=1500928606; bh=CsAjC/GGtV3onWCigO0IqF04O1pHsTUv10wU6jHszW4=; h=Subject:To:References:From:Date:In-Reply-To; b=ERpdZbdXAYVUpK7EjUzMqw2VCh7VS8bzYJrgKPeU8PvrYuuJyE36z7kYWReox3fT6 kHg/vKWlkx1WzGMHtOl7+JoIl6/ha6Oxksa4J+8xlttLlZJN1S/iFxfPZDIQeZJTWf cDsyMdITlkN6RlIOxL6tRbbEInDAyss4COkbKWFEq2skhVk4I3jtZib2ftLFetQTvr Mf4msj4oku3AL5fHIEB3CisZxJ4YDR+iSC+CQXpLkKv+QR6NDV8ugYGQL70OqTxKro 6VAwItS4KtQjAetCavevWAHA2lNIrwflPsmWtLMEsr+U6cn/S5QCAoWr7j7mLBpIhW 24zQFcA6+JxpA== To: dcrup@ietf.org References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> From: "A. Schulze" Message-ID: <9c777ce3-f608-832c-9df5-2295a8a87010@andreasschulze.de> Date: Mon, 24 Jul 2017 22:34:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 20:36:52 -0000 Am 24.07.2017 um 21:56 schrieb Salz, Rich: > We should not say MUST NOT implement. Do we? I like "MUST NOT implement". I see no benefit on "SHOULD NOT validate SHA1" My server - my rules - but my users, too. "MUST NOT validate" is a justification to /my/ users. They don't ask if any other organization behave wrong, they ask me (as their ISP) Responding with "the sender MUST NOT sign" is not enough. Users understand "SHA1 = broken". That's what we, the industry, claim for more then 10 years. But they don't distinguish the fine difference between "SHA1 is bad in certificates but still acceptable in DKIM signatures" ? SHA1: MUST NOT implement. any operator running a software that implement SHA1 is free to not enforce MUST NOT for it's local requirements. So there is no real damage... Andreas From nobody Mon Jul 24 13:42: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 C67E2131F20 for ; Mon, 24 Jul 2017 13:42:32 -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, 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=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 TkrBbsDuwYdR for ; Mon, 24 Jul 2017 13:42:30 -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 80C1B131F1A for ; Mon, 24 Jul 2017 13:42:30 -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 v6OKb1lP032431; Mon, 24 Jul 2017 21:42:12 +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=SRx5OvP5xSd7v1ZAHQVbkMsaJv/bZszPeHnXjXD2dKo=; b=AqSDvhEyKt41Tc9N7bboMDYqRUPnACuuCrvdhLAPTcwEJJg/z/NYMVjx+okEZ7QxMRGr RNYsiU+515W1WsUnd6HvxQ49MIyxO79fOaJloQXTFOXYzuy3f7I5hTtYC3eYHbZmeXcV 5PafFq+FsEVN+boea03G5roalL6Ce50uTgrGzpDUvg2Dsk3v8rsEE3VsCXX9RfoEdKer O9ahHWHdPpQtt8KSgenMgtpTmtMV+DNS2h8ymCsXGrbIYm7DmVYnHYWwqKi/kJHDyJ7n Lb9nsg929eG+73AEBN4yrvspXHzMS1swZjYpBVaQvk3WLALYlP6i9PdZ6xvoViVIr2He HQ== 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 2buwyqst74-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 21:42: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 v6OKfDSC006588; Mon, 24 Jul 2017 16:42:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21ufchm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 24 Jul 2017 16:42:10 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 24 Jul 2017 13:42:10 -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, 24 Jul 2017 16:42: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; Mon, 24 Jul 2017 16:42:10 -0400 From: "Salz, Rich" To: "A. Schulze" , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4A== Date: Mon, 24 Jul 2017 20:42:09 +0000 Message-ID: <7c8f94df8e674f23a0e23680ab8576fb@usma1ex-dag1mb1.msg.corp.akamai.com> References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> <9c777ce3-f608-832c-9df5-2295a8a87010@andreasschulze.de> In-Reply-To: <9c777ce3-f608-832c-9df5-2295a8a87010@andreasschulze.de> 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.32.112] 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-07-24_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-1706020000 definitions=main-1707240316 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-24_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-1706020000 definitions=main-1707240315 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 20:42:33 -0000 I am sorry, I used the word "implement" and then said "we should not use th= at." Let me rephrase. Do not generate, do not validate SHA1 and short-key RSA. Jim disagrees and wants validation to remain. > Users understand "SHA1 =3D broken". That's what we, the industry, claim f= or > more then 10 years. > But they don't distinguish the fine difference between "SHA1 is bad in > certificates but still acceptable in DKIM signatures" ? Yes, the chance of confusing the user community seems very high. From nobody Mon Jul 24 15:26: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 89BE2127342 for ; Mon, 24 Jul 2017 15:26:07 -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 REqrZdSTb4IB for ; Mon, 24 Jul 2017 15:26:06 -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 E9B411267BB for ; Mon, 24 Jul 2017 15:26:05 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id a18so1186299qta.0 for ; Mon, 24 Jul 2017 15:26:05 -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=+mF14xBDLIKRRhGuHZQtUe9GUrBm51wclw/W/I9CiBg=; b=BIdzYFJX8it2eDruUITGa9uWCjRri57UkDz017s6xQ03GIDTdbQzQBBydpz3iGi+mx 3HGcikh+vQ6uVX3SGmV1UbqAH8fNBqICUE4kbgNkAsH/LW412KLg2EiQhD7buEaf4VJB AIhRdATQwwnCSyDyhNZvhnL3/icVbZ2W+J4+VUbm1W2ujw9Iipu1PH44VWnm5FDipr30 lAax8CaHqxhw/0VQIqPXD3XpHYIvtPnAE7C7tQcHWX2k0bnSTu0eanLdgbvqT8vRFkor GfZAPLjRbDiN1PNWlOqthMAz9vf8y1qv7oH3ixUC1m4GGS4kHIu00fso5dufrYw8aoHA E4pA== 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=+mF14xBDLIKRRhGuHZQtUe9GUrBm51wclw/W/I9CiBg=; b=AEPwc5gslCMfHizkXj86hfWE0gpJUpkjmP2bQaQFv5pYi1L8AjPZV8PS6lCf7/YtSb L9b56f4c5MX7bbYMaUl01KeRVioeLkAE18JwPAWyNXS7Ge/IO3MJM7QrxC5ZiCZ97ebr qTz0rB6QdEW9sdFugiAIDex4z3L9qXWzfILsKYY/J2s5YIyqLfZDVHNCEezV1UqAz4nS q+GHjZbTSBQSBWvuPQoDUKLXT12DqpWBQDSo4AmlDBh9/cWoG6BdZfg/32qjrJrXV02V XlBOkaBsJAvDw/pOGgKJQrQlqDQWDrwo4ilxBLCkF0PI8wBKeFYxAYzLibo0WDWofSpL GncA== X-Gm-Message-State: AIVw111FgLGAZKVyLBH1h1jmBxfN+0PS8r0DoRmIFv7KHZzfCMKQQIJ6 l0yblJIoc81WI8tGQ5W5rjBmcYPddQ== X-Received: by 10.200.40.135 with SMTP id i7mr11453748qti.55.1500935165076; Mon, 24 Jul 2017 15:26:05 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.200.2.9 with HTTP; Mon, 24 Jul 2017 15:26:04 -0700 (PDT) In-Reply-To: <7c8f94df8e674f23a0e23680ab8576fb@usma1ex-dag1mb1.msg.corp.akamai.com> References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> <9c777ce3-f608-832c-9df5-2295a8a87010@andreasschulze.de> <7c8f94df8e674f23a0e23680ab8576fb@usma1ex-dag1mb1.msg.corp.akamai.com> From: Barry Leiba Date: Tue, 25 Jul 2017 00:26:04 +0200 X-Google-Sender-Auth: YRUfuI3OD6D0hWxm5o55T58RaJY Message-ID: To: "Salz, Rich" Cc: "A. Schulze" , "dcrup@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 24 Jul 2017 22:26:08 -0000 >> Users understand "SHA1 = broken". That's what we, the industry, claim for >> more then 10 years. >> But they don't distinguish the fine difference between "SHA1 is bad in >> certificates but still acceptable in DKIM signatures" ? > > Yes, the chance of confusing the user community seems very high. Really? To whom are you referring when you say "users" and "user community"? Surely not the vast majority of email users in the world, almost none of whom have the slightest idea what SHA1 is, much less whether or not it's broken. If what you're referring to by "users" is the set of people who are responsible for deploying DKIM software, well... those aren't "users", and, anyway, most of them don't look at the DKIM specs anyway. Someone's going to sell them software along with configuration advice, and they're going to install it and configure it based on that advice. If what you're referring to by "users" is the set of people to develop/code DKIM implementations, well... those are the people who are, or at least ought to be, reading the DKIM specs. We need to make sure we're saying the right thing to those people, so they can right code that works and interoperates and configuration advice that helps the group in the paragraph above properly configure their systems. If you really think *that* group of people will be confused by the advice we're giving on SHA1, then it's pretty easy to include an explanation of *why* we care as far as we do and not farther, and why we want to get people to stop using SHA1 but aren't ready to drop a bomb on it yet. Barry From nobody Mon Jul 24 18:48: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 0651412702E for ; Mon, 24 Jul 2017 18:48:20 -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 Tsw_M3N_Vvxi for ; Mon, 24 Jul 2017 18:48:18 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 527891201F8 for ; Mon, 24 Jul 2017 18:48:18 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id v205so13589968itf.1 for ; Mon, 24 Jul 2017 18:48: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=MMcgRyBk7z3sDiIp26v4V/Q3+AApwf/htsivIr4Xgw0=; b=OwRnK7KFc7e5jqtXAd/wkiaqYdy2JbyqH3w7DrYOAP5UEhlpRIKJwi1ps1F7IELWej LgX6tw15jULgETJR5kAQpbEs4nBcGxmwT7yO4nuD1L9WFkXuLtPDNqViDK3Dg1jrhZX0 UsG18S2otj3H1+HugmUxBhOWeTKBcV068kvfbZ2uHhI7mLn+tXWz+KivISTc9+r1Pn49 /cZAaBsLtsWhlUtV8YFiBuoJtOQAcpwICzN03Z2m9ixQCnRi0A3+4hm6Hqz4DRW/oIjm XhyGBT7kK+sbN4HsyzJ7eS6MekZ/NpkTcvA9M1u+naf4Z1QnakZOzuJCsUIhmUn9Mqh3 CIKQ== 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=MMcgRyBk7z3sDiIp26v4V/Q3+AApwf/htsivIr4Xgw0=; b=WNiD0UDw2327MXFg5u5xz7weenUrFIbxxpDHJDhsJ2YIxu/sAz6+YMEqZBooVdXTRm oYhcXvllGJa7Bvi6ei6+0YdOeVLhNv5x9dAuWJOt5TyZama2OSIR2B1H2tfns0qPQ0cg y+m14FtWu1zalE7c3pU3ZPj76JzOmdf1f4eTDm84L43gf+hCvke3rumkJ8zz6iYjVVzD JeTMgEL4rTdIBrPh1c7jjyrbhV0hlUWg7cvktAZjZKQWnfR2h9A7atb4ZbaWP5jYuLG5 m4bWsRTnHVCn6BvKU9yLX/2D/yfCsQZaqsiG9yLZeVD1YaVeBJy1d6XJl3Ib+GtZeczo MJeQ== X-Gm-Message-State: AIVw111nWc2+TebeYo+D4r/j/CMcDmCF8hSz771H//fLBn1gaguBAFNE K9v9FfDkQETqOKACH5QE4SSFPN0KwOBIpW4= X-Received: by 10.36.3.72 with SMTP id e69mr9473803ite.154.1500947297657; Mon, 24 Jul 2017 18:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 24 Jul 2017 18:48:16 -0700 (PDT) In-Reply-To: <84372b7e-d037-3124-10c8-d2f4285059fa@bluepopcorn.net> References: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.msg.corp.akamai.com> <84372b7e-d037-3124-10c8-d2f4285059fa@bluepopcorn.net> From: Martin Thomson Date: Tue, 25 Jul 2017 11:48:16 +1000 Message-ID: To: Jim Fenton Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Notes from IETF99 dcrup meeting 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, 25 Jul 2017 01:48:20 -0000 On 22 July 2017 at 06:52, Jim Fenton wrote: > Yoav was channeling me from Jabber here. The actual question was, "If we are > trying to minimize the number of things that need to interoperate, do we > need both hashing and elliptic curve? Aren't they two ways of solving the > same problem?" John's response was a shrug. My understanding of this situation was that there was a desire to provide an easy path for existing implementations where adding wholly new cryptographic algorithms is not feasible. That is, their existing RSA signing/verification code could be used, just with larger keys and a relatively small tweak to support hashing. At the same time, performance for Ed25519 is considerably better on a few dimensions. Having two options (making three in total) does increase complexity considerably, particularly since it is likely that all signatures would need to be used to ensure that a signature could be accepted. From nobody Mon Jul 24 22:05: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 23106126BF3 for ; Mon, 24 Jul 2017 22:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.333 X-Spam-Level: * X-Spam-Status: No, score=1.333 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_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=N6B3F4BH; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=S6m4xo3W 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 uqrSsWukxZGg for ; Mon, 24 Jul 2017 22:05:23 -0700 (PDT) Received: from ntbbs.winserver.com (mail.catinthebox.net [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 50DF7126B7E for ; Mon, 24 Jul 2017 22:05:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1430; t=1500959122; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Ec6fEgNsJfgOW9dYplQE07gKAaw=; b=N6B3F4BHH7P+FHTDCEGKqszLf3r+1AiqDUG79LtOtRuT2FPXFgSOz5DDsLu15I gY1JDduBfh3zonqUksOP5Sc8hwP2JVTHIlm/ud8DVGlkyMgOBMO1NvS4RbTyhJbp Mc9Pfg41od1lMBnHlOcjJ5sEYbRJeg7/TZ9DZk9AREY/I= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 25 Jul 2017 01:05:21 -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.6) with ESMTP id 1022999387.1.3768; Tue, 25 Jul 2017 01:05:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1430; t=1500958851; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=BQBczzy 7gwgTf8bSlmM02rYvTR56Jrlzdc11C8f2/1U=; b=S6m4xo3WLiqc/oiXMhmkbLo WReQOhpwkpdmK0i6SpbFpV/Lckt53dm6ocvf//TK39tWOlBEd6N44OOYJAgdESYi KImX1vvvZSAsFGy+Q65PwSvv9/ZwGSXT+E57LX+ChatOPN2guMF36R4UGSijODGM CRZI9BIheV8iF7w3IuVI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 25 Jul 2017 01:00:51 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1565522127.9.199292; Tue, 25 Jul 2017 01:00:50 -0400 Message-ID: <5976D18D.3090707@isdg.net> Date: Tue, 25 Jul 2017 01:05:17 -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: "Salz, Rich" , Jim Fenton , "dcrup@ietf.org" References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 25 Jul 2017 05:05:25 -0000 On 7/24/2017 3:56 PM, Salz, Rich wrote: >> I am even more opposed to "MUST NOT implement SHA1". Our standards >> should be dictating what to do, not prohibiting code from existing in >> implementations. > > We should not say MUST NOT implement. Do we? -1, No. You're not going to stop everyone from covering all existing protocol options, including legacy operations. You're not paying for my support issues when complaints come in reporting that our "New DKIM package with only SHA256 support" does not support valid incoming mail with SHa1. You're not going to force people to update or upgrade when in all honestly SHA1 is still valid today. Most people don't change until a real problem exist and I think this will also cause major problems for valid senders who all of a sudden have their SHA1 DKIM mail not accepted at SHA256 receivers. If you want to discuss this in the specification, I think we are smart enough to read amd decide, but to try to "enforce" this, I don't think that would be right. I don't consider that "Protocol Development" personally. Note: This doesn't mean I won't change the DKIM signing options on my system, but I am not about to add logic to reject/invalidate a SHA1 message, nor pull the code to handle it, and I really hope others don't go about pulling SHA1 support on their system causing problems for people who haven't unnecessarily changed yet. -- HLS From nobody Mon Jul 24 22:08: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 29E731274D2 for ; Mon, 24 Jul 2017 22:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.333 X-Spam-Level: * X-Spam-Status: No, score=1.333 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_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=aGWKMfq5; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=Gmu5QPYz 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 MFBJfy5StuZ0 for ; Mon, 24 Jul 2017 22:08:13 -0700 (PDT) Received: from ntbbs.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 205E6126B7E for ; Mon, 24 Jul 2017 22:08:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1654; t=1500959287; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=A0ZigOTKHQ1YHHWXgOmpLBdsgoY=; b=aGWKMfq5mcakBrtJrRegw/OykabUp4mj+ElC/IegJ8imtkzu930jZoOostdLZO 11SU5wtM2+1EcLKr0+v/FbplHhTxqRPW275JwyyCQCvPZ4oPndmAFzyxMgmCMhz7 hwaYrEZQRRKtMUZB1y6TT3VKko6ul/eMDuBIodHYHw5PU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 25 Jul 2017 01:08:07 -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.6) with ESMTP id 1023164748.1.6052; Tue, 25 Jul 2017 01:08:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1654; t=1500959014; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=J+S1Sqd IUXl/05+vAMHWov78820fWzPec0o1Ok62JvU=; b=Gmu5QPYzHejeslr7CJWs3IN J6dAk+8BUsHL6BmPACfgB/CW4okOX/5oPF8hy8UJknJhN6127SJ0ObQrfjXsDAHH sKzGh3EmSTjCP9jZv7PaiEFQAaxY8RyA9qtX5KuS7iVFeZcTK8eWA55pcKElK5vU MFfI7t/JR2OL8nUqjNZA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Tue, 25 Jul 2017 01:03:34 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1565685112.9.204740; Tue, 25 Jul 2017 01:03:33 -0400 Message-ID: <5976D230.6070100@isdg.net> Date: Tue, 25 Jul 2017 01:08: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: "Salz, Rich" , Jim Fenton , "dcrup@ietf.org" References: <121498c5d3d742b79d35dbca85e15d42@usma1ex-dag1mb1.msg.corp.akamai.com> <404d581352d243aeabc24cd9396d0724@usma1ex-dag1mb1.msg.corp.akamai.com> <5976D18D.3090707@isdg.net> In-Reply-To: <5976D18D.3090707@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 25 Jul 2017 05:08:14 -0000 Sorry, misread the double negative. It should be a "SHOULD NOT SIGN" security concept. Thats it. Its not that difficult. On 7/25/2017 1:05 AM, Hector Santos wrote: > On 7/24/2017 3:56 PM, Salz, Rich wrote: >>> I am even more opposed to "MUST NOT implement SHA1". Our standards >>> should be dictating what to do, not prohibiting code from existing in >>> implementations. >> >> We should not say MUST NOT implement. Do we? > > -1, No. > > You're not going to stop everyone from covering all existing protocol > options, including legacy operations. You're not paying for my > support issues when complaints come in reporting that our "New DKIM > package with only SHA256 support" does not support valid incoming mail > with SHa1. You're not going to force people to update or upgrade when > in all honestly SHA1 is still valid today. Most people don't change > until a real problem exist and I think this will also cause major > problems for valid senders who all of a sudden have their SHA1 DKIM > mail not accepted at SHA256 receivers. > > If you want to discuss this in the specification, I think we are smart > enough to read amd decide, but to try to "enforce" this, I don't think > that would be right. I don't consider that "Protocol Development" > personally. > > Note: This doesn't mean I won't change the DKIM signing options on my > system, but I am not about to add logic to reject/invalidate a SHA1 > message, nor pull the code to handle it, and I really hope others > don't go about pulling SHA1 support on their system causing problems > for people who haven't unnecessarily changed yet. > -- HLS From nobody Tue Jul 25 23:15: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 B7939127077 for ; Tue, 25 Jul 2017 23:15:22 -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 70xn5CNKjpT1 for ; Tue, 25 Jul 2017 23:15:21 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 1DF081200ED for ; Tue, 25 Jul 2017 23:15:21 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id v127so62777629itd.0 for ; Tue, 25 Jul 2017 23:15:20 -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=usZQ47FoRZ0damIcr+4UOsLuxwijs11c4zpqCB1m+hQ=; b=fOjTTznv+y2QzL2RR28KTmkhADD282isf+D9GVAPiD1PgBB4RlxHUUBUTag6B2LtdU wUKPF7OLB3nwh6NCxUmNrisXbVjFCVwPRKWqIsmeeDq6NhMvbhzrtmcuSWaGG+qgL5ph 10StWSPcMsqsTMYlFLDG21fY5uepeZ3hzL/FrEYtod11usgCn9LA7KP2rKn3Pty2a5X1 gFgwWb7EvcQChcwjBGSM5x7O8RNiRD98r3RyttroOvnqc2ehNajwagRRNIqz+H6lXOzv PqCMyD2UdhDN1x1jIl5DE/BHM1YyEM3kx20qCT1dhrqyQNt5Jnmt7H7AIFuhrPnJ+qFd 9TfA== 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=usZQ47FoRZ0damIcr+4UOsLuxwijs11c4zpqCB1m+hQ=; b=l12f07SC6JRESe3LytZ98N7bL5DVF86Sr7jWrcSu+SurE8FfHJkISJhLvXus5+jR3f enyc0l2Xbr4LPfm8jhKOT+iIKIYM0OkLHIOgcbUmefo2Ehw9mvq+oZbiRP/yMHv55bzU FAyFqzfbDkEqW08PTc5pIzao2CCH2E+knAsAyo2o4BHCAGrcqt8xJ0Z5igAoz5ofMnRs 78NQD2W3vU0jkVuJMhjBAi3hdZYU4K+80wxv7//aSkh0zh6mT4/4/jNzZwpX+v1qC5+l T1a4C3q4tAQRAVWiWZSv7UlLkQcrnexKEIB54lj7HJQUByS+90fTIyhGgsNOeqDgXtQR VoxA== X-Gm-Message-State: AIVw1136JdIVakqu8bgvdKcSyiV9tfLLmMsJgFPB53ltpwJmo4j0aa30 8cAyU03CD/urlznByUOmzFKQJAI3qSNWcyk= X-Received: by 10.36.53.70 with SMTP id k67mr13819659ita.79.1501049720053; Tue, 25 Jul 2017 23:15:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 25 Jul 2017 23:15:19 -0700 (PDT) From: Martin Thomson Date: Wed, 26 Jul 2017 16:15:19 +1000 Message-ID: To: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Dcrup] Text for duplicate signature key selection attack 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, 26 Jul 2017 06:15:23 -0000 This is for the Ed25519 draft. I've used the kramdown format. I can also provide XML should that be necessary. I don't have the identity of the rsafp draft, so that needs to be filled in. ~~~ ## Duplicate Signature Key Selection The scheme in {{?DKIM-RSAFP=RFC7230}} describes a method where the public key is hashed. The primary motivation for this design is allowing for a smaller key representation of larger public keys. Hashing has a secondary effect: the public key is included in messages and is signed. Including and signing the public key renders duplicate signature key selection attacks {{?DSKS=DOI.10.3934/amc.2013.7.1}} infeasible. An attacker cannot claim a message by constructing a key that would be valid for a signed message because the public key is covered by the signature. There is currently no known way that an attacker might use a duplicate signature key selection attack to their advantage and so defending against the attack is not mandated by this specification. In the event that a potential attack becomes known, a signer could include the public key in messages using the `p=` parameter. If the `p=` parameter is present, a verifier MUST ensure that the parameter contains the public key that it uses to verify the message signature. ~~~ From nobody Wed Jul 26 21:01: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 05FA712EC13 for ; Wed, 26 Jul 2017 21:01:35 -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 6wo8edgnrxPN for ; Wed, 26 Jul 2017 21:01:33 -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 2816C124BE8 for ; Wed, 26 Jul 2017 21:01:33 -0700 (PDT) Received: (qmail 3956 invoked from network); 27 Jul 2017 04:01:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jul 2017 04:01:31 -0000 Date: 27 Jul 2017 04:01:09 -0000 Message-ID: <20170727040109.1235.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: barryleiba@computer.org 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] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 04:01:35 -0000 In article you write: >If you really think *that* group of people will be confused by the >advice we're giving on SHA1, then it's pretty easy to include an >explanation of *why* we care as far as we do and not farther, and why >we want to get people to stop using SHA1 but aren't ready to drop a >bomb on it yet. I hear a lot of large mailers still do SHA-1 largely because they can. Keeping in mind that switching from SHA-1 to SHA-256 is just a configuration change (the code's been there for a decade) how about MUST NOT sign and SHOULD NOT verify? SHOULD NOT means MUST NOT unless you understand why you're doing it anyway, which sounds right in this case. R's, John From nobody Wed Jul 26 21:04: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 9912E131BC5 for ; Wed, 26 Jul 2017 21:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, 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 X84Ls1jOeRta for ; Wed, 26 Jul 2017 21:04:22 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (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 BB2B212EC13 for ; Wed, 26 Jul 2017 21:04:22 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id h199so76906726ith.1 for ; Wed, 26 Jul 2017 21:04:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=z6G/5eCBWEiQO/kvtPMFwniwV00tX3AakQRfP2SBqtQ=; b=bpVyEreq7P3NeCyvLCaaeIlu/dNhQltdyswivPz2gpgeMihUgXAmluH3QszA1P3jEA FOWL58/gQQvtoAId0gST/fzWD6A3KQnm1FyhSpXLlZN0zjchcxmoo9xijtbXTG1mjb61 YqI7yStX7qoxk/zLfvz7YkHxr8igXQUkrSa89zcW0522Zzm7JZIOvyDXP2bzgp/VlVct 2OE9frpU8BOfsG6nRmAqoPokviXeUbs6M2FnxygbkxJclLgdIHZOt0BXWfU7x7ZVaT2V 8B4c9k0QiSW5/InifLAD43WDPXcqX/x5V8A1rpF9Q5AUCldS6FUVpZJBry/zFWX3W/1k +8Hg== X-Gm-Message-State: AIVw112EGTcVlJzNGzgBOwrp3HH8LTwrU/UhX1RCTbuPkAwyzNEXJboU 66CHbTmcMdp19ksWXqTyQwMv2ha+QQ== X-Received: by 10.36.71.135 with SMTP id t129mr3581409itb.141.1501128261987; Wed, 26 Jul 2017 21:04:21 -0700 (PDT) MIME-Version: 1.0 References: <20170727040109.1235.qmail@ary.lan> In-Reply-To: <20170727040109.1235.qmail@ary.lan> From: Barry Leiba Date: Thu, 27 Jul 2017 04:04:10 +0000 Message-ID: To: John Levine , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1145ba72d16fd1055544a87e" Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 04:04:26 -0000 --001a1145ba72d16fd1055544a87e Content-Type: text/plain; charset="UTF-8" I can get behind this. Barry On Thu, Jul 27, 2017 at 12:01 AM John Levine wrote: > In article < > CAC4RtVCrBNEGJMo8qiZH8N7tg9FBuKmz8Qx-nF7XC+g5bAXJCw@mail.gmail.com> you > write: > >If you really think *that* group of people will be confused by the > >advice we're giving on SHA1, then it's pretty easy to include an > >explanation of *why* we care as far as we do and not farther, and why > >we want to get people to stop using SHA1 but aren't ready to drop a > >bomb on it yet. > > I hear a lot of large mailers still do SHA-1 largely because they can. > Keeping in > mind that switching from SHA-1 to SHA-256 is just a configuration change > (the code's > been there for a decade) how about MUST NOT sign and SHOULD NOT verify? > > SHOULD NOT means MUST NOT unless you understand why you're doing it > anyway, which sounds right in this case. > > R's, > John > -- Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ --001a1145ba72d16fd1055544a87e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can get behind this.

Barry

On Thu= , Jul 27, 2017 at 12:01 AM John Levine <johnl@taugh.com> wrote:
I= n article <CAC4RtVCrBNEGJMo8qiZH8N7tg9FBu= Kmz8Qx-nF7XC+g5bAXJCw@mail.gmail.com> you write:
>If you really think *that* group of people will be confused by the
>advice we're giving on SHA1, then it's pretty easy to include a= n
>explanation of *why* we care as far as we do and not farther, and why >we want to get people to stop using SHA1 but aren't ready to drop a=
>bomb on it yet.

I hear a lot of large mailers still do SHA-1 largely because they can.=C2= =A0 Keeping in
mind that switching from SHA-1 to SHA-256 is just a configuration change (t= he code's
been there for a decade) how about MUST NOT sign and SHOULD NOT verify?

SHOULD NOT means MUST NOT unless you understand why you're doing it
anyway, which sounds right in this case.

R's,
John
--
Barry
--
Barry Leiba = =C2=A0(barryle= iba@computer.org)
http://internetmessagingtechnology.org/
--001a1145ba72d16fd1055544a87e-- From nobody Wed Jul 26 21:14: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 7DC2D128961 for ; Wed, 26 Jul 2017 21:14: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, 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 aauddrdyxujE for ; Wed, 26 Jul 2017 21:14:49 -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 C3F28124BE8 for ; Wed, 26 Jul 2017 21:14:49 -0700 (PDT) Received: from kitterma-e6430.localnet (unknown [98.180.144.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0EA70C4005E for ; Wed, 26 Jul 2017 23:14:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1501128887; bh=iYBRK2qwnSgEvXggiWDhXyTiWxAD7oKHTkhUxpA9274=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xovlR0y0350PeyWASNdJdEXEaV8CaDd9peEvstnR4R+SCoPJvvmHsEkSB4bkOcZ/Z KFLUzgrusCJeLhk7ks71TKaPKvfh9sSPpGxNvflfbWh9boCk48LUKioUHL2YuAFJj1 juwT8dsGf8tQi2zfM7jlqc1feMqL7LjiwR/HePWw= From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 27 Jul 2017 00:14:45 -0400 Message-ID: <1574181.Nk75d4j0sL@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20170727040109.1235.qmail@ary.lan> References: <20170727040109.1235.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 04:14:51 -0000 On Thursday, July 27, 2017 04:01:09 AM John Levine wrote: > In article you write: > >If you really think *that* group of people will be confused by the > >advice we're giving on SHA1, then it's pretty easy to include an > >explanation of *why* we care as far as we do and not farther, and why > >we want to get people to stop using SHA1 but aren't ready to drop a > >bomb on it yet. > > I hear a lot of large mailers still do SHA-1 largely because they can. > Keeping in mind that switching from SHA-1 to SHA-256 is just a > configuration change (the code's been there for a decade) how about MUST > NOT sign and SHOULD NOT verify? > > SHOULD NOT means MUST NOT unless you understand why you're doing it > anyway, which sounds right in this case. No one is forced to claim they've updated to the requirements of this new draft. I think MUST NOT sign/MUST NOT verify is much cleaner and it avoids yet another draft later. How long do we wait before we write that one? Let's just rip the band-aid off and get it done. Scott K From nobody Wed Jul 26 21:51: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 CD095128AB0 for ; Wed, 26 Jul 2017 21:51:04 -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 jJ0l42wCJgmS for ; Wed, 26 Jul 2017 21:51:03 -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 27761126557 for ; Wed, 26 Jul 2017 21:51:03 -0700 (PDT) Received: (qmail 18447 invoked from network); 27 Jul 2017 04:51:01 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jul 2017 04:51:01 -0000 Date: 27 Jul 2017 04:50:39 -0000 Message-ID: <20170727045039.1387.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] Text for duplicate signature key selection attack 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, 27 Jul 2017 04:51:05 -0000 In article you write: >This is for the Ed25519 draft. Thanks, will splice it in when I revise it I hope by the end of the week. >~~~ >## Duplicate Signature Key Selection > >The scheme in {{?DKIM-RSAFP=RFC7230}} describes a method where the public key >is hashed. The primary motivation for this design is allowing for >a smaller key representation of larger public keys. Hashing has a >secondary effect: the public key is included in messages and is signed. >Including and signing the public key renders duplicate signature key selection >attacks {{?DSKS=DOI.10.3934/amc.2013.7.1}} infeasible. An attacker cannot claim >a message by constructing a key that would be valid for a signed message because >the public key is covered by the signature. > >There is currently no known way that an attacker might use a duplicate signature >key selection attack to their advantage and so defending against the attack is >not mandated by this specification. In the event that a potential attack >becomes known, a signer could include the public key in messages using the `p=` >parameter. If the `p=` parameter is present, a verifier MUST ensure that the >parameter contains the public key that it uses to verify the message signature. >~~~ > From nobody Wed Jul 26 23:11: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 EA62512708C for ; Wed, 26 Jul 2017 23:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NeCl9wgn20xQ for ; Wed, 26 Jul 2017 23:11:54 -0700 (PDT) Received: from smtp64.ord1c.emailsrvr.com (smtp64.ord1c.emailsrvr.com [108.166.43.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 BB73A13202B for ; Wed, 26 Jul 2017 23:11:54 -0700 (PDT) Received: from smtp17.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp17.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 13F5760152; Thu, 27 Jul 2017 02:11:52 -0400 (EDT) X-Auth-ID: jon@merrymeet.com Received: by smtp17.relay.ord1c.emailsrvr.com (Authenticated sender: jon-AT-merrymeet.com) with ESMTPSA id 9EFB46017D; Thu, 27 Jul 2017 02:11:51 -0400 (EDT) X-Sender-Id: jon@merrymeet.com Received: from [10.0.23.16] (media.merrymeet.com [173.164.244.98]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 27 Jul 2017 02:11:52 -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: <20170727040109.1235.qmail@ary.lan> Date: Wed, 26 Jul 2017 23:11:50 -0700 Cc: Jon Callas , dcrup@ietf.org, barryleiba@computer.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DC1CBCB-662C-4307-A409-386F20A41366@callas.org> References: <20170727040109.1235.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 06:11:56 -0000 I agree with Rich Salz's previous comments that we should not say MUST = NOT. The purpose of a standard is to provide interoperability. It is a = grammar of how to interpret a message. It is not a programming guide nor = an implementation manual. If you want to put in scolding language about = how SHA-1 will cause hair to grow on the palms of their hands, I can get = behind that, too. In practical terms, as much we all want people to get off of SHA-1, the = implementers have to implement. And as much as we might rail about it, = they have do deal with our idealism meeting reality. Beyond that, we = don't have any teeth in this. If someone implements DKIM and does SHA-1 = because their customers demand it, what are we going to do? Type a = protest note to them and hit the keys really hard? What if the = implementer issues a warning saying that ZOMG, if you use SHA-1, you're = not compliant with RFC XXXX? Lest you think that I'm supporting SHA-1, I'm not. I'm being realistic. = Twenty years ago, when MD5 was in a similar state, it was hell getting = people to stop using it. You can lead them to water, but you can't make = them drink. It's better to say SHOULD NOT and have it all stated out, = than to say MUST NOT and have people just know that yeah, yeah, RFCs = aren't to be taken seriously. Jon From nobody Thu Jul 27 04:02: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 A4D75131FC7 for ; Thu, 27 Jul 2017 04:02:53 -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, 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=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 LrWrhGEJHnCV for ; Thu, 27 Jul 2017 04: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 B17741319B4 for ; Thu, 27 Jul 2017 04: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 v6RB2S5W009625; Thu, 27 Jul 2017 12:02:50 +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=F0qseB4w/FRaIGJYATd3TIV1e8uUkp7X0JLD7DrUCyI=; b=Zx2CyU6IeaNuQg34QUZqPdYjvYqMce+osUHnxm7Vynt7nxVTqy9Sautfe6CMjt5ckzl6 jeH4+WzR+SxQchJXoDVbsmYomC/JBVd5xTu9uIaT70L36qidczZWe1HgP2ENa+4juI8+ HdFJ3+alw8C45etDXt8Ygix/fJTsoG8eALSds5V770zUn83sy3cVRRK8/fJPRhmyAEwp 6Fa9gtdiVXOactp4ZSAuaoZYjcjG3fezoajZ7OadaU/BlFVOz2Ztbs+D2g75dGtBbRKA A1ugMYnqoZqZqGdZNP9+OfQgzFXGA9Mfz47Z7AMmYEQIIaVweXNogsVlJ7QiTWFFjn/m 0Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2bxjb4pn0b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 12: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 v6RB2knF012380; Thu, 27 Jul 2017 07:02:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bv21vmkad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 07:02:48 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 07:02:47 -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; Thu, 27 Jul 2017 07:02:47 -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; Thu, 27 Jul 2017 07:02:47 -0400 From: "Salz, Rich" To: Scott Kitterman , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4P//3iUAgAOCSYCAAAPNgP//0TmQ Date: Thu, 27 Jul 2017 11:02:46 +0000 Message-ID: <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> In-Reply-To: <1574181.Nk75d4j0sL@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.40.55] 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-07-27_05:, , 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-1706020000 definitions=main-1707270178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_05:, , 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-1706020000 definitions=main-1707270178 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 11:02:54 -0000 > No one is forced to claim they've updated to the requirements of this new > draft. I think MUST NOT sign/MUST NOT verify is much cleaner and it avoi= ds > yet another draft later. Speaking as an individual, I find this reasoning very compelling. From nobody Thu Jul 27 11:06: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 1AA7A132094 for ; Thu, 27 Jul 2017 11:06: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, 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=Lq/V41eL; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=vHj2Dz6L 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 7mcAp-K6KHcy for ; Thu, 27 Jul 2017 11:06:21 -0700 (PDT) Received: from catinthebox.net (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 345D9132092 for ; Thu, 27 Jul 2017 11:06:20 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1962; t=1501178776; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=XGaj1eRfpJUl3DsBtdsa8pMx1/M=; b=Lq/V41eLxX299EFjWKxSaTV2b3B0SWDf8oYzfYiCn+/QObVbV048NHvcDFKpTj 0zZ3lxlhiY5hL/ymPZPyXk1k97+s1prrmJmmZl5Hm4PJiYXANsD23pq5kdnzFD9n A2nML+lyYvl+RU6P0ssb3SrcqIqbDIJ60z4d5iNstZGpc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 14:06:16 -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.6) with ESMTP id 1242652367.1.4120; Thu, 27 Jul 2017 14:06:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1962; t=1501178504; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fPeTMF9 1h9VxzHoAz9AaQ+lpiB540sp0gUBQMvv5oQM=; b=vHj2Dz6LHhHqW0wW8ulSeWD MYiotrlnRjBlVPGiJLUB9QJEKSkKY+18Ft2rgalvpy84BbrECkFWUfRJStsxqY6W VMBjAnpm5InYQ6hRR+Okw4gvjr87evXR2DS8seMdNpu0n+3gUeckKjmEWHMAmttD o0K95JHLi9u9k29sm1uM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 14:01:44 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1785174440.9.512068; Thu, 27 Jul 2017 14:01:43 -0400 Message-ID: <597A2B9A.8060308@isdg.net> Date: Thu, 27 Jul 2017 14:06:18 -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: <20170727040109.1235.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 18:06:24 -0000 -1, I can't get behind a "SHOULD NOT verify with SHA1." I don't see me turning off SHA1 verification in my package unless it comes with some additional conditions, such as: SHOULD NOT verify with SHA1 IFF you don't trust the source, i.e. unsolicited, unauthenticated sessions. or stated another way: SHOULD only verify with SHA1 if you trust the source, i.e. authenticated sessions. At best, this is just another local policy consideration, a BCP which means that the DKIM specs needs to say both SHA256 and SHA1 MUST be implemented for legacy and migration reasons. -- HLS On 7/27/2017 12:04 AM, Barry Leiba wrote: > I can get behind this. > > Barry > > On Thu, Jul 27, 2017 at 12:01 AM John Levine > wrote: > > In article > > > you write: > >If you really think *that* group of people will be confused by the > >advice we're giving on SHA1, then it's pretty easy to include an > >explanation of *why* we care as far as we do and not farther, and why > >we want to get people to stop using SHA1 but aren't ready to drop a > >bomb on it yet. > > I hear a lot of large mailers still do SHA-1 largely because they > can. Keeping in > mind that switching from SHA-1 to SHA-256 is just a configuration > change (the code's > been there for a decade) how about MUST NOT sign and SHOULD NOT > verify? > > SHOULD NOT means MUST NOT unless you understand why you're doing it > anyway, which sounds right in this case. > > R's, > John > > -- > Barry > -- > Barry Leiba (barryleiba@computer.org ) > http://internetmessagingtechnology.org/ > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > From nobody Thu Jul 27 11:15: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 EE6EF131D37 for ; Thu, 27 Jul 2017 11:15: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=EwHq+dj+; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=P9X+x+Wo 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 KcU4a8swZNy9 for ; Thu, 27 Jul 2017 11:14:59 -0700 (PDT) Received: from catinthebox.net (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF7F126B6E for ; Thu, 27 Jul 2017 11:14:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=967; t=1501179292; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=RGrVLWZECZlUP8vduaYCJyaJ8yw=; b=EwHq+dj+vE8EoApbUSm7VnVz55KmfaboKstpOEec3ch/pE6zKqmMQAPZ+lqH1O RWvikNhIOu0JYCw/2jiyvstwiC+5spu0dS+UEm9/s/1K1H5p3NSA4/I3j0T5Ip5S COoUVY9zFaEnn4h2CjbzI7lM7Picr/v+fDL1YJbZRdwD0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 14:14:52 -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.6) with ESMTP id 1243167373.1.2080; Thu, 27 Jul 2017 14:14:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=967; t=1501179016; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=umaMAkO 5psmVB3o2mQ0s09R+v4HJH3yrkBxGg3Mx0q4=; b=P9X+x+WoEmLywADshLm71DQ B0tU1tt3DYFc0/mIbFXq10KCu9WZE4OlYDok4+/oPWz8JNC00qrulBI6qigOZIyc FIWJ8tIxyT2ZqKdNm8ioFgUrRggDZLqNFbBkh1Z82/swCeYXJnk1EbqhQZ3bfWcL t/2ZvHOTThLv8NIPOLE8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 14:10:16 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1785687127.9.512948; Thu, 27 Jul 2017 14:10:15 -0400 Message-ID: <597A2D9B.7060506@isdg.net> Date: Thu, 27 Jul 2017 14:14:51 -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: <20170727040109.1235.qmail@ary.lan> <2DC1CBCB-662C-4307-A409-386F20A41366@callas.org> In-Reply-To: <2DC1CBCB-662C-4307-A409-386F20A41366@callas.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 18:15:13 -0000 On 7/27/2017 2:11 AM, Jon Callas wrote: > I agree with Rich Salz's previous comments that we should not say MUST NOT. > > The purpose of a standard is to provide interoperability. It is a grammar of how to interpret a message. It is not a programming guide nor an implementation manual. If you want to put in scolding language about how SHA-1 will cause hair to grow on the palms of their hands, I can get behind that, too. > > In practical terms, as much we all want people to get off of SHA-1, the implementers have to implement.... Basic engineering insights will suggest it will not be practical without a migration path. I'm all for a POLICY-based system which already exist with the DKIM key "h=" tag. If the originating domain is worry about possible SHA1 exploited mail fraud, then it has the facility to expose what its expectations are (h=sha256). It is the verifiers that now needs to leverage the policy-based information. -- HLS From nobody Thu Jul 27 11:33: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 0C1D5131E08 for ; Thu, 27 Jul 2017 11:33:01 -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=Pz0ljiZA; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=z557sXRh 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 3P02KqWVVDeg for ; Thu, 27 Jul 2017 11:32:59 -0700 (PDT) Received: from catinthebox.net (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5411320B5 for ; Thu, 27 Jul 2017 11:32:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1245; t=1501180372; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=6vIqgqE3fTUQIILUwSAZQzMLp+U=; b=Pz0ljiZAGswSJy+lRdWIr0G4eZxTRvQ9JGgEF2MYsUClJFWNc/JvUj+gbCErGK 46lR+xh/46Q51ONlMp5wPH/U6vu5qCfMXdpo6Xj5GfqxFfk/aZceWA4FIx4Hp7pl Z2VtJf1yQNYZO4Rw5zi84MyDsnWynkGUyhzhRfy8xBJFo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 14:32:52 -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.6) with ESMTP id 1244247477.1.1520; Thu, 27 Jul 2017 14:32:51 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1245; t=1501180096; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ch7GMw4 rVkI14uzyBwMCaHv2R0LADfKp4hn20EqCpvU=; b=z557sXRhArE7FlLc1QF+KGs 5xn/JNHzCirFu3jZ/4oFIxs3m4M2yAIAvIwrvSMiWT0oM/bdGUY04pHo4UgjsZoR UKS/6+carT6pfC9YVY9y0p5fXLSxpraLQwap/o4rrffGTxcfC+2modrCrBuC4ED7 Hh4ZQ1zzyq0TeDIp7vDU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 14:28:16 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1786767174.9.512396; Thu, 27 Jul 2017 14:28:15 -0400 Message-ID: <597A31D3.7030607@isdg.net> Date: Thu, 27 Jul 2017 14:32:51 -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: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 18:33:01 -0000 On 7/27/2017 7:02 AM, Salz, Rich wrote: >> No one is forced to claim they've updated to the requirements of this new >> draft. I think MUST NOT sign/MUST NOT verify is much cleaner and it avoids >> yet another draft later. > > Speaking as an individual, I find this reasoning very compelling. Not to me. The problem is that it will immediately put developers and implementors in tight positions of technically "violating" the specification right out of the box. Thats not good IETF protocol development for everyone involved. Can't force people to do the "wrong" engineering thing that they believe to be true. SHA1 exist. It is a rare STD status document. We worked hard for it. Its a migration issue to remove SHA1 and we have the technical STD feature and facility for domains to set h=sha256 in their keys and for verifiers to honor it. What the specs could say, if not already, in so many words: "If the signer domain key has a h=sha256 tag, then the verifier MUST NOT verify any SHA1 mail." That effectively invalidates the DKIM message triggering other possible local policy mail handling features; Imo, that's good and fair protocol negotiation engineering for all parties involved. -- HLS From nobody Thu Jul 27 11:37:31 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 610011320CC for ; Thu, 27 Jul 2017 11:37:30 -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, 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=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 KbYsHViBhxln for ; Thu, 27 Jul 2017 11:37:29 -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 19C321320BE for ; Thu, 27 Jul 2017 11:37:29 -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 v6RIbAot030630; Thu, 27 Jul 2017 19:37:26 +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=9iPb574qe0ltXCJzYhAW/rM7EPfcWPg84Hl6guHfXtU=; b=Qt9sGn05PMfaBzie50pF1zifXTP6Ctsx2vEdbpzxlwk9DxiFpuWVi9aajDKd5MUx7MCy mAaCzvN4YEI4SIKCKZHlJRQUMOFJkNXsKL5sbQUEkcUhaQ0+QjDyX8jfHE9h3txmBs7Z o2rnTnpyttX6+reud3enptXTBUkObaYIXiMJsrcQ+3LdKIatdm4kzQLHnPIS8Zlet/EG rv79XLTYdxKKfSAAzGNCZNL7dEnbuv7vugX0sXjYjlec1hYGs+Lrtg1UvB9W98IYcwCt t9/68Yi90Mp+fQytfhDxYdu3iw5uzNzUGMhXrH9rvuFfon8VL+ld46y/ztdGw88UVF8z xw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2bxjb4rkjc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 19:37:26 +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 v6RIbIha008816; Thu, 27 Jul 2017 14:37:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2bv21vnq6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 14:37:25 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 14:37:24 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 14:37:23 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 27 Jul 2017 14:37:23 -0400 From: "Salz, Rich" To: Hector Santos , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4P//3iUAgAOCSYCAAAPNgP//0TmQgAEeh4CAAEJ/4A== Date: Thu, 27 Jul 2017 18:37:23 +0000 Message-ID: References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> In-Reply-To: <597A31D3.7030607@isdg.net> 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.228] 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-07-27_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-1706020000 definitions=main-1707270290 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_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-1706020000 definitions=main-1707270290 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 18:37:30 -0000 > The problem is that it will immediately put developers and implementors i= n > tight positions of technically "violating" the specification right out of= the box. Speaking as co-chair: You are only violating the spec if you claim to support it. So until you= can actually STOP doing SHA1, you don't claim support. Speaking as an individual: This draft sends a strong message to everyone to stop generating and veri= fying SHA1 very soon. We have been saying "stop" for years now. It's time= to ramp up the pressure. From nobody Thu Jul 27 11:54: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 C5127131D16 for ; Thu, 27 Jul 2017 11:54:31 -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=U5MvkX9D; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=BjeDVw/0 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 GVUd9vVvkUS3 for ; Thu, 27 Jul 2017 11:54:30 -0700 (PDT) Received: from catinthebox.net (winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E50EC131CAC for ; Thu, 27 Jul 2017 11:54:29 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1263; t=1501181666; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=MKS/2QiqfjakSRF/B3pr+8IEdmU=; b=U5MvkX9DEhcfe/RtHhCXtzuhUrPmQF5Yzszcsq1xpaFflGk83qaOTOXLjijcpQ rvQUCUZue4EyNHH6fOMr2uTKVcx4ZGIQhjTHbnkXtl6vHftBEYutclT0vObkgddR fYBQbs/vffDZJ27WC8u/u7xOc6Kj5J39FxsDZ4nr88Cz4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 14:54:26 -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.6) with ESMTP id 1245542629.1.4332; Thu, 27 Jul 2017 14:54:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1263; t=1501181391; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=TUqIwX6 GRS2NS/AKeEoVpd9hVCCc5cOIPTHXMBPcvow=; b=BjeDVw/0p/YXvSNaG6AQ/jl hqO3gAeXYvbTXiC+7SyiZd5iHbY0gMu96596rYl2duuXqXqK/IkmZfm8YlMWWX4+ Vc8ml0GHHR/grblph4FSt8tGKMBkLAGXNbYORxcmunCAj+Fv+qydtd6DKNc/tnWo VR3LETICr1vnhaXf1uUI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 14:49:51 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1788062080.9.513028; Thu, 27 Jul 2017 14:49:50 -0400 Message-ID: <597A36E2.5080309@isdg.net> Date: Thu, 27 Jul 2017 14:54:26 -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: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 18:54:32 -0000 On 7/27/2017 2:37 PM, Salz, Rich wrote:>> >>The problem is that it will immediately put developers and implementors in >> tight positions of technically "violating" the specification right out of the box. > Speaking as co-chair: > You are only violating the spec if you claim to support it. So until you can actually STOP doing SHA1, you don't claim support. Yes, and I believe it is also wrong to label anyone of violating the specification, in fact, it can be considered "tort," when in fact there is strong reason the believe the specification was incorrect and with excellent possibilities that other current implementators are not going follow it as well. There are many more implementators out there that do not hang out here. It will be a big surprise to them. > Speaking as an individual: > This draft sends a strong message to everyone to stop generating and verifying SHA1 very soon. We have been saying "stop" for years now. It's time to ramp up the pressure. > That doesn't work for the reasons stated and chances are good it will cause more problems with new implementators learning the hard way. We should not ignore the engineering migration considerations by leveraging the feature that already exist. -- HLS From nobody Thu Jul 27 12:00: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 502EC1321E3 for ; Thu, 27 Jul 2017 12:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, 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 hlwp5WYXoPx4 for ; Thu, 27 Jul 2017 12:00:32 -0700 (PDT) Received: from smtp88.iad3a.emailsrvr.com (smtp88.iad3a.emailsrvr.com [173.203.187.88]) (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 BD2281321D0 for ; Thu, 27 Jul 2017 12:00:26 -0700 (PDT) Received: from smtp28.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp28.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DE48051F7; Thu, 27 Jul 2017 15:00:25 -0400 (EDT) X-Auth-ID: jon@merrymeet.com Received: by smtp28.relay.iad3a.emailsrvr.com (Authenticated sender: jon-AT-merrymeet.com) with ESMTPSA id 5C034557C; Thu, 27 Jul 2017 15:00:25 -0400 (EDT) X-Sender-Id: jon@merrymeet.com Received: from [172.16.40.226] ([TEMPUNAVAIL]. [65.199.22.133]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Thu, 27 Jul 2017 15:00:25 -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: Thu, 27 Jul 2017 12:00:22 -0700 Cc: Jon Callas , Hector Santos , "dcrup@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> To: "Salz, Rich" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 19:00:34 -0000 > On Jul 27, 2017, at 11:37 AM, Salz, Rich wrote: >=20 >> The problem is that it will immediately put developers and = implementors in >> tight positions of technically "violating" the specification right = out of the box. >=20 > Speaking as co-chair: > You are only violating the spec if you claim to support it. So until = you can actually STOP doing SHA1, you don't claim support. >=20 > Speaking as an individual: > This draft sends a strong message to everyone to stop generating and = verifying SHA1 very soon. We have been saying "stop" for years now. = It's time to ramp up the pressure. Sure. However, let me suppose that I am an implementer and my customers tell = me that if I drop SHA1 they'll go to someone else, and also tell me that = if I don't support ECC, they'll go to someone else. What do I do? Strong message aside, and even agreeing with the sentiment to get rid of = SHA1, it sounds like our advice is to say that you support RFC XXXX = (DKIM with SHA1) and RFC YYYY (DKIM with ECC but no SHA1) and talk out = of whichever side of your mouth seems appropriate, and if you have to = change mouth sides with every other sentence, do so. Jon From nobody Thu Jul 27 12:02: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 C417A131CBB for ; Thu, 27 Jul 2017 12:02:19 -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 0IAluAMAAnUc for ; Thu, 27 Jul 2017 12:02: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 9ABA413216E for ; Thu, 27 Jul 2017 12:02: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 v6RIt15w011380; Thu, 27 Jul 2017 20:02:11 +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=xYq8Qxq78jb1o5GpFREZx0LEXVkRWPfm7fFq/K7BWkU=; b=dVaYjHukl1EIRXiq45HjjhSahCLun2Uhfa7LkktVGhA/BW29e1a/iXX1sCF/YshaNbWG yJl+BlBZUHqt4Hj9ox4CUvLaVPzuSazFPVHf4bblDpp0NxGZWlbV/RB1Rp/msAfqSjhX zBktTbbC5wnGDa1VNVM86J15K19xRmOTBWzLKzarpa4HpI2aI43Q7Er7Q1aEjtIcRlze Vy6XfSc3P/4T2yqa/g96dn22cTrFNkLP3SFkfl99awutKy+I3S1YUaITQxn9ybxFZiEn JwQub+Tn28BAjYSO4v8D3W6At0I2PKN8tvXheaRchCZdHZuUgBfWd84Pcur3DpjNbBr5 qQ== 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 2bx7n2ccax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 20:02:10 +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 v6RJ23ln000583; Thu, 27 Jul 2017 15:02:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21utsuw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 15:02:09 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 12:02:09 -0700 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 27 Jul 2017 15:02:08 -0400 From: "Salz, Rich" To: Jon Callas CC: Hector Santos , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4P//3iUAgAOCSYCAAAPNgP//0TmQgAEeh4CAAEJ/4P//xTEAAAhXa5A= Date: Thu, 27 Jul 2017 19:02:08 +0000 Message-ID: References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> 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.228] 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-07-27_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-1706020000 definitions=main-1707270297 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707270293 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 19:02:20 -0000 > However, let me suppose that I am an implementer and my customers tell > me that if I drop SHA1 they'll go to someone else, and also tell me that = if I > don't support ECC, they'll go to someone else. What do I do? Should not be a problem; the "don't use SHA1" document is separate from the= "use ECC" document, for just this reason. From nobody Thu Jul 27 12:03: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 8D27613212E for ; Thu, 27 Jul 2017 12:03:52 -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, 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=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 SiCbAmNW16nb for ; Thu, 27 Jul 2017 12:03: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 3E3B7131CBB for ; Thu, 27 Jul 2017 12:03: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 v6RJ3pcd018697; Thu, 27 Jul 2017 20:03: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=2tElbWgwK6bnG2jkEFZOhwDgX/LaDROqx7NpzVfl5JQ=; b=BsadC8THSjP2hibudgQoZ9a4BF40BA9NNam9oOLuAERcveUmJnt/xWAi7fIQ3C16vmRV r8Z9aqCZ1hcY0o3AeNkLNPiTQObawW58nx3Y/Z2sw94a5xcpxr68nDMjuAWpQPkO61tW GJ1j5QT1emhqy2Ce7BLY2Sx9yn5c2bbv4OspE5n5DSaE0YKFwgy5efeh3clP1VdewP/V pR/aiRjGQo6QIitQRfmf23BeI82wCLwweCQFBXB58P8Gzj+a2G/n0203KZLc3AGnaHix BDpNL8hDtG8zCOrgpKSN4oFbo/rYhyGmJvj2lDigFZdaWKJXOsHcx1XxQdW3oXKGdrq0 pg== 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 2bxjb4rp9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 20:03:50 +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 v6RJ24PQ016580; Thu, 27 Jul 2017 15:03:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2bv21v2vqp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 15:03:48 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 15:03:47 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 27 Jul 2017 15:03:47 -0400 From: "Salz, Rich" To: Hector Santos , "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4P//3iUAgAOCSYCAAAPNgP//0TmQgAEeh4CAAEJ/4P//w4kAAAgbB2A= Date: Thu, 27 Jul 2017 19:03:46 +0000 Message-ID: References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> <597A36E2.5080309@isdg.net> In-Reply-To: <597A36E2.5080309@isdg.net> 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.228] 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-07-27_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-1706020000 definitions=main-1707270297 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707270293 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 19:03:53 -0000 Nobody is labelling anyone as being in violation of anything. The IETF doe= sn't have a compliance arm, nor even a brand enforcement arm. :) If you want to sign via SHA2, go ahead. Nobody is stopping you, and the do= cument says how to do it. If you want to say you are say you are compliant with the "do not use SHA1"= document, then don't use SHA1. From nobody Thu Jul 27 12:58: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 1BC6C129B62 for ; Thu, 27 Jul 2017 12:58: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, 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=PZchPQ2O; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=in/5vacR 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 tBC6-rK1pueA for ; Thu, 27 Jul 2017 12:58:10 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 532781274D2 for ; Thu, 27 Jul 2017 12:58:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1501; t=1501185482; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=i8AUkYXXIn+vqd3HVq64yPmICHE=; b=PZchPQ2OcfcPivegW5hNUoFsRZcleFu6UjT1ZiKchsW9v6fCPhpqQDcsqNs13F cd7oPcXdNvFA5i3bHZUM9KpEolmirD4R6yoAcO/92OU0MCL3C5VzBUsJ+0jc6j0A mUsxHfX/A5WVMOY4r6cz976hf9Kh6lDkr4/2yP9/kE46g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 15:58:02 -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.6) with ESMTP id 1249357805.1.5948; Thu, 27 Jul 2017 15:58:01 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1501; t=1501185209; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=v+DQY0w XTjgKHOofVsE5wKkp225yXaQPogq/OIKQ9GI=; b=in/5vacRjef40qB5RmgNEde s8FYchrHbyuUtmOqVRRtCq0NpEL14muDec726F8DxK73lCij6Y3TeDUsXhF9F6Uu H8Ys796Q42ecND5gQIvYADN0zdxYd8J2jQ1+97Tq+AAJ8JWE3s2AHgIhkF+7sIKu AW8V0NvhhBKzpqMmLEx4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 15:53:29 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1791879362.9.518508; Thu, 27 Jul 2017 15:53:28 -0400 Message-ID: <597A45CB.8000407@isdg.net> Date: Thu, 27 Jul 2017 15:58:03 -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: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> <597A36E2.5080309@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 19:58:13 -0000 On 7/27/2017 3:03 PM, Salz, Rich wrote: > Nobody is labelling anyone as being in violation of anything. The IETF doesn't have a compliance arm, nor even a brand enforcement arm. :) > But there is product branding, reputation, support and cost concerns because of what you said below: > If you want to sign via SHA2, go ahead. Nobody is stopping you, and the document says how to do it. > Did you mean SHA1? > If you want to say you are say you are compliant with the "do not use SHA1" document, then don't use SHA1. > My implementation has evolved from the original DKIM drafts to the STD76 DKIM-BASE document. https://tools.ietf.org/html/std76. A new "update" proposal that changes its STD features in regards to SHA1 and SHA256 can be supported and compliant by developers who MUST deal with all possibilities, including verifying SHA1 mail. You are suggesting they would be violating this "change" by supporting SHA1 in any way (mostly by verifying because I have no issue with the SHA256-only signing recommendation). If so, there would be something very IETF wrong about this, especially coming from the co-chair. It fails to see the more completed IETF engineering picture that creates or fits the proper protocol for client/server, senders/receivers automated negotiations. This draft proposal needs a discussion on migration which means existing developers can consider verifying SHA1 under special considerations and still be compliant. -- HLS From nobody Thu Jul 27 13:03: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 C987C12F24E for ; Thu, 27 Jul 2017 13:03:11 -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 (1024-bit key) header.d=isdg.net header.b=fm9lNzmQ; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=fS39B9Vo 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 mvdaZeT53UX4 for ; Thu, 27 Jul 2017 13:03:10 -0700 (PDT) Received: from pop3.winserver.com (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14F129B19 for ; Thu, 27 Jul 2017 13:03:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=651; t=1501185783; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=VGThf9+HOGanry/gwvcS0PFD5SU=; b=fm9lNzmQJ4Qg67oLDpXgD/3N+UOn8LPm51ab2IVSViz5VdjEPzwVg/vuS/x4Sz DrDmX+ObNzp4+FaIvbxdCSLP/1t5p6XwnG9P6rIi8xn0D+uCUEzjL06n2cq5m5Xt vegSjUbpSj/Q7vGwJe1tzEDWbF2Ar5v8CFjCtVm6wl0rQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 16:03: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.6) with ESMTP id 1249658060.1.5604; Thu, 27 Jul 2017 16:03:01 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=651; t=1501185507; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=A/1uTsV UbWo2aTH43f+Nfs0OX0ZFE25AW6nE7zjJS2I=; b=fS39B9VofeOUrq+z3y07/V9 l4MwzwGqsuxCBvSm7AKVj4mkZ40IPbXQvascB78FeKqkINhRSukOhs0EH50e1S2l cwlwjwYRY7vtmW0orGsGEPFOc6yOiSdTnOEhIunqkywwXX5e8OVnVflUMSqt0HOA iTQAu/gpivkgPFV9gXLY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 15:58: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 1792177658.9.519584; Thu, 27 Jul 2017 15:58:26 -0400 Message-ID: <597A46F5.2020805@isdg.net> Date: Thu, 27 Jul 2017 16:03:01 -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: Jon Callas , "Salz, Rich" CC: "dcrup@ietf.org" References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 20:03:12 -0000 On 7/27/2017 3:00 PM, Jon Callas wrote: > > Strong message aside, and even agreeing with the sentiment to get rid of SHA1, it sounds like our advice is to say that you support RFC XXXX (DKIM with SHA1) and RFC YYYY (DKIM with ECC but no SHA1) and talk out of whichever side of your mouth seems appropriate, and if you have to change mouth sides with every other sentence, do so. > Sounds like there should be two documents: RFC Update to STD76 that deprecates SHA1 RFC Update to STD76 that adds ECC That allows a developer to be supportive of STD76 and the ECC update, and choose what he wants to do about the SHA1 update. -- HLS From nobody Thu Jul 27 13:07: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 E7C14131E2A for ; Thu, 27 Jul 2017 13:07:31 -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, 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=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 D_JOWDcrbDnQ for ; Thu, 27 Jul 2017 13:07:30 -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 355ED131DAC for ; Thu, 27 Jul 2017 13:07:30 -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 v6RK6W0T009903; Thu, 27 Jul 2017 21:07:27 +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=RPt1Ie2AdsZM7VYByCIgfGMEu4h8/eu5l6JNmdqMWtg=; b=CbAZjEhQg9eB+t/lVl0Z3aQvS2Sidx8sO3DeGmb4Gb9rmNsJPXALvAz8Z+HRgRybyjOS FJbzsgSzT8h2aDq4fiXiEd9szhCGHnvPuSK3DP0wfZvj9GAOO221DnvATCl6ICSjNkbI DtH8uZhisizkEj81UOf2B4rfNa4hIFvFv2PIPjBldip4SAr/px/Z/sGZ2t1Pq6GWVm5L TEeSYRfXcRmfUI3LmROqHGSbBXi2KJeJsEgNtdGhyY36dtAeqR32zAf6zfZd527+BLil u0FUi9Bpg09vHeLME/3zttvDFRrVefokgfKdkCalH9dLg02Yi9G3qw5FECe/qSIBKN6a Iw== 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 2by2p0cqrn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 21:07:26 +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 v6RK6SMb012757; Thu, 27 Jul 2017 16:07:24 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21uu01x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 16:07:24 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 16:07:23 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 27 Jul 2017 16:07:23 -0400 From: "Salz, Rich" To: Hector Santos , Jon Callas CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4P//3iUAgAOCSYCAAAPNgP//0TmQgAEeh4CAAEJ/4P//xTEAAAIwMYAACE9wUA== Date: Thu, 27 Jul 2017 20:07:22 +0000 Message-ID: References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> <597A46F5.2020805@isdg.net> In-Reply-To: <597A46F5.2020805@isdg.net> 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.228] 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-07-27_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-1706020000 definitions=main-1707270312 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_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-1706020000 definitions=main-1707270312 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 20:07:32 -0000 PiBTb3VuZHMgbGlrZSB0aGVyZSBzaG91bGQgYmUgdHdvIGRvY3VtZW50czoNCj4gDQo+ICAgIFJG QyBVcGRhdGUgdG8gU1RENzYgdGhhdCBkZXByZWNhdGVzIFNIQTENCj4gICAgUkZDIFVwZGF0ZSB0 byBTVEQ3NiB0aGF0IGFkZHMgRUNDDQo+IA0KPiBUaGF0IGFsbG93cyBhIGRldmVsb3BlciB0byBi ZSBzdXBwb3J0aXZlIG9mIFNURDc2IGFuZCB0aGUgRUNDIHVwZGF0ZSwgYW5kDQo+IGNob29zZSB3 aGF0IGhlIHdhbnRzIHRvIGRvIGFib3V0IHRoZSBTSEExIHVwZGF0ZS4NCg0KSSBhbSBjb25mdXNl ZC4gIFRoZXJlICphcmUqIHR3byBkb2N1bWVudHMuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGNydXAtZGtpbS11c2FnZS8/aW5jbHVkZV90ZXh0PTEgaXMg YWJvdXQgdXNpbmcgU0hBMjU2IGFuZCBub3QgdXNpbmcgU0hBMSBmb3IgUlNBLg0KDQpodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRjcnVwLWRraW0tZWNjLz9pbmNs dWRlX3RleHQ9MSBpcyBhYm91dCB1c2luZyBFQ0MuICBBbmQgc2luY2UgRUNDIGlzIGJyYW5kLW5l dyB0byBES0lNLCB0aGVyZSBpcyBubyBsZWdhY3kvaW5zdGFsbGVkIGJhc2UgdG8gZGVhbCB3aXRo IHNvIHdlIGNhbiBqdXN0IG5vdCB1c2UgU0hBMS4NCg0KSXMgdGhpcyBva2F5PyAgSWYgbm90LCB3 aGF0IHdoYXQgaXMgd3JvbmcuDQoNCg== From nobody Thu Jul 27 13:33: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 83EC1131CCA for ; Thu, 27 Jul 2017 13:33:03 -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 (1024-bit key) header.d=isdg.net header.b=Lknl8LBL; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=DXd+cXDH 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 N5Xx2uKrK_AT for ; Thu, 27 Jul 2017 13:33:01 -0700 (PDT) Received: from pop3.winserver.com (pop3.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id DC34F1277BB for ; Thu, 27 Jul 2017 13:33:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1735; t=1501187573; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=HJIRHQUH9qYxgChEr1O1gPf/5t4=; b=Lknl8LBLJrMbF4Ox3FAoJXIvSw9XwIuPwzC2cn3PgMaZWxwi/iSmBWD4H+SmnJ 04GvY4CjjxWX6tzGZBVOlnuf2Owd/wmEmwP/FywjuWgrfsWaHp3yCn4KCRRc0CoB Gl04JcwWn2zvlWKBgDLSgTM3aenDszC7+cVA2lWaMGSN0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 27 Jul 2017 16:32:53 -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.6) with ESMTP id 1251448405.1.4916; Thu, 27 Jul 2017 16:32:52 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1735; t=1501187297; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fZmsWFH cJy9h+OgRkw01BH0e8yrd2csN1csUzVIDN60=; b=DXd+cXDHxBEQ4mvTVKslHvE hSH7UDKUHaOalmYvLV/Fh6iX/Y9y8Ex4IRK0B8n8zkIHAfiIM41d7SU4ieMwh7Se GcHOHuNegENW8kvFpVmuOB1/GQJJAANacPy0RihufZ6O7BRq4eEtgHaQ+bNpAkCU QRdLUW6AlXSLGzbNbivc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.5) for dcrup@ietf.org; Thu, 27 Jul 2017 16:28:17 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.5) with ESMTP id 1793967721.9.517832; Thu, 27 Jul 2017 16:28:16 -0400 Message-ID: <597A4DF3.6010602@isdg.net> Date: Thu, 27 Jul 2017 16:32:51 -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: "Salz, Rich" , Jon Callas CC: "dcrup@ietf.org" References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> <597A46F5.2020805@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 20:33:04 -0000 On 7/27/2017 4:07 PM, Salz, Rich wrote: >> Sounds like there should be two documents: >> >> RFC Update to STD76 that deprecates SHA1 >> RFC Update to STD76 that adds ECC >> >> That allows a developer to be supportive of STD76 and the ECC update, and >> choose what he wants to do about the SHA1 update. > > I am confused. There *are* two documents. > > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/?include_text=1 is about using SHA256 and not using SHA1 for RSA. > > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/?include_text=1 is about using ECC. And since ECC is brand-new to DKIM, there is no legacy/installed base to deal with so we can just not use SHA1. > > Is this okay? If not, what what is wrong. Sorry, trying to catch up, I was not aware there were two drafts: 1) Cryptographic Algorithm and Key Usage to DKIM https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage 2) Defining ECC Algorithms for use with DKIM https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc Ok, perfect! I thought both ideas was being lump together in the WG under one spec change. Existing Developers will may support #2 and ignore #1 because they will continue to support SHA1. I believe it will cause a problem for new developers when they follow #1 by not providing an UI, the SHA1 features to allow for operators to enable SHA1 verification at a minimum. Nah, now that I read this draft-ietf-dcrup-dkim-usage proposal, as it written for rsa-sha1, I can't support this document. There are no implementation, nor migration notes. Section 3.1 lacks a discussion on the possible operational and support ramifications for implementators who follow it. -- HLS From nobody Thu Jul 27 16:01: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 1D134131E84 for ; Thu, 27 Jul 2017 16:01: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 yupXmYRXkBzm for ; Thu, 27 Jul 2017 16:01: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 3D8F312F274 for ; Thu, 27 Jul 2017 16:01:24 -0700 (PDT) Received: (qmail 24233 invoked from network); 27 Jul 2017 23:01:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jul 2017 23:01:23 -0000 Date: 27 Jul 2017 23:00:52 -0000 Message-ID: <20170727230052.51646.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: rsalz@akamai.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] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 23:01:26 -0000 In article you write: >https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-ecc/?include_text=1 is about using ECC. And >since ECC is brand-new to DKIM, there is no legacy/installed base to deal with so we can just not use >SHA1. > >Is this okay? If not, what what is wrong. Nothing's wrong. The current draft just says eddsa-sha256, to be renamed ed25519-sha256. I suppose I should split that from the hashed RSA draft although it's going to be kind of a pain to cross-reference the new key field in the signature header. R's, John From nobody Thu Jul 27 16:29:48 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 E1624131C24 for ; Thu, 27 Jul 2017 16:29:47 -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 d8rwsBpPHTh4 for ; Thu, 27 Jul 2017 16:29:46 -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 3F610129AA0 for ; Thu, 27 Jul 2017 16:29:46 -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 v6RNR85R022366; Fri, 28 Jul 2017 00:29:42 +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=2xKTbMtLppoe2C8PpShWP3sI8IL7Uq3KDyIbso9Mwss=; b=GvWZhV0nuggsE7a+Dzs+m/GRA0omP/dqOppCE4L8Ab7KNZIY+bBn/2ia7yH2sovzlyWu R4cNRICgivG5xXfbdnbNO0RYrgnGiT4z/ktyJNRNpTh9wH3Ld8EgQRB8kBSFHYVufHcB +58ATpW/TbZCZRP5yTHSmEG9m1qnkP5GgxGnQEPoMGAGQTmUBdk2xuTEawkrigl2AbHx rsORTv8ztocKT0/kTcbJFq3IaMma0mXIQ/uz66Yy0DmKAqStz8Dl6NTmuuyWFWKZAkgR Zx2cmajRmoTeXKU56tqN7TGPYEpbKvwPqRFF164dGXAm1y2rYbTT5mz3m9NC0DWLTbcu aA== 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 2bydp13fyf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Jul 2017 00:29:42 +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 v6RNQALw017980; Thu, 27 Jul 2017 19:29:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2bv21uuhjm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jul 2017 19:29:41 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 19:29:40 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 27 Jul 2017 19:29:40 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 27 Jul 2017 19:29:40 -0400 From: "Salz, Rich" To: Hector Santos , Jon Callas CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] Open issue -- sha1 must not generate [and|or] accept Thread-Index: AdMBPADJTflopAx6Q9eSw+1T9/VqogAJ2x2AANPlEVAACUX7gAAISxOg///I4wCAAEEm4P//3iUAgAOCSYCAAAPNgP//0TmQgAEeh4CAAEJ/4P//xTEAAAIwMYAACE9wUAAHRLSAABDEh4A= Date: Thu, 27 Jul 2017 23:29:39 +0000 Message-ID: <8d415810cdd3458895dd15fdb0e0c951@usma1ex-dag1mb3.msg.corp.akamai.com> References: <20170727040109.1235.qmail@ary.lan> <1574181.Nk75d4j0sL@kitterma-e6430> <22c03d2e21e54d7f82216e55f8004d95@usma1ex-dag1mb1.msg.corp.akamai.com> <597A31D3.7030607@isdg.net> <597A46F5.2020805@isdg.net> <597A4DF3.6010602@isdg.net> In-Reply-To: <597A4DF3.6010602@isdg.net> 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.126] 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-07-27_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-1706020000 definitions=main-1707270358 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-27_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-1706020000 definitions=main-1707270359 Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 23:29:48 -0000 PiBOYWgsIG5vdyB0aGF0IEkgcmVhZCB0aGlzIGRyYWZ0LWlldGYtZGNydXAtZGtpbS11c2FnZSBw cm9wb3NhbCwgYXMgaXQgd3JpdHRlbg0KPiBmb3IgcnNhLXNoYTEsIEkgY2FuJ3Qgc3VwcG9ydCB0 aGlzIGRvY3VtZW50LiAgVGhlcmUgYXJlIG5vIGltcGxlbWVudGF0aW9uLA0KPiBub3IgbWlncmF0 aW9uIG5vdGVzLiAgU2VjdGlvbiAzLjEgbGFja3MgYSBkaXNjdXNzaW9uIG9uIHRoZSBwb3NzaWJs ZQ0KPiBvcGVyYXRpb25hbCBhbmQgc3VwcG9ydCByYW1pZmljYXRpb25zIGZvciBpbXBsZW1lbnRh dG9ycyB3aG8gZm9sbG93IGl0Lg0KDQpQbGVhc2UgY29uc2lkZXIgc3VwcGx5aW5nIHRleHQuICBJ IHRoaW5rIHJpZ2h0IG5vdyB0aGUgV0cgaGFzIHN0cm9uZyBjb25zZW5zdXMsIGp1c3QgZGlzY3Vz c2lvbiBhYm91dCBNVVNUIG9yIFNIT1VMRC4NCg== From nobody Thu Jul 27 16:40: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 E798D131E01 for ; Thu, 27 Jul 2017 16:40:43 -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 qltRcpIycPKB for ; Thu, 27 Jul 2017 16:40:42 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 3FC79131D02 for ; Thu, 27 Jul 2017 16:40:42 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id v127so90826263itd.0 for ; Thu, 27 Jul 2017 16:40: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=0qZVfRFVMgllPWDXoH9Q9EAX78A2Jt2BOSuQcVnDVl8=; b=PTezVS45umodxZsvqsU9Xdth/08GY3cVYbW7vyZvyMTvfbrLIXlQExb4STv3PqbdUC skZyIj5gEkS8QIROMMyxSk0pBGTTJrwQqBLm5yxGUnzvX7A0EdUHeG9ftwGE8TQeKGNn 95kc1mEihoeSIdONROlqjlkWW7uC8q8Og8pT2tfFLEMLuU8FJsvdF3WN0rUg9Xt5nF3F ZyNawhKeVR+EHNq3uTbD7SRaAE1BQf2wnfx6wzjfeKqEWz9yu9Zr1pFqIIaf5ytvhYNi x4YTVdz3YeEFYBt5fmz0n8+RxIRe7qZ46xpXmNjrTly1p9pvlquIbzN57So8uYgAL3Tj W90A== 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=0qZVfRFVMgllPWDXoH9Q9EAX78A2Jt2BOSuQcVnDVl8=; b=N3BOV4IfI88HYNYuqNH0C5v80W/e6b7DFOmJSHop2xNpbfl7dMY7GZd2DaoIeAeKc5 DxcLJj/YoX4wvnQIxbrCse4nHxjONSnQTC2CqLvV+IS/WMQ/TsJDnwPrOygC9oSMgqEK yinvZFseZpQv9TNi16Vl7DeTYqrwZq+zukkmjq61oVdyQ7TdbniMK3+DG9FFK0pPkfLF n2swYkMEDSwXAy8CyjV8lDk32SRhI0UmAoHIV50AbAY9PjZL6VBmAkf076q/ON60FVJj WYEDO4CxmNmjWeoaImtAapblS+MKTezne2zrDWWNptH24b8jSrn5SUp0lqQlDr3bL9bz 8+fA== X-Gm-Message-State: AIVw113MzHgmcUdIMASVj/xsZGQ2FVlZKiePBd5nGPIeX3/KS4AHYgKb GRnThL9qTLg6WOTgAfxs2+XrFDYnkA== X-Received: by 10.36.16.143 with SMTP id 137mr7290533ity.154.1501198841563; Thu, 27 Jul 2017 16:40:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 27 Jul 2017 16:40:40 -0700 (PDT) In-Reply-To: <20170727230052.51646.qmail@ary.lan> References: <20170727230052.51646.qmail@ary.lan> From: Martin Thomson Date: Fri, 28 Jul 2017 09:40:40 +1000 Message-ID: To: John Levine Cc: dcrup@ietf.org, "Salz, Rich" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] Open issue -- sha1 must not generate [and|or] accept 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, 27 Jul 2017 23:40:44 -0000 On 28 July 2017 at 09:00, John Levine wrote: > I suppose I should split that from the hashed RSA draft although it's going to be kind of > a pain to cross-reference the new key field in the signature header. I wouldn't. The text I provided the other day would be harder to fit into two documents. From nobody Fri Jul 28 10:59:13 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 B07FD131C3A; Fri, 28 Jul 2017 10:59:11 -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.57.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150126475166.25167.11181232668791918352@ietfa.amsl.com> Date: Fri, 28 Jul 2017 10:59:11 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-04.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, 28 Jul 2017 17:59:12 -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 WG of the IETF. Title : New cryptographic signature methods for DKIM Author : John Levine Filename : draft-ietf-dcrup-dkim-crypto-04.txt Pages : 7 Date : 2017-07-28 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-04 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 Jul 28 11:11: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 318031321B7 for ; Fri, 28 Jul 2017 11:11:04 -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 (1536-bit key) header.d=iecc.com header.b=hYQJaE6D; dkim=pass (1536-bit key) header.d=taugh.com header.b=IHZpHYKF 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 k8XExaqRhh72 for ; Fri, 28 Jul 2017 11:11:02 -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 5037C13205C for ; Fri, 28 Jul 2017 11:11:02 -0700 (PDT) Received: (qmail 88620 invoked from network); 28 Jul 2017 18:11:01 -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=15a1f.597b7e35.k1707; bh=kGJRmIGHHSRkGR28AngdEOzTbukDZfKBIfIKot/zz44=; b=hYQJaE6DH3sZcrVrOQJukobX8F1/PYBv2E70PsX4+gfX6AzjyZLRt1pq6DORvdPCE4PffpB05Tvyx83qPQGnlUnS7hyLJJbPdlTJ5Vc40lBKipEuGv5nmX5oRG4e6VIgSrg0lIjDji9/EsAjRwrU2Bww+PF79mK1tg4F0CT1mRgwROuXIMMoPssaD6s1iY0tuoMOeXz/vk6MDiKRWFV4lIyUxijBkKCHlyEPieWGLq4luBVTVO5M3Wj3JldV0Z5j 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=15a1f.597b7e35.k1707; bh=kGJRmIGHHSRkGR28AngdEOzTbukDZfKBIfIKot/zz44=; b=IHZpHYKFas9ocz/X0oDPbH2aTFpUAPrz441JOJb8KX/MQ45aAwgyzQSXAaHeswiBCfCN/mXW6gH9CWlCmT7prLdrxq5dSCOySfz74m549di5YIV2jboSP9ixsPWsy99/4Y4EjCtHvYOAnKwoXKyAEep1RA7BS3xv9HMGXnHVjTaEa7nhsSwvxcWJHCrYWty8NptL1rbxiI9prNiaG1VKDkl3fa1dE4ln4Z3ZtzdfF1X1yVY3uQLe+y7/Q7WSR/fu 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 Jul 2017 18:11:00 -0000 Date: 28 Jul 2017 14:11:00 -0400 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; format=flowed; charset=US-ASCII Archived-At: Subject: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 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, 28 Jul 2017 18:11:04 -0000 This takes out the sha-1 deprecation stuff and makes many editorial changes based on comments from ekr and Martin T. I didn't necessarily do everything they suggested, but I think I did look at all the suggestions. 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 Jul 30 20:14: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 E8D58131C60 for ; Sun, 30 Jul 2017 20:14:15 -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 5FVembd3_ixo for ; Sun, 30 Jul 2017 20:14:14 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 EF39A126CB6 for ; Sun, 30 Jul 2017 20:14:13 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h199so118818726ith.1 for ; Sun, 30 Jul 2017 20:14: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=6jYZmvqoSi4BrwYC4tJHBrGL98zAzHKK+cpe5imag3E=; b=TF12oP/10jT5tDBNHHumQfuWjs1QZ0TG+uv1LFCQcbWHLqQIXtHY8skudpEZsAYETV Tr6ynbDbJuYmQLUpw7/8N++gjHPmhFm+AsrsReCoJaBc1A33353QwfQgw18oEysZdx/O nwCfpKyfdb+PRbJ/OOloQFO7XTfdvdbe6CJt9acQ6m09ofjbS1JR+ez7ZJKCeI5IwEp0 Q61OaKshW5txs482+qMrtI3yPkJ8ywFvTr3DN8vdRrgeHHXXggdhG5ffbqP1J2pQ+uXE VBA5wuov810MfDH7lIELi/gC58bKkzhptsV9ft20D+Co14+hnSG3N8xzP0Nb/iu2jzWf REfQ== 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=6jYZmvqoSi4BrwYC4tJHBrGL98zAzHKK+cpe5imag3E=; b=iQVj2O3fD8oNj5nE6o2fhQkQRpN9J/DqtjMfuRMn3XjOnmtemhnw7k6VyzHPT0B2OY d7d1F+48bWvNKlHSOyNHVdBK+yLRFfrQ0TcRbQj8EmJcre8MpWDOqEBGSXSw7BPF24io jWL4synTLRelY0kLsLDQS68a0U3SI2DftlVZB8b0+EZ76fIvtoox/Hgik9y2Z/je0/1n g88myUP7ZaOskMo0VGpzUtVqYmHDfL+plbN1569z8tsummnvsKU2qMcmoiXeC4Q0ve3f xLU77NqbEX6ywNuMhczHiTXW4GUuG55zMMsCiBR+wK2r9ISwiU8ghg02B65R5dy8gqCQ neRw== X-Gm-Message-State: AIVw112AMzGLd1J5kL2zXIsub+byF9O5gEERuYYGDkO6YH8BH1VM991R EQqzkGjVTNXavKncxQxtfHRNRdmvhgwWH3w= X-Received: by 10.36.5.68 with SMTP id 65mr17740298itl.140.1501470853234; Sun, 30 Jul 2017 20:14:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sun, 30 Jul 2017 20:14:12 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 31 Jul 2017 13:14:12 +1000 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 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, 31 Jul 2017 03:14:16 -0000 Hi John, This looks pretty good. The abstract still says "and deprecates an obsolete signing algorithm", which I think that you only obliquely. I think that you can remove the "Updates: RFC 6376" as well, but that means larger changes. In the spirit of leaving the removal of the crusty old stuff to the other draft, I think that you should: 1. remove the clause from the abstract 2. remove the first paragraph of Section 6 (which specifies the update to RFC 6376) 3. remove the requirement to use 1024-bit keys for "rsa-sha256" That means changing Section 3 to concentrate on what rsafp does, rather than specify it as patches to RFC 6376. Yes, this doesn't make the change to hashed keys generic and others will likely cargo-cult this document, but monkey-patching RFC 6376 like this could affect "rsa" keys as well as "rsafp" keys. OLD: Section 5.5 of [RFC6376], on computing the message hash and signature, is modified as follows: When creating a signature with a signing algorithm that uses a key fingerprint, the signer includes the public key in the signature as a base64 encoded string with a k= tag. The key in the tag is the same one that would be published in a non-fingerprint key record. NEW: When creating a signature with an "rsafp" algorithm, the signer includes the public key in the signature as a base64 encoded string with a p= tag. The value of the p= tag is an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey (see [RFC3447], Sections 3.1 and A.1.1). IMPORTANT: I think that you meant p= here rather than k=. OLD: Section 3.7 of [RFC6376], on computing the message hashes, is not modified. Since the key in the k= tag is known in advance, it included in the signature in the same manner as all of the other signature fields other than b=. NEW: Message hashes are computed exactly as described in [RFC6376]. Since the key in the p= tag is known in advance, it is included in the signature in the same manner as all of the other signature fields other than b=. OLD: Section 6.1.3 of [RFC6376], to compute the verification, is modified as follows: In item 4, if the signing algorithm uses a key fingerprint, extract the verification key from the k= tag. If there is no such tag, the signature does not validate. Extract the key hash from the p= tag of the key record. If there is no such tag or the tag is empty, the signature does not validate. Compute the SHA-256 hash of the verification key, and compare it to the value of the key hash. If they are not the same, the signature does not validate. Otherwise proceed to verify the signature using the validation key and the algorithm described in the "a=" tag. NEW: To verify a signature using the "rsafp" algorithm, follow the process described in RFC 6376 for "rsa" keys. However, the "rsafp" algorithm takes the verification key from the p= tag. If the p=tag is not present in the message, the signature does not validate. In addition to signature verification, the verifier MUST ensure that the p= field of the key record is equal to the SHA-256 hash of the verification key. If this check fails, the signature does not validate. Final unrelated comment: You recommend that "rsafp signatures SHOULD use key lengths of 1536 or 2048 bits". I think that you want to include an "at least" here, and use MUST. Pick a number. The rest of the industry is relatively comfortable with 2048, which would be my pick, i.e., "rsafp signatures MUST use keys that are 2048 bits or larger" On 29 July 2017 at 04:11, John R Levine wrote: > This takes out the sha-1 deprecation stuff and makes many editorial changes > based on comments from ekr and Martin T. I didn't necessarily do everything > they suggested, but I think I did look at all the suggestions. > > 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 Jul 31 08:06: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 5D15C1323BF; Mon, 31 Jul 2017 08:06:58 -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, 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 H7yjhykav3tD; Mon, 31 Jul 2017 08:06: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 3671513249D; Mon, 31 Jul 2017 08:06:54 -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 v6VF4XUk010836; Mon, 31 Jul 2017 16:06: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 : mime-version; s=jan2016.eng; bh=UXxht2iQB8lazc5EyqutVmeeDP8OPyVRmK0fjQRi1zo=; b=mM/xutRy7tt6hyJsQ3xiXgIbZQ+Un5+M1ZUMrV/ga18kJHmhyEvDuL5b1YiunFtOSEEE 5KxFTih5KqfGH3EfkVGTHQK8cxFKTzbq2zTVGXtyuyn3eFu1QdANPWldKNi4fxcbg3Dw 1ok/8vtL3AvXJOATfkuqdjnFL4hBYx29SU/Ej4Dl4B8fNHZOCadjSeyQwhxTyVC5+BdA 7gGjDxKM2WIzO/Nw4o5RdpNbg8TAXNWN0NuxkaUaRtMzCEWkHLMSBamlrrQK+CtK2oR9 mxW9gHye+PUPT/TVQZP9JlTUdYLoyffXamBDSsSDV63iaqAe+67GT5a22LZ83bU4sxm+ Cw== 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 2c0js79cu7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Jul 2017 16:06:51 +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 v6VF0xSA026641; Mon, 31 Jul 2017 11:06:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c0npupxqm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Jul 2017 11:06:49 -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; Mon, 31 Jul 2017 11:06:49 -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, 31 Jul 2017 11:06:49 -0400 From: "Salz, Rich" To: "Salz, Rich" , Kurt Andersen , "dcrup@ietf.org" , "dcrup-chairs@ietf.org" Thread-Topic: Notes from IETF99 dcrup meeting Thread-Index: AQHTATmcyP4sIVT+MkWUNHUYLDz27aJc/shAgBEb+EA= Date: Mon, 31 Jul 2017 15:06:48 +0000 Message-ID: References: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.msg.corp.akamai.com> In-Reply-To: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.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.34.207] Content-Type: multipart/alternative; boundary="_000_dfcc0e29bb2f4639a4e59dd09169eaa0usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_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-1706020000 definitions=main-1707310254 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310255 Archived-At: Subject: Re: [Dcrup] Notes from IETF99 dcrup meeting 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, 31 Jul 2017 15:06:58 -0000 --_000_dfcc0e29bb2f4639a4e59dd09169eaa0usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S3VydOKAmXMgbWludXRlcyBoYXZlIGJlZW4gdXBsb2FkZWQsIHRoYW5rcyENCg0KLS0NClNlbmlv ciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVh bQ0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQpGcm9tOiBTYWx6 LCBSaWNoIFttYWlsdG86cnNhbHpAYWthbWFpLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDIw LCAyMDE3IDE6NTEgUE0NClRvOiBLdXJ0IEFuZGVyc2VuIDxrdXJ0YUBkcmt1cnQuY29tPjsgZGNy dXBAaWV0Zi5vcmc7IGRjcnVwLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IE5vdGVzIGZy b20gSUVURjk5IGRjcnVwIG1lZXRpbmcNCg0KS3VydCwNCg0KVGhhbmsgeW91IHZlcnkgdmVyeSBt dWNoIGZvciB0aGUgZGV0YWlsZWQgbm90ZXMhDQoNCkF0dGVuZGVlczogcGxlYXNlIHBvc3QgY29y cmVjdGlvbnMgYnkgbmV4dCB3ZWVrIQ0K --_000_dfcc0e29bb2f4639a4e59dd09169eaa0usma1exdag1mb1msgcorpak_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5LdXJ0 4oCZcyBtaW51dGVzIGhhdmUgYmVlbiB1cGxvYWRlZCwgdGhhbmtzITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+LS0mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2ll czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+TWVtYmVyLCBPcGVuU1NMIERldiBUZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JTTogcmljaHNhbHpAamFiYmVyLmF0 IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gU2FseiwgUmljaCBbbWFpbHRvOnJzYWx6QGFrYW1haS5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMjAsIDIwMTcgMTo1MSBQTTxi cj4NCjxiPlRvOjwvYj4gS3VydCBBbmRlcnNlbiAmbHQ7a3VydGFAZHJrdXJ0LmNvbSZndDs7IGRj cnVwQGlldGYub3JnOyBkY3J1cC1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IE5vdGVzIGZyb20gSUVURjk5IGRjcnVwIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkt1cnQsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlRoYW5rIHlvdSB2ZXJ5IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIG5vdGVzITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5BdHRlbmRlZXM6IHBsZWFzZSBwb3N0IGNvcnJlY3Rpb25zIGJ5IG5leHQg d2VlayE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_dfcc0e29bb2f4639a4e59dd09169eaa0usma1exdag1mb1msgcorpak_-- From nobody Mon Jul 31 08:08: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 192B61324A0 for ; Mon, 31 Jul 2017 08:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 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, T_KAM_HTML_FONT_INVALID=0.01] 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 NndkhbCELR0y for ; Mon, 31 Jul 2017 08:08:07 -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 EFA9913249C for ; Mon, 31 Jul 2017 08:08:06 -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 v6VF4bqa015942; Mon, 31 Jul 2017 16:08:00 +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=WXz1cP3Z6+7APNp8OjdmMwewjATgWMnrpVeWybK0tSs=; b=mYw9Eez9OgVamUvLj5U7dyGoDDg0GTdBjkN+jyYR5oJMvT6QeJaHrATMXmWC2vHpXdUK XKTED4NwlgoEXOpv7UkxrAWgkLUpUjMUpIawTl6Pcr3VnplOdDt366y9IJuFHP5aa7/s RGddZd0x1HyBkT1AofS4AWRhcU/JLUPedakyPI2DyhCZkECMG35nSI7Ltlzz7LY9i8KG dxvF7vfAnG6+KRWHp6p9+8+kWWmQg95BFjoGUi0woXC79+bkMsSPTnTnfhJ12CDQIlYu RAyoqV+AS7eX61D1+g38EL7rUjO2hhVXi1XfdRwYlFlHVdcs5+Xp/qlNGJC++iA7f1HE 4g== 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 2c0hwe9mnw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Jul 2017 16:08: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 v6VF0qeG027923; Mon, 31 Jul 2017 11:07:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c0npuf0aq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Jul 2017 11:07:58 -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, 31 Jul 2017 11:07:58 -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, 31 Jul 2017 11:07:58 -0400 From: "Salz, Rich" To: Jim Fenton , "dcrup@ietf.org" Thread-Topic: [Dcrup] Notes from IETF99 dcrup meeting Thread-Index: AQHTATmcyP4sIVT+MkWUNHUYLDz27aJc/shAgAIIU4CADxP3MA== Date: Mon, 31 Jul 2017 15:07:57 +0000 Message-ID: <226969b204dd4b3cbace330ef5e695d4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <737c2948eae54ca49bb4fec3b7e64289@usma1ex-dag1mb3.msg.corp.akamai.com> <84372b7e-d037-3124-10c8-d2f4285059fa@bluepopcorn.net> In-Reply-To: <84372b7e-d037-3124-10c8-d2f4285059fa@bluepopcorn.net> 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.34.207] Content-Type: multipart/alternative; boundary="_000_226969b204dd4b3cbace330ef5e695d4usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_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-1706020000 definitions=main-1707310254 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-31_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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707310255 Archived-At: Subject: Re: [Dcrup] Notes from IETF99 dcrup meeting 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, 31 Jul 2017 15:08:08 -0000 --_000_226969b204dd4b3cbace330ef5e695d4usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gY2xhcmlmeSwgSmlt4oCZcyBjb3JyZWN0aW9uIG9mIFlvYXbigJlzIGphYmJlciBjb21tZW50 IHdhcyBpbmNsdWRlZC4NCg== --_000_226969b204dd4b3cbace330ef5e695d4usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5UbyBjbGFyaWZ5LCBKaW3igJlzIGNvcnJlY3Rpb24g b2YgWW9hduKAmXMgamFiYmVyIGNvbW1lbnQgd2FzIGluY2x1ZGVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_226969b204dd4b3cbace330ef5e695d4usma1exdag1mb1msgcorpak_-- From nobody Mon Jul 31 10:52: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 B8F68132739 for ; Mon, 31 Jul 2017 10:52: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, 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 (1536-bit key) 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 WMoHA3anhjlD for ; Mon, 31 Jul 2017 10:52:05 -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 65E0513273B for ; Mon, 31 Jul 2017 10:52:05 -0700 (PDT) Received: (qmail 70918 invoked from network); 31 Jul 2017 17:52:04 -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=11504.597f6e44.k1707; bh=2RiTcoeguCNm5al82aAoB0VgWWWFPBzVdifSBAQxAbY=; b=SzJYZiSXPpg44FL0TyfnBFGphF2ZCX9vh+S0sTs3BVg6Fmc5GabUpmZlsKgIZnE3Fh48AdvC34noZrJUKJtCtfnSB+YZUVQ105tKYIQ3Cr7CjNH/ctefw3iSKbxeYQM0qvrjUsqkBKpIBLaTfrgaRqZ2IXGU4Xrgl+1+ZkbEC1C61NK1Kv6WjUivUy1/QaMv9MOzhwboZGft25D3jdsBCFnNDe+SGlb1Tuup2hIWKNVwcmfqj7J6OudVuoPg6pUt 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; 31 Jul 2017 17:52:04 -0000 Date: 31 Jul 2017 13:52:03 -0400 Message-ID: From: "John R. Levine" To: dcrup@ietf.org, dmarc@ietf.org 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: [Dcrup] Did you get survey spam from VT students? 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, 31 Jul 2017 17:52:11 -0000 I just got spam from a couple of Virginia Tech students with an impressively clueless "survey" about DKIM and DMARC usage. If you got it, could you instead reply to their professor and the VT IRB pointing out that scraping people's addresses from mailing lists is unethical and, in many countries, illegal. The multiple-choice question about DMARC usage did not include any options about DMARC causing more problems than it solved which (whether or not you agree that's the problem) tells us that they didn't do their homework. I could just barely tolerate a survey sent to the relevant mailing lists, but scraping individual addresses is way beyond the pale. Professor: gangwang@vt.edu IRB: moored@vt.edu, terrysparks@vt.edu, ctgreen@vt.edu 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 Mon Jul 31 15:25:30 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 9896F127010; Mon, 31 Jul 2017 15:25:20 -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.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150153992053.30783.12790628537230486560@ietfa.amsl.com> Date: Mon, 31 Jul 2017 15:25:20 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-03.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, 31 Jul 2017 22:25:21 -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 WG of the IETF. Title : Cryptographic Algorithm and Key Usage Update to DKIM Author : Scott Kitterman Filename : draft-ietf-dcrup-dkim-usage-03.txt Pages : 6 Date : 2017-07-31 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. 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-03 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 Jul 31 15:27: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 A3A61127010 for ; Mon, 31 Jul 2017 15:27: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, 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 jaYFLZx3MGJ0 for ; Mon, 31 Jul 2017 15:27:51 -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 CC9321327DD for ; Mon, 31 Jul 2017 15:27:51 -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 D424AC4021C for ; Mon, 31 Jul 2017 17:27:50 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1501540070; bh=0rCndFH71JFjDu+tUuxmcFeDEbWDEYSVB3gBOvzO4xs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oatIHauC1ZSXNRDkkUC8es7YMDMrSIOcHKSTuF1yhgTe1QAz30ho79LwF6fbkhR6s CESG7W1zAZL7vH5++L47e3KFajrPoqoup9OxvX1jG1bl2rSiIvgJrfxFZ5ZbD4LSPn BkCK7ROv5EAT3mvXyRfpCF9QBmrC1wZZYT/xBagE= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 31 Jul 2017 18:27:53 -0400 Message-ID: <5168806.T2ksrY36HR@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: 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 review and progress 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, 31 Jul 2017 22:27:54 -0000 If I did things right, -03 should be posted. Except for the 'should be rsa- sha256' in the ABNF comment, I took a stab at incorporating all of the below items. I didn't address that one because "sha1" / "sha256" / ... is straight out of RFC 6376, so I was reluctant to change it without further discussion in the group. Scott K On Tuesday, July 18, 2017 04:53:43 PM Murray S. Kucherawy wrote: > Having talked to a few others here at IETF 99 I'm abandoning my push > against using MUST NOT with respect to discouraging use of "rsa-sha1". > Scott, you're free to restore that language at your discretion, and I > believe consensus on that other thread supports that decision. Thanks for > everyone's patience while we worked through that one. > > We're going to appoint Seth Blank as the document shepherd for this one. > I'll help him through the process. Unless there's anything controversial > in here or in the two things on the agenda regarding this document, I > intend to start Working Group Last Call on it after the session on Thursday. > > I've reviewed the document (as a participant) and I have the following > additional feedback, in my role as a reviewing participant. > > Abstract: > - Remove the last sentence. It's already there in the header of the > document. > > Section 1: > - The discussion venue thing should be marked "[RFC EDITOR: Please remove > before publication.]" In fact, it's probably a good idea to make that its > own subsection. > - This section should also mention that SHA1 is being deprecated (and give > references explaining why). > > Section 3: > - "One algorithms" should be "One algorithm" at least; we could also say > "Two algorithms are defined, but only one is currently supported", and have > a subsection acknowledging that "rsa-sha1" did exist but it is obsolete and > no longer supported. I would prefer the latter. > > Section 3.2: > - There's an errant comma after "DKIM" near the end of the section. > - Should we say verifiers SHOULD NOT verify signatures with keys smaller > than 1024? > > Section 4: > - The ABNF should allow "rsa-sha256", not "sha256". > > Section 6: > - Errand double period at the end. > > Appendix A: > - I would remove the specific draft reference, unless you want this draft > to wait for that one to be published. Acknowledging John for a lot of > source material separately is at your discretion. > > -MSK