From nobody Wed Nov 1 15:45: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 9A81B13FF15 for ; Wed, 1 Nov 2017 15:45:20 -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 1t0JRR4MXJXI for ; Wed, 1 Nov 2017 15:45:18 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 3736B13FF12 for ; Wed, 1 Nov 2017 15:45:18 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id w134so4693320qkb.0 for ; Wed, 01 Nov 2017 15:45: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=rf5tnLGegMepvhwn15WNNdSRQeQuGxWQULaqNAgPqOI=; b=eH8q/nAWCaOHtFqak4IdOVH3Kjg16kkXFChtkcuv78IMOo/4RnFRgo3HhUBdxgJW6B DKfbogd0VE2q5Va1Z+gwFPZpUsjqg04xVFzrPkBO4DgvUqqesx9iwLPCZFXt9f/42hcI Qc0jlxf7FZAhEJT7SokOx5RlV1dgLAKNKO5wYdSBeN84Sasz17/MAJ+xGJhYxKQ2pEvB V3aN3+CVKccnd8gyebkHv6cRM1TIS7wR5AYyuEIlvNW+2CWWtOJlrU9IVuOR1jVFzzIU W2UIznQbBrG94+EX+LGBXnY5s9C7YfEK9g6SOqCYIDIeztkz6hFbc5TmhmnXbxoSU1Jj 1XRw== 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=rf5tnLGegMepvhwn15WNNdSRQeQuGxWQULaqNAgPqOI=; b=VWMMqkjdH1zCqc3PYmkmaHwJBpir62e1xGPoUSAveLsF6Ixky4CaQUfGHPploNsMVi SVviTQZd1L+sQnKfEL8W/S1B4M2kiZVgB+OO34zOLdH76fpLdnY9vdj0bnCOmB8YxBEy RqfRWHLcfvngSFxG84yt5No8uR6JK7n2LHmOgNGa1uOak8tqRsjDkP0BY+4tQMPO/bNP BBNIjsKX/Vcf8oBvnyisrd5k7SI9E/KurSrmLrf4xaTKTkyt/V1Zv5I4XyiVFWX4T0D3 BJpbkV+eVNY4biwwtg4It0QMh+dhzf2dMSflcQGGzVhyvkIFR1/jyDfq/9ikxnzOZxSD SD7A== X-Gm-Message-State: AJaThX4BNQxqLEszjDCgqz1b+AQ8D0ZXhZQx461lb51Y28U2Cp7p5sHu lkffO6saVOX9mStcc4NOWCjgY713TITardcmB1k8YFnS X-Google-Smtp-Source: ABhQp+Rnjzb5uRskW73oM0B7GOpp2GuEqXxTZfRzaYR8tXh4P0qBL8GMdXnGcOAg0wJR5emU7XhYZZ323zcsriL9gF8= X-Received: by 10.55.204.157 with SMTP id n29mr2059333qkl.243.1509576317210; Wed, 01 Nov 2017 15:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Wed, 1 Nov 2017 15:45:16 -0700 (PDT) In-Reply-To: <1504177085.2153024.1090910512.3EA32E07@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> <1504177085.2153024.1090910512.3EA32E07@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Wed, 1 Nov 2017 15:45:16 -0700 Message-ID: To: Alexey Melnikov Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1146d0522615e7055cf3a0fa" Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 22:45:21 -0000 --001a1146d0522615e7055cf3a0fa Content-Type: text/plain; charset="UTF-8" Circling back on this, which is the remaining point: On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov wrote: > On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote: > > On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov > wrote: > > > > On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote: > > The first line in Section 4 already says this updates 3.3 of RFC6376. You > think we need to be more specific? > > > > As I mentioned: I think sections 3.3.2 and 3.3.4 are still relevant. If > this document is replacing 3.3 and its subsections, some of this is lost. > > If you really intended to replace 3.3 and its subsections, it would be > worth adding "and its subsections" to the draft. > > > The draft says "updates", but you're saying "replaces". I don't see those > as the same thing. What this document says is to my mind treated as an > overlay, not a replacement; read RFC6376, then read this for current > advice, then act. > > I assume you are replacing the whole sections. If this is not what you are > doing, the document is even less clear and need to be clarified. > > If it's better to say this updates a specific subsection, then that's also > reasonable. I just thought what we have is sufficient. > > > Yes, please be specific. I couldn't be certain which sections are still in > force and which were updated. > I propose this, replacing our document's current Section 4: 4. Update to DKIM Signing and Verification Algorithms Section 4.1 updates the text in [RFC6376] Section 3.3. Section 4.2 updates the first paragraph in [RFC6376] Section 3.3.3. 4.1. DKIM Signing and Verification Algorithms DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or verifying. DKIM signatures signed with historic algorithms (currently rsa-sha1) or with insufficient key sizes (currently rsa-sha256 with less than 1024 bits) have permanently failed evaluation as discussed in [RFC6376] Section 3.9 . 4.2. Key Sizes Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits. Verifiers MUST be able to validate signatures with keys ranging from 1024 bits to 4096 bits, and they MAY be able to validate signatures with larger keys. Verifier policies can use the length of the signing key as one metric for determining whether a signature is acceptable. Verifiers MUST NOT consider signatures using RSA keys of less than 1024 bits as valid signatures. Alexey, would this suffice? -MSK --001a1146d0522615e7055cf3a0fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Circling back on this, which is the remaining point:

On Thu, Aug 31, 201= 7 at 3:58 AM, Alexey Melnikov <aamelnikov@fastmail.fm> = wrote:
On Thu, Aug 31, 2017, at 01:11 AM, Murray = S. Kucherawy wrote:
On Wed, Aug 30, 2017 at 11:= 33 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:<= br>


On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote:
The first line in Section = 4 already says this updates 3.3 of RFC6376.=C2=A0 You think we need to be m= ore specific?


As I mentioned: I think sections 3.3.2 and 3.3.4 are still relevant. I= f this document is replacing 3.3 and its subsections, some of this is lost.=

If you really intended to replace 3.3 and its subsections, it would be= worth adding "and its subsections" to the draft.

The draft says "updates", but you're saying "replac= es".=C2=A0 I don't see those as the same thing.=C2=A0 What this do= cument says is to my mind treated as an overlay, not a replacement; read RF= C6376, then read this for current advice, then act.
I assume you are replacing the whole sections. If = this is not what you are doing, the document is even less clear and need to= be clarified.

If it's bette= r to say this updates a specific subsection, then that's also reasonabl= e.=C2=A0 I just thought what we have is sufficient.

Yes, please be specific. I couldn't be certain which sectio= ns are still in force and which were updated.

I propose this, replacing our document's current Section = 4:

4. Upda=
te to DKIM Signing and Verification Algorithms

   Section 4.1 update=
s the text in [RFC6376] Section 3.3.

   Section 4.2 updates the firs=
t paragraph in [RFC6376] Section 3.3.3.

4.1. DKIM Signing and Verifi=
cation Algorithms

   DKIM supports multiple digital signature algorithms.  Two algorithms
   are defined by this specification at this time: rsa-sha1 and rsa-
   sha256.  Signers MUST sign using rsa-sha256.  Verifiers MUST be able
   to verify using rsa-sha256.  rsa-sha1 MUST NOT be used for signing or
   verifying.

   DKIM signatures signed with historic algorithms (currently rsa-sha1)
   or with insufficient key sizes (currently rsa-sha256 with less than
   1024 bits) have permanently failed evaluation as discussed in
   [RFC6376] Se=
ction=C2=A03.9.

4.2. Key Sizes

   Selecting appropriate key sizes is a trade-off between cost,
   performance, and risk.  Since short RSA keys more easily succumb to
   off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
   all keys.  Signers SHOULD use RSA keys of at least 2048 bits.
   Verifiers MUST be able to validate signatures with keys ranging from
   1024 bits to 4096 bits, and they MAY be able to validate signatures
   with larger keys.  Verifier policies can use the length of the
   signing key as one metric for determining whether a signature is
   acceptable.  Verifiers MUST NOT consider signatures using RSA keys of
   less than 1024 bits as valid signatures.

Alexey, would this suf=
fice?
-MSK
--001a1146d0522615e7055cf3a0fa-- From nobody Wed Nov 1 18:12: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 E9D4C13F591 for ; Wed, 1 Nov 2017 18:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_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 s7mTQxDqh7rt for ; Wed, 1 Nov 2017 18:12: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 B5F541386A1 for ; Wed, 1 Nov 2017 18:12:42 -0700 (PDT) Received: from [10.85.41.183] (mobile-166-170-35-78.mycingular.net [166.170.35.78]) (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 88966C4021F; Wed, 1 Nov 2017 20:12:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1509585160; bh=qLTGCd0QUdfi1/sdNqGWLvL7H/s2NXcB48WW6gLoW5w=; h=Date:In-Reply-To:References:Subject:To:From:From; b=FFDzsTgDVHK0wmpJjzcrr+asnh4upqUhl/oJcAAceAGFwlqRMTJB42cJMXdrH26sz f1ccjHIBRgZ73o2WF3xGU8FiFyR6MnAVLdjCHfGHUM6TPLPraIgVTfDd7VAonHvNVd IQEstPr0m10Bj3o1HZ/QUIV5F+mP4/K+jZM62uds= Date: Thu, 02 Nov 2017 01:12:35 +0000 In-Reply-To: References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> <1504177085.2153024.1090910512.3EA32E07@webmail.messagingengine.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: <185C158A-6306-426E-98B8-2E73D5056178@kitterman.com> Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 01:12:45 -0000 On November 1, 2017 6:45:16 PM EDT, "Murray S=2E Kucherawy" wrote: >Circling back on this, which is the remaining point: > >On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov > >wrote: > >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S=2E Kucherawy wrote: >> >> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov > >> wrote: >> >> >> >> On Wed, Aug 30, 2017, at 07:29 PM, Murray S=2E Kucherawy wrote: >> >> The first line in Section 4 already says this updates 3=2E3 of RFC6376= =2E > You >> think we need to be more specific? >> >> >> >> As I mentioned: I think sections 3=2E3=2E2 and 3=2E3=2E4 are still rele= vant=2E >If >> this document is replacing 3=2E3 and its subsections, some of this is >lost=2E >> >> If you really intended to replace 3=2E3 and its subsections, it would >be >> worth adding "and its subsections" to the draft=2E >> >> >> The draft says "updates", but you're saying "replaces"=2E I don't see >those >> as the same thing=2E What this document says is to my mind treated as >an >> overlay, not a replacement; read RFC6376, then read this for current >> advice, then act=2E >> >> I assume you are replacing the whole sections=2E If this is not what >you are >> doing, the document is even less clear and need to be clarified=2E >> >> If it's better to say this updates a specific subsection, then that's >also >> reasonable=2E I just thought what we have is sufficient=2E >> >> >> Yes, please be specific=2E I couldn't be certain which sections are >still in >> force and which were updated=2E >> > >I propose this, replacing our document's current Section 4: > >4=2E Update to DKIM Signing and Verification Algorithms > > Section 4=2E1 updates the text in [RFC6376] Section 3=2E3=2E > > Section 4=2E2 updates the first paragraph in [RFC6376] Section 3=2E3= =2E3=2E > >4=2E1=2E DKIM Signing and Verification Algorithms > > DKIM supports multiple digital signature algorithms=2E Two algorithms > are defined by this specification at this time: rsa-sha1 and rsa- > sha256=2E Signers MUST sign using rsa-sha256=2E Verifiers MUST be ab= le > to verify using rsa-sha256=2E rsa-sha1 MUST NOT be used for signing or > verifying=2E > > DKIM signatures signed with historic algorithms (currently rsa-sha1) > or with insufficient key sizes (currently rsa-sha256 with less than > 1024 bits) have permanently failed evaluation as discussed in >[RFC6376] Section 3=2E9 >=2E > >4=2E2=2E Key Sizes > > Selecting appropriate key sizes is a trade-off between cost, > performance, and risk=2E Since short RSA keys more easily succumb to > off-line attacks, Signers MUST use RSA keys of at least 1024 bits for > all keys=2E Signers SHOULD use RSA keys of at least 2048 bits=2E > Verifiers MUST be able to validate signatures with keys ranging from > 1024 bits to 4096 bits, and they MAY be able to validate signatures > with larger keys=2E Verifier policies can use the length of the > signing key as one metric for determining whether a signature is > acceptable=2E Verifiers MUST NOT consider signatures using RSA keys of > less than 1024 bits as valid signatures=2E > >Alexey, would this suffice? > >-MSK That would leave the new language about permanently failing tied only to r= sa-sha1 and not also in key size=2E I would either split the second paragra= ph of 4=2E1 to put with insufficient key size in 4=2E2 (DKIM signatures sig= ned with insufficient key sizes (currently rsa-sha256 with less than 1024 b= its) have permanently failed evaluation as discussed in [RFC6376] Section 3= =2E9 ) or move the w= hole paragraph up into section 4=2E Scott K From nobody Wed Nov 1 18:29: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 4914813F693 for ; Wed, 1 Nov 2017 18:29:57 -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 FJWt7n-NXfaS for ; Wed, 1 Nov 2017 18:29:55 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8A113F562 for ; Wed, 1 Nov 2017 18:29:55 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id n70so2594556vkf.11 for ; Wed, 01 Nov 2017 18:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h3J3yhnJ+EC0lM3PFRC0/xDEPKwylQVPr5jnkSVrc5w=; b=UPF2rBOXr3hTnPeJeROTbrdSW7xM/3Z520RWvUg5tLKHtG2BAtC/9WUcwssXicY+M+ yinOfhCsXtsCOm0K2REIk/OGQwM33pPtpI6l3M1Y9W60KaRdwCqTKeSY3riof/0MOWy+ 5WJiLoCod7BW0Qis6oTkm3BmIqBAdtGPVaGDDXYdkkN584S7A9RVGTEkK8TFyUEPhGok 7QBXm+BLDk1nChBIuJSnjIkGoeOfm1UjEfHfbabCvHqXAypJrJHeumZHhs+n9ekTh9Xq mQHQymwBmiCye9xG6hSdj8U53lYtXnOEF71zJy0NZM827g7cIJgeuRmR7lr6dZmiqlUU hUdA== 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=h3J3yhnJ+EC0lM3PFRC0/xDEPKwylQVPr5jnkSVrc5w=; b=fhNlpJYEo/eZYYZ1iz6LmD0xi4X4MJLQEfCHx8O2JQrbfC2NLzqyVUp2rNxx3PJbHy PWwTWJixArYy0nCpCiQcRTxtu0mXC2zRk8bxRZunN6XVLk2SPFYT/upZJoWk+J7ReU+h wn0EhM4cWUTYVwPJtAYK3x/DTSVLfDVJ5sJ8kMRuE/nOOsyl38Ef+OJW8F0vU+B7VuD9 BHdkSj9xb7xzKV8T2C3574VJNy9IVl9G1aqecyBPcDZXpwflbdfWu3utfUJOaDff8Hpy ZJxcjVmnknGv9O7AHenKQS5XOZkQuI6xza6b3NePvrIHbI5x78kiyG60GZpZCShFKAsN xKNA== X-Gm-Message-State: AJaThX7FUPME4f1RAkxXCEgcWnOlpThJYAYnNNq/ntapzcg7TkB3Eif3 mzJgZ9jLXXI0agajHdgEIIBNEkkyB9PeQMP47is= X-Google-Smtp-Source: ABhQp+QWdhQ+DZX/E37en2OfvDwGxpcPZrB9qb8drti/rFYhm12bizqPFEBsCqEO7zKwiVUbTe0jqhPHrqLD0CuOxRM= X-Received: by 10.31.155.74 with SMTP id d71mr1458938vke.94.1509586194406; Wed, 01 Nov 2017 18:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.72.67 with HTTP; Wed, 1 Nov 2017 18:29:53 -0700 (PDT) In-Reply-To: <185C158A-6306-426E-98B8-2E73D5056178@kitterman.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> <1504177085.2153024.1090910512.3EA32E07@webmail.messagingengine.com> <185C158A-6306-426E-98B8-2E73D5056178@kitterman.com> From: "Murray S. Kucherawy" Date: Wed, 1 Nov 2017 18:29:53 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113d2b12e0231d055cf5ec8b" Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 01:29:57 -0000 --001a113d2b12e0231d055cf5ec8b Content-Type: text/plain; charset="UTF-8" On Wed, Nov 1, 2017 at 6:12 PM, Scott Kitterman wrote: > That would leave the new language about permanently failing tied only to > rsa-sha1 and not also in key size. I would either split the second > paragraph of 4.1 to put with insufficient key size in 4.2 (DKIM signatures > signed with insufficient key sizes (currently rsa-sha256 with less than > 1024 bits) have permanently failed evaluation as discussed in [RFC6376] > Section 3.9 ) or move > the whole paragraph up into section 4. > I think I like the first option. Anyone else (and Alexey in particular)? -MSK --001a113d2b12e0231d055cf5ec8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 1, 2017 at 6:12 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
That would leave the ne= w language about permanently failing tied only to rsa-sha1 and not also in = key size. I would either split the second paragraph of 4.1 to put with insu= fficient key size in 4.2 (DKIM signatures signed with insufficient key size= s (currently rsa-sha256 with less than 1024 bits) have permanently failed e= valuation as discussed in [RFC6376] Section 3.9 <h= ttps://tools.ietf.org/html/rfc6376#section-3.9>) or move the wh= ole paragraph up into section 4.

I thin= k I like the first option.=C2=A0 Anyone else (and Alexey in particular)?

-MSK
--001a113d2b12e0231d055cf5ec8b-- From nobody Thu Nov 2 08: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 7B94513FA9F for ; Thu, 2 Nov 2017 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=3HjeZYBg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LIUTLZwW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk6x0b0JRqah for ; Thu, 2 Nov 2017 08:06:35 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0696D13F92E for ; Thu, 2 Nov 2017 08:06:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 6E0D620C76; Thu, 2 Nov 2017 11:06:34 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 02 Nov 2017 11:06:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=KbOIthYQAdCMGc9U078KPk39N3CvU PrFZe5uRHDgi6g=; b=3HjeZYBgJHVeSVosxsnrZY67F1wbNVL75C/8GgKaW0lo6 vKKi31ztki1JDof8x8WfL8QteDfnzJOL+9k2onm+/17mS10xlA3BbuyD1UXi8Icf YMZWnICvKAT+i7KyN2hI3jsXB6WT/iqgQLrHrI5QVIAEqdjP+JDTeFWiS4KMhNvR /ap5wHFBtwEqITAXtEExBr5g7xytKa8seP1vD/nsoCinqEt+56sH4Mf78T4vBFzt Jf3rck+kwUwXj90JaCSQ71GwGZ02UUPcNAj6rUJktdziQ98a1Oar1vuo1rGKSTz/ ydSGm0grS50frcww2uU/x6lTZW0HPFxeDEftMu2kQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=KbOIth YQAdCMGc9U078KPk39N3CvUPrFZe5uRHDgi6g=; b=LIUTLZwW1zlj+qAE7FB+j2 YGlT6QpZ8F2W8tZbPT+a37kr5ul6K1C2S00kSSo5ZllJ0pV8V5DJMCBAyqjpOun/ uqurhdSLx4wU8EYdjerzbAF3JWsaNBc1yyAvO22pynp19v/bstrjLwpQVWkk4GOn I7XG34eYBrwvBEFB0ALADvm5AWqp8gD2yzzJnvyb7UXQYPwpcgBx7M0As5CUM965 a7PU9nI4A+GDWF399bFpqFHuSunMpuko5zV3gzTEHO3sZTS4pM8+fCMGiFsAk++p FivSMu06hqsWsJJ7M/+kUlBhiFBvBE778x/vYLG32w9MUpnCA2Zo3tDYDMobkbQg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4B1469E301; Thu, 2 Nov 2017 11:06:34 -0400 (EDT) Message-Id: <1509635194.3915266.1159421104.02964C44@webmail.messagingengine.com> From: Alexey Melnikov To: "Murray S. Kucherawy" Cc: dcrup@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150963519439152662" X-Mailer: MessagingEngine.com Webmail Interface - ajax-66b6e65c References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> <1504177085.2153024.1090910512.3EA32E07@webmail.messagingengine.com> Date: Thu, 02 Nov 2017 15:06:34 +0000 In-Reply-To: Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:06:36 -0000 This is a multi-part message in MIME format. --_----------=_150963519439152662 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote: > Circling back on this, which is the remaining point: > > On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov > wrote:>> >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote: >>> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov >>> wrote:>>>> >>>> >>>> On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote: >>>>> The first line in Section 4 already says this updates 3.3 of >>>>> RFC6376. You think we need to be more specific?>>>> >>>> >>>> As I mentioned: I think sections 3.3.2 and 3.3.4 are still >>>> relevant. If this document is replacing 3.3 and its subsections, >>>> some of this is lost.>>>> >>>> If you really intended to replace 3.3 and its subsections, it would >>>> be worth adding "and its subsections" to the draft.>>> >>> The draft says "updates", but you're saying "replaces". I don't see >>> those as the same thing. What this document says is to my mind >>> treated as an overlay, not a replacement; read RFC6376, then read >>> this for current advice, then act.>> >> I assume you are replacing the whole sections. If this is not what >> you are doing, the document is even less clear and need to be >> clarified.>> >> >>> If it's better to say this updates a specific subsection, then >>> that's also reasonable. I just thought what we have is sufficient.>> >> >> Yes, please be specific. I couldn't be certain which sections are >> still in force and which were updated.> > I propose this, replacing our document's current Section 4: > > 4. Update to DKIM Signing and Verification Algorithms > > > > Section 4.1 updates the text in [RFC6376] Section 3.3. > > > > Section 4.2 updates the first paragraph in [RFC6376] Section 3.3.3. > I want some specific text about what happens to sections: 3.3.1. The rsa-sha1 Signing Algorithm 3.3.2. The rsa-sha256 Signing Algorithm 3.3.4. Other Algorithms e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected" or similar. (Or the correct disposition of these sections if what I suggested is not correct. > > > 4.1. DKIM Signing and Verification Algorithms DKIM supports multiple > digital signature algorithms. Two algorithms are defined by this > specification at this time: rsa-sha1 and rsa- sha256. Signers > MUST sign using rsa-sha256. Verifiers MUST be able to verify > using rsa-sha256. rsa-sha1 MUST NOT be used for signing or > verifying. DKIM signatures signed with historic algorithms > (currently rsa-sha1) or with insufficient key sizes (currently > rsa-sha256 with less than 1024 bits) have permanently failed > evaluation as discussed in [RFC6376] Section 3.9[1]. 4.2. Key > Sizes Selecting appropriate key sizes is a trade-off between > cost, performance, and risk. Since short RSA keys more easily > succumb to off-line attacks, Signers MUST use RSA keys of at > least 1024 bits for all keys. Signers SHOULD use RSA keys of at > least 2048 bits. Verifiers MUST be able to validate signatures > with keys ranging from 1024 bits to 4096 bits, and they MAY be > able to validate signatures with larger keys. Verifier policies > can use the length of the signing key as one metric for > determining whether a signature is acceptable. Verifiers MUST > NOT consider signatures using RSA keys of less than 1024 bits as > valid signatures. > > Alexey, would this suffice? -MSK Links: 1. https://tools.ietf.org/html/rfc6376#section-3.9 --_----------=_150963519439152662 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote:
Circling back on this, which is the remaining point:

On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:

On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote:
On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:


On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote:
The first line in Section 4 already says this updates 3.3 of RFC6376.  You think we need to be more specific?


As I mentioned: I think sections 3.3.2 and 3.3.4 are still relevant. If this document is replacing 3.3 and its subsections, some of this is lost.

If you really intended to replace 3.3 and its subsections, it would be worth adding "and its subsections" to the draft.

The draft says "updates", but you're saying "replaces".  I don't see those as the same thing.  What this document says is to my mind treated as an overlay, not a replacement; read RFC6376, then read this for current advice, then act.

I assume you are replacing the whole sections. If this is not what you are doing, the document is even less clear and need to be clarified.


If it's better to say this updates a specific subsection, then that's also reasonable.  I just thought what we have is sufficient.


Yes, please be specific. I couldn't be certain which sections are still in force and which were updated.

I propose this, replacing our document's current Section 4:

4. Update to DKIM Signing and Verification Algorithms





   Section 4.1 updates the text in [RFC6376] Section 3.3.





   Section 4.2 updates the first paragraph in [RFC6376] Section 3.3.3.

I want some specific text about what happens to sections:

3.3.1.  The rsa-sha1 Signing Algorithm
3.3.2.  The rsa-sha256 Signing Algorithm
3.3.4.  Other Algorithms

e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected" or similar. (Or the correct disposition of these sections if what I suggested is not correct.




4.1. DKIM Signing and Verification Algorithms

   DKIM supports multiple digital signature algorithms.  Two algorithms
   are defined by this specification at this time: rsa-sha1 and rsa-
   sha256.  Signers MUST sign using rsa-sha256.  Verifiers MUST be able
   to verify using rsa-sha256.  rsa-sha1 MUST NOT be used for signing or
   verifying.

   DKIM signatures signed with historic algorithms (currently rsa-sha1)
   or with insufficient key sizes (currently rsa-sha256 with less than
   1024 bits) have permanently failed evaluation as discussed in
   [RFC6376] Section 3.9.

4.2. Key Sizes

   Selecting appropriate key sizes is a trade-off between cost,
   performance, and risk.  Since short RSA keys more easily succumb to
   off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
   all keys.  Signers SHOULD use RSA keys of at least 2048 bits.
   Verifiers MUST be able to validate signatures with keys ranging from
   1024 bits to 4096 bits, and they MAY be able to validate signatures
   with larger keys.  Verifier policies can use the length of the
   signing key as one metric for determining whether a signature is
   acceptable.  Verifiers MUST NOT consider signatures using RSA keys of
   less than 1024 bits as valid signatures.


Alexey, would this suffice?
-MSK

--_----------=_150963519439152662-- From nobody Thu Nov 2 08:08: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 9142A13FAB0 for ; Thu, 2 Nov 2017 08:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Q3G+cz87; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=g9dRRORw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqUDM82bWuEu for ; Thu, 2 Nov 2017 08:08:16 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A14B13FA9F for ; Thu, 2 Nov 2017 08:08:16 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 83B2620DD3; Thu, 2 Nov 2017 11:08:15 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 02 Nov 2017 11:08:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=/rkg7RFMtd3ew2sDtopTrlMsdezj8 DhPT9NfNfCpwwM=; b=Q3G+cz8790SmUvyxDs6ewHsa+nt1lbRXvHqasempFMJUn RiHGpwF10E+gWI/+UlCE8yYmrhUWWYFwEXw0Xnp8u7QkVwqMbF6BJzNe/RlJNDEf jGsYvOruQZxlYhTE1jDGcaMCseWSuh3B2QBhlggD21pgUqnwHbRRsUR+h6gFYb+q cn3FIMdhtriMo+T1v/8O9+957irZHGUCoZ26spNz0Ca+DUkv/zf0ho2LiB1+B3Dy +P3t+HOHDOGoz0Sou6lbwOkLoK0q/FCJtlFaaU3dKUFgm+xEMTMPfU4pVPd1YPuw XDjE0RTKSRbKYXhGg3aSkmb3CxpQ+YgGyrjcmeAUg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=/rkg7R FMtd3ew2sDtopTrlMsdezj8DhPT9NfNfCpwwM=; b=g9dRRORwAXIeubV0YVFI8i mW24jjUlLmkSUtT9iQj16F/2hYmRFk4IoVlPzPa3csgpv4hErzKjN+aE21TS5zfi h4jI5IcEoHgswNGE0xWlza+ZTac1DzeU7oWXPgIXhUPbxKtK/R4cjpijKEUIvY+2 GXV8mn33V861s41jase1gRO/jRNd6n/1GUX3KF2CaXf+6g8vJsYQCpe6/AcP/kH6 iGLJ8oVteDaZcjsWTQOeLBR3enQ+6MAx3YoW2MsCY2Mt3cYN6X05fxdGAuj5Iwtp TchdL+2ykEbNjBF+fKrbAqTtppAfMwiEKPgK9JrhdqKLIBMO+p4AdypkMCnBHOlQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 6696C9E2E8; Thu, 2 Nov 2017 11:08:15 -0400 (EDT) Message-Id: <1509635295.3915594.1159426944.0FC7FF67@webmail.messagingengine.com> From: Alexey Melnikov To: "Murray S. Kucherawy" , Scott Kitterman Cc: dcrup@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150963529539155940" X-Mailer: MessagingEngine.com Webmail Interface - ajax-66b6e65c Date: Thu, 02 Nov 2017 15:08:15 +0000 References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> <1504177085.2153024.1090910512.3EA32E07@webmail.messagingengine.com> <185C158A-6306-426E-98B8-2E73D5056178@kitterman.com> In-Reply-To: Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:08:17 -0000 This is a multi-part message in MIME format. --_----------=_150963529539155940 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, Nov 2, 2017, at 01:29 AM, Murray S. Kucherawy wrote: > On Wed, Nov 1, 2017 at 6:12 PM, Scott Kitterman > wrote:>> That would leave the new language about permanently failing tied only >> to rsa-sha1 and not also in key size. I would either split the second >> paragraph of 4.1 to put with insufficient key size in 4.2 (DKIM >> signatures signed with insufficient key sizes (currently rsa-sha256 >> with less than 1024 bits) have permanently failed evaluation as >> discussed in [RFC6376] Section 3.9 >> ) or move the whole >> paragraph up into section 4.> > I think I like the first option. Anyone else (and Alexey in > particular)? Either is fine with me. --_----------=_150963529539155940 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, Nov 2, 2017, at 01:29 AM, Murray S. Kucherawy wrote:
On Wed, Nov 1, 2017 at 6:12 PM, Scott Kitterman <sklist@kitterman.com> wrote:
That would leave the new language about permanently failing tied only to rsa-sha1 and not also in key size. I would either split the second paragraph of 4.1 to put with insufficient key size in 4.2 (DKIM signatures signed with insufficient key sizes (currently rsa-sha256 with less than 1024 bits) have permanently failed evaluation as discussed in [RFC6376] Section 3.9 <https://tools.ietf.org/html/rfc6376#section-3.9>) or move the whole paragraph up into section 4.

I think I like the first option.  Anyone else (and Alexey in particular)?

Either is fine with me.


--_----------=_150963529539155940-- From nobody Thu Nov 2 11:38: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 3AE8E13F59F for ; Thu, 2 Nov 2017 11:38:53 -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 gOEBV9-Q19Da for ; Thu, 2 Nov 2017 11:38: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 7886E137832 for ; Thu, 2 Nov 2017 11:38: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 ESMTPS id 86F9DC400B7 for ; Thu, 2 Nov 2017 13:38:49 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 02 Nov 2017 14:01:08 -0400 Message-ID: <7977231.PulXPLHMLE@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-133-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1509635295.3915594.1159426944.0FC7FF67@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1509635295.3915594.1159426944.0FC7FF67@webmail.messagingengine.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 18:38:53 -0000 On Thursday, November 02, 2017 03:08:15 PM Alexey Melnikov wrote: > On Thu, Nov 2, 2017, at 01:29 AM, Murray S. Kucherawy wrote: > > On Wed, Nov 1, 2017 at 6:12 PM, Scott Kitterman > > wrote:>> That would leave the new language about > > permanently failing tied only> > >> to rsa-sha1 and not also in key size. I would either split the second > >> paragraph of 4.1 to put with insufficient key size in 4.2 (DKIM > >> signatures signed with insufficient key sizes (currently rsa-sha256 > >> with less than 1024 bits) have permanently failed evaluation as > >> discussed in [RFC6376] Section 3.9 > >> ) or move the whole > >> paragraph up into section 4.> > > > > I think I like the first option. Anyone else (and Alexey in > > particular)? > > Either is fine with me. OK. I'll have an update shortly. There's also a word missing in Appendix A that I'll fix at the same time (this was reported off-list after I uploaded -05): Appendix A, Line 194: READS: Thanks to John Levine his DCRUP work that was the source for much of SHOULD READ: Thanks to John Levine for his DCRUP work that was the source for much of Scott K From nobody Thu Nov 2 12:18: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 A9A0613F584 for ; Thu, 2 Nov 2017 12:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 hFLWn5D0F2Ui for ; Thu, 2 Nov 2017 12:18:30 -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 E46CA137832 for ; Thu, 2 Nov 2017 12:18:29 -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 ESMTPS id 1F6D1C401DB for ; Thu, 2 Nov 2017 14:18:27 -0500 (CDT) From: Scott Kitterman To: dcrup@ietf.org Date: Thu, 02 Nov 2017 15:18:13 -0400 Message-ID: <2853504.Nql0Dy0gKo@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-133-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <1509635194.3915266.1159421104.02964C44@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1509635194.3915266.1159421104.02964C44@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart4156455.TpyuXuajss" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 19:18:33 -0000 This is a multi-part message in MIME format. --nextPart4156455.TpyuXuajss Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, November 02, 2017 03:06:34 PM Alexey Melnikov wrote: > On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote: > > Circling back on this, which is the remaining point: > > > > On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov > > wrote:>> > > > >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote: > >>> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov > >>> wrote:>>>> > >>> > >>>> On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote: > >>>>> The first line in Section 4 already says this updates 3.3 of > >>>>> RFC6376. You think we need to be more specific?>>>> > >>>> > >>>> As I mentioned: I think sections 3.3.2 and 3.3.4 are still > >>>> relevant. If this document is replacing 3.3 and its subsections, > >>>> some of this is lost.>>>> > >>>> If you really intended to replace 3.3 and its subsections, it would > >>>> be worth adding "and its subsections" to the draft.>>> > >>> > >>> The draft says "updates", but you're saying "replaces". I don't see > >>> those as the same thing. What this document says is to my mind > >>> treated as an overlay, not a replacement; read RFC6376, then read > >>> this for current advice, then act.>> > >> > >> I assume you are replacing the whole sections. If this is not what > >> you are doing, the document is even less clear and need to be > >> clarified.>> > >> > >>> If it's better to say this updates a specific subsection, then > >>> that's also reasonable. I just thought what we have is sufficient.>> > >> > >> Yes, please be specific. I couldn't be certain which sections are > >> still in force and which were updated.> > > > > I propose this, replacing our document's current Section 4: > > > > 4. Update to DKIM Signing and Verification Algorithms > > > > Section 4.1 updates the text in [RFC6376] Section 3.3. > > > > > > > > Section 4.2 updates the first paragraph in [RFC6376] Section 3.3.3. > > I want some specific text about what happens to sections: > > 3.3.1. The rsa-sha1 Signing Algorithm > 3.3.2. The rsa-sha256 Signing Algorithm > 3.3.4. Other Algorithms > > e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected" or similar. (Or > the correct disposition of these sections if what I suggested is > not correct. > > > 4.1. DKIM Signing and Verification Algorithms DKIM supports multiple > > > > digital signature algorithms. Two algorithms are defined by this > > specification at this time: rsa-sha1 and rsa- sha256. Signers > > MUST sign using rsa-sha256. Verifiers MUST be able to verify > > using rsa-sha256. rsa-sha1 MUST NOT be used for signing or > > verifying. DKIM signatures signed with historic algorithms > > (currently rsa-sha1) or with insufficient key sizes (currently > > rsa-sha256 with less than 1024 bits) have permanently failed > > evaluation as discussed in [RFC6376] Section 3.9[1]. 4.2. Key > > Sizes Selecting appropriate key sizes is a trade-off between > > cost, performance, and risk. Since short RSA keys more easily > > succumb to off-line attacks, Signers MUST use RSA keys of at > > least 1024 bits for all keys. Signers SHOULD use RSA keys of at > > least 2048 bits. Verifiers MUST be able to validate signatures > > with keys ranging from 1024 bits to 4096 bits, and they MAY be > > able to validate signatures with larger keys. Verifier policies > > can use the length of the signing key as one metric for > > determining whether a signature is acceptable. Verifiers MUST > > NOT consider signatures using RSA keys of less than 1024 bits as > > valid signatures. > > > > Alexey, would this suffice? -MSK > > Links: > > 1. https://tools.ietf.org/html/rfc6376#section-3.9 I added text about 3.3.1, 2, and 4. See the attached RFC diff. If that works for you, I'll submit -06 and (hopefully) we can call it done. Scott K --nextPart4156455.TpyuXuajss Content-Disposition: attachment; filename="draft-ietf-dcrup-dkim-usage-from--05.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-dcrup-dkim-usage-from--05.diff.html" Diff: draft-ietf-dcrup-dkim-usage-05.txt - draft-ietf-dcrup-dkim-usage.txt
 draft-ietf-dcrup-dkim-usage-05.txt   draft-ietf-dcrup-dkim-usage.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft Kitterman Technical Services Internet-Draft Kitterman Technical Services
Updates: 6376 (if approved) October 27, 2017 Updates: 6376 (if approved) November 2, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: April 30, 2018 Expires: May 6, 2018
Cryptographic Algorithm and Key Usage Update to DKIM Cryptographic Algorithm and Key Usage Update to DKIM
draft-ietf-dcrup-dkim-usage-05 draft-ietf-dcrup-dkim-usage-06
Abstract Abstract
The cryptographic algorithm and key size requirements included when The cryptographic algorithm and key size requirements included when
DKIM was designed in the last decade are functionally obsolete and in DKIM was designed in the last decade are functionally obsolete and in
need of immediate revision. This document updates DKIM requirements need of immediate revision. This document updates DKIM requirements
to those minimaly suitable for operation with currently specified to those minimaly suitable for operation with currently specified
algorithms. algorithms.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2018. This Internet-Draft will expire on May 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 2 1. Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. DKIM Signing and Verification Algorithms . . . . . . . . . . 3 4. DKIM Signing and Verification Algorithms . . . . . . . . . . 3
4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. DKIM Signing and Verification Algorithms . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Discussion Venue 1. Discussion Venue
RFC EDITOR: Please remove this section before publication. RFC EDITOR: Please remove this section before publication.
Discussion about this draft is directed to the dcrup@ietf.org [1] Discussion about this draft is directed to the dcrup@ietf.org [1]
mailing list. mailing list.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
3. Conventions Used in This Document 3. Conventions Used in This Document
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
4. DKIM Signing and Verification Algorithms 4. DKIM Signing and Verification Algorithms
This section updates [RFC6376] Section 3.3. Section 4.1 updates [RFC6376] Section 3.3.
Section 4.2 updates [RFC6376] Section 3.3.3.
The algorithm described in[RFC6376] Section 3.3.1 is now historic and
no longer used by DKIM.
[RFC6376] Sections 3.3.2 and 3.3.4 are not affected.
4.1. DKIM Signing and Verification Algorithms
DKIM supports multiple digital signature algorithms. Two algorithms DKIM supports multiple digital signature algorithms. Two algorithms
are defined by this specification at this time: rsa-sha1 and rsa- are defined by this specification at this time: rsa-sha1 and rsa-
sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able sha256. Signers MUST sign using rsa-sha256. Verifiers MUST be able
to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or to verify using rsa-sha256. rsa-sha1 MUST NOT be used for signing or
verifying. verifying.
DKIM signatures signed with historic algorithms (currently rsa-sha1) DKIM signatures identified as having been signed with historic
or with insufficient key sizes (currently rsa-sha256 with less than algorithms (currently rsa-sha1) have permanently failed evaluation as
1024 bits) have permanently failed evaluation as discussed in discussed in [RFC6376] Section 3.9.
[RFC6376] Section 3.9.
4.1. Key Sizes 4.2. Key Sizes
Selecting appropriate key sizes is a trade-off between cost, Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
all keys. Signers SHOULD use RSA keys of at least 2048 bits. all keys. Signers SHOULD use RSA keys of at least 2048 bits.
Verifiers MUST be able to validate signatures with keys ranging from Verifiers MUST be able to validate signatures with keys ranging from
1024 bits to 4096 bits, and they MAY be able to validate signatures 1024 bits to 4096 bits, and they MAY be able to validate signatures
with larger keys. Verifier policies can use the length of the with larger keys. Verifier policies can use the length of the
signing key as one metric for determining whether a signature is signing key as one metric for determining whether a signature is
acceptable. Verifiers MUST NOT consider signatures using RSA keys of acceptable. Verifiers MUST NOT consider signatures using RSA keys of
less than 1024 bits as valid signatures. less than 1024 bits as valid signatures.
DKIM signatures with insufficient key sizes (currently rsa-sha256
with less than 1024 bits) have permanently failed evaluation as
discussed in [RFC6376] Section 3.9.
5. Security Considerations 5. Security Considerations
This document does not change the Security Considerations of This document does not change the Security Considerations of
[RFC6376]. It reduces the risk of signature compromise due to weak [RFC6376]. It reduces the risk of signature compromise due to weak
cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are cryptography. The SHA-1 risks discussed in [RFC6194] Section 3 are
resolved due to rsa-sha1 no longer being used by DKIM. resolved due to rsa-sha1 no longer being used by DKIM.
6. IANA Considerations 6. IANA Considerations
IANA is requested to update the "sha1" registration in the "DKIM Hash IANA is requested to update the "sha1" registration in the "DKIM Hash
skipping to change at page 5, line 11 skipping to change at page 5, line 24
7.3. URIs 7.3. URIs
[1] mailto:dcrup@ietf.org [1] mailto:dcrup@ietf.org
Appendix A. Acknowledgements Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and The author wishes to acknowledge the following for their review and
comment on this proposal: Kurt Andersen, Murray S. Kucherawy, Martin comment on this proposal: Kurt Andersen, Murray S. Kucherawy, Martin
Thomson, John Levine, Russ Housley, and Jim Fenton. Thomson, John Levine, Russ Housley, and Jim Fenton.
Thanks to John Levine his DCRUP work that was the source for much of Thanks to John Levine for his DCRUP work that was the source for much
the introductory material in this draft. of the introductory material in this draft.
Author's Address Author's Address
Scott Kitterman Scott Kitterman
Kitterman Technical Services Kitterman Technical Services
3611 Scheel Dr 3611 Scheel Dr
Ellicott City, MD 21042 Ellicott City, MD 21042
Phone: +1 301 325-5475 Phone: +1 301 325-5475
Email: scott@kitterman.com Email: scott@kitterman.com
 End of changes. 11 change blocks. 
15 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart4156455.TpyuXuajss-- From nobody Fri Nov 3 03:11: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 00F9A13FD44 for ; Fri, 3 Nov 2017 03:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.fm header.b=5arcg/T1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oJ1AwtAO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVL2U3ggkY3j for ; Fri, 3 Nov 2017 03:10:58 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EFD813FD3E for ; Fri, 3 Nov 2017 03:10:58 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E799020CF4; Fri, 3 Nov 2017 06:10:57 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Fri, 03 Nov 2017 06:10:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=1ZGnvAHd9TKxmGIbSQwYS1iFTv6KC 9UZ9rP+LTdQ674=; b=5arcg/T1UAFEdc6Bshi6mQBlGf7VtyQ5O8GLaFDwbqpS5 jae4bjAXNaJyUzvyXmGxCvjS3qtgLXs2ABsWkya+QQREsiWf6anpnpPNXQKJZ7nc aRO4PRDZQ6rvh2dJ0mXneEEyYDpT9zoo2bhCVRgt6c8sDWPARD7l+13EKYgVCJdn +sQUaZFa+ZZ9Dlc4IGr0LtvjyJ+69Q9/r9aiIxfm4IF7hVBUdr1PTn3bLWd9dfv+ mSF8zmn1eUyLzaU2v8X4wzvsKL+fViSlmV0Gz9k07dhL0aK0DF6wofY1EvgM+LFX zTtz9Oc4KqBt5nD6VOqacJkjdG0kW9lXiBKquU5JQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=1ZGnvA Hd9TKxmGIbSQwYS1iFTv6KC9UZ9rP+LTdQ674=; b=oJ1AwtAOOJh3JfSEiHcVQk R4y9Qia3WXJkxaxVbrrCi1FWLwI3KpjPcoJUu3uSTCJKS4rX9WrVGVwY2+noJMTp 4Cbb2Qa8cTs0+Bwq97MkFq8+MRr27AbAuPmeTHTP3Z3/vuirVP7FZfWFB6AyJvD2 wx0uuHsWtR36ykmBJSQCXHE4DwQ0gBDa/GVP5eaqBGUUKwG3u92Sp2wC86EfvSRi n74zreC5M3+d9A+bqSwVqnXN98zUd85FP1fegJ5/Ii1E2F3uH4dxuqNr7awjMzuI lVPy7RWvKY6W4+hxJZWzCoFHADw0PwXTYj4en0Swc23GBrzsxG58coO79bGOLemQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C76D09E227; Fri, 3 Nov 2017 06:10:57 -0400 (EDT) Message-Id: <1509703857.2871167.1160341520.3C2D0DC2@webmail.messagingengine.com> From: Alexey Melnikov To: Scott Kitterman , dcrup@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-c8a842c4 Date: Fri, 03 Nov 2017 10:10:57 +0000 References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1509635194.3915266.1159421104.02964C44@webmail.messagingengine.com> <2853504.Nql0Dy0gKo@kitterma-e6430> In-Reply-To: <2853504.Nql0Dy0gKo@kitterma-e6430> Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 10:11:00 -0000 This looks good to me. Please post a new version. If you need to do a manual post (due to pre-Singapore draft submission deadline), please request it and I will authorize it. On Thu, Nov 2, 2017, at 07:18 PM, Scott Kitterman wrote: > On Thursday, November 02, 2017 03:06:34 PM Alexey Melnikov wrote: > > On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote: > > > Circling back on this, which is the remaining point: > > > > > > On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov > > > wrote:>> > > > > > >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote: > > >>> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov > > >>> wrote:>>>> > > >>> > > >>>> On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote: > > >>>>> The first line in Section 4 already says this updates 3.3 of > > >>>>> RFC6376. You think we need to be more specific?>>>> > > >>>> > > >>>> As I mentioned: I think sections 3.3.2 and 3.3.4 are still > > >>>> relevant. If this document is replacing 3.3 and its subsections, > > >>>> some of this is lost.>>>> > > >>>> If you really intended to replace 3.3 and its subsections, it would > > >>>> be worth adding "and its subsections" to the draft.>>> > > >>> > > >>> The draft says "updates", but you're saying "replaces". I don't see > > >>> those as the same thing. What this document says is to my mind > > >>> treated as an overlay, not a replacement; read RFC6376, then read > > >>> this for current advice, then act.>> > > >> > > >> I assume you are replacing the whole sections. If this is not what > > >> you are doing, the document is even less clear and need to be > > >> clarified.>> > > >> > > >>> If it's better to say this updates a specific subsection, then > > >>> that's also reasonable. I just thought what we have is sufficient.>> > > >> > > >> Yes, please be specific. I couldn't be certain which sections are > > >> still in force and which were updated.> > > > > > > I propose this, replacing our document's current Section 4: > > > > > > 4. Update to DKIM Signing and Verification Algorithms > > > > > > Section 4.1 updates the text in [RFC6376] Section 3.3. > > > > > > > > > > > > Section 4.2 updates the first paragraph in [RFC6376] Section 3.3.3. > > > > I want some specific text about what happens to sections: > > > > 3.3.1. The rsa-sha1 Signing Algorithm > > 3.3.2. The rsa-sha256 Signing Algorithm > > 3.3.4. Other Algorithms > > > > e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected" or similar. (Or > > the correct disposition of these sections if what I suggested is > > not correct. > > > > > 4.1. DKIM Signing and Verification Algorithms DKIM supports multiple > > > > > > digital signature algorithms. Two algorithms are defined by this > > > specification at this time: rsa-sha1 and rsa- sha256. Signers > > > MUST sign using rsa-sha256. Verifiers MUST be able to verify > > > using rsa-sha256. rsa-sha1 MUST NOT be used for signing or > > > verifying. DKIM signatures signed with historic algorithms > > > (currently rsa-sha1) or with insufficient key sizes (currently > > > rsa-sha256 with less than 1024 bits) have permanently failed > > > evaluation as discussed in [RFC6376] Section 3.9[1]. 4.2. Key > > > Sizes Selecting appropriate key sizes is a trade-off between > > > cost, performance, and risk. Since short RSA keys more easily > > > succumb to off-line attacks, Signers MUST use RSA keys of at > > > least 1024 bits for all keys. Signers SHOULD use RSA keys of at > > > least 2048 bits. Verifiers MUST be able to validate signatures > > > with keys ranging from 1024 bits to 4096 bits, and they MAY be > > > able to validate signatures with larger keys. Verifier policies > > > can use the length of the signing key as one metric for > > > determining whether a signature is acceptable. Verifiers MUST > > > NOT consider signatures using RSA keys of less than 1024 bits as > > > valid signatures. > > > > > > Alexey, would this suffice? -MSK > > > > Links: > > > > 1. https://tools.ietf.org/html/rfc6376#section-3.9 > > I added text about 3.3.1, 2, and 4. See the attached RFC diff. If that > works > for you, I'll submit -06 and (hopefully) we can call it done. From nobody Fri Nov 3 10:34: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 AA1AC13FF1A for ; Fri, 3 Nov 2017 10:34: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 rB2cjbqiWmPm for ; Fri, 3 Nov 2017 10:34:43 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27D5313FF0D for ; Fri, 3 Nov 2017 10:34:43 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id z28so4109655qtz.13 for ; Fri, 03 Nov 2017 10:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RCRrDnbAbUDY1YEKDBP5i027uqEu66Qjf/dtv5jSLcM=; b=Xh0+E3deJC1HRJZw8Ha7prOBEGl7JDW9isv0etHEt1LDEKq3gPjjV5znTxkPTBZM0p ZvkQt3p3o9ySR0XauSVaxLYzJrOij/d/L3TEevOSo6lAhXxAmMMd26806RMBIPlTmTud 570gD9hYaJ61xJ/ueeA/MoZAr/DyBp9B9J+hHI4xd8zIwVSZ0pdcKl2HNC2ebdVXrrX1 Noo91FQPX5bDQt7oUUR9Czpf42vlpXkl3B9wmAB/dW36HNYyyBlxozfffjHZql2AwDLZ YPCUIVfD1kS1Kl6/oin2mAcUKIHf2cICkZi+okg3vfRVToOVo1IYKuWIGxeLjwMxm9/L ZaCw== 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=RCRrDnbAbUDY1YEKDBP5i027uqEu66Qjf/dtv5jSLcM=; b=tRyCzSDJteMCh6/sawiuE6PgQR7NIslOT/lfPOT8Tb3/a/+3mHTvFLATtHiPjDz9/M N6QcchIsV+cYfWjE+BG+UmWeOKzZN4aqt/8dFcN1gJ+H1UoZwFBVIysl0R6Yo0vaI40v +ITAkgXgGn2lmlzXQ3RUwwig7lQ5yJPn+UTjq61VgBvGpKHSox8/0FQzvp89cChc9FrI dVZRgrBUSVcAMwh/V0XaCZa6QCH2PbI9Cx0AikwYTxGRCLccBNPr+9f6IT1KnyMkOEr+ 2IW96C1gr2ROtt+M5Cv9TcnisW9pbh4LaOaHsSEHads8P9HZjHqza1qXuoGGaQG/bfFM 4I+w== X-Gm-Message-State: AMCzsaU7sLCt5BuTiiwOSk2uJIiXs1SeR0SxEHwaPlYFjkLkpeKlhgu9 YM1jHyJDd24NRhi+QU5iW7L4AV5w3sRhD2eUcY8= X-Google-Smtp-Source: ABhQp+Q1raCOgJw23nbHeuZXpjMDKw+OAe92doS78IzdT9qASShRAt+V6Zaa5nY65UY6kxcjXU9bdnCiBVXX5y91yn0= X-Received: by 10.237.62.153 with SMTP id n25mr10916175qtf.124.1509730482116; Fri, 03 Nov 2017 10:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Fri, 3 Nov 2017 10:34:41 -0700 (PDT) In-Reply-To: <1509703857.2871167.1160341520.3C2D0DC2@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1509635194.3915266.1159421104.02964C44@webmail.messagingengine.com> <2853504.Nql0Dy0gKo@kitterma-e6430> <1509703857.2871167.1160341520.3C2D0DC2@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Fri, 3 Nov 2017 10:34:41 -0700 Message-ID: To: Alexey Melnikov Cc: Scott Kitterman , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113a1f1617dc2c055d178561" Archived-At: Subject: Re: [Dcrup] AD review of draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 17:34:46 -0000 --001a113a1f1617dc2c055d178561 Content-Type: text/plain; charset="UTF-8" Scott may not have had to do that before, so just to be sure: The procedure I've used there is to email internet-drafts@ietf.org with the content as an attachment(s) and explain that Alexey will be approving it. On Fri, Nov 3, 2017 at 3:10 AM, Alexey Melnikov wrote: > This looks good to me. Please post a new version. > If you need to do a manual post (due to pre-Singapore draft submission > deadline), please request it and I will authorize it. > > On Thu, Nov 2, 2017, at 07:18 PM, Scott Kitterman wrote: > > On Thursday, November 02, 2017 03:06:34 PM Alexey Melnikov wrote: > > > On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote: > > > > Circling back on this, which is the remaining point: > > > > > > > > On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov > > > > wrote:>> > > > > > > > >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy wrote: > > > >>> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov > > > >>> wrote:>>>> > > > >>> > > > >>>> On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kucherawy wrote: > > > >>>>> The first line in Section 4 already says this updates 3.3 of > > > >>>>> RFC6376. You think we need to be more specific?>>>> > > > >>>> > > > >>>> As I mentioned: I think sections 3.3.2 and 3.3.4 are still > > > >>>> relevant. If this document is replacing 3.3 and its subsections, > > > >>>> some of this is lost.>>>> > > > >>>> If you really intended to replace 3.3 and its subsections, it > would > > > >>>> be worth adding "and its subsections" to the draft.>>> > > > >>> > > > >>> The draft says "updates", but you're saying "replaces". I don't > see > > > >>> those as the same thing. What this document says is to my mind > > > >>> treated as an overlay, not a replacement; read RFC6376, then read > > > >>> this for current advice, then act.>> > > > >> > > > >> I assume you are replacing the whole sections. If this is not what > > > >> you are doing, the document is even less clear and need to be > > > >> clarified.>> > > > >> > > > >>> If it's better to say this updates a specific subsection, then > > > >>> that's also reasonable. I just thought what we have is > sufficient.>> > > > >> > > > >> Yes, please be specific. I couldn't be certain which sections are > > > >> still in force and which were updated.> > > > > > > > > I propose this, replacing our document's current Section 4: > > > > > > > > 4. Update to DKIM Signing and Verification Algorithms > > > > > > > > Section 4.1 updates the text in [RFC6376] Section 3.3. > > > > > > > > > > > > > > > > Section 4.2 updates the first paragraph in [RFC6376] Section > 3.3.3. > > > > > > I want some specific text about what happens to sections: > > > > > > 3.3.1. The rsa-sha1 Signing Algorithm > > > 3.3.2. The rsa-sha256 Signing Algorithm > > > 3.3.4. Other Algorithms > > > > > > e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected" or similar. (Or > > > the correct disposition of these sections if what I suggested is > > > not correct. > > > > > > > 4.1. DKIM Signing and Verification Algorithms DKIM supports multiple > > > > > > > > digital signature algorithms. Two algorithms are defined by > this > > > > specification at this time: rsa-sha1 and rsa- sha256. Signers > > > > MUST sign using rsa-sha256. Verifiers MUST be able to verify > > > > using rsa-sha256. rsa-sha1 MUST NOT be used for signing or > > > > verifying. DKIM signatures signed with historic algorithms > > > > (currently rsa-sha1) or with insufficient key sizes (currently > > > > rsa-sha256 with less than 1024 bits) have permanently failed > > > > evaluation as discussed in [RFC6376] Section 3.9[1]. 4.2. Key > > > > Sizes Selecting appropriate key sizes is a trade-off between > > > > cost, performance, and risk. Since short RSA keys more easily > > > > succumb to off-line attacks, Signers MUST use RSA keys of at > > > > least 1024 bits for all keys. Signers SHOULD use RSA keys of at > > > > least 2048 bits. Verifiers MUST be able to validate signatures > > > > with keys ranging from 1024 bits to 4096 bits, and they MAY be > > > > able to validate signatures with larger keys. Verifier policies > > > > can use the length of the signing key as one metric for > > > > determining whether a signature is acceptable. Verifiers MUST > > > > NOT consider signatures using RSA keys of less than 1024 bits as > > > > valid signatures. > > > > > > > > Alexey, would this suffice? -MSK > > > > > > Links: > > > > > > 1. https://tools.ietf.org/html/rfc6376#section-3.9 > > > > I added text about 3.3.1, 2, and 4. See the attached RFC diff. If that > > works > > for you, I'll submit -06 and (hopefully) we can call it done. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a113a1f1617dc2c055d178561 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott may not have had to do that before, so just to be su= re: The procedure I've used there is to email internet-drafts@ietf.org with the content as an atta= chment(s) and explain that Alexey will be approving it.

On Fri, Nov 3, 2017 at 3:10= AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
This looks good to me. Please post a new ve= rsion.
If you need to do a manual post (due to pre-Singapore draft submission
deadline), please request it and I will authorize it.

On Thu, Nov 2, 2017, at 07:18 PM, Scott Kitterman wrote:
> On Thursday, November 02, 2017 03:06:34 PM Alexey Melnikov wrote:
> > On Wed, Nov 1, 2017, at 10:45 PM, Murray S. Kucherawy wrote:
> > > Circling back on this, which is the remaining point:
> > >
> > > On Thu, Aug 31, 2017 at 3:58 AM, Alexey Melnikov
> > > <aamelnikov@fas= tmail.fm> wrote:>>
> > >
> > >> On Thu, Aug 31, 2017, at 01:11 AM, Murray S. Kucherawy w= rote:
> > >>> On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov > > >>> <aameln= ikov@fastmail.fm> wrote:>>>>
> > >>>
> > >>>> On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kuc= herawy wrote:
> > >>>>> The first line in Section 4 already says thi= s updates 3.3 of
> > >>>>> RFC6376.=C2=A0 You think we need to be more = specific?>>>>
> > >>>>
> > >>>> As I mentioned: I think sections 3.3.2 and 3.3.4= are still
> > >>>> relevant. If this document is replacing 3.3 and = its subsections,
> > >>>> some of this is lost.>>>>
> > >>>> If you really intended to replace 3.3 and its su= bsections, it would
> > >>>> be worth adding "and its subsections" = to the draft.>>>
> > >>>
> > >>> The draft says "updates", but you're s= aying "replaces".=C2=A0 I don't see
> > >>> those as the same thing.=C2=A0 What this document sa= ys is to my mind
> > >>> treated as an overlay, not a replacement; read RFC63= 76, then read
> > >>> this for current advice, then act.>>
> > >>
> > >> I assume you are replacing the whole sections. If this i= s not what
> > >> you are doing, the document is even less clear and need = to be
> > >> clarified.>>
> > >>
> > >>> If it's better to say this updates a specific su= bsection, then
> > >>> that's also reasonable.=C2=A0 I just thought wha= t we have is sufficient.>>
> > >>
> > >> Yes, please be specific. I couldn't be certain which= sections are
> > >> still in force and which were updated.>
> > >
> > > I propose this, replacing our document's current Section= 4:
> > >
> > > 4. Update to DKIM Signing and Verification Algorithms
> > >
> > >=C2=A0 =C2=A0 Section 4.1 updates the text in [RFC6376] Secti= on 3.3.
> > >
> > >
> > >
> > >=C2=A0 =C2=A0 Section 4.2 updates the first paragraph in [RFC= 6376] Section 3.3.3.
> >
> > I want some specific text about what happens to sections:
> >
> > 3.3.1.=C2=A0 The rsa-sha1 Signing Algorithm
> > 3.3.2.=C2=A0 The rsa-sha256 Signing Algorithm
> > 3.3.4.=C2=A0 Other Algorithms
> >
> > e.g. "Sections 3.3.1, 3.3.2 and 3.3.4 are not affected"= or similar. (Or
> >=C2=A0 =C2=A0 =C2=A0 the correct disposition of these sections if = what I suggested is
> >=C2=A0 =C2=A0 =C2=A0 not correct.
> >
> > > 4.1. DKIM Signing and Verification Algorithms=C2=A0 DKIM sup= ports multiple
> > >
> > >=C2=A0 =C2=A0 =C2=A0 digital signature algorithms.=C2=A0 Two = algorithms are defined by this
> > >=C2=A0 =C2=A0 =C2=A0 specification at this time: rsa-sha1 and= rsa- sha256.=C2=A0 Signers
> > >=C2=A0 =C2=A0 =C2=A0 MUST sign using rsa-sha256.=C2=A0 Verifi= ers MUST be able to verify
> > >=C2=A0 =C2=A0 =C2=A0 using rsa-sha256.=C2=A0 rsa-sha1 MUST NO= T be used for signing or
> > >=C2=A0 =C2=A0 =C2=A0 verifying.=C2=A0 DKIM signatures signed = with historic algorithms
> > >=C2=A0 =C2=A0 =C2=A0 (currently rsa-sha1) or with insufficien= t key sizes (currently
> > >=C2=A0 =C2=A0 =C2=A0 rsa-sha256 with less than 1024 bits) hav= e permanently failed
> > >=C2=A0 =C2=A0 =C2=A0 evaluation as discussed in=C2=A0 [RFC637= 6] Section 3.9[1].=C2=A0 4.2. Key
> > >=C2=A0 =C2=A0 =C2=A0 Sizes=C2=A0 Selecting appropriate key si= zes is a trade-off between
> > >=C2=A0 =C2=A0 =C2=A0 cost, performance, and risk.=C2=A0 Since= short RSA keys more easily
> > >=C2=A0 =C2=A0 =C2=A0 succumb to off-line attacks, Signers MUS= T use RSA keys of at
> > >=C2=A0 =C2=A0 =C2=A0 least 1024 bits for all keys.=C2=A0 Sign= ers SHOULD use RSA keys of at
> > >=C2=A0 =C2=A0 =C2=A0 least 2048 bits. Verifiers MUST be able = to validate signatures
> > >=C2=A0 =C2=A0 =C2=A0 with keys ranging from 1024 bits to 4096= bits, and they MAY be
> > >=C2=A0 =C2=A0 =C2=A0 able to validate signatures with larger = keys.=C2=A0 Verifier policies
> > >=C2=A0 =C2=A0 =C2=A0 can use the length of the signing key as= one metric for
> > >=C2=A0 =C2=A0 =C2=A0 determining whether a signature is accep= table.=C2=A0 Verifiers MUST
> > >=C2=A0 =C2=A0 =C2=A0 NOT consider signatures using RSA keys o= f less than 1024 bits as
> > >=C2=A0 =C2=A0 =C2=A0 valid signatures.
> > >
> > > Alexey, would this suffice? -MSK
> >
> > Links:
> >
> >=C2=A0 =C2=A01. https://tools.ietf.org/html/= rfc6376#section-3.9
>
> I added text about 3.3.1, 2, and 4.=C2=A0 See the attached RFC diff.= =C2=A0 If that
> works
> for you, I'll submit -06 and (hopefully) we can call it done.

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

--001a113a1f1617dc2c055d178561-- From nobody Sat Nov 4 19:10:41 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 95FC213FADE; Sat, 4 Nov 2017 19:10:38 -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.64.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150984783848.32747.13310081104213271023@ietfa.amsl.com> Date: Sat, 04 Nov 2017 19:10:38 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-06.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, 05 Nov 2017 02:10:38 -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-06.txt Pages : 5 Date : 2017-11-04 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-06 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 Nov 4 23:00: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 BF4E113FB25 for ; Sat, 4 Nov 2017 23:00:33 -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 Bvwf7Syod9-Z for ; Sat, 4 Nov 2017 23:00:32 -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 CFE2913FB05 for ; Sat, 4 Nov 2017 23:00:31 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id v41so7542600qtv.12 for ; Sat, 04 Nov 2017 23:00:31 -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=2WuCvkWS6w3l7m7REzm6Jm0XDVExrm0SJ7byhEXOpm4=; b=aoOCMIMdkJS2xW5kFGtfANw0wzBEIJqVW30iS3P2JaBRjq5xmJ5sKLd+4LhBZm6CkE qXIllSrlVyUq9N2Ljm6l61abxFCLOvcO9uFktagW/W3SWTRtrQd6X/a7VVBAR6r6s88s NhT4BBEYGiB3Iv0FAkeY4yayiXfx8FQiknbn7hdJCXyCM+kO+aYpybx1EbylTCrmAwx+ 5cO/thVr9FjqBnfOW5KQTRwnzPC3GUcbJI6a+qG+6mtj9sKIfitb9vaRqpui+1TIxnVe aA/2dtZuxYBeXXJA+X73Qsb1XhbIgpXLCiYVHd1dOh8RNR3vZOXX/79mp/611asLjS2V POWA== 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=2WuCvkWS6w3l7m7REzm6Jm0XDVExrm0SJ7byhEXOpm4=; b=pwu9TgEYksJBVzhDiHlJZwi6RBIwArpq3TjoqscqpDntXR5BhYvkEqrhnE7GOpgzGo tmDlcMXvWGN+j3pTEJPxxmqwo8XLr07eibrLkrPkqLYFMruXJC8mocYdVx4ho84Jth0/ cJRKMNK0S3/cW9kCu8UHUQiNPGB9iSIuDHppgOvQtho4oSUpiOwaz4mOL9cfZk0AuWGZ 8x62XAQ1bAhoPBXEQqT7q+QzQLAt9HhP0qoTPV1FZOWtcJD6Z2W/9zgeUGodxCy4EcM7 VVevBJeKMaGQgKpxmaMpchuuPfez5uL2g2D2Ka2FCF18aAm+VC2voP4RbnhGjyFc2tOn EZmQ== X-Gm-Message-State: AMCzsaVJ45UElnLLnRId1avmjtdCNxcmzKeOi+UzX24AiekW22YQfx0f lI7QklCFzGSKVIafzgloR1la7rJQDwFW2uXxIdIRjgXT X-Google-Smtp-Source: ABhQp+SIw/Sk1hYUGBzkG1QWhDPkkQ2q1ot8aV+JiYHDZxW/VH0N2StvV/aWh6lzWBkoiTPl0s2m2X1FugdwNslBfbc= X-Received: by 10.237.62.153 with SMTP id n25mr16735067qtf.124.1509861630631; Sat, 04 Nov 2017 23:00:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Sat, 4 Nov 2017 23:00:30 -0700 (PDT) From: "Murray S. Kucherawy" Date: Sat, 4 Nov 2017 23:00:30 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a113a1f16276321055d360e7e" Archived-At: Subject: [Dcrup] IETF 100 Agenda X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 05 Nov 2017 06:00:34 -0000 --001a113a1f16276321055d360e7e Content-Type: text/plain; charset="UTF-8" Colleagues, We have a half hour on Wednesday morning assigned to a DCRUP meeting. We're behind on publishing an agenda. Our apologies. As I understand it (and having re-read the list since our last meeting) the only thing we appear not to have decided is whether to support both ED25519 and RSAFP, which affects the content of draft-ietf-dcrup-dkim-crypto (by about half), and the biggest open question is library support for the former and whether a pre-hash version is expected to be available. Please correct me if I'm wrong on that. Someone was going to ping the crypto library implementers and find out their likely path. Did we ever get an answer on that? John, would you like to lead the discussion? Do we need any time on draft-ietf-dcrup-dkim-ecc, or does that really depend on the answers to the above? -MSK --001a113a1f16276321055d360e7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

We have a h= alf hour on Wednesday morning assigned to a DCRUP meeting.=C2=A0 We're = behind on publishing an agenda.=C2=A0 Our apologies.

As I understand= it (and having re-read the list since our last meeting) the only thing we = appear not to have decided is whether to support both ED25519 and RSAFP, wh= ich affects the content of draft-ietf-dcrup-dkim-crypto (by about half), an= d the biggest open question is library support for the former and whether a= pre-hash version is expected to be available.=C2=A0 Please correct me if I= 'm wrong on that.

Someone was going to pin= g the crypto library implementers and find out their likely path.=C2=A0 Did= we ever get an answer on that?

John, would you li= ke to lead the discussion?

Do we need any time on draft-i= etf-dcrup-dkim-ecc, or does that really depend on the answers to the above?=

-MSK
--001a113a1f16276321055d360e7e-- From nobody Sun Nov 5 05:02: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 0471D13FACD for ; Sun, 5 Nov 2017 05:02:35 -0800 (PST) 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 Hthe7f2TEMOt for ; Sun, 5 Nov 2017 05:02:33 -0800 (PST) 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 D7DBF13F3D5 for ; Sun, 5 Nov 2017 05:02:32 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA5D2TW2006907; Sun, 5 Nov 2017 13:02:29 GMT 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=UP0z6DEe37Hw7XzrWdt3NYi0Bx6wdnC6t1Yo2JqMnUI=; b=IIvfWT49/JNhk8U97BK6/c5nRhd8DYHgo/CYRpGWL8/3HUe8Aa/0zp3sOHHuGY709eZR BiJm8e5K1HYuXno7saozvhTokF9JKUNfzmBvCToRKN0eGfnUZh00LYRZbiyKx62PSRyE rlYveIlD0vjq047Z4lbrGhncjZZg5rzLtUOQwKlY9ttYka+cG9gvenHdagq41QbZ83AZ FNnOx6i7uTQev97KscvjWwMguwGX2/EyD08Z/l39uMWebW7exiWvPvx7/RfQks2iiOUR lY04goWyJvreHzEJBvsD1QAXAyfZ+JJwC5k0MXSYFfRkyFiNV0z+Dtfq2LiC9IsT9O/l 7Q== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2e139v3nmq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 13:02:29 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA5D0Smi001824; Sun, 5 Nov 2017 08:02:28 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2e18vvkawc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 05 Nov 2017 08:02:28 -0500 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, 5 Nov 2017 08:02:27 -0500 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, 5 Nov 2017 08:02:27 -0500 From: "Salz, Rich" To: "Murray S. Kucherawy" , "dcrup@ietf.org" Thread-Topic: [Dcrup] IETF 100 Agenda Thread-Index: AQHTVftq6NjviBq9vUG7Y6FPsRtf36MGFIIA Date: Sun, 5 Nov 2017 13:02:26 +0000 Message-ID: <1A82A04E-C098-4B9E-85EB-4F6F502C7403@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.45] Content-Type: multipart/alternative; boundary="_000_1A82A04EC0984B9E85EB4F6F502C7403akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_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-1707230000 definitions=main-1711050188 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-05_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-1707230000 definitions=main-1711050188 Archived-At: Subject: Re: [Dcrup] IETF 100 Agenda X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 05 Nov 2017 13:02:35 -0000 --_000_1A82A04EC0984B9E85EB4F6F502C7403akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgU29tZW9uZSB3YXMgZ29pbmcgdG8gcGluZyB0aGUgY3J5cHRvIGxpYnJhcnkgaW1wbGVt ZW50ZXJzIGFuZCBmaW5kIG91dCB0aGVpciBsaWtlbHkgcGF0aC4gIERpZCB3ZSBldmVyIGdldCBh biBhbnN3ZXIgb24gdGhhdD8NCg0KSSBjYW4gYW5zd2VyIGZvciBvcGVuc3NsOiAgbm8gcGxhbnMg dG8gZG8g4oCccHJlaGFzaOKAnQ0K --_000_1A82A04EC0984B9E85EB4F6F502C7403akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <333D9799AEB3894B8B327EACF93563B8@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUt bmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MTA0NjY0MjE1ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6NTgyMDI1MDI2IDcwMzIyNDIwNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOmJsYWNrOw0KCW1zby1hbnNpLWZvbnQtd2Vp Z2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj5Tb21lb25lIHdhcyBnb2luZyB0byBwaW5nIHRoZSBjcnlwdG8gbGli cmFyeSBpbXBsZW1lbnRlcnMgYW5kIGZpbmQgb3V0IHRoZWlyIGxpa2VseSBwYXRoLiZuYnNwOyBE aWQgd2UgZXZlciBnZXQgYW4gYW5zd2VyIG9uIHRoYXQ/PG86cD48L286cD48L2xpPjwvdWw+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGNhbiBhbnN3ZXIgZm9yIG9wZW5zc2w6Jm5ic3A7IG5vIHBsYW5zIHRv IGRvIOKAnHByZWhhc2jigJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_1A82A04EC0984B9E85EB4F6F502C7403akamaicom_-- From nobody Sun Nov 5 07:53: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 577FB13FB1F for ; Sun, 5 Nov 2017 07:53:45 -0800 (PST) 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 eFf4OOCoXPtf for ; Sun, 5 Nov 2017 07:53:43 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 36D2B13FA91 for ; Sun, 5 Nov 2017 07:53:43 -0800 (PST) Received: (qmail 17871 invoked from network); 5 Nov 2017 15:53:42 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 5 Nov 2017 15:53:42 -0000 Date: 5 Nov 2017 15:53:20 -0000 Message-ID: <20171105155320.15440.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] IETF 100 Agenda X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 05 Nov 2017 15:53:45 -0000 In article you write: >As I understand it (and having re-read the list since our last meeting) the >only thing we appear not to have decided is whether to support both ED25519 >and RSAFP, which affects the content of draft-ietf-dcrup-dkim-crypto (by >about half), and the biggest open question is library support for the >former and whether a pre-hash version is expected to be available. Please >correct me if I'm wrong on that. Seems right. Per later discussion it seems pretty clear that if we do ed25519, we need to double hash if we ever want it to be implemented. >John, would you like to lead the discussion? Like to? Not exactly but I'm certainly willing to do so. >Do we need any time on draft-ietf-dcrup-dkim-ecc, or does that really >depend on the answers to the above? I think Scott said that events overtook that draft, and we have general agreement that if we add an elliptic algorithm, the one in RFC 8032 is the one to use. R's, John From nobody Mon Nov 6 06:33:35 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 D345913F3D5; Mon, 6 Nov 2017 06:33:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.65.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dcrup@ietf.org, seth@sethblank.com, dcrup-chairs@ietf.org, alexey.melnikov@isode.com, draft-ietf-dcrup-dkim-usage@ietf.org, Seth Blank , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150997880882.29234.3579800468195631952.idtracker@ietfa.amsl.com> Date: Mon, 06 Nov 2017 06:33:28 -0800 Archived-At: Subject: [Dcrup] Protocol Action: 'Cryptographic Algorithm and Key Usage Update to DKIM' to Proposed Standard (draft-ietf-dcrup-dkim-usage-06.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, 06 Nov 2017 14:33:29 -0000 The IESG has approved the following document: - 'Cryptographic Algorithm and Key Usage Update to DKIM' (draft-ietf-dcrup-dkim-usage-06.txt) as Proposed Standard This document is the product of the DKIM Crypto Update Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ Technical Summary 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 minimally suitable for operation with currently specified algorithms. Working Group Summary There were two points which were discussed at length, but consensus was reached and is appropriately reflected in the document. Additional concerns have been moved to other documents. Document Quality This has received security and DKIM community participation. No further expert reviews are warranted. This document removes obsolete protocol elements from a widely deployed and understood standard. Personnel Seth Blank is the Document Shepherd, and Alexey Melnikov is the responsible Area Director. From nobody Tue Nov 14 19:49: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 5B97E126CBF for ; Tue, 14 Nov 2017 19:49:51 -0800 (PST) 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 WLQNUWlv8JeT for ; Tue, 14 Nov 2017 19:49:49 -0800 (PST) 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 7BAE21294C9 for ; Tue, 14 Nov 2017 19:49:48 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF3kpKS023365 for ; Wed, 15 Nov 2017 03:49:47 GMT 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=9mymACDEoxaRtfUiAKLLbn+a+81mtYwP8lnIjJ1CWaA=; b=gRk9V9Loepdy5u13hhVi4Vd9iKs2wSoPV2T+8p1DuyXV1Vh1cMmHfRuWpLa+40FPXvXA VPr57wVUtKhSbPIzIhWT1XOtxHwbm+K0ERNAGi4NnwF0rGjwyF9c1I2D5DV1c8WT52IK oQhI7SkmQPsvh3bqqVMUGredldxy1JA26bG/0a/LM7oecJeIJxct4JNzZQy1spDfvQb4 5ScPApCEQn1LNEkdnFRO2arpwKh6kiQNZKNeUew2pxKWpAg23YGK8uFX0j3BDcOOZhhW NBqRTY/Bko1OzgHmfAeQMNrM4CWnuIlQI/ngoBFMR51NVchKzFp9sBAWcLDTfHuCTb7T fA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2e8d5kg37y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 15 Nov 2017 03:49:46 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAF3jv0t014569 for ; Tue, 14 Nov 2017 22:49:45 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wkvap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 14 Nov 2017 22:49:45 -0500 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; Tue, 14 Nov 2017 22:49:44 -0500 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, 14 Nov 2017 22:49:44 -0500 From: "Salz, Rich" To: "dcrup@ietf.org" Thread-Topic: dcrup-dkim-crypto question Thread-Index: AQHTXcTFbFxn4Znqr0SF4ObrqUx3MQ== Date: Wed, 15 Nov 2017 03:49:43 +0000 Message-ID: <7F9E3F7C-0691-4DB3-A662-26E8A4166902@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.119] Content-Type: multipart/alternative; boundary="_000_7F9E3F7C06914DB3A66226E8A4166902akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_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-1709140000 definitions=main-1711150051 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_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-1709140000 definitions=main-1711150051 Archived-At: Subject: [Dcrup] dcrup-dkim-crypto question X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 03:49:51 -0000 --_000_7F9E3F7C06914DB3A66226E8A4166902akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lcyBhbnlvbmUgZGlzYWdyZWUgd2l0aCByZW1vdmluZyB0aGUgUlNBZnAgYWxnb3JpdGhtIGZy b20gdGhlIGRyYWZ0IGluIHF1ZXN0aW9uPyAgSWYgc28sIHBsZWFzZSBzYXkgc28gYW5kIGV4cGxh aW4gd2h5IHdpdGhpbiB0aGUgbmV4dCBmZXcgZGF5cy4NCg0KDQoNCg== --_000_7F9E3F7C06914DB3A66226E8A4166902akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Eb2VzIGFueW9uZSBkaXNhZ3JlZSB3aXRo IHJlbW92aW5nIHRoZSBSU0FmcCBhbGdvcml0aG0gZnJvbSB0aGUgZHJhZnQgaW4gcXVlc3Rpb24/ Jm5ic3A7IElmIHNvLCBwbGVhc2Ugc2F5IHNvIGFuZCBleHBsYWluIHdoeSB3aXRoaW4gdGhlIG5l eHQgZmV3IGRheXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F9E3F7C06914DB3A66226E8A4166902akamaicom_-- From nobody Tue Nov 14 19:50: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 365C21294D3 for ; Tue, 14 Nov 2017 19:50:51 -0800 (PST) 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 Ksv3dplmVAfU for ; Tue, 14 Nov 2017 19:50:50 -0800 (PST) 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 217E612878D for ; Tue, 14 Nov 2017 19:50:50 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id v41so31454621qtv.12 for ; Tue, 14 Nov 2017 19:50:50 -0800 (PST) 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=vSMUnlBK5CGImPskPZHWhs8bM6wp6tTXdYCl8rVq4+4=; b=GOXdo/HNRM9nT7BnjUGUDPzW+yeRbAOwto1XmIJeqX5dwBwMYlqXCCaU/+08c/YRUn r09kREHJPOeqQMxZ1y20/+8vP3EE+/QDKnyU/KiI20dT3Im5LrmXKitIs4p16Y0JlB/A PG+7oEI4qePeE/BylpaWAbX14P+h8xZskhEa9qA7bA9VqOXd4YQNqntEM8bRsbaRAZ+s 00e27bjrEBRhZ1WMyqyW7Z8FLz7h0WbSaJUjy/CTCyFCoFDBzpbEAPW5KZ3WbiXzq8aB MKG2DBn5WJhPeYR3+M66D9ncEikL4ANlSd7DF49dIXTcVX2yfOj+nF0nzEO0U/YhCqgj LfCA== 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=vSMUnlBK5CGImPskPZHWhs8bM6wp6tTXdYCl8rVq4+4=; b=Hfw/r6eALAmPkFNwEZRCgihH+rfKOAk6n11mwU/ncZonN/lHwoOeUwZOv45Vl1ASFN 1Ep6jaLluw5vtbMWEFhs64YDdBTwlVmI1+S+ONd7pw7bmJO3e6KF2/eB8+TAxwkX8mBi j9AwVIPV7WY1tq0ZJwBThXNFRGW4VorWVvDdtHvJTnogN5HoFl0TVD5Vd6L+46L88+Bk UMjSk5RiUPjy9n7jDH9ltgz18yiEE86QqTZqEtju7vGvxoqQ60/qBx2AasCGmnC+gJ22 qWmwB+Jj8C57K1zwriOI07rgWRcsDg1Sak9La8h040GOGksY3qNtrczOx7Bncb7zgOPn JBrg== X-Gm-Message-State: AJaThX5aJQLKqXJxN+g2sWBoXxFbDP6fmZkt2n30fqzwl2bf6WNRXWZN EH7JeMCtzdY6VriE8PfVdM433mmy1oB0JRGP95pZMA== X-Google-Smtp-Source: AGs4zMZAGCNOYQm4oT8arAWz7AzoEc/ggiczdna400cLYa82XrzcvvvuoP/vmJxM2a+QDboK3U9lioNNnvBkJb7Wzoc= X-Received: by 10.237.41.37 with SMTP id s34mr14581230qtd.154.1510717848880; Tue, 14 Nov 2017 19:50:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.40.115 with HTTP; Tue, 14 Nov 2017 19:50:48 -0800 (PST) From: "Murray S. Kucherawy" Date: Wed, 15 Nov 2017 11:50:48 +0800 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c124a22bd0bc2055dfd68e2" Archived-At: Subject: [Dcrup] Next steps for 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: Wed, 15 Nov 2017 03:50:51 -0000 --94eb2c124a22bd0bc2055dfd68e2 Content-Type: text/plain; charset="UTF-8" Colleagues, Consensus in the room at IETF 100 is to have this document settle on doing "hash EDDSA" only, i.e., dropping support for "rsafp". If there are any objections to going this way, please speak up on the list. If there are none, we'll advise John to proceed with updating the document based on that call. We'll proceed to Working Group Last Call when that happens. Barry Leiba has volunteered to act as document shepherd. -MSK, co-chairin' --94eb2c124a22bd0bc2055dfd68e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colleagues,

Consensus in the r= oom at IETF 100 is to have this document settle on doing "hash EDDSA&q= uot; only, i.e., dropping support for "rsafp".

If th= ere are any objections to going this way, please speak up on the list.=C2= =A0 If there are none, we'll advise John to proceed with updating the d= ocument based on that call.=C2=A0 We'll proceed to Working Group Last C= all when that happens.

Barry Leiba has volunteered= to act as document shepherd.

-MSK, co-chairin= '
--94eb2c124a22bd0bc2055dfd68e2-- From nobody Thu Nov 16 12:20:18 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0D1289C3 for ; Thu, 16 Nov 2017 12:20:14 -0800 (PST) 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=ggKybZeu; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=aF33TMS9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r98UytbinR9o for ; Thu, 16 Nov 2017 12:20:12 -0800 (PST) Received: from news.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id F24B012704B for ; Thu, 16 Nov 2017 12:20:11 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1093; t=1510863602; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=Y+3XJyr+IfPozreuO4TIQCE9JnM=; b=ggKybZeuDcpVKbRj5atqv2XWSyToeBzKKkMiLNTc1y6YJqw9kQ/pQ5cK/VU9pG nJOmZ876auCGPZ6MW6dizMpv+Nk21uPAbHxuEwlsNp6pRWHH0juyGDXXZnnGy+bz iUQ7CeSUZqfOZ2FhotQ0I3Ub8cyZzPkem0PAc0a9eHrOE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 16 Nov 2017 15:20:02 -0500 Authentication-Results: dkim.winserver.com; dkim=fail (DKIM_SELECTOR_DNS_PERM_FAILURE) 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 732328552.1.3836; Thu, 16 Nov 2017 15:19:51 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1093; t=1510863452; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=N1c9YbR itSBmdaeCmOv/nVL/+xsa6bft/r5aDpEw1+8=; b=aF33TMS9Jw5Gy9Kn8dCsiUh pn5LRwtk5vi9uzqxgjrwHIb/EXR4w5ntNDf7SUZO9s8MKZ/PABF16wwq1auLv+By Dn2NkZtBNMtSgDWq26SEM6mk1OCdHjaF18vB9y+5drURUPlNbmiJNCUpRyLUSskU QAlD65O5RKcyZ488kpFk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Thu, 16 Nov 2017 15:17:32 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 732292657.9.221828; Thu, 16 Nov 2017 15:17:31 -0500 Message-ID: <5A0DF2E9.6030105@isdg.net> Date: Thu, 16 Nov 2017 15:19:53 -0500 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: "Murray S. Kucherawy" , dcrup@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Next steps for 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, 16 Nov 2017 20:20:14 -0000 Hi, (I don't know what rsafp means, looked at doc for definition, I presume it is about SHA1 signing). Just so I understand, this document will update DKIM STD to where, from a product development standpoint: - RSA SHA1 is not longer required to be supported at DKIM receivers, so do not use or enabled RSA SHA1 for signing. - EDDSA support should be added, but you are not REQUIRED to add support. There will be an unknown migration period. What is expected to happen when the DKIM receiver does not support EDDSA? -- HLS On 11/14/2017 10:50 PM, Murray S. Kucherawy wrote: > Colleagues, > > Consensus in the room at IETF 100 is to have this document settle on > doing "hash EDDSA" only, i.e., dropping support for "rsafp". > > If there are any objections to going this way, please speak up on the > list. If there are none, we'll advise John to proceed with updating > the document based on that call. We'll proceed to Working Group Last > Call when that happens. > > Barry Leiba has volunteered to act as document shepherd. > > -MSK, co-chairin' From nobody Thu Nov 16 12:35: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 BEE031201FA for ; Thu, 16 Nov 2017 12:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42Lbcezt3nUW for ; Thu, 16 Nov 2017 12:35:16 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 C1C471200C5 for ; Thu, 16 Nov 2017 12:35:15 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id r135so322511lfe.5 for ; Thu, 16 Nov 2017 12:35:15 -0800 (PST) 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=C31aZVYvsnFQJTP7WZZY3ino0kSxJJRl4kC6gCVNFNM=; b=K601jnXsiKx3cjYdKjph2Z5ic0RdJBrViJ3gV29q9YHsztNvaGEaruhdhHZJO7zUgz /CS/0ibyCZ+X6hmh4TbswvBZgacNv25upmoERchnTIBE0fa2kRnGnCxBVnP3bWFJUTAU ezz/TCALUqOtnO5M1Rdn50Of6SlKFP/a8GL5I= 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=C31aZVYvsnFQJTP7WZZY3ino0kSxJJRl4kC6gCVNFNM=; b=unKPLHxgHd1XoSSL+TyDl/WI6Y7qnHbqp7b4yckHDMy0s8rkm7YXDMMgRDLFS31tnL CLCPwjRH16QyZTcUkSuD9dKyxnYm0vky21mJTKwSPlN0eb3j53xW2elcr77jHm/k6yDy m5oKMRRJIsHzr1wHVvzb6jlHRH3p4Vu9sfsMsaXvc514c8IeIK4dmFHw9JyBdmK572ik nW5khqf3Y77gvjz/hbWqlyMXE/gaYlNuoUTpr90FX13Ju5lb3Wd87ZvHC9IPuZvIiASk EL0+tI9wtOgXSTFZMWKch6l9EODyuWsOUllCh1XJFej3Xym/vYrqAdinn0hAXHd5wAmm i01g== X-Gm-Message-State: AJaThX4YASNkEIdA8AdL5uEqnGzXqTHVaj5/9vawqdUGEpWCC6QIWSga g2ev/H18pwLrKUDoay/fULqYr101pOUVSyomrPN6b4cXrlo= X-Google-Smtp-Source: AGs4zMYVnp0IC62JLBlc0CnEoDSe9xKv2kAYv0cRwZ1+7d8OGAHYxepgeSTeRYgV25pEDDXqHlNURiSTFfhhs4wrC0M= X-Received: by 10.46.57.10 with SMTP id g10mr1203126lja.77.1510864513723; Thu, 16 Nov 2017 12:35:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.56.9 with HTTP; Thu, 16 Nov 2017 12:35:12 -0800 (PST) In-Reply-To: <5A0DF2E9.6030105@isdg.net> References: <5A0DF2E9.6030105@isdg.net> From: Kurt Andersen Date: Thu, 16 Nov 2017 10:35:12 -1000 Message-ID: To: Hector Santos Cc: "Murray S. Kucherawy" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="089e082f5ce4a54edf055e1f8e82" Archived-At: Subject: Re: [Dcrup] Next steps for 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, 16 Nov 2017 20:35:18 -0000 --089e082f5ce4a54edf055e1f8e82 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 10:19 AM, Hector Santos wrote: > Hi, > > (I don't know what rsafp means, looked at doc for definition, I presume it > is about SHA1 signing). rsafp is the idea of publishing just the key fingerprint (fp) in DNS with the full key in the header but validated against the DNS. --Kurt --089e082f5ce4a54edf055e1f8e82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 16, 2017 at 10:19 AM, Hector Santos <hsantos@isdg.net> wrote:
Hi,

(I don't know what rsafp means, looked at doc for definition, I presume= it is about SHA1 signing).

rsafp is the id= ea of publishing just the key fingerprint (fp) in DNS with the full key in = the header but validated against the DNS.

--Kurt= =C2=A0

--089e082f5ce4a54edf055e1f8e82-- From nobody Thu Nov 16 14:00: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 9DAE4127005 for ; Thu, 16 Nov 2017 14:00:17 -0800 (PST) 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=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 MpRgDMEyoKWp for ; Thu, 16 Nov 2017 14:00:14 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 56CA0126DD9 for ; Thu, 16 Nov 2017 14:00:14 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id 134so6809860ioo.0 for ; Thu, 16 Nov 2017 14:00:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fiction.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0mjG/QVJu2cfVpogtBLZoIxbAJJOAn28EE8VIEjkZh8=; b=ekXJ2elX3A8GOob9eUxWZARVVQ9Rt8lkA3BNQh+aE+zF7UKkRPBIEs+P/ncTM74UjC R9rYqdBGEucR1K+9fqk/724kyIQj/TrYElDfOp5HUuEt17fDjlV+YRIAST17ZXPi4dtj rNa8hcdjY+D2pucuLEF/EgsQh14SlykzLuYlha0dZX7iMaYtpiVCuk11Wcw/5hIkq1K+ z+rR9XyMaGJ9eqRIg1QTaoU/bvvUexwkwz1FcjxiFm+3QGk+lOaaxESNij5x8qPsoC8t pjSRHBJfuTCkFrpd18IlSxbUN+0o4kO/VI0IgOF0OFD5b4bDVpOiIi7/lr54WD+VnBIy 4vFQ== 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:cc; bh=0mjG/QVJu2cfVpogtBLZoIxbAJJOAn28EE8VIEjkZh8=; b=rf+nbH1KS/CQqaP8hOlkOhaqBpe63QmrOHCEv968QuMUXCwolJPfKTccUBaZorFOgE uY3IRA9L77ldGngpsiPkbjwvD93nGgoXffDv9pe2L8+S2ZQL8tqanL+DjEla5qIFB7h7 GBrebMvUOkcxSB90m3iUQYc0pFgCUrT4saejEnckekeWoXu4gIbWeAs8D4C6e93xth7L q8UqqUsBSGyuh6vYYcnKhTSeB3qmUKUpTt/H0aKtNEpoeAmMJ1ihSVTwPfkTB1UCEOAX Cw/AzboTGjanYUUKlhJVv97uSKWtWwaEzEbLOpG0HRjgfJN3rb4/YvDEwdBnC1BvuSBA OnfA== X-Gm-Message-State: AJaThX5JAf7kDfdcQaj8UJptYhVTfGEUF8XGn1FX1djgTu6IAqS1vEnB V7Tu8qFMM6iQ28jSIUl0GbR2Lpdt X-Google-Smtp-Source: AGs4zMYnCe5QLqp7iNIMYSMyCaK1twTQPTR3K0mB3fpEsSSRThLW1tJAmri2oLJKJbB7cztD1DV/Qw== X-Received: by 10.107.11.36 with SMTP id v36mr412359ioi.13.1510869613535; Thu, 16 Nov 2017 14:00:13 -0800 (PST) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id r65sm1254763ith.3.2017.11.16.14.00.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 14:00:12 -0800 (PST) Received: by mail-io0-f179.google.com with SMTP id 71so6799992ior.7 for ; Thu, 16 Nov 2017 14:00:12 -0800 (PST) X-Received: by 10.107.134.227 with SMTP id q96mr410347ioi.197.1510869612081; Thu, 16 Nov 2017 14:00:12 -0800 (PST) MIME-Version: 1.0 References: <5A0DF2E9.6030105@isdg.net> In-Reply-To: <5A0DF2E9.6030105@isdg.net> From: Brandon Long Date: Thu, 16 Nov 2017 21:59:55 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Hector Santos Cc: "Murray S. Kucherawy" , dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a1145f48a889137055e20be8e" Archived-At: Subject: Re: [Dcrup] Next steps for 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, 16 Nov 2017 22:00:17 -0000 --001a1145f48a889137055e20be8e Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 12:20 PM Hector Santos wrote: > Hi, > > (I don't know what rsafp means, looked at doc for definition, I > presume it is about SHA1 signing). > > Just so I understand, this document will update DKIM STD to where, > from a product development standpoint: > > - RSA SHA1 is not longer required to be supported at DKIM receivers, so > do not use or enabled RSA SHA1 for signing. > > - EDDSA support should be added, but you are not REQUIRED to add > support. > There will be an unknown migration period. > > What is expected to happen when the DKIM receiver does not support EDDSA? > The message won't be considered authenticated by the receiver. Brandon > > -- > HLS > > On 11/14/2017 10:50 PM, Murray S. Kucherawy wrote: > > Colleagues, > > > > Consensus in the room at IETF 100 is to have this document settle on > > doing "hash EDDSA" only, i.e., dropping support for "rsafp". > > > > If there are any objections to going this way, please speak up on the > > list. If there are none, we'll advise John to proceed with updating > > the document based on that call. We'll proceed to Working Group Last > > Call when that happens. > > > > Barry Leiba has volunteered to act as document shepherd. > > > > -MSK, co-chairin' > > > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --001a1145f48a889137055e20be8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



On= Thu, Nov 16, 2017 at 12:20 PM Hector Santos <hsantos@isdg.net> wrote:
Hi,

(I don't know what rsafp means, looked at doc for definition, I
presume it is about SHA1 signing).

Just so I understand, this document will update DKIM STD to where,
from a product development standpoint:

=C2=A0 =C2=A0- RSA SHA1 is not longer required to be supported at DKIM rece= ivers, so
=C2=A0 =C2=A0 =C2=A0do not use or enabled RSA SHA1 for signing.

=C2=A0 =C2=A0- EDDSA support should be added, but you are not REQUIRED to a= dd
support.
=C2=A0 =C2=A0 =C2=A0There will be an unknown migration period.

What is expected to happen when the DKIM receiver does not support EDDSA?

The message won't be considered auth= enticated by the receiver.

Brandon
=C2= =A0

--
HLS

On 11/14/2017 10:50 PM, Murray S. Kucherawy wrote:
> Colleagues,
>
> Consensus in the room at IETF 100 is to have this document settle on > doing "hash EDDSA" only, i.e., dropping support for "rs= afp".
>
> If there are any objections to going this way, please speak up on the<= br> > list.=C2=A0 If there are none, we'll advise John to proceed with u= pdating
> the document based on that call.=C2=A0 We'll proceed to Working Gr= oup Last
> Call when that happens.
>
> Barry Leiba has volunteered to act as document shepherd.
>
> -MSK, co-chairin'



_______________________________________________
Dcrup mailing list
Dcrup@ietf.org
https://www.ietf.org/mailman/listinfo/dcrup
--001a1145f48a889137055e20be8e-- From nobody Thu Nov 16 15:14: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 B1E74127517 for ; Thu, 16 Nov 2017 15:14:00 -0800 (PST) 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 (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 naGKjSY62QiQ for ; Thu, 16 Nov 2017 15:13:59 -0800 (PST) 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 0B0BF1270A0 for ; Thu, 16 Nov 2017 15:13:59 -0800 (PST) Received: from [192.168.1.116] (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 480D9C4024D; Thu, 16 Nov 2017 17:13:57 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1510874037; bh=BCDPVKjq+UqiQK0c34sI0WUV0QqsXmM4X8iX8iQHS/c=; h=Date:In-Reply-To:References:Subject:To:From:From; b=RUGAFAd8I6I22oKuwP696hoDyVZMFvzpM8wgKjpJRZ7uiko5+4p5fCMosO6yZzKqV k9Vi8GvIRXBBlFzdHEONNcHWlhkhiGMiCOfEkaB5R50lxdKLqfUcfUmNEm2PER8goX qMGwjM/AFmAlEnEFvh+ua56MsvAx5H7Rr0khr4o0= Date: Thu, 16 Nov 2017 23:13:54 +0000 In-Reply-To: References: <5A0DF2E9.6030105@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] Next steps for 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, 16 Nov 2017 23:14:01 -0000 On November 16, 2017 4:59:55 PM EST, Brandon Long wr= ote: >On Thu, Nov 16, 2017 at 12:20 PM Hector Santos >wrote: > >> Hi, >> >> (I don't know what rsafp means, looked at doc for definition, I >> presume it is about SHA1 signing)=2E >> >> Just so I understand, this document will update DKIM STD to where, >> from a product development standpoint: >> >> - RSA SHA1 is not longer required to be supported at DKIM >receivers, so >> do not use or enabled RSA SHA1 for signing=2E >> >> - EDDSA support should be added, but you are not REQUIRED to add >> support=2E >> There will be an unknown migration period=2E >> >> What is expected to happen when the DKIM receiver does not support >EDDSA? >> > >The message won't be considered authenticated by the receiver=2E > >Brandon Which is why the smart move operationally would be to double sign rsa-sha2= 56 and EDDSA for some time to come=2E This used to be common with rsa-sha1= and rsa-sha256 (in the early days of DKIM)=2E Scott K From nobody Sat Nov 18 08:32: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 279F1124BFA for ; Sat, 18 Nov 2017 08:32:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[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=EpvJ3Nq6; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ZIFgjMDH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZTe28sGzvH1 for ; Sat, 18 Nov 2017 08:32:38 -0800 (PST) Received: from demo.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 53905120726 for ; Sat, 18 Nov 2017 08:32:38 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=971; t=1511022755; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=rBeNj3YSwoY6BibLyDsy3E78yIs=; b=EpvJ3Nq6cDuVx3BSDr/icqfsBL8kl+s3MbbsapQsmJB+Ry6x7OJlWagpzzpvap dec8x5sfs+LeYs1QOYmcd7t+UeTHpgZ1FRr329odxKFmkk9Lmz5x0JtMrn3Au3D5 J3vuDcf0hOL9Wf/vnH/X86kbhwktzMD29Y77CWH/5aXAk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Sat, 18 Nov 2017 11:32:35 -0500 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 891491083.13.1712; Sat, 18 Nov 2017 11:32:35 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=971; t=1511022612; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iMrtD/H NKdDWkiBPd4wIl2RcXW8QRMdF184DtMXQRUw=; b=ZIFgjMDHpSFxeu6Sh5RwVkG POSRWnXQVXk25kM9QO9rC/v99EE0ukShFPEwsYZv66CALuY4x4e73VMhUQWyLjIa Yxc6CFw6TosFIgDvO70QQ5Z5aEbY3E1G/KxmxozcXv5zRbEFj1nAFPK9qQyvWi5c AnN9Jmx9pUB/J4+AFdHM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Sat, 18 Nov 2017 11:30:12 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 891453250.9.229136; Sat, 18 Nov 2017 11:30:11 -0500 Message-ID: <5A1060A7.80505@isdg.net> Date: Sat, 18 Nov 2017 11:32:39 -0500 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: <5A0DF2E9.6030105@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] Next steps for 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: Sat, 18 Nov 2017 16:32:40 -0000 On 11/16/2017 6:13 PM, Scott Kitterman wrote: > On November 16, 2017 4:59:55 PM EST, Brandon Long wrote: >> On Thu, Nov 16, 2017 at 12:20 PM Hector Santos >> wrote: >>> >>> What is expected to happen when the DKIM receiver does not support >> EDDSA? >>> >> >> The message won't be considered authenticated by the receiver. >> >> Brandon > > Which is why the smart move operationally would be to double sign rsa-sha256 and EDDSA for some time to come. This used to be common with rsa-sha1 and rsa-sha256 (in the early days of DKIM). > I recall seeing them but not as common as you saw it because SHA1 and SHA256 were both required hashing methods to select. The DKIM receiver had to support one or the other. My signing package never had a "Hash with Both" option. Until the tools are available to support EDDSA, i.e. OpenSSL in our case, SHA256 would be sufficient to cover all receiver nodes. -- HLS From nobody Sun Nov 19 08:58: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 C9CEB126E64 for ; Sun, 19 Nov 2017 08:58:38 -0800 (PST) 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 7mZqeCJSzULm for ; Sun, 19 Nov 2017 08:58:37 -0800 (PST) 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 5BF15126DCA for ; Sun, 19 Nov 2017 08:58:37 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAJGvPVp001340; Sun, 19 Nov 2017 16:58:34 GMT 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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=l0iXIueavg6BduR9md+isI8ozt7hJdou55YjUokFXS0=; b=JVYQxx53FMJ/mpbJPbHmvAEITOnDgOA1GxSZ9MK/F+UzXifTxsyQyOUiXGuhPiAkE2R6 8mcSpkfCiEUwfCkhMJb7zGvMkSHNp6UzJVSRsXXzwZUnxuYrxGR9sqEo+ppLoHN+c8cm HpmTxLvphOkNxEWZgxjDBVtcb4uNJYau63E8Qz4TlfhPjzRktlrb3vV/Y7t7kAYYaUXt XYK1puH8l8lcKfyJOHVZyhxYG8W183baDklSC1EOUPpBMtV46J37Pe9ljcQy64AXa52u US6CzxKxbtkG+AjZfa/odM+tsLKnd3jxw5c3Ds0jjXpwrF7CLwYiS27nJDetRI8btzaF pw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2ead08kr2m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 19 Nov 2017 16:58:34 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAJGuLK9022163; Sun, 19 Nov 2017 11:58:33 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2eah2xkm4t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 19 Nov 2017 11:58:33 -0500 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; Sun, 19 Nov 2017 11:58:32 -0500 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, 19 Nov 2017 11:58:32 -0500 From: "Salz, Rich" To: Hector Santos , "dcrup@ietf.org" Thread-Topic: [Dcrup] Next steps for draft-ietf-dcrup-dkim-crypto Thread-Index: AQHTXcTwCmn5iJ3LHEGdHozYUCQAoqMXyM2AgAAb84CAABSsAIACtI6AgAGZj4A= Date: Sun, 19 Nov 2017 16:58:32 +0000 Message-ID: <2CE0DC9D-202E-418F-AC25-98DE9D9D8CC6@akamai.com> References: <5A0DF2E9.6030105@isdg.net> <5A1060A7.80505@isdg.net> In-Reply-To: <5A1060A7.80505@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.81] Content-Type: text/plain; charset="utf-8" Content-ID: <6B9ED1202995164B825042A67B313E85@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-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-1709140000 definitions=main-1711190239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-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-1709140000 definitions=main-1711190239 Archived-At: Subject: Re: [Dcrup] Next steps for 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: Sun, 19 Nov 2017 16:58:39 -0000 4p6iICAgICBVbnRpbCB0aGUgdG9vbHMgYXJlIGF2YWlsYWJsZSB0byBzdXBwb3J0IEVERFNBLCBp LmUuIE9wZW5TU0wgaW4gb3VyIGNhc2UsDQoNClRoZSBjdXJyZW50IHBsYW4gaXMgdGhhdCB0aGUg bmV4dCByZWxlYXNlIG9mIE9wZW5TU0wgd2lsbCBoYXZlIHRoZSBuZWNlc3NhcnkgQVBJIGluLXBs YWNlLiAgVGhpcyBpcyBhbHNvIHRoZSByZWxlYXNlIHRoYXQgd2lsbCBoYXZlIFRMUyAxLjMsIGFu ZCBpdOKAmXMgYmluYXJ5IGNvbXBhdGlibGUgd2l0aCAxLjEuMCwgc28gaG9wZWZ1bGx5IHRoZSB1 cHRha2Ugd2lsbCBiZSByYXBpZC4NCg0K From nobody Mon Nov 20 17:11: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 4C5801205F0 for ; Mon, 20 Nov 2017 17:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tSPKZtRFeuU for ; Mon, 20 Nov 2017 17:11:42 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 8D9BE1201FA for ; Mon, 20 Nov 2017 17:11:41 -0800 (PST) Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.122) id 1eGx6B-0002lz-79 for dcrup@ietf.org (return-path ); Tue, 21 Nov 2017 01:11:39 +0000 To: dcrup@ietf.org References: <20170914014118.2378.qmail@ary.lan> From: Jeremy Harris Message-ID: <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org> Date: Tue, 21 Nov 2017 01:11:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) with esmtpsa Archived-At: Subject: Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 21 Nov 2017 01:11:44 -0000 On 15/09/17 01:32, John R Levine wrote: >> JL> I haven't looked in detail at the APIs for Ed25519 crypto, but >> naively >> JL> assumed that if the spec says there's a pure version that doesn't >> hash >> JL> its input, the libraries would implement it. >> >> I thought that the consensus was the opposite.  Wasn't esr demanding >> that and everyone else arguing the opposite? > > No, that was an unrelated issue of how to publish the verification keys. > See the WG archives. > >> It is certainly the case the the "pure" version of eddsa is unlikely to >> get much support by the crypto libraries. > > That seems strange, since the difference between pure and hash is that > the pure version just skips the hash.  But if it is really the case that > it will be hard to find pure versions it would be silly buy harmless to > change the spec to say that it calls the hash version of Ed25519 so it > rehashes the hash we give it. > > As far as I know rehashing a hash with a reasonable second hash function > doesn't make it any weaker. Wouldn't it be more aesthetically pleasing to decouple, for dkim a=ed25519-sha256 signing, the hash used for the body (sha256 as specified by the 'a' tag) from the hash used for signing headers (sha512, I think, but whatever the libraries have tied to Ed25519 signing)? [I think we should specify the hash method that goes with the signing, too] The hash of the headers does not appear to be used for anything but debug output and feeding to the signing stage, at least in the current Exim implementation of dkim signing. Doing the above would avoid the rehash. Either way (this or the rehash), Ed25519 signing is going to be different to RSA signing. -- Cheers, Jeremy From nobody Tue Nov 21 14:04: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 EA3C6129B52 for ; Tue, 21 Nov 2017 14:03:59 -0800 (PST) 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 uQmovtxdC2ia for ; Tue, 21 Nov 2017 14:03:58 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 7BA85128C83 for ; Tue, 21 Nov 2017 14:03:58 -0800 (PST) Received: (qmail 69227 invoked from network); 21 Nov 2017 22:03:56 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 21 Nov 2017 22:03:56 -0000 Date: 21 Nov 2017 22:03:34 -0000 Message-ID: <20171121220334.8209.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: jgh@wizmail.org In-Reply-To: <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.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] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 21 Nov 2017 22:04:00 -0000 Keeping in mind that you're responding to a message I wrote two months ago ... In article <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org> you write: >Wouldn't it be more aesthetically pleasing to decouple, for dkim >a=ed25519-sha256 signing, the hash used for the body (sha256 as >specified by the 'a' tag) from the hash used for signing headers >(sha512, I think, but whatever the libraries have tied to >Ed25519 signing)? No. R's, John From nobody Tue Nov 21 15:28: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 9A255129B79 for ; Tue, 21 Nov 2017 15:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPCSRKgK2GHK for ; Tue, 21 Nov 2017 15:28:08 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 0323A12704A for ; Tue, 21 Nov 2017 15:28:07 -0800 (PST) Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.122) id 1eHHxV-0000W5-Sv for dcrup@ietf.org (return-path ); Tue, 21 Nov 2017 23:28:05 +0000 To: dcrup@ietf.org References: <20171121220334.8209.qmail@ary.lan> From: Jeremy Harris Message-ID: <00d888c1-64c9-9f26-0426-fbbb17fc5bdc@wizmail.org> Date: Tue, 21 Nov 2017 23:28:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171121220334.8209.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) with esmtpsa Archived-At: Subject: Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 21 Nov 2017 23:28:09 -0000 On 21/11/17 22:03, John Levine wrote: > Keeping in mind that you're responding to a message I wrote two months ago ... > > In article <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org> you write: >> Wouldn't it be more aesthetically pleasing to decouple, for dkim >> a=ed25519-sha256 signing, the hash used for the body (sha256 as >> specified by the 'a' tag) from the hash used for signing headers >> (sha512, I think, but whatever the libraries have tied to >> Ed25519 signing)? > > No. I think you need to further support your position. -- Jeremy From nobody Tue Nov 21 18:48:32 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27DE129C0B for ; Tue, 21 Nov 2017 18:48:31 -0800 (PST) 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=UEonJtot; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=gjCGTmiR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09q1IvptYCEP for ; Tue, 21 Nov 2017 18:48:30 -0800 (PST) Received: from mail.winserver.com (dkim.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 47491120713 for ; Tue, 21 Nov 2017 18:48:29 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=512; t=1511318908; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=jcYjabBpiVGYb4SeO/t/URrL8Ow=; b=UEonJtotSP1NSYivhZwdJMPUQ5FMRNkOC2dARY4IeW7Az9IKEi0lh0yoIMmP+T c9zOsb9n96QOQ/61uFaQg8FzDEamvwAQZkUb96DG6BN1tF3P2LifGA1uqjVpYah9 ZjkiOU7nhIUZTtr78veOgQLzEzuohnnBuIBFueqNMVzQ8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 21 Nov 2017 21:48:28 -0500 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 1187639840.13.3200; Tue, 21 Nov 2017 21:48:27 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=512; t=1511318759; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nIvtwej e90D71P9SZXhE2sUhd3kOFD3VWEXB6ax5dqg=; b=gjCGTmiRLEY+bIM1HjaIGEm xxLqiv085j1+xZjKuD0RHSKRVhZtqfT2DaKGX0ZhTx+Vm14VrB6pXnaTx3KwLYUA kqzpusNDenWgpYnLaonMuQrLKL0xE2+nIhpFoPzRl2xZ+NBIzHftMzBi01KoyFUA AKkIaDfEp+xZt2d4w/Ws= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Tue, 21 Nov 2017 21:45:59 -0500 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1187600500.9.251008; Tue, 21 Nov 2017 21:45:59 -0500 Message-ID: <5A14E57C.4040008@isdg.net> Date: Tue, 21 Nov 2017 21:48:28 -0500 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: <5A0DF2E9.6030105@isdg.net> <5A1060A7.80505@isdg.net> <2CE0DC9D-202E-418F-AC25-98DE9D9D8CC6@akamai.com> In-Reply-To: <2CE0DC9D-202E-418F-AC25-98DE9D9D8CC6@akamai.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Dcrup] Next steps for 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: Wed, 22 Nov 2017 02:48:32 -0000 On 11/19/2017 11:58 AM, Salz, Rich wrote: > ➢ Until the tools are available to support EDDSA, i.e. OpenSSL in our case, > > The current plan is that the next release of OpenSSL will have the necessary API in-place. This is also the release that will have TLS 1.3, and it’s binary compatible with 1.1.0, so hopefully the uptake will be rapid. > 1.1.0 is a significant API/layout/build/DLL naming change, hence, we could have a longer migration, wait period. I'll start planning for it. -- HLS From nobody Tue Nov 21 20:36: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 0F207129C30 for ; Tue, 21 Nov 2017 20:36:19 -0800 (PST) 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 1ZT_JTF67Qc6 for ; Tue, 21 Nov 2017 20:36:17 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 46414129C2F for ; Tue, 21 Nov 2017 20:36:17 -0800 (PST) Received: (qmail 55070 invoked from network); 22 Nov 2017 04:36:15 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 22 Nov 2017 04:36:15 -0000 Date: 22 Nov 2017 04:35:53 -0000 Message-ID: <20171122043553.9264.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: jgh@wizmail.org In-Reply-To: <00d888c1-64c9-9f26-0426-fbbb17fc5bdc@wizmail.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] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 22 Nov 2017 04:36:19 -0000 In article <00d888c1-64c9-9f26-0426-fbbb17fc5bdc@wizmail.org> you write: >On 21/11/17 22:03, John Levine wrote: >> Keeping in mind that you're responding to a message I wrote two months ago ... >> >> In article <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org> you write: >>> Wouldn't it be more aesthetically pleasing to decouple, for dkim >>> a=ed25519-sha256 signing, the hash used for the body (sha256 as >>> specified by the 'a' tag) from the hash used for signing headers >>> (sha512, I think, but whatever the libraries have tied to >>> Ed25519 signing)? >> >> No. > >I think you need to further support your position. You might want to review some of the 100 messages posted to this list since the one you were responding to. R's, John PS: look for the ones about many libraries don't plan to provide the pure version of ed25519, and how we agreed to deal with that. From nobody Wed Nov 22 01:25: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 3E2B2128D6F for ; Wed, 22 Nov 2017 01:25:25 -0800 (PST) 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 IDs5V9dpD6aO for ; Wed, 22 Nov 2017 01:25:23 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 923E8128D69 for ; Wed, 22 Nov 2017 01:25:22 -0800 (PST) Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.122) id 1eHRHU-0000Ql-C6 for dcrup@ietf.org (return-path ); Wed, 22 Nov 2017 09:25:20 +0000 To: dcrup@ietf.org References: <20171122043553.9264.qmail@ary.lan> From: Jeremy Harris Message-ID: Date: Wed, 22 Nov 2017 09:25:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171122043553.9264.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) with esmtpsa Archived-At: Subject: Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 22 Nov 2017 09:25:25 -0000 On 22/11/17 04:35, John Levine wrote: > In article <00d888c1-64c9-9f26-0426-fbbb17fc5bdc@wizmail.org> you write: >> On 21/11/17 22:03, John Levine wrote: >>> Keeping in mind that you're responding to a message I wrote two months ago ... >>> >>> In article <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org> you write: >>>> Wouldn't it be more aesthetically pleasing to decouple, for dkim >>>> a=ed25519-sha256 signing, the hash used for the body (sha256 as >>>> specified by the 'a' tag) from the hash used for signing headers >>>> (sha512, I think, but whatever the libraries have tied to >>>> Ed25519 signing)? >>> >>> No. >> >> I think you need to further support your position. > > You might want to review some of the 100 messages posted to this list > since the one you were responding to. > PS: look for the ones about many libraries don't plan to provide the > pure version of ed25519, and how we agreed to deal with that. I already did. All assumed immediately the re-hash, once it was accepted that we had no chance of the libraries providing a pure signing facility. I didn't see one that suggested that the headers be passed in original unhashed form to the library hash-and-sign. Is your position "it's too late, we already decided"? You final sentence above implies that, but perhaps I misread you. -- Cheers, Jeremy From nobody Wed Nov 22 03:19: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 7B0B512426E for ; Wed, 22 Nov 2017 03:19:32 -0800 (PST) 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 OzDgQy9gBBKW for ; Wed, 22 Nov 2017 03:19:29 -0800 (PST) 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 E935A127522 for ; Wed, 22 Nov 2017 03:19:28 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x68so17815828lff.0 for ; Wed, 22 Nov 2017 03:19:28 -0800 (PST) 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=rn2Ppm5fBY74yJFXqcYp/NIrdl18NOHX8gJ9FA9vpEY=; b=ALOIfBQgpGM1Z6pkSgKgKoM5OV+PL9FRfBhL8tm+ZjgXr3c2yPp9U76uAyixODQAl6 UznmRGaPDgo/tpr0kr5MbF33NFxZ9otfFfzdvTtvK9sTpwGVpU+I9GZvLnmJuHUv1vBX 3IqUlaB2g4Sd4yWY8JM578MaDYW5Omv2yPaVkM78q7KGhDWOzWC1ZGitd3O2pfgYAgHG NlKScitPjJfYWt/sW2qROzRzrWmdQeZevnG+vvoowmKYEDhR3a9tcjgzQsabwIpO3NZJ uh/9yoQPR1TaU9QnQkyH+BqSzHHbljYIg5EBEaRthqb0lP4SvUqz22dWPvrGA+W5/Adi X+MQ== 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=rn2Ppm5fBY74yJFXqcYp/NIrdl18NOHX8gJ9FA9vpEY=; b=g2S5Mk3EjQcFIuadRkeRCyQnQgkHDSW7IItpbok0syHTmaB6IwyUycuTkOOymBNLkY FeQJtHe+A3TV9uTyEXF7Jp3om839r3qn42y6Jmz3nqPjUp7atSyjSzXUVs3Qg8nA5mkS AG6BLBpwkTdWxA8RzK4aR0siPQJoGLpyaurwL4ebY0sCluvLldm0pQsbdZ6F1aFPhFKw E/W6FlgA+IZXOTQB3slgALwxiQVjynlnMEMQKCslxL/dIZPM3rVwaDJRUqiJaNVhM316 /FnSxAFk/zTzORmGWzoQGnr+V4tpnfvBkttOFlv01liMP2vKB3kJFeQ0AjeW41vJGg4S BhEw== X-Gm-Message-State: AJaThX5w4kljRNbHfDee7WZ3yZm2PHLTDi7bJGeRd+5+pzmZ/Zf5/05l ZzY+28z59mhUa+HR2zAqLGD0TEqNJDLPh6udxUs= X-Google-Smtp-Source: AGs4zMYPttCpOSpwxXjNSU7Ah2zZGV3G1tUjAHP+8pGsq2jzE0MTVMQRjybRLiEemewBLNvSUWvgFeJxYef6iuhVphs= X-Received: by 10.46.34.196 with SMTP id i187mr6304453lji.106.1511349567291; Wed, 22 Nov 2017 03:19:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.179.2.3 with HTTP; Wed, 22 Nov 2017 03:19:26 -0800 (PST) In-Reply-To: References: <20171122043553.9264.qmail@ary.lan> From: denis bider Date: Wed, 22 Nov 2017 05:19:26 -0600 Message-ID: To: Jeremy Harris Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="f4030439e19417045a055e907e4b" Archived-At: Subject: Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 22 Nov 2017 11:19:32 -0000 --f4030439e19417045a055e907e4b Content-Type: text/plain; charset="UTF-8" Jeremy, I believe the exact thing you describe (whether to pass original headers to the library to hash and sign) was discussed in many back-and-forths. That is the obvious alternative to re-hash, so the entire discussion was about that, vs. re-hash. denis On Wed, Nov 22, 2017 at 3:25 AM, Jeremy Harris wrote: > On 22/11/17 04:35, John Levine wrote: > > In article <00d888c1-64c9-9f26-0426-fbbb17fc5bdc@wizmail.org> you write: > >> On 21/11/17 22:03, John Levine wrote: > >>> Keeping in mind that you're responding to a message I wrote two months > ago ... > >>> > >>> In article <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org> you > write: > >>>> Wouldn't it be more aesthetically pleasing to decouple, for dkim > >>>> a=ed25519-sha256 signing, the hash used for the body (sha256 as > >>>> specified by the 'a' tag) from the hash used for signing headers > >>>> (sha512, I think, but whatever the libraries have tied to > >>>> Ed25519 signing)? > >>> > >>> No. > >> > >> I think you need to further support your position. > > > > You might want to review some of the 100 messages posted to this list > > since the one you were responding to. > > > PS: look for the ones about many libraries don't plan to provide the > > pure version of ed25519, and how we agreed to deal with that. > > I already did. All assumed immediately the re-hash, once it was > accepted that we had no chance of the libraries providing a pure > signing facility. I didn't see one that suggested that the headers > be passed in original unhashed form to the library hash-and-sign. > > Is your position "it's too late, we already decided"? You > final sentence above implies that, but perhaps I misread you. > -- > Cheers, > Jeremy > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --f4030439e19417045a055e907e4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeremy,

I believe the exact thing you d= escribe (whether to pass original headers to the library to hash and sign) = was discussed in many back-and-forths. That is the obvious alternative to r= e-hash, so the entire discussion was about that, vs. re-hash.
denis


=
On Wed, Nov 22, 2017 at 3:25 AM, Jeremy Harris <= span dir=3D"ltr"><j= gh@wizmail.org> wrote:
On 22/11/17 04:35, John Levine wrote:
> In article <00d888c1-64c9-9f26-0426-fbbb17fc5bdc@wizmail.org> = you write:
>> On 21/11/17 22:03, John Levine wrote:
>>> Keeping in mind that you're responding to a message I wrot= e two months ago ...
>>>
>>> In article <383fef94-84c4-9b54-5566-a6fa1279aa38@wizmail.org<= /a>> you write:
>>>> Wouldn't it be more aesthetically pleasing to decouple= , for dkim
>>>> a=3Ded25519-sha256 signing, the hash used for the body (sh= a256 as
>>>> specified by the 'a' tag) from the hash used for s= igning headers
>>>> (sha512, I think, but whatever the libraries have tied to<= br> >>>> Ed25519 signing)?
>>>
>>> No.
>>
>> I think you need to further support your position.
>
> You might want to review some of the 100 messages posted to this list<= br> > since the one you were responding to.

> PS: look for the ones about many libraries don= 't plan to provide the
> pure version of ed25519, and how we agreed to deal with that.

I already did.=C2=A0 All assumed immediately the re-hash, once it wa= s
accepted that we had no chance of the libraries providing a pure
signing facility.=C2=A0 I didn't see one that suggested that the header= s
be passed in original unhashed form to the library hash-and-sign.

Is your position "it's too late, we already decided"?=C2=A0 Y= ou
final sentence above implies that, but perhaps I misread you.
--
Cheers,
=C2=A0 Jeremy

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

--f4030439e19417045a055e907e4b-- From nobody Wed Nov 22 03:34: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 710A812426E for ; Wed, 22 Nov 2017 03:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQfnTtv5k5Hm for ; Wed, 22 Nov 2017 03:34:25 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 E5EF9129408 for ; Wed, 22 Nov 2017 03:34:24 -0800 (PST) Received: from [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89.122) id 1eHTIM-0004DZ-Qf for dcrup@ietf.org (return-path ); Wed, 22 Nov 2017 11:34:22 +0000 To: dcrup@ietf.org References: <20171122043553.9264.qmail@ary.lan> From: Jeremy Harris Message-ID: Date: Wed, 22 Nov 2017 11:34:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:df75:dcf5:c97b:6fad] (helo=localhost.localdomain) with esmtpsa Archived-At: Subject: Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 22 Nov 2017 11:34:26 -0000 On 22/11/17 11:19, denis bider wrote: > I believe the exact thing you describe (whether to pass original headers to > the library to hash and sign) was discussed in many back-and-forths. That > is the obvious alternative to re-hash, so the entire discussion was about > that, vs. re-hash. Ah, I must have been blind then. My apologies for the noise. I'll go search yet again. -- Cheers, Jeremy From nobody Wed Nov 22 06:00: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 F1901129449 for ; Wed, 22 Nov 2017 05:59:58 -0800 (PST) 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 wWOqUiSoDY6k for ; Wed, 22 Nov 2017 05:59:57 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 9409812944A for ; Wed, 22 Nov 2017 05:59:57 -0800 (PST) Received: (qmail 1973 invoked from network); 22 Nov 2017 13:59:55 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 22 Nov 2017 13:59:55 -0000 Date: 22 Nov 2017 13:59:33 -0000 Message-ID: <20171122135933.9750.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: jgh@wizmail.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] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 22 Nov 2017 13:59:59 -0000 In article you write: >I already did. All assumed immediately the re-hash, once it was >accepted that we had no chance of the libraries providing a pure >signing facility. I didn't see one that suggested that the headers >be passed in original unhashed form to the library hash-and-sign. As several people noted, passing the unhashed canonicalized headers and body would require opening up code that was written and debugged a decade ago, and inventing some tricky coroutine interfaces since the string is likely to be too big to buffer in memory. Compared to that, a second hash is a no-brainer. R's, John From nobody Wed Nov 22 07:06: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 E96D512940E for ; Wed, 22 Nov 2017 07:06:00 -0800 (PST) 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 ql_6rNj82VAT for ; Wed, 22 Nov 2017 07:05:59 -0800 (PST) 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 D82DB1288A9 for ; Wed, 22 Nov 2017 07:05:58 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAMF3m53021201; Wed, 22 Nov 2017 15:05:53 GMT 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=uTnQ8MN951SeNxbg54nMZd4HMnXHXhmgsfL5U5ZOpT4=; b=OSGkgXI9C+UbRmAWGxrPjWfRh+R/UWHwf+o+pIawQ3eg8GPR1clUNfpIcvj31NSKnKDy YOp2h9lYTFe0rDbqRrvA2Ev0Rn1SfASkAP6vgD4v1Ux8E8oh+jeSCodafvs/ilDacHVa 5SUzJ74JTebkgLFCARQ5LgVZHsxRu4QfgDkQCgCjWQ0QKdpJw0n2djjp7ABdQu15f9KQ 0CjL9TD1H0uV224VocPO4JSZMmfEZ5if7BYJNxe9iKnIY6D7bZyv7tz49i8ZKMUsxn+4 ClOvXXY9Dn3p+1oCyAqZEo0WZ74jYTtxass2oOZBG+A2c/FKmAemPCLbhEmz22e9CQkQ 9A== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2eaatfxjg0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Nov 2017 15:05:53 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAMF5qXu002007; Wed, 22 Nov 2017 10:05:52 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2eah31ajfr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 Nov 2017 10:05:52 -0500 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; Wed, 22 Nov 2017 10:05:51 -0500 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, 22 Nov 2017 10:05:51 -0500 From: "Salz, Rich" To: denis bider , Jeremy Harris CC: "dcrup@ietf.org" Thread-Topic: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 Thread-Index: AQHTYmW1EIrLf/ILeEm05wBLBpQnX6MfuCwAgAAXnACAAFYAgIAAUN0AgAAf5ACAAD9BAA== Date: Wed, 22 Nov 2017 15:05:50 +0000 Message-ID: <291AADBD-18BE-4CC6-BC17-888CB39C9B08@akamai.com> References: <20171122043553.9264.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.105] Content-Type: multipart/alternative; boundary="_000_291AADBD18BE4CC6BC17888CB39C9B08akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-22_04:, , 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-1709140000 definitions=main-1711220206 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-22_04:, , 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-1709140000 definitions=main-1711220205 Archived-At: Subject: Re: [Dcrup] I-D draft-ietf-dcrup-dkim-crypto-06 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 22 Nov 2017 15:06:01 -0000 --_000_291AADBD18BE4CC6BC17888CB39C9B08akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGUgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0byBwYXNzIHRoZSBoYXNoZWQgY29udGVu dCB0byB0aGUgc2lnbmluZyBsaWJyYXJ5LCBvciB3aGV0aGVyIHRvIHBhc3MgdGhlIHJhdyBoZWFk ZXJzLCB3YXMgZGlzY3Vzc2VkIGEgZ3JlYXQgZGVhbCwgYW5kIHRoZSBXRyBkZWNpZGVkIHRvIOKA nHNpZ24gYSBoYXNoLuKAnQ0KDQpTcGVha2luZyBhcyBjaGFpciwgbGV04oCZcyBub3QgcmUtb3Bl biB0aGlzIGlzc3VlIHVubGVzcyB0aGVyZSBpcyBuZXcgY29udGVudCB0byBkaXNjdXNzLg0KDQo= --_000_291AADBD18BE4CC6BC17888CB39C9B08akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <20552D8B393D4B44AA3BB48739E36609@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzLCB0aGUgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0byBwYXNzIHRo ZSBoYXNoZWQgY29udGVudCB0byB0aGUgc2lnbmluZyBsaWJyYXJ5LCBvciB3aGV0aGVyIHRvIHBh c3MgdGhlIHJhdyBoZWFkZXJzLCB3YXMgZGlzY3Vzc2VkIGEgZ3JlYXQgZGVhbCwgYW5kIHRoZSBX RyBkZWNpZGVkIHRvIOKAnHNpZ24gYSBoYXNoLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T cGVha2luZyBhcyBjaGFpciwgbGV04oCZcyBub3QgcmUtb3BlbiB0aGlzIGlzc3VlIHVubGVzcyB0 aGVyZSBpcyBuZXcgY29udGVudCB0byBkaXNjdXNzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_291AADBD18BE4CC6BC17888CB39C9B08akamaicom_-- From nobody Thu Nov 30 17:36: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 17E21126B7F for ; Thu, 30 Nov 2017 17:36:35 -0800 (PST) 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=[BAYES_20=-0.001, 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 (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 K89MMKHZ2BCA for ; Thu, 30 Nov 2017 17:36:33 -0800 (PST) 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 9FF041241FC for ; Thu, 30 Nov 2017 17:36:33 -0800 (PST) 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 608FAC401B6 for ; Thu, 30 Nov 2017 19:36:31 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1512092191; bh=SioKWztd21erNuTbW1ew5GUCiElgUwEOhEj/Y8+vMnM=; h=From:To:Subject:Date:From; b=nYfQLm2t+goJwSqHt+0P82kOM9RPLSWiBEGIj0w7GefBzAjbOYMHzok3bLkNa8gnu rV3/ojbahI6Y9+uifvykQD+MeHn4qLejSv+Y31QnkXRcgh3DKN1byCKWzPKjk0EFZC jWcLoi4w115oOnm2+LVk6keCnec2OFjdYx9jhI5g= From: Scott Kitterman To: "dcrup@ietf.org" Date: Thu, 30 Nov 2017 20:36:30 -0500 Message-ID: <4586222.5KzNczgk1I@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-133-generic; KDE/4.13.3; x86_64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: [Dcrup] Hash-alg versus sig-alg X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 01 Dec 2017 01:36:35 -0000 RFC 6376 says both these things (page 31): hash-alg: is the hashing algorithm specified in the "a" parameter. sig-alg: is the signature algorithm specified by the "a" parameter. For sha-1/sha-256 these were always the same. As I understand it, for RFC 8032 HashEdDSA ed25519, that's not true. I think sig-alg is ed25519, but it uses sha-512 internally as the hash algorithm. My assumption then is that if the "a" parameter is ed25519, then when calculating the body hash for the bh= tag, one should canonicalize and then hash with sha-512. Is that right? Assuming it is, that probably needs be explicitly stated in the updated draft. How's that coming? Scott K From nobody Thu Nov 30 17:55: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 2DD0F12704B for ; Thu, 30 Nov 2017 17:54:59 -0800 (PST) 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 rcUV7nXNOpbm for ; Thu, 30 Nov 2017 17:54:57 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 81A9D1241FC for ; Thu, 30 Nov 2017 17:54:57 -0800 (PST) Received: (qmail 64938 invoked from network); 1 Dec 2017 01:54:56 -0000 Received: from unknown (64.57.183.53) by gal.iecc.com with QMQP; 1 Dec 2017 01:54:56 -0000 Date: 1 Dec 2017 01:39:33 -0000 Message-ID: <20171201013933.25910.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <4586222.5KzNczgk1I@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Dcrup] Hash-alg versus sig-alg X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 01 Dec 2017 01:54:59 -0000 In article <4586222.5KzNczgk1I@kitterma-e6430> you write: >For sha-1/sha-256 these were always the same. As I understand it, for RFC >8032 HashEdDSA ed25519, that's not true. I think sig-alg is ed25519, but it >uses sha-512 internally as the hash algorithm. My assumption then is that if >the "a" parameter is ed25519, then when calculating the body hash for the bh= >tag, one should canonicalize and then hash with sha-512. Is that right? Nope. The canonicalization process does exactly what it's always done, smooshing the header and body text and making sha-256 hashes of it. Then it hands the header hash to HashEdDSA which internally takes that hash and makes a sha-512 hash of it and signs that. That second hash doesn't do anything useful, but we hear that PureEdDSA isn't likely to be widely implemented while HashEdDSA is so we'll go with what we're likely to get. >Assuming it is, that probably needs be explicitly stated in the updated draft. >How's that coming? I was waiting to hear if there were any objection to our tentative decision in Singapore to ditch the RSA signatures with fingerprints. Hearing none, I will hack it out of the draft. One remaining nit is whether to keep the p= tag in the signatures which has a copy of the verification key. For rsafp we needed it, for ed25519 we don't. Martin Thompson mentioned an arcane key reverse engineering attack that the p= tag deterred but I think that only applies to RSA, not elliptical curve crypto. R's, John From nobody Thu Nov 30 18:36: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 9E8F61270A7 for ; Thu, 30 Nov 2017 18:35:57 -0800 (PST) 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=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 EdwpZySMAKcO for ; Thu, 30 Nov 2017 18:35:56 -0800 (PST) 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 6B09A126B72 for ; Thu, 30 Nov 2017 18:35:56 -0800 (PST) Received: from [192.168.1.115] (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 1D4E4C4024D; Thu, 30 Nov 2017 20:35:55 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1512095755; bh=pOz09MPj0DMr6jBbN02nJUhuz4gP1TBxc6mjx9VPovo=; h=Date:In-Reply-To:References:Subject:To:From:From; b=knCvD8uIqeCZ15/czQHF6Qw/GHywMvz9eEXqMbn51NFdv53PLvzCmocZ76cE21txu wz2E1fXqKaoKjJDXA/VR9z5xR2LJV4Joe0LKZfxFukTmkcNl41j8OlAWJsbBiYQzIJ xxFshFeUVI/lQZyueXMfA07APsxCKY4af91a+hbM= Date: Fri, 01 Dec 2017 02:35:52 +0000 In-Reply-To: <20171201013933.25910.qmail@ary.lan> References: <20171201013933.25910.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: <41D6DDCC-4690-42B5-A27B-6D73D48DB310@kitterman.com> Archived-At: Subject: Re: [Dcrup] Hash-alg versus sig-alg X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 01 Dec 2017 02:35:58 -0000 On November 30, 2017 8:39:33 PM EST, John Levine wrote= : >In article <4586222=2E5KzNczgk1I@kitterma-e6430> you write: >>For sha-1/sha-256 these were always the same=2E As I understand it, for >RFC=20 >>8032 HashEdDSA ed25519, that's not true=2E I think sig-alg is ed25519, >but it=20 >>uses sha-512 internally as the hash algorithm=2E My assumption then is >that if=20 >>the "a" parameter is ed25519, then when calculating the body hash for >the bh=3D=20 >>tag, one should canonicalize and then hash with sha-512=2E Is that >right? > >Nope=2E The canonicalization process does exactly what it's always >done, smooshing the header and body text and making sha-256 hashes of >it=2E Then it hands the header hash to HashEdDSA which internally takes >that hash and makes a sha-512 hash of it and signs that=2E That second >hash doesn't do anything useful, but we hear that PureEdDSA isn't >likely to be widely implemented while HashEdDSA is so we'll go with >what we're likely to get=2E Thanks for the clarification=2E >>Assuming it is, that probably needs be explicitly stated in the >updated draft=2E >>How's that coming? > >I was waiting to hear if there were any objection to our tentative >decision in >Singapore to ditch the RSA signatures with fingerprints=2E Hearing none, >I will >hack it out of the draft=2E > >One remaining nit is whether to keep the p=3D tag in the signatures >which has a copy of the verification key=2E For rsafp we needed it, for >ed25519 we don't=2E Martin Thompson mentioned an arcane key reverse >engineering attack that the p=3D tag deterred but I think that only >applies to RSA, not elliptical curve crypto=2E Looking forward to it=2E Scott K From nobody Thu Nov 30 23:09: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 506D9126D74 for ; Thu, 30 Nov 2017 23:09:50 -0800 (PST) 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 xjwpsa2coWnn for ; Thu, 30 Nov 2017 23:09:49 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A521201F2 for ; Thu, 30 Nov 2017 23:09:48 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id g10so11876264qtj.12 for ; Thu, 30 Nov 2017 23:09:48 -0800 (PST) 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=85fpjzCIXuk16wEABym+7cqj3m8Ui4kDhsI8Zw1Qx1s=; b=U39lCxtz9ILfQhSl6l9JpvLxBi76OD8tN1oG18cl+Xzcxt0iUznnru9NN2+2lWGhTn 7HJpoyDwzi5SnKZ5NnwxpWfRrlfSvuhnU/7wzynZINSUKJb6czl3RTOakhXgZVQZWubK drOwid2IkKTwhm1YU6d4p0cg1hxKajoy3krVW6f8ToTBCsT/Jd1iQrbFNAAMLFg6ogNu 9ymCjjgr8BtF00Lk9cYWpmDyzrS7MHe52bLEr5bjms5kHslx1/rGxg+o+qOEXxfTuCpg YBlaZq6Y/DCFoJt10JFWK5kIY4qwBVenTJrlKajT5y2WkK9QHO57h3w7Al4quVOUV3eJ JRIw== 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=85fpjzCIXuk16wEABym+7cqj3m8Ui4kDhsI8Zw1Qx1s=; b=Iy84pzMj3I/IpiUSpEfuTen4kZsZHbswAlvD5a/V7gyBkb7CZJR5fMpxjlIdf4fyRU BZUGr7P40kH0+Ig/ZUNeXgfGbipTVAD6+NaxYgX7rio9B0j8NQpF6WPn8lRidrTy48Wz k305y2/AFS+fexEtkPeD+5ECbqW2avsDycaMG0v7EvuZ30VgDKXAnRB1VmtCgHHLHFqJ 8xW2ZUuaMZpVzuuPjhTaDTekWybpERyqgE3Uo/GahortqLuBXOtLYyCii3070tbx+yuw b17rTIPCaYKYyUHoq6GJAXGHDj1GRIhxCvO3CooTsXzzNQHGaTivvmcnPKP7SkYbIUET 3g9g== X-Gm-Message-State: AKGB3mLmyNqI4rDczhPwFjbDGJrIHF8RYMIao5UaCa0+hfrXhRBdKHyM JXWbgY0qtBObZelsQHdISKMFunh1ABVxB+teYt4= X-Google-Smtp-Source: AGs4zMaqR0LZWe+6vyeCIl5zfxpji2ehxVivx0ZcVmExbEMZKYl1MC+6A+G+atZBHsQUUXGCjahmzjjpkzbGvwN5His= X-Received: by 10.237.35.207 with SMTP id k15mr7648578qtc.95.1512112187793; Thu, 30 Nov 2017 23:09:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.50.196 with HTTP; Thu, 30 Nov 2017 23:09:47 -0800 (PST) In-Reply-To: <20171201013933.25910.qmail@ary.lan> References: <4586222.5KzNczgk1I@kitterma-e6430> <20171201013933.25910.qmail@ary.lan> From: "Murray S. Kucherawy" Date: Thu, 30 Nov 2017 23:09:47 -0800 Message-ID: To: John Levine Cc: dcrup@ietf.org, Scott Kitterman Content-Type: multipart/alternative; boundary="001a11356cccd06783055f420db4" Archived-At: Subject: Re: [Dcrup] Hash-alg versus sig-alg X-BeenThere: dcrup@ietf.org X-Mailman-Version: 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, 01 Dec 2017 07:09:50 -0000 --001a11356cccd06783055f420db4 Content-Type: text/plain; charset="UTF-8" Yes, please proceed. There's been no objection raised. On Thu, Nov 30, 2017 at 5:39 PM, John Levine wrote: > One remaining nit is whether to keep the p= tag in the signatures > which has a copy of the verification key. For rsafp we needed it, for > ed25519 we don't. Martin Thompson mentioned an arcane key reverse > engineering attack that the p= tag deterred but I think that only > applies to RSA, not elliptical curve crypto. > IMHO, we should drop it. Unless I've missed something, at this point there's no reason it should be any different than how we've always done it with RSA keys. -MSK --001a11356cccd06783055f420db4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<chair> Yes, please proceed.=C2=A0 There's been = no objection raised.=C2=A0 </chair>

On Thu, Nov 30, 2017 = at 5:39 PM, John Levine <johnl@taugh.com> wrote:
= One remaining nit is whether to keep the p=3D tag in the signatures
which has a copy of the verification key.=C2=A0 For rsafp we needed it, for=
ed25519 we don't.=C2=A0 Martin Thompson mentioned an arcane key reverse=
engineering attack that the p=3D tag deterred but I think that only
applies to RSA, not elliptical curve crypto.

IMHO, we should drop it.=C2=A0 Unless I've missed something, at t= his point there's no reason it should be any different than how we'= ve always done it with RSA keys.

-MSK
--001a11356cccd06783055f420db4--