From nobody Wed Aug 2 16:37:24 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 07CFC126C7A; Wed, 2 Aug 2017 16:37:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: dcrup-chairs@ietf.org, dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150171704196.5809.13431573373056194069.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 16:37:21 -0700 Archived-At: Subject: [Dcrup] Ben Campbell's Yes on charter-ietf-dcrup-01-02: (with COMMENT) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:37:22 -0000 Ben Campbell has entered the following ballot position for charter-ietf-dcrup-01-02: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-dcrup/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm fine skipping the external review. From nobody Fri Aug 4 10:50:00 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 A3248132339; Fri, 4 Aug 2017 10:49:51 -0700 (PDT) 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.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dcrup@ietf.org, dcrup-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150186899166.18657.15344334905238027446.idtracker@ietfa.amsl.com> Date: Fri, 04 Aug 2017 10:49:51 -0700 Archived-At: Subject: [Dcrup] WG Action: Rechartered DKIM Crypto Update (dcrup) X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:49:52 -0000 The DKIM Crypto Update (dcrup) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. DKIM Crypto Update (dcrup) ----------------------------------------------------------------------- Current status: Active WG Chairs: Rich Salz Murray Kucherawy Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Technical advisors: Eric Rescorla Mailing list: Address: dcrup@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/dcrup Archive: https://mailarchive.ietf.org/arch/browse/dcrup/ Group page: https://datatracker.ietf.org/group/dcrup/ Charter: https://datatracker.ietf.org/doc/charter-ietf-dcrup/ The DKIM Crypto Update (DCRUP) Working Group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptographic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records. DKIM also currently supports use of SHA1 coupled with RSA. SHA1 has been formally deprecated due to weakness especially when used in the context transport security, though the risk of a successful preimage attack is less severe. Still, the community wishes to discourage its continued use in the DKIM context. DCRUP will consider four types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, changes to key strength advice and requirements, deprecating the use of SHA1, and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records. It will limit itself to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifiers. Milestones: From nobody Sun Aug 6 19:52:52 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 82226126CB6; Sun, 6 Aug 2017 19:52:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150207437049.19046.8620414411887127702@ietfa.amsl.com> Date: Sun, 06 Aug 2017 19:52:50 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-crypto-05.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, 07 Aug 2017 02:52:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update WG of the IETF. Title : New cryptographic signature methods for DKIM Author : John Levine Filename : draft-ietf-dcrup-dkim-crypto-05.txt Pages : 7 Date : 2017-08-06 Abstract: DKIM was designed to allow new cryptographic algorithms to be added. This document adds a new signing algorithm and a new way to represent signature validation keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-crypto/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dcrup-dkim-crypto-05 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-crypto-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-crypto-05 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 Sun Aug 6 19:54:07 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D399127077 for ; Sun, 6 Aug 2017 19:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=SaK76re+; dkim=pass (1536-bit key) header.d=taugh.com header.b=Sf3K+w4N Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJtE3eTJ3dnL for ; Sun, 6 Aug 2017 19:54:01 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D8C126CD8 for ; Sun, 6 Aug 2017 19:53:57 -0700 (PDT) Received: (qmail 89402 invoked from network); 7 Aug 2017 02:53:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15d38.5987d644.k1707; bh=bA05vfcZu+fEsIJFZ6YYaPDKCWsflCrHiiDVS5Ct4Ro=; b=SaK76re+fm5KydhuNF8PQoNxtBfX08CEB7c3wYSXenjcuXxn+0p2cT5b0WnYV7d2dGjWY7micdjf5BfqIySMAWkW6caPrKiCaSGzvjjHfrMa9l9KU4ONf2awsjZoP9c4S6H+yQUmpWaAFREwtRqKRV5mZGf2ZmyXVTHSzCeCmWNPKfJM2dqUoW5NU6OlVRN472Am7zjkn8cl7YMtknvCqY0umvbNRhrCPwVWonNobRBlBEIyQdmZ2bCf6Lp+Alee DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15d38.5987d644.k1707; bh=bA05vfcZu+fEsIJFZ6YYaPDKCWsflCrHiiDVS5Ct4Ro=; b=Sf3K+w4NV84gWmxS+KZQYadcn0RvVY/sdr/kTvnORSgdvVd2fimZtHhIpHqBnvTTInkSr4n5rRdYBMgjuENIss9F48/cJHsJaQGN5dX3i1WZWSeIw52CLHpVAmPteozsunKmvXI7ofOqaVayxcszlx5R0Iy7AN9qWBWLqjiOZZXTdXeL1EfXELygMV/cPbIHnn+P8HoZGvMS446R80xK9qDQhZggvqPzB0PDBl84VG7KDy8Y91zdgCGm+0Ry9ciX Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Aug 2017 02:53:56 -0000 Date: 6 Aug 2017 22:53:55 -0400 Message-ID: From: "John R Levine" To: "Martin Thomson" Cc: dcrup@ietf.org In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 02:54:03 -0000 > This looks pretty good. Thanks, > The abstract still says "and deprecates an obsolete signing > algorithm", Right, it's gone. > In the spirit of leaving the removal of the crusty old stuff to the > other draft, I think that you should: > > 1. remove the clause from the abstract > 2. remove the first paragraph of Section 6 (which specifies the update > to RFC 6376) > 3. remove the requirement to use 1024-bit keys for "rsa-sha256" That makes no sense to me. Going forward, if DKIM signers and verifiers are going to interoperate, the verifiers have to handle every signature that a signer can create. It's not like TLS where they get to negotiate at connection time. So we have to update 6376 to add all the new signature methods that a signer might use. Also remember that the current unhashed RSA works just fine for the large fraction of signers whose DNS provisioning system isn't broken, so we're not deprecating it. For the editorial stuff, you're right that I confused p= and k= which I think are right in the -05 version. The text changes don't seem any clearer to me so I'll wait and see what other people say. > Final unrelated comment: > > You recommend that "rsafp signatures SHOULD use key lengths of 1536 or > 2048 bits". Well, actually, I said 1536 to 2048 bits in one place and 1024 to 2048 in another. Oops. I took out the second and now says signatures MUST be at least 1024 bits and SHOULD be 2048 bits, and verifiers MUST NOT accept shorter than 1024. I think that matches reality, particularly the final MUST NOT to get the remaining 512 bit signers to increase the key size. R's, John From nobody Sun Aug 6 21:20:49 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087F012702E for ; Sun, 6 Aug 2017 21:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICu9ONBamNh9 for ; Sun, 6 Aug 2017 21:20:46 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA9112420B for ; Sun, 6 Aug 2017 21:20:46 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id j32so21734026iod.0 for ; Sun, 06 Aug 2017 21:20:46 -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=d2p7RwH4FU6h2fWvBX2scn+1QUyzc1OPTtzRR0Uk098=; b=nWvIlSaoUMfVhhQpuXFauzewtnxUkNKS1tM9Z98klFuuT/W8yJJpuTAAuBdLGgez41 JJgUhACmnCiXUzIZ2qOyXWbpqDR5lslU+w46U8Bo056MTZJA2exdCQnM+iRWAe7nxJJl JIfkp2LbNlOdlkVhpFy1AKMMLJgnHkZ/L+yhQ55jLAys70sJXYRbuL3fLXc2JTdJ9Zgo nxZk/HAYDv2iBneA9yXP97ptI3bPd4yV8zynwc8LEoF6X/emYBHG0bnz4tjMF3wlj8AH YNIN81s0U0bPdD876cVi5XiLbH8wGOByCXs0pgksU7oFWW8Uoptre/A6VyXwc7jLX4y1 UY0A== 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=d2p7RwH4FU6h2fWvBX2scn+1QUyzc1OPTtzRR0Uk098=; b=ftI5GEGiQ+/FqtEADcYMaAF7uU333Y+VL3ZqcT+qVYh+gsywD8UFNACldSt5Sh5y1m V3izxbz5Yay1343ztRZsLrjjcqSroIld3bJ+QivENtY2a1Kms2ObhyMDsTpZ7O83XVhY 1HiK+dz1IW+VoXIc/1L4VUocqJWdTNSorrwTBUGhIpgPLEDVtKrwo3+yX1PpWHDKxsGG Qy2YXxpTzVm/URYrW4SuToxkHey6xD+rvFPnzxlovtumEK4flONG0M1qLvMzUHZvjNLB DFFyxKV/vOzem3jM661U7gZS0uY2aGSisbPKdhy4R/iXROSMsLeatdOvQs1bb3a5/e1l 0Dng== X-Gm-Message-State: AHYfb5jJ0vMASJvC5qMaF9ITNHe/wBRPfh2+HSQvrQ1Ln+C+gY1B2MI1 RWEhq9kBXrv9YEmEDM7QQHVNz0U7Msr2 X-Received: by 10.107.137.30 with SMTP id l30mr11268285iod.279.1502079645403; Sun, 06 Aug 2017 21:20:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sun, 6 Aug 2017 21:20:44 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 7 Aug 2017 14:20:44 +1000 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 04:20:48 -0000 On 7 August 2017 at 12:53, John R Levine wrote: > So we have to update 6376 to add all the new signature > methods that a signer might use. Also remember that the current unhashed > RSA works just fine for the large fraction of signers whose DNS provisioning > system isn't broken, so we're not deprecating it. That wasn't my point. And it might just come back to us disagreeing what "updates" means, but 6376 clearly establishes an extension point for new signature algorithms. Part of that includes the assumption that verifiers have to be willing to verify any defined algorithm (and the converse, that signers risk messages being marked as bad because they fail to include signatures over old algorithms when they add new ones). I don't believe that adding a signature algorithm means that you need to update 6376. > I took out the second and now says signatures MUST be at > least 1024 bits and SHOULD be 2048 bits, and verifiers MUST NOT accept > shorter than 1024. That works for me. From nobody Mon Aug 7 08:51:06 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C9712ECB7 for ; Mon, 7 Aug 2017 08:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=nQy7oNN2; dkim=pass (1536-bit key) header.d=taugh.com header.b=S4nFC9zg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEYxEsNsp87A for ; Mon, 7 Aug 2017 08:51:03 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DECC12EC11 for ; Mon, 7 Aug 2017 08:51:03 -0700 (PDT) Received: (qmail 70902 invoked from network); 7 Aug 2017 15:51:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=114f4.59888c65.k1707; bh=FrGc0ZdVdlyy8uFOT4A8UtEH+IVeq7rPelrHsTloTpo=; b=nQy7oNN2xtG9BIa6e1xE7VSD28QVxSg2/SsRe6cB3THK+S/iosOSL2evHib3mnthra9pewtGPyLQ2qGLP9paQWgU9QdmezHgeHMZBHD6BZ1GKy6f9XMpc4VZMM04HyaU7NKbLxrXmVliwr/2jQed5/PH4ow2YHFD6XdCyrNJugDFOWRvkyFeDKhUaUFtfvNIs0Q6zfV9rye//95usNTTz+EJmcDbKQjlmxD8C+pbqYkwNdAMSXYUr3etrqGbKBLV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=114f4.59888c65.k1707; bh=FrGc0ZdVdlyy8uFOT4A8UtEH+IVeq7rPelrHsTloTpo=; b=S4nFC9zgky8hoP+4OWo2eVoaWU9yZ6I9MA3l4dEjW/hsdOnkXlyLax6iFZA68t59nojeC5lUpiA+EEqk+c1V3+/iC+2qgnSDNPioPjkB/HAP/jJphnnvyZWy+23iT+PScc8Hn0/0kWkkoAITDdks4OfYeDBN12T88O5yVHru+LdepWXVy0zmmw07nqB+QYRRyXmofJwGwG1mjtkwYYbM1B0gjGNyNwx61xP1VNW41FA+Wi7rTQs2qUY+mG9zCAgV Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 07 Aug 2017 15:51:01 -0000 Date: 7 Aug 2017 11:51:00 -0400 Message-ID: From: "John R Levine" To: "Martin Thomson" Cc: dcrup@ietf.org In-Reply-To: References: User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 15:51:05 -0000 On Mon, 7 Aug 2017, Martin Thomson wrote: > I don't believe that adding a signature algorithm means that you need > to update 6376. Well, OK, but where does all the new ABNF go? Our plan here is that once this is published, people implement 6376 plus this draft plus (or perhaps minus) Scott's anti-SHA1, which tells me that these have to update 6376, but in any event, this is a decision for the WG or the chairs, not for us. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Mon Aug 7 21:46: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 92A9C126C23 for ; Mon, 7 Aug 2017 21:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym6piAeYfJJt for ; Mon, 7 Aug 2017 21:46:23 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::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 CBBE51243F3 for ; Mon, 7 Aug 2017 21:46:23 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so9525766ioe.5 for ; Mon, 07 Aug 2017 21:46:23 -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=5pXB7IAc1Ys8qLtrH0qpW9UtU6nDGqRGg338Fzh7SI0=; b=K7snR/2pmySkhorJyzG696Wh166H3ExHSDRFro2fdEpOzIOW1vTn7+cplcXJ08FVs+ jmaPtlyrX4vvrlOgzn+8AvsiDeK4hAurA+5rgpkKlFSXbRdRFeeIKmGIpEys/U059v5n 26ZQvyFYbChDrNGPDGOSDjlArbQVoDAVJfjnFOiwVmmMYVxCimkIePQNxqXRy7WWFnP/ 7x0Ogj9WBtqRb+Oc1XgLc/I81C28FsfTEXYJy7x+0lEPPUkVpxmg2Jrom5cm1/CySJiN 7geImWNKIGu5DfoEfzUw1J53zeetw0qYNhTGkz8ClEChAvnH/QEVWt16cL21uoA3kvAb UbxA== 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=5pXB7IAc1Ys8qLtrH0qpW9UtU6nDGqRGg338Fzh7SI0=; b=LOVoIxIkHprHzicwrkcUjt/PWhnB8Hxnzq4/xpu28e5swVHb9ACOMG1iTw6zGBqSAe /bQbiisSM/aWMN71B2/Y6QXUe/8v66+lqUYzVLuOEV3ctKi6L3lsi1r8kB2R6ouEJR8l DkIligK8S4qrDczAkq6hYDC3YrnKe1z9DwRqakwjCrzJogTyfxXgDjHRnm6oM2h3EI5m cHmLlbTcdSNBtINuwcIkETDB0Cuy1gIGJtUNKkTYs2XxgiRDgc8ePLtamC5YrfNNMgBP hwyRNtWNlBP7UDEP2ECo6D+7Ix7r6SAACRFJKGbAk8/nptbljrPv4tjLxOJpv+TVzIB5 8yvA== X-Gm-Message-State: AHYfb5gA4FCAzDiz1rr894pmYrqgkyY0LfTXy2DuFlG3FEjHXYkadtZ0 BZlO/FCErFE4MgRc5pUSmPCvwnpz3w== X-Received: by 10.107.16.196 with SMTP id 65mr2855650ioq.297.1502167582922; Mon, 07 Aug 2017 21:46:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 7 Aug 2017 21:46:22 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 8 Aug 2017 14:46:22 +1000 Message-ID: To: John R Levine Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 04:46:25 -0000 On 8 August 2017 at 01:51, John R Levine wrote: > On Mon, 7 Aug 2017, Martin Thomson wrote: >> >> I don't believe that adding a signature algorithm means that you need >> to update 6376. > > > Well, OK, but where does all the new ABNF go? In your draft? It's not like you can't define new values, but it's also the case that you don't have to. The already-defined extension point covers all valid values. > Our plan here is that once this is published, people implement 6376 plus > this draft plus (or perhaps minus) Scott's anti-SHA1, which tells me that > these have to update 6376, Yes, that's possible without updating 6376. One problem I've encountered is that 6376 plus its updates and 6376 plus some other RFC are materially different to some people. "Updates" is taken to mean corrections, and we're not really correcting it - it's perfectly fine. > but in any event, this is a decision for the WG > or the chairs, not for us. I don't think that it's the chairs who decide these things, though I would certainly respect their views on this. Ultimately, it's a community-consensus thing. From nobody Mon Aug 7 22:10: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 07648126DD9 for ; Mon, 7 Aug 2017 22:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC4X4KBxQFAZ for ; Mon, 7 Aug 2017 22:10:38 -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 0F72012420B for ; Mon, 7 Aug 2017 22:10:37 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C9BD1C4005E for ; Tue, 8 Aug 2017 00:10:35 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1502169035; bh=nnCatxa4xGfA4GPL3pa7XcuBSGZ0gzkxgyeUoeVFxPY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IJHfB2yVRiiwFy2TnrRjk5ZrrJzuQ2Cy6oFsn8qZxcX25j1E6G2q2qsH96dtw0/Qm uy4VrsBIrX8yqfBoANKYQYv3+VRSrZOAVQ0++d04muMBuIMIANYCOPbGMNEJ46kxxk sY8ATf/eJumLzLMtR/T9ew8+xusRu0HfCvOgANb4= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 08 Aug 2017 01:10:30 -0400 Message-ID: <2658203.QR0WuVOzkS@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04 X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 05:10:40 -0000 On Tuesday, August 08, 2017 02:46:22 PM Martin Thomson wrote: > On 8 August 2017 at 01:51, John R Levine wrote: > > On Mon, 7 Aug 2017, Martin Thomson wrote: > >> I don't believe that adding a signature algorithm means that you need > >> to update 6376. > > > > Well, OK, but where does all the new ABNF go? > > In your draft? > > It's not like you can't define new values, but it's also the case that > you don't have to. The already-defined extension point covers all > valid values. > > > Our plan here is that once this is published, people implement 6376 plus > > this draft plus (or perhaps minus) Scott's anti-SHA1, which tells me that > > these have to update 6376, > > Yes, that's possible without updating 6376. One problem I've > encountered is that 6376 plus its updates and 6376 plus some other RFC > are materially different to some people. "Updates" is taken to mean > corrections, and we're not really correcting it - it's perfectly fine. I've never heard that interpretation. I've seen updates used in the way we are discussing lots of times. See RFC 7208 and RFC 7372 for a reasonably on the nose example. Scott K P.S. Any document that considers 512 bit RSA keys OK, is not 'perfectly fine' in 2017. > > but in any event, this is a decision for the WG > > or the chairs, not for us. > > I don't think that it's the chairs who decide these things, though I > would certainly respect their views on this. Ultimately, it's a > community-consensus thing. > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Sat Aug 12 14:58: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 3E87E132359 for ; Sat, 12 Aug 2017 14:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xh3T7mW8YsH for ; Sat, 12 Aug 2017 14:58:34 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 8A5801321BF for ; Sat, 12 Aug 2017 14:58:34 -0700 (PDT) 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 v7CLvGOs014997; Sat, 12 Aug 2017 22:58:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=CXNHAscTUK60LxQRWCCkimlaV6Lp74F2GYH0TN45aKQ=; b=fNVXJ98NyxzWP+Kfiuwi63WuLBTiRKQCG/cQTaZkkwfYcwfefPBmyWvuDeAs48szQ4pk ksnzUZy04mvnCv5dxOTMSX3nzPvMRFW+Ac0zQcM17gJh5+tj3f1xpZoGpmTcRiZ16q+R jAOhXX9PBA85s2S2tn18lc9sTp2mcydrQvUtIB1HvLmRxoKffx3Jm8q0j4qcBysUeXR5 JTptVtyJvqtRgEWl5o/2uLnH6RfCvqd3ddyK0agVuUzKXU15Gcp4QiFO3fy5D+MdAgS3 7LCSdshXGZND78wokx6aW2579iTtl/XrqX3NFHFV1Qzdc1a082atdSCCsgH+06OSfyTN LA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2c9rx1sp3d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Aug 2017 22:58:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7CLuIPl030181; Sat, 12 Aug 2017 17:58:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c9w0uhqh3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 12 Aug 2017 17:58:31 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 12 Aug 2017 17:58:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sat, 12 Aug 2017 17:58:30 -0400 From: "Salz, Rich" To: "dcrup@ietf.org" CC: "seth@sethblank.com" Thread-Topic: IETF WG state changed for draft-ietf-dcrup-dkim-usage Thread-Index: AQHTE7W45khdOvlgD06q7xzF/04M/aKBRNgA Date: Sat, 12 Aug 2017 21:58:30 +0000 Message-ID: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> In-Reply-To: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.222] Content-Type: text/plain; charset="utf-8" Content-ID: <2B246E0345515E4E8D27B72DAB255299@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708120360 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-12_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708120360 Archived-At: Subject: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 21:58:36 -0000 QXQgdGhlIElFVEYgbWVldGluZyBsYXN0IG1vbnRoIHRoZXJlIHdhcyBzdHJvbmcgY29uc2Vuc3Vz IHRvIGhhdmUgTVVTVCBOT1QgZm9yIGJvdGggZ2VuZXJhdGUgYW5kIHZlcmlmeSB1c2luZyBTSEEt MS4gIFRoZSBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0IGhhZCBvbmUgbWFqb3IgcGFydGljaXBhbnQg b3Bwb3NlZCwgd2hvIHJlbW92ZWQgdGhlaXIgb2JqZWN0aW9uIG9uY2UgdGhleSB1bmRlcnN0b29k IHRoZXJlIHdlcmUgdHdvIHNlcGFyYXRlIGRvY3VtZW50cy4NCg0KVGhlcmVmb3JlLCB3ZSBhcmUg ZW50ZXJpbmcgYSBvbmUtd2VlayBXRyBsYXN0IGNhbGwuDQoNCihTZXRoLCBwbGVhc2Ugc3RhcnQg cHJlcGFyaW5nIHlvdXIgc2hlcGhlcmQgd3JpdGV1cCA6KQ0KDQoNCk9uIDgvMTIvMTcsIDU6NTUg UE0sICJJRVRGIFNlY3JldGFyaWF0IiA8aWV0Zi1zZWNyZXRhcmlhdC1yZXBseUBpZXRmLm9yZz4g d3JvdGU6DQoNCiAgICANCiAgICBUaGUgSUVURiBXRyBzdGF0ZSBvZiBkcmFmdC1pZXRmLWRjcnVw LWRraW0tdXNhZ2UgaGFzIGJlZW4gY2hhbmdlZCB0byAiSW4gV0cNCiAgICBMYXN0IENhbGwiIGZy b20gIldHIERvY3VtZW50IiBieSBSaWNoIFNhbHo6DQogICAgDQogICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kY3J1cC1ka2ltLXVzYWdlLw0KICAgIA0KICAg IA0KDQo= From nobody Sun Aug 13 11:34: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 46903132783 for ; Sun, 13 Aug 2017 11:34:24 -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 FcEIhb_JPdic for ; Sun, 13 Aug 2017 11:34:22 -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 5E94F1324B5 for ; Sun, 13 Aug 2017 11:34:22 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id t37so42449745qtg.5 for ; Sun, 13 Aug 2017 11:34:22 -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; bh=rEPFAmbfE3XDWqmivSNcJ1QnWJariW2wl13Wx3fGhX4=; b=Om7iWQ1c6J9lg/MC607qwFas8aZ3fZhyWWPYHmdyP+4qYhmmzMsZV/KMnO/kKINnTh OWZ+Jwncwj7cPdyQxVB+ujc2RE9VJacYKU0kg9pkll98jV1lkl7HjNv0vJ9bbBUKNyGP XeVOKio6x4t5Q3sQqpKISAwrSDwICtT7gmwfOx/n/G6Dh5xtNw2J4dTIJGSE5QAYK1t4 BbVU6i0Y6nNCNYRNLAupJ/fZB9PJPWy81VredQIHFVK8YaWBbwgAuR5kE1MF5UGUK20O FrIwu9O4sbfH9OpUvzuQLBGDD3UeABh/8IT+mDGxIYGtm9PnX7tpCdsMflJXKYPgBC99 4qag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rEPFAmbfE3XDWqmivSNcJ1QnWJariW2wl13Wx3fGhX4=; b=tEadC/FruzJnltCknBYI+3TVqtBTi1/1AEzEmxNA6x9PXxlMZ++px1HJds0Gju1mUa szoDPC3hLW/yVGRIIOba3Ef0U+nsquy52rS/uQijLafz8b8w61vBHdPTjH12v0BPP0ve 6i1h8T6t5PYwdxw3MLQA6++12JNthjyQw5A6Fp+7foxxWAU2tcC79tF3oF99Qmky9y0g 0BdBzKt2iGs7GL6HUs0xKpAVuRVozOztAH0aSMZBu5K9UbXQSlg7EeUEICldeCDjgDnb xsTya8Okv2GkcHj2yvz60HEG/IsrjbsNZLi1TQPAiFQD7rf3Nq4pL3B7+1s7Amb4o6+A OkdQ== X-Gm-Message-State: AHYfb5hffAaKoDXuee4fbLD4Lgx1NeUYqrxl8MRYc9QViehh/hIz9UO2 nY84G1GHK0csbehWmIIjlAvqlc65HsaX X-Received: by 10.200.14.72 with SMTP id j8mr30182781qti.124.1502649261157; Sun, 13 Aug 2017 11:34:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Sun, 13 Aug 2017 11:34:20 -0700 (PDT) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> From: "Murray S. Kucherawy" Date: Sun, 13 Aug 2017 11:34:20 -0700 Message-ID: To: dcrup@ietf.org Content-Type: multipart/alternative; boundary="089e08225dac6ef0720556a6cb72" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 18:34:24 -0000 --089e08225dac6ef0720556a6cb72 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 12, 2017 at 2:58 PM, Salz, Rich wrote: > At the IETF meeting last month there was strong consensus to have MUST NOT > for both generate and verify using SHA-1. The discussion on the list had > one major participant opposed, who removed their objection once they > understood there were two separate documents. > > Therefore, we are entering a one-week WG last call. > > (Seth, please start preparing your shepherd writeup :) > Getting caught up after a long post-Prague vacation and recovery period. The content and intent seem fine to me. However, I was asked this after the meeting in Prague as to form, in the spirit of "it's not done until you can no longer remove things" or however that aphorism goes: This document will be shown as "updates RFC6376". Is replacing text in RFC6376 the right way to do this? Or would that not be better left to an actual replacement document? That is, why not just say "MUST NOT sign/verify with rsa-sha1", change the state of "sha1" to obsolete, change the minimum key size to 1024, and stop? In particular, is it necessary to render "a=rsa-sha1" syntactically invalid by removing it from the ABNFs, or replace all of a section when only a couple of numbers are being tweaked? Otherwise this seems ready to go. -MSK, participating --089e08225dac6ef0720556a6cb72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 12, 2017 at 2:58 PM, Salz, Rich <rsalz@akamai.= com> wrote:
At the IETF meeting last month there= was strong consensus to have MUST NOT for both generate and verify using S= HA-1.=C2=A0 The discussion on the list had one major participant opposed, w= ho removed their objection once they understood there were two separate doc= uments.

Therefore, we are entering a one-week WG last call.

(Seth, please start preparing your shepherd writeup :)

Getting caught up after a long post-Prague vacation and rec= overy period.

The content and intent seem fine to me.=C2= =A0 However, I was asked this after the meeting in Prague as to form, in th= e spirit of "it's not done until you can no longer remove things&q= uot; or however that aphorism goes:

This document will be shown as &= quot;updates RFC6376".=C2=A0 Is replacing text in RFC6376 the right wa= y to do this?=C2=A0 Or would that not be better left to an actual replaceme= nt document?=C2=A0 That is, why not just say "MUST NOT sign/verify wit= h rsa-sha1", change the state of "sha1" to obsolete, change = the minimum key size to 1024, and stop?=C2=A0 In particular, is it necessar= y to render "a=3Drsa-sha1" syntactically invalid by removing it f= rom the ABNFs, or replace all of a section when only a couple of numbers ar= e being tweaked?

Otherwise this seems ready to go.
-MSK, participating
--089e08225dac6ef0720556a6cb72-- From nobody Sun Aug 13 14:21:00 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACBE132B83 for ; Sun, 13 Aug 2017 14:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJZr9mCogJMx for ; Sun, 13 Aug 2017 14:20:56 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D74132938 for ; Sun, 13 Aug 2017 14:20:56 -0700 (PDT) Received: (qmail 32410 invoked from network); 13 Aug 2017 21:20:54 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Aug 2017 21:20:54 -0000 Date: 13 Aug 2017 21:20:32 -0000 Message-ID: <20170813212032.39626.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] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 21:20:58 -0000 In article you write: >This document will be shown as "updates RFC6376". Is replacing text in >RFC6376 the right way to do this? Or would that not be better left to an >actual replacement document? That is, why not just say "MUST NOT >sign/verify with rsa-sha1", change the state of "sha1" to obsolete, change >the minimum key size to 1024, and stop? Having finally reread the draft, I agree, don't update the syntax. It's fine if a verifier syntactically recognizes rsa-sha1 so long it doesn't consider the signature to be valid. Perhaps it could provoke an SMTP response like 554 5.7.20 Fix your signatures if you want people to accept your mail. Also, I think the status for dead codes is "historic" rather than "obsolete" but that's up to IANA to make it consistent with other registries. R's, John From nobody Sun Aug 13 14:26: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 0974E1320C9 for ; Sun, 13 Aug 2017 14:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 DNKux5h3Jvlv for ; Sun, 13 Aug 2017 14:25:58 -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 C9765132E01 for ; Sun, 13 Aug 2017 14:25:58 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A5D83C4031D for ; Sun, 13 Aug 2017 16:25:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1502659556; bh=uAla9CTf31Yr7lWs1TpgGGmCN2qCPgfRttn4q47B/AE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=huD9iX0/tkByorPGZ0efH7RjtL95jnBY+CWz7QTQXy7SzRfwK+5ZlKih/loRZnhpF EFXhckY0WLmBJrbNN/MngkVizSrtWE94F3yvpu0ErGmV7crpyH/ueFOzY+kfkAqSG+ 7M1IzE2FDV1AYEjWJbmC8J0YP3LjbXq3NA2GpFDw= From: Scott Kitterman To: dcrup@ietf.org Date: Sun, 13 Aug 2017 17:25:50 -0400 Message-ID: <36659107.dMb7D4c16s@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 21:26:01 -0000 On Sunday, August 13, 2017 11:34:20 AM Murray S. Kucherawy wrote: > On Sat, Aug 12, 2017 at 2:58 PM, Salz, Rich wrote: > > At the IETF meeting last month there was strong consensus to have MUST NOT > > for both generate and verify using SHA-1. The discussion on the list had > > one major participant opposed, who removed their objection once they > > understood there were two separate documents. > > > > Therefore, we are entering a one-week WG last call. > > > > (Seth, please start preparing your shepherd writeup :) > > Getting caught up after a long post-Prague vacation and recovery period. > > The content and intent seem fine to me. However, I was asked this after > the meeting in Prague as to form, in the spirit of "it's not done until you > can no longer remove things" or however that aphorism goes: > > This document will be shown as "updates RFC6376". Is replacing text in > RFC6376 the right way to do this? Or would that not be better left to an > actual replacement document? That is, why not just say "MUST NOT > sign/verify with rsa-sha1", change the state of "sha1" to obsolete, change > the minimum key size to 1024, and stop? In particular, is it necessary to > render "a=rsa-sha1" syntactically invalid by removing it from the ABNFs, or > replace all of a section when only a couple of numbers are being tweaked? > > Otherwise this seems ready to go. The draft has been this way from the beginning, so I find it a bit surprising to see this in last call when you've reviewed this more than once before, but oh well. I updated the ABNF in the draft because I think if we are going to kill it, we should kill it absolutely dead. What is the benefit of retaining obsolete features that are MUST NOT use in the ABNF? In terms of the structure of the draft, I wrote it this was so it's very clear what is being updated. This has been discussed a bit, but I don't think anyone really objected so far. I find it's common in IETF documents to see one document updates another, but then it's hard to really tell everything in the original document that's affected by the update. This is an attempt to be clear about that. That's why, but I may be the only one that feels that way. Scott K From nobody Sun Aug 13 15:35: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 D8F6913351B for ; Sun, 13 Aug 2017 15:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkpZWdjom4qe for ; Sun, 13 Aug 2017 15:35:54 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 476B3133519 for ; Sun, 13 Aug 2017 15:35:54 -0700 (PDT) Received: (qmail 40031 invoked from network); 13 Aug 2017 22:35:52 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 13 Aug 2017 22:35:52 -0000 Date: 13 Aug 2017 22:35:30 -0000 Message-ID: <20170813223530.39855.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <36659107.dMb7D4c16s@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] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 22:35:56 -0000 In article <36659107.dMb7D4c16s@kitterma-e6430> you write: >I updated the ABNF in the draft because I think if we are going to kill it, we >should kill it absolutely dead. What is the benefit of retaining obsolete >features that are MUST NOT use in the ABNF? Recognize them and ridicule people who are still using them? On a slightly more pragmatic note, leaving them in the ABNF makes it less likely that someone later will add something that conflicts. I realize that the chances of adding something else named sha1 are pretty low, but who knows what strangeness may happen a decade from now. R's, John From nobody Sun Aug 13 18:18:17 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95AD4134403 for ; Sun, 13 Aug 2017 18:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 SNWDmkSdFash for ; Sun, 13 Aug 2017 18:18:14 -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 DDD40134401 for ; Sun, 13 Aug 2017 18:18:13 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id a77so43674063qkb.0 for ; Sun, 13 Aug 2017 18:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Gi41oL6R3yfDjkKlf35DpQ6UV0DGAjSsR/hbdTgVqc=; b=a3seZnfsAHnk2YnArRfssJ8m45+bbODX12Ye+xP/XZ3oyL1FI8FIn6f00/P5zNh/Rp lSo5FwX37k6HfJgCw0twO5SDNjBUosmr4Q8p4wr6rpqFZmzrfD8ibio5xIw8MIFZP3Zy CMvTyH8nKDZ404dAhVTNg3r00l835QGgxtXP6j+/ByV+F093eNbVRvdZYIzy8Bf7hYee nPG2a/wveLaVq91YHanp65eBKAkiyDZb+CNS7Oyr5B03oxH/GTGpvXfb1zL03vfZ7iUV Ie+UWHgOBnBSubb9hpeo5pooYF6ebTiIOQOhasdTGLHasOSDWuxgWUlsLDYo95Luo+I9 eA1Q== 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=5Gi41oL6R3yfDjkKlf35DpQ6UV0DGAjSsR/hbdTgVqc=; b=fR5BNSs3ZkH//hn4+qEp/+rHHEYjIo4qutD+wha2NhqVI0YNY4MIs/52ZB34tsKDTs A8pLgCf/Yqjq7SiypvER2cGNOx29PLgPZyPhAeWnTnDnetpgQDlvmVflBZwFZyCqCCgS mQ3f2X91Cl2rkcWLoxVXYJopiXnkVnjluEjJyKLvLNV7iLwtqj1IvhBo+xVqq3UeEgze hVD79p6InYzP4DTSnsl1MssDRF2chvtiICayCqlnti+gkreGp9ibn6TtAJscoB/kR5AA 37yixLv8RATypTs91MfSPwy+4ESWYwViJBLhWbSKhz4d+6uYf4ET2IapW9BXo2jHIOAj xAAQ== X-Gm-Message-State: AHYfb5gbW9Pa3nF0XWmzBt1KnHVZHbz+Yq+o2d6ETDbpo/OnSVPnHXrp uQL3bqXFSGh8UBeGqzNz2mDqkbyCJAur X-Received: by 10.55.73.135 with SMTP id w129mr29554645qka.249.1502673493004; Sun, 13 Aug 2017 18:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Sun, 13 Aug 2017 18:18:12 -0700 (PDT) In-Reply-To: <36659107.dMb7D4c16s@kitterma-e6430> References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> <36659107.dMb7D4c16s@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sun, 13 Aug 2017 18:18:12 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114a8562c397080556ac6fde" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 01:18:15 -0000 --001a114a8562c397080556ac6fde Content-Type: text/plain; charset="UTF-8" On Sun, Aug 13, 2017 at 2:25 PM, Scott Kitterman wrote: > The draft has been this way from the beginning, so I find it a bit > surprising > to see this in last call when you've reviewed this more than once before, > but > oh well. > I don't see why that's relevant, but OK: The suggestion was made to me in person after the meeting in Prague, and the more I think about it, the more I think it's worth the WG's consideration. > I updated the ABNF in the draft because I think if we are going to kill > it, we > should kill it absolutely dead. What is the benefit of retaining obsolete > features that are MUST NOT use in the ABNF? > I think the intent is to reject those signatures as no longer acceptable, not render them syntactically invalid. In terms of the structure of the draft, I wrote it this was so it's very > clear > what is being updated. This has been discussed a bit, but I don't think > anyone really objected so far. I find it's common in IETF documents to see > one document updates another, but then it's hard to really tell everything > in > the original document that's affected by the update. This is an attempt > to be > clear about that. > You could do it either way, I suppose, but as I understand "updates" it places an annotation on RFC6376 indicating that one really needs to read this document after that one to fully read the state-of-the-art. If that's correct, then expressing a delta to the original spec is adequate to achieve the goal rather than including an entire section of text with only a few numbers adjusted. Put simply, you can do either, but the more verbose approach seems like overkill. -MSK --001a114a8562c397080556ac6fde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 13, 2017 at 2:25 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
The draft has been this= way from the beginning, so I find it a bit surprising
to see this in last call when you've reviewed this more than once befor= e, but
oh well.

I don't see why that's= relevant, but OK:

The suggestion was made to me in person after the= meeting in Prague, and the more I think about it, the more I think it'= s worth the WG's consideration.
=C2=A0
I updated the ABNF in the draft because I think if we are going to kill it,= we
should kill it absolutely dead.=C2=A0 What is the benefit of retaining obso= lete
features that are MUST NOT use in the ABNF?

=
I think the intent is to reject those signatures as no longer acceptab= le, not render them syntactically invalid.

In terms of the structure of the draft, I wrote it this was so it's ver= y clear
what is being updated.=C2=A0 This has been discussed a bit, but I don't= think
anyone really objected so far.=C2=A0 I find it's common in IETF documen= ts to see
one document updates another, but then it's hard to really tell everyth= ing in
the original document that's affected by the update.=C2=A0 This is an a= ttempt to be
clear about that.

You could do it eithe= r way, I suppose, but as I understand "updates" it places an anno= tation on RFC6376 indicating that one really needs to read this document af= ter that one to fully read the state-of-the-art.=C2=A0 If that's correc= t, then expressing a delta to the original spec is adequate to achieve the = goal rather than including an entire section of text with only a few number= s adjusted.

Put simply, you can do either, but the more v= erbose approach seems like overkill.

-MSK
=
--001a114a8562c397080556ac6fde-- From nobody Sun Aug 13 18:19:53 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7413441B for ; Sun, 13 Aug 2017 18:19:51 -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 2QKik4BP9Oh0 for ; Sun, 13 Aug 2017 18:19:50 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117AC1330CF for ; Sun, 13 Aug 2017 18:19:50 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id u139so43609433qka.1 for ; Sun, 13 Aug 2017 18:19:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sp1R8nzIq4mrwVI31fx+/w9NLvVD0OdkOK7SviiT+ro=; b=KwZhQmxekWM2e8eb94rrFfXjsrrC8nshmkXjepIjdomh1de+6LggeicwTGzZ8dA2Nz +99g9mZVeCjYUO3T9iQ7C+NKLaiSX8+xexpq9BvACsd2o5zp+aQ1VQJtsN7Lw5ompqwk c5jtDazuBx/3HCGwzZTra/+UM9R2IdwXcamg92z4xZd83d8g3UKIizUVYAkXI0KZprQ9 aAxZPLIewjGs41yJZLWQCg5un2gWhXAZb4OCQbr+fFKbPFs3Kq2xzJ00xOv/GsARsO7l xrr/H9zIPAW9LeWk0cKvqW4CIAWOloUBQKTncGMpChXtaAKQmbk1JxbIoS5s2lJKI1VK ZX2g== 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=sp1R8nzIq4mrwVI31fx+/w9NLvVD0OdkOK7SviiT+ro=; b=Sqk8hoznPCGy24eu8CTOaZaDFIC7tY3gtXWQ3wz2tFGzPPE2i3CRA/NwjfN0aO2TOQ 5iiL0VNaZyO4T8U47i6qZH01PEHW9XznI87xs7xgF7VyjkM3l6m2AQOfF/LM63LvRihZ ECrw5mDtOE8urDhOexE6ubuEed20niNPh4c0caoYvK2TbwWDa+VnJM0jgDiIT/j3mSpX 08n0i4bplM09dBADAJd1WQ0Tq3XmLmOsE5j1H3eXzAi0YHMZ3tyqiHRPhFq8qNSiMd3d mqnT5Bkll7LVXjnRXRyO6L/gO8tpa6mdHD4iomQas5bDArHYCJk7sMrgd9Cy3RO1wlPi +0UQ== X-Gm-Message-State: AHYfb5iWKN62YxZy3a/79jqwZZotD3jZRjmBxNPMB4cJThLR4JPkeEFe zMNxngLawxpJsIV2B205VWSRqDD9ILDj X-Received: by 10.55.66.84 with SMTP id p81mr27136331qka.243.1502673589144; Sun, 13 Aug 2017 18:19:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Sun, 13 Aug 2017 18:19:48 -0700 (PDT) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> <36659107.dMb7D4c16s@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sun, 13 Aug 2017 18:19:48 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114abe307e91570556ac7537" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 01:19:52 -0000 --001a114abe307e91570556ac7537 Content-Type: text/plain; charset="UTF-8" On Sun, Aug 13, 2017 at 6:18 PM, Murray S. Kucherawy wrote: > > >> I updated the ABNF in the draft because I think if we are going to kill >> it, we >> should kill it absolutely dead. What is the benefit of retaining obsolete >> features that are MUST NOT use in the ABNF? >> > > I think the intent is to reject those signatures as no longer acceptable, > not render them syntactically invalid. > Another way to look at this: I think it's more appropriate to render rsa-sha1 obsolete, but this approach seems as if we want to act like it never existed. -MSK --001a114abe307e91570556ac7537 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Aug 13, 2017 at 6:18 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
=C2=A0
I updated the ABNF in the draft because I think if we are going to kill it,= we
should kill it absolutely dead.=C2=A0 What is the benefit of retaining obso= lete
features that are MUST NOT use in the ABNF?

=
I think the intent is to reject those signatures as no longer a= cceptable, not render them syntactically invalid.

Another way to look at this: I think it's = more appropriate to render rsa-sha1 obsolete, but this approach seems as if= we want to act like it never existed.

-MSK
--001a114abe307e91570556ac7537-- From nobody Sun Aug 13 19:37: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 2A54A12009C for ; Sun, 13 Aug 2017 19:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdX9QWYUqcY0 for ; Sun, 13 Aug 2017 19:37:14 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9CE1200F3 for ; Sun, 13 Aug 2017 19:37:14 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id 77so15875345itj.1 for ; Sun, 13 Aug 2017 19:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u9NvrRkLgHMHg62CNeAkO5QdcTK/q1NLqdT5+/Rwvlg=; b=uP1S4V+XY1tRx6z/GcB82/pluhWtbYmzc08mwOuNIlaoo17j4daCbhpOXVu0Jczwoi F8AgPM2kD9f3+Ud7E1ZIUDf099eAbb9ZGHNOKFpcXpJ655us7Bhmz9hfPOqMvD1G7erb a2FSpDPC1Vlp/UCW2MGOClEQdnRyKC4wK3MoasxxqNyIky8X9ZuqlRAk+2isWq2TO6fi CsZYme7q0oSQs15ELyoCpDDd2YkGxpOv7N80CafEKsuMedGDhuzkSh1aS0mnZJFc4lhu t7XA5Ff5KQgBbd2iA8ZwhzYJYVjri3EG2Cbt8+OTa1OOt6Tw+pfUrbYbwHhAITJzZRyX jKVQ== 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=u9NvrRkLgHMHg62CNeAkO5QdcTK/q1NLqdT5+/Rwvlg=; b=qMNMqEY+zO84nrXS9XlvmuuHZwUOqPFTqJXQ683Sqz7rLwU29uNHuzqdwPvq4UVFSR VIM+U86TAJkWlnDxhbf22XY/p8CbKoEdlf12aVzR8UyhORTBRN5gXWiXc69m+2DhioM5 scIF1g7zP0r48deaVDXYd+P7xwWd6KyO4CpHZ4aDMKOkEIrxLIQpnLomoxWeX6CWS9+u Opv3Zdy63cjrj6HrXivU2fRLNdiIf4QSsliR/l2qe818XkihKCfH7/pDkRuBMzbb/Qdg noPaEyak/xQuuRRpGM2SIRfdIakZjwcpzCgza/hZENU4Ptr1v9kc19JSC4XLp1bW1MVy 6vgg== X-Gm-Message-State: AHYfb5gJ8FOQhxVossQwyRm3uBXmw7GufmFrGGmDDaws9QDmYLNOznub wQNVHTjk+mZJ27Gn5wGriN9autJczw== X-Received: by 10.36.193.199 with SMTP id e190mr4875095itg.122.1502678234137; Sun, 13 Aug 2017 19:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sun, 13 Aug 2017 19:37:13 -0700 (PDT) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> <36659107.dMb7D4c16s@kitterma-e6430> From: Martin Thomson Date: Mon, 14 Aug 2017 12:37:13 +1000 Message-ID: To: "Murray S. Kucherawy" Cc: Scott Kitterman , dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 02:37:17 -0000 One problem I have with the current text is that it buries the lede. It doesn't outright say what it is doing (worse because I tried to skip the parenthetical in the paragraph that says this and it never closes. Then you have to sift through pages of RFC 6376 that are largely unchanged. It's a simple statement. The document to make that statement should easily fit on one page (plus one for header boilerplate, plus one for references and back matter). On 14 August 2017 at 11:19, Murray S. Kucherawy wrote: > On Sun, Aug 13, 2017 at 6:18 PM, Murray S. Kucherawy > wrote: >> >> >>> >>> I updated the ABNF in the draft because I think if we are going to kill >>> it, we >>> should kill it absolutely dead. What is the benefit of retaining >>> obsolete >>> features that are MUST NOT use in the ABNF? >> >> >> I think the intent is to reject those signatures as no longer acceptable, >> not render them syntactically invalid. > > > Another way to look at this: I think it's more appropriate to render > rsa-sha1 obsolete, but this approach seems as if we want to act like it > never existed. > > -MSK > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > From nobody Mon Aug 14 15:14:08 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1755132431 for ; Mon, 14 Aug 2017 15:14:06 -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 b-CSVO3tzLs7 for ; Mon, 14 Aug 2017 15:14:05 -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 EB80F132442 for ; Mon, 14 Aug 2017 15:14:04 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A6141C4031D for ; Mon, 14 Aug 2017 17:14:01 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1502748841; bh=NsAzBzUmAVYa3C29J8U4b2rFh70zDzKjfelYnHuyxz8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kei2LkDJ0FoqjykHtogC2vlpfHL5oApoginDNnJO+Jy3XFCCI56dIa7UYQgOAaP7x J2wRJxJCS2Vxm029OfEtEdlKqc4MU0TxB9DSJlA1neEALCapKJfPFzV0f5X1Z5W7/K Mk+E3l2aLo2uWITzK95uiWLoe17pAYKygdmmY5Nw= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 14 Aug 2017 18:14:01 -0400 Message-ID: <8695284.qrNCWkNy01@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 22:14:07 -0000 On Sunday, August 13, 2017 06:19:48 PM Murray S. Kucherawy wrote: > On Sun, Aug 13, 2017 at 6:18 PM, Murray S. Kucherawy > > wrote: > >> I updated the ABNF in the draft because I think if we are going to kill > >> it, we > >> should kill it absolutely dead. What is the benefit of retaining > >> obsolete > >> features that are MUST NOT use in the ABNF? > > > > I think the intent is to reject those signatures as no longer acceptable, > > not render them syntactically invalid. > > Another way to look at this: I think it's more appropriate to render > rsa-sha1 obsolete, but this approach seems as if we want to act like it > never existed. Fast forward a few years: Is the fact that it ever existed relevant to anything? I think it's highly unlikely. Since RFCs are forever, it'll never be like it never existed (people can always read old RFCs if they care), it'll just be like it's irrelevant to the current protocol definition. I think that's appropriate. Scott K From nobody Mon Aug 14 19:38: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 A06421324AE for ; Mon, 14 Aug 2017 19:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTYZ8CF-Iopb for ; Mon, 14 Aug 2017 19:37:58 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D001324A1 for ; Mon, 14 Aug 2017 19:37:57 -0700 (PDT) Received: (qmail 82855 invoked from network); 15 Aug 2017 02:37:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 15 Aug 2017 02:37:56 -0000 Date: 15 Aug 2017 01:33:33 -0000 Message-ID: <20170815013333.1308.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <8695284.qrNCWkNy01@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] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 02:37:59 -0000 In article <8695284.qrNCWkNy01@kitterma-e6430> you write: >> Another way to look at this: I think it's more appropriate to render >> rsa-sha1 obsolete, but this approach seems as if we want to act like it >> never existed. > >Fast forward a few years: Is the fact that it ever existed relevant to >anything? I think it's highly unlikely. The Internet being the Internet, sha-1 hashes will trickle in forever. I'd rather have the diagnostic say "obsolete hash" than "syntax error." If you look at this curdle draft that deprecates RC4, it goes through and makes changes to turn OPTIONAL to MUST NOT and the like, but it doesn't try to undefine the obsolete rc4 crypto modes. I think you'll find that typical in crypto updates. https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ R's, John From nobody Mon Aug 14 20:26:43 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927351323CA for ; Mon, 14 Aug 2017 20:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KpurBcrEiwg5 for ; Mon, 14 Aug 2017 20:26:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9922C13202D for ; Mon, 14 Aug 2017 20:26:40 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AB500C4031D for ; Mon, 14 Aug 2017 22:26:39 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1502767599; bh=kNWWbcIbsw6Bzxrty6zsruuVVJ58pXd9olFLsdib2VM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Uz50mXCxWAJueFZxYm1WwaqoUMk9Kh3qLo6QHbUq4ddLZTldGrgRd933Xwl8oHutV t/JQMaiK0gUyTr4rGkmTu8AJFYkhUMQddAfpj4YcZu8oCTqSWswTEK1CkZ/tnLw6Ne koh7AG/i5bQivzJVuXlNK1yJ4MyNjgWl3yKOWZ98= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 14 Aug 2017 23:26:38 -0400 Message-ID: <1619558.erSAfqAhe6@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20170815013333.1308.qmail@ary.lan> References: <20170815013333.1308.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 03:26:43 -0000 On Tuesday, August 15, 2017 01:33:33 AM John Levine wrote: > In article <8695284.qrNCWkNy01@kitterma-e6430> you write: > >> Another way to look at this: I think it's more appropriate to render > >> rsa-sha1 obsolete, but this approach seems as if we want to act like it > >> never existed. > > > >Fast forward a few years: Is the fact that it ever existed relevant to > >anything? I think it's highly unlikely. > > The Internet being the Internet, sha-1 hashes will trickle in forever. > I'd rather have the diagnostic say "obsolete hash" than "syntax > error." > > If you look at this curdle draft that deprecates RC4, it goes through > and makes changes to turn OPTIONAL to MUST NOT and the like, but it > doesn't try to undefine the obsolete rc4 crypto modes. I think you'll > find that typical in crypto updates. > > > https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ OK. It seems odd to me, but if that's the IETF norm, no problem. Scott K From nobody Wed Aug 16 11:06: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 D3A2F13267B for ; Wed, 16 Aug 2017 11:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=XJUxNgug; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=lPt62wdz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8z6IJVVnzu8I for ; Wed, 16 Aug 2017 11:05:48 -0700 (PDT) Received: from ftp.catinthebox.net (listserv.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB9113239A for ; Wed, 16 Aug 2017 11:05:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1700; t=1502906746; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=KWhL563b6nkKaBbA/fXkz8+6gLI=; b=XJUxNgug5CVAXc6m4GFZnuts19R/ih70PkjE9gxmG6rtdz8IS7FmhOEXFGZcc+ Cs6q3NYbYQu4bX3GT8M/8DIYJCBJ8T5f3W4wfYriDt8K6fkh0C+rh2C+BODXT/ey gboZ3IuiBql2M+2Rq7C5s+K1I5Tj/ObPcNaEDuXPot+Ug= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Wed, 16 Aug 2017 14:05:46 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 2970602199.1.4532; Wed, 16 Aug 2017 14:05:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1700; t=1502906708; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tCMv3yd mFn51YkWaPzXzM7cTb9hp1N9A85Nwjzwpj1g=; b=lPt62wdzPJuQu0EwQ8s4H3p DyQqtwQq2kbfR7wyRc2zRQCo8hW4hTUhaH8VivooFHyfJ6Q7qUJE8OCA6oNTJ7DK hb4kEihAIeEaVgLtNLNo0uGUqpvkkPdaJRVCta8Et5Z8r0HXdP1J+eBt+IGgO9pY c5TmSnbnS5H1UlgM6Oz8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Wed, 16 Aug 2017 14:05:08 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3513106237.9.479404; Wed, 16 Aug 2017 14:05:08 -0400 Message-ID: <5994897B.8080700@isdg.net> Date: Wed, 16 Aug 2017 14:05:47 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <20170815013333.1308.qmail@ary.lan> In-Reply-To: <20170815013333.1308.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 18:05:59 -0000 On 8/14/2017 9:33 PM, John Levine wrote: > In article <8695284.qrNCWkNy01@kitterma-e6430> you write: >>> Another way to look at this: I think it's more appropriate to render >>> rsa-sha1 obsolete, but this approach seems as if we want to act like it >>> never existed. >> >> Fast forward a few years: Is the fact that it ever existed relevant to >> anything? I think it's highly unlikely. > > The Internet being the Internet, sha-1 hashes will trickle in forever. > I'd rather have the diagnostic say "obsolete hash" than "syntax > error." > > If you look at this curdle draft that deprecates RC4, it goes through > and makes changes to turn OPTIONAL to MUST NOT and the like, but it > doesn't try to undefine the obsolete rc4 crypto modes. I think you'll > find that typical in crypto updates. +1. The odds are very good that it will continue to be a "will not sign, but will verify as needed" behavior for a very long time. And probably, local rules will apply on a site by site basis using other bits in the mail. I am not about to break communications with my existing customers or break communications for my installation base. My key concern here is that the IETF guidelines should not change history for future developers. It should help developers as it will be a big surprise when SHA1 mail is encountered and these new developers are not ready for it. The 20/20 hindsight question will be raised: "Why wasn't it documented that DKIM mail with SHA1 will exist and developers should be prepared to deal with it?" Having the IETF suggest that sha1 DKIM mail MUST|SHOULD be rejected with a 55z policy code, is probably not good advice -- IMO. -- HLS From nobody Sat Aug 19 12:46:42 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E406C1329DE for ; Sat, 19 Aug 2017 12:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kitterman.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnnYGlsLXOcY for ; Sat, 19 Aug 2017 12:46:37 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE771329DD for ; Sat, 19 Aug 2017 12:46:37 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E5AA7C40166 for ; Sat, 19 Aug 2017 14:46:35 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1503171996; bh=DwgBAY73lVL5XwitRLupNTEiwJfOTOVZzeNpZJnVkt0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kZlz0S8HzuhElSbXezgbA1b2+J/WoPmNxOnZzjrUu1ErwDwbclhEwIwrxWXKqepgN 4lrc9WthcD7kAXXp4kLusMnPD+UykGTXy8FZ/mN6BCGad6oNagD4z5VecY27Vda/rw dpXVH834oXYGAZ6/UcSivheW7zJaClb75mAO2nF0= From: Scott Kitterman To: dcrup@ietf.org Date: Sat, 19 Aug 2017 15:46:39 -0400 Message-ID: <1577948.qipkle3Fep@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart2413950.EA2yxVcUPJ" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 19:46:41 -0000 This is a multi-part message in MIME format. --nextPart2413950.EA2yxVcUPJ Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Saturday, August 12, 2017 09:58:30 PM Salz, Rich wrote: > At the IETF meeting last month there was strong consensus to have MUST NOT > for both generate and verify using SHA-1. The discussion on the list had > one major participant opposed, who removed their objection once they > understood there were two separate documents. > > Therefore, we are entering a one-week WG last call. > > (Seth, please start preparing your shepherd writeup :) > > > On 8/12/17, 5:55 PM, "IETF Secretariat" > wrote: > > > The IETF WG state of draft-ietf-dcrup-dkim-usage has been changed to "In > WG Last Call" from "WG Document" by Rich Salz: > > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ We're within a few hours of the week being up and the rate of additional commentary has fallen to nil, so I took a crack at updating based on the last call comments. I'm attaching an rfcdiff of what I would propose as a post-LC -04, but won't upload it until I get some direction. Scott K --nextPart2413950.EA2yxVcUPJ Content-Disposition: attachment; filename="draft-ietf-dcrup-dkim-usage-from--03.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-dcrup-dkim-usage-from--03.diff.html" Diff: draft-ietf-dcrup-dkim-usage-03.txt - draft-ietf-dcrup-dkim-usage.txt
 draft-ietf-dcrup-dkim-usage-03.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) July 31, 2017 Updates: 6376 (if approved) August 19, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: February 1, 2018 Expires: February 20, 2018
Cryptographic Algorithm and Key Usage Update to DKIM Cryptographic Algorithm and Key Usage Update to DKIM
draft-ietf-dcrup-dkim-usage-03 draft-ietf-dcrup-dkim-usage-04
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 February 1, 2018. This Internet-Draft will expire on February 20, 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. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4.3. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. The DKIM-Signature Header Field . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Key Management and Representation . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4
9.1. Normative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 6
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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.
2. Introduction 2. Introduction
skipping to change at page 3, line 8 skipping to change at page 2, line 50
[VULNOTE], the operational community has recognized that shorter keys [VULNOTE], the operational community has recognized that shorter keys
compromise the effectiveness of DKIM. While 1024 bit signatures are compromise the effectiveness of DKIM. While 1024 bit signatures are
common, stronger signatures are not. Widely used DNS configuration common, stronger signatures are not. Widely used DNS configuration
software places a practical limit on key sizes, because the software software places a practical limit on key sizes, because the software
only handles a single 256 octet string in a TXT record, and RSA keys only handles a single 256 octet string in a TXT record, and RSA keys
significantly longer than 1024 bits don't fit in 256 octets. significantly longer than 1024 bits don't fit in 256 octets.
Due to the recognized weakness of the sha1 hash algorithm, see Due to the recognized weakness of the sha1 hash algorithm, see
[RFC6194], and the wide availability of the sha256 hash algorithm (it [RFC6194], and the wide availability of the sha256 hash algorithm (it
has been a required part of DKIM [RFC6376] since it was originally has been a required part of DKIM [RFC6376] since it was originally
standardized in 2007, the sha1 hash algorithm is removed from the standardized in 2007, the sha1 hash algorithm MUST NOT be used. This
protocol. This is being done now to allow the operational community is being done now to allow the operational community time to fully
time to fully shift to sha256 in advance of any sha1 related crisis. shift to sha256 in advance of any sha1 related crisis.
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 replaces [RFC6376] Section 3.3 in its entirety. This section updates [RFC6376] Section 3.3.
Generally, DKIM supports multiple digital signature algorithms. One
algorithm, rsa-sha256, is currenlty defined. Signers MUST implement
and sign using rsa-sha256. Verifiers MUST implement and verify using
rsa-sha256.
4.1. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described DKIM supports multiple digital signature algorithms. Two algorithms
in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the are defined by this specification at this time: rsa-sha1 and rsa-
hash-alg. That hash is then signed by the Signer using the RSA sha256. Signers MUST sign using rsa-sha256. Verifiers MUST verify
algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg using rsa-sha256. rsa-sha1 MUST NOT be used for signing or
and the Signer's private key. The hash MUST NOT be truncated or verifying.
converted into any form other than the native binary form before
being signed. The signing algorithm SHOULD use a public exponent of
65537.
4.2. Key Sizes 4.1. Key Sizes
Selecting appropriate key sizes is a trade-off between cost, Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
all keys. Verifiers MUST be able to validate signatures with keys all keys. Signers SHOULD use RSA keys of at least 2048 bits.
ranging from 1024 bits to 4096 bits, and they MAY be able to validate Verifiers MUST be able to validate signatures with keys ranging from
signatures with larger keys. Verifier policies can use the length of 1024 bits to 4096 bits, and they MAY be able to validate signatures
the signing key as one metric for determining whether a signature is with larger keys. Verifier policies can use the length of the
signing key as one metric for determining whether a signature is
acceptable. acceptable.
Factors that should influence the key size choice include the 5. Security Considerations
following:
o The practical constraint that large (e.g., 4096-bit) keys might
not fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 2048 bits may be
subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email
o Keys can be replaced on a regular basis; thus, their lifetime can
be relatively short
o The security goals of DKIM [RFC6376] are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes.
4.3. Other Algorithms
The rsa-sha1 was formerly used by DKIM [RFC6376]. Signers MUST NOT
sign with rsa-sha1 and verifiers MUST NOT verify using rsa-sha1.
Other algorithms will be defined in the future. Verifiers MUST
ignore any signatures using algorithms that they do not implement.
5. The DKIM-Signature Header Field
This section updates the a= tag in [RFC6376] Section 3.5.
The text description of the tag is now:
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha256"; Signers MUST
sign using "rsa-sha256". See [RFC6376] Section 3.3 (as updated
by this document) for a description of the algorithms.
The following ABNF element is updated:
ABNF:
sig-a-tag-h = "sha256" / x-sig-a-tag-h
6. Key Management and Representation
This section updates the h= tag in [RFC6376] Section 3.6.1.
The following ABNF element is updated:
ABNF:
key-h-tag-alg = "sha256" / x-key-h-tag-alg
7. 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 the removal of rsa-sha1 from DKIM. resolved due to the removal of rsa-sha1 from DKIM.
8. 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
Algorithms" as follows: Algorithms" as follows:
+------+-----------------+----------+ +------+-----------------+----------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
+------+-----------------+----------+ +------+-----------------+----------+
| sha1 | (this document) | obsolete | | sha1 | (this document) | obsolete |
+------+-----------------+----------+ +------+-----------------+----------+
Table 1: DKIM Hash Algorithms Changed Value Table 1: DKIM Hash Algorithms Changed Value
9. References 7. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<http://www.rfc-editor.org/info/rfc3766>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <http://www.rfc-editor.org/info/rfc6376>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<http://www.rfc-editor.org/info/rfc8017>. <http://www.rfc-editor.org/info/rfc8017>.
9.2. Informative References 7.2. Informative References
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>. <http://www.rfc-editor.org/info/rfc6194>.
[VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys [VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys
Identified Mail (DKIM) Verifiers may inappropriately Identified Mail (DKIM) Verifiers may inappropriately
convey message trust", October 2012. convey message trust", October 2012.
9.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 his DCRUP work that was the source for much of
 End of changes. 17 change blocks. 
106 lines changed or deleted 34 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/
--nextPart2413950.EA2yxVcUPJ-- From nobody Sun Aug 20 10:47: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 9A34B13209C for ; Sun, 20 Aug 2017 10:47:34 -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 AXRU8rqUW14K for ; Sun, 20 Aug 2017 10:47:33 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68D41241FC for ; Sun, 20 Aug 2017 10:47:32 -0700 (PDT) Received: (qmail 6034 invoked from network); 20 Aug 2017 17:47:31 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Aug 2017 17:47:31 -0000 Date: 20 Aug 2017 17:47:09 -0000 Message-ID: <20170820174709.4697.qmail@ary.lan> From: "John Levine" To: dcrup@ietf.org Cc: sklist@kitterman.com In-Reply-To: <1577948.qipkle3Fep@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] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 17:47:35 -0000 In article <1577948.qipkle3Fep@kitterma-e6430> you write: >We're within a few hours of the week being up and the rate of additional >commentary has fallen to nil, so I took a crack at updating based on the last >call comments. I'm attaching an rfcdiff of what I would propose as a post-LC >-04, but won't upload it until I get some direction. Looks fine to me. I don't know whether the IANA change should move SHA-1 to "obsolete" or "historic", but IANA can presumably give advice about what the practice has been. R's, John From nobody Sun Aug 20 11:00:28 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2831321EC for ; Sun, 20 Aug 2017 11:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 pF_kXGkWQPRu for ; Sun, 20 Aug 2017 11:00:26 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD391321C0 for ; Sun, 20 Aug 2017 11:00:26 -0700 (PDT) Received: from [192.168.195.72] (unknown [65.246.72.82]) (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 CAA86C402C8; Sun, 20 Aug 2017 13:00:24 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1503252024; bh=2apafrBUHYk8rQtIrYGyQ1t8WcerdUcX6mgmqGFoecs=; h=Date:In-Reply-To:References:Subject:To:From:From; b=lW3Rrw9gYQ9/wcfXiKoojOGZSWZDMTCvedKAmtJVGSsoqrsF3Jv5BGuUObU9bRhtH ZtGS2372ImLKnzRs27WxpMt7uQ1jduAMaqsyESgJoQ3a4/D9uKncupZHPCAfS0/qFL R91bddQJLHf7rzSnihEpgFNj2WWC/iapaH2e7a6k= Date: Sun, 20 Aug 2017 18:00:18 +0000 In-Reply-To: <20170820174709.4697.qmail@ary.lan> References: <20170820174709.4697.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: <1FBE750D-6EB1-47F9-B308-02A37FE2B6C8@kitterman.com> Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 18:00:28 -0000 On August 20, 2017 1:47:09 PM EDT, John Levine wrote: >In article <1577948=2Eqipkle3Fep@kitterma-e6430> you write: >>We're within a few hours of the week being up and the rate of >additional=20 >>commentary has fallen to nil, so I took a crack at updating based on >the last=20 >>call comments=2E I'm attaching an rfcdiff of what I would propose as a >post-LC=20 >>-04, but won't upload it until I get some direction=2E > >Looks fine to me=2E I don't know whether the IANA change should move >SHA-1 to "obsolete" or "historic", but IANA can presumably give advice >about what the practice has been=2E Thanks=2E I'm not sure either, so I left it alone=2E Since we aren't remo= ving it from the protocol definition anymore, I think obsolete works with M= UST NOT/MUST NOT better than historic, but whatever IANA suggests, as you s= aid=2E Scott K From nobody Sun Aug 20 22:08:28 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6107C132064 for ; Sun, 20 Aug 2017 22:08:27 -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 6dJhJV9xzhm4 for ; Sun, 20 Aug 2017 22:08:25 -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 845861321A3 for ; Sun, 20 Aug 2017 22:08:24 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id b4so29882013qta.1 for ; Sun, 20 Aug 2017 22:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jPy6xcP6aPTkqLu8JhW64XQreqqfcDDhLHq02KW9OA8=; b=U537xc4MKDe9GMGCa/KzAqmaPvOWwPaYOpq6vxzcIcxky/chopXKUMt0rD3/Y8X41+ P/dPVXzUGaICigfPoyYeJJg4Y5qwkl/Ku8i1V5K6uC+9aRl+pZb2+DC3YUhwsBq1l07r Nb9VHJmym48CzM7W9ebgF4lmohLV81VjgAb2yvMkFKoRpyrf0zl+m3yToKaBOoIjFK92 XB8gte21ietEp/0T6qB5Qlpa174nTSsK7v0+FbjZ5HKFXQSaz80jKE/tIrXLljY9w0rZ rG9ix7bzCfs6qtgexr48f9ldy5K/jMqL72xSf0zlST23nRIX+8q+C3F37VQv0eBFBMrv KnBg== 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=jPy6xcP6aPTkqLu8JhW64XQreqqfcDDhLHq02KW9OA8=; b=dm9EvPbv8BUfhBFUU0U8jJoJTHmPpjSyfbkhVzR+yuNiUA4uE3ZnfTQZH5RPept3uQ QdPmWOcxW9R4PyTTtMYzWrA2krwOLcznj8UcJETWTE1Ex1fNsFoFU/Si7Y3vp0MyNpgu JiKhK6lScJiUyN3JQYMjCUZ38lWEG6Ck3ijeTg8u/YrrDLygKZzwrXCQAxCjU/qEKqYk zQnz73YnzhGZrsIXoRbApphUChoEj2kA+LtKvJVqS5AB0da9bRHb/p2mLe09uswqWqIR FXON7trlQENbf45frE8WupA5uuNe957k+5VSKoZqNr15yUxeMEB7Bu0NTy86V4PcocSH W3+Q== X-Gm-Message-State: AHYfb5g803kG4z6P91e3+F4sWcI8N012a1hxUUiI8T/Sl3BXawYmrV5H kn/h4ydjiHTppdspIZzrNTQ7qduE8A== X-Received: by 10.237.53.221 with SMTP id d29mr22565789qte.79.1503292103488; Sun, 20 Aug 2017 22:08:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Sun, 20 Aug 2017 22:08:22 -0700 (PDT) In-Reply-To: <1577948.qipkle3Fep@kitterma-e6430> References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> <1577948.qipkle3Fep@kitterma-e6430> From: "Murray S. Kucherawy" Date: Sun, 20 Aug 2017 22:08:22 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11c009a8d27b3705573c77c2" Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 05:08:27 -0000 --001a11c009a8d27b3705573c77c2 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 19, 2017 at 12:46 PM, Scott Kitterman wrote: > On Saturday, August 12, 2017 09:58:30 PM Salz, Rich wrote: > > At the IETF meeting last month there was strong consensus to have MUST > NOT > > for both generate and verify using SHA-1. The discussion on the list had > > one major participant opposed, who removed their objection once they > > understood there were two separate documents. > > > > Therefore, we are entering a one-week WG last call. > > > > (Seth, please start preparing your shepherd writeup :) > > > > > > On 8/12/17, 5:55 PM, "IETF Secretariat" > > > wrote: > > > > > > The IETF WG state of draft-ietf-dcrup-dkim-usage has been changed to > "In > > WG Last Call" from "WG Document" by Rich Salz: > > > > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ > > We're within a few hours of the week being up and the rate of additional > commentary has fallen to nil, so I took a crack at updating based on the > last > call comments. I'm attaching an rfcdiff of what I would propose as a > post-LC > -04, but won't upload it until I get some direction. > Hard to tell since the colors showing what's changed aren't rendering for me, but it looks like it's going in the right direction. Only a couple of minor things with this version: - Section 4.1 gives no guidance to verifiers about what to do with smaller keys. It only says it should be able to verify signatures generated with >= 1024-bit keys. Do we want to say SHOULD NOT accept smaller keys? Otherwise, I can accept a 512-bit key and be compliant. I realize it also says the thing about local policy, so we're covered as-is, but I'm surprised we're not sending a stronger message on this point like we did everything else. - Section 6 shouldn't change the Reference column for rsa-sha1 since the place it's actually defined isn't changing. We're only changing the Status column of that entry. As for John's question about what the value should be, Section 7 of RFC6376 stipulates that it has to be either "active" or "historic", so that's our answer there. Late last week I met with Seth, who's getting his process feet wet by shepherding this one, and we went through the process. He should be submitting his writeup and/or contacting Scott either offline or via the list to mention anything outstanding. Once he submits his final writeup we can send it along to Alexey. -MSK --001a11c009a8d27b3705573c77c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 19, 2017 at 12:46 PM, Scott Kitterman <skl= ist@kitterman.com> wrote:
On Sa= turday, August 12, 2017 09:58:30 PM Salz, Rich wrote:
> At the IETF meeting last month there was strong consensus to have MUST= NOT
> for both generate and verify using SHA-1.=C2=A0 The discussion on the = list had
> one major participant opposed, who removed their objection once they > understood there were two separate documents.
>
> Therefore, we are entering a one-week WG last call.
>
> (Seth, please start preparing your shepherd writeup :)
>
>
> On 8/12/17, 5:55 PM, "IETF Secretariat" <ietf-secretariat-reply@ietf.org= >
> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0The IETF WG state of draft-ietf-dcrup-dkim-usage ha= s been changed to "In
> WG Last Call" from "WG Document" by Rich Salz:
>
>=C2=A0 =C2=A0 =C2=A0https://datatra= cker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/

We're within a few hours of the week being up and the rate of ad= ditional
commentary has fallen to nil, so I took a crack at updating based on the la= st
call comments.=C2=A0 I'm attaching an rfcdiff of what I would propose a= s a post-LC
-04, but won't upload it until I get some direction.

Hard to tell since the colors showing what's changed = aren't rendering for me, but it looks like it's going in the right = direction.

Only a couple of minor things with this versio= n:

- Section 4.1 gives no guidance to verifiers about wha= t to do with smaller keys.=C2=A0 It only says it should be able to verify s= ignatures generated with >=3D 1024-bit keys.=C2=A0 Do we want to say SHO= ULD NOT accept smaller keys?=C2=A0 Otherwise, I can accept a 512-bit key an= d be compliant.=C2=A0 I realize it also says the thing about local policy, = so we're covered as-is, but I'm surprised we're not sending a s= tronger message on this point like we did everything else.

- Section 6 shouldn't change the Reference column for rsa-sha1 since = the place it's actually defined isn't changing.=C2=A0 We're onl= y changing the Status column of that entry. As for John's question abou= t what the value should be, Section 7 of RFC6376 stipulates that it has to = be either "active" or "historic", so that's our ans= wer there.

Late last week I met with Seth, who's gett= ing his process feet wet by shepherding this one, and we went through the p= rocess.=C2=A0 He should be submitting his writeup and/or contacting Scott e= ither offline or via the list to mention anything outstanding.=C2=A0 Once h= e submits his final writeup we can send it along to Alexey.

-MSK
--001a11c009a8d27b3705573c77c2-- From nobody Mon Aug 21 07:50:17 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FA6132A5D for ; Mon, 21 Aug 2017 07:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] 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 h5tpgN1DFgh1 for ; Mon, 21 Aug 2017 07:50:12 -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 38C0A126B7E for ; Mon, 21 Aug 2017 07:50:12 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9528FC40312 for ; Mon, 21 Aug 2017 09:50:10 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1503327010; bh=pjO0Xgp/u5kdKjdFCMxxDpNtuSAvhxtoXyBVFjl4rO0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fD+df7zvqrcEZy06Qx+DQ1EL6AN2FPlBJ9nyCvMpHi51bXTpCUIHwSjRx7zAV+XhT MicoWrN3xZAie+l4plWZb9xVkS0RLAYLC2dwErF6lmK30S+KiMHQVT88ChNrS/yyHa f4yfTQd906fI7X7C396kplZHwTrgFkLz7m1EO7Ls= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 21 Aug 2017 10:50:09 -0400 Message-ID: <9404668.thG6NAQU00@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <150257492983.26466.3488799276681870364.idtracker@ietfa.amsl.com> <1577948.qipkle3Fep@kitterma-e6430> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1686695.yve1oFq2ya" Content-Transfer-Encoding: 7Bit Archived-At: Subject: Re: [Dcrup] FW: IETF WG state changed for draft-ietf-dcrup-dkim-usage X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:50:16 -0000 This is a multi-part message in MIME format. --nextPart1686695.yve1oFq2ya Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Sunday, August 20, 2017 10:08:22 PM Murray S. Kucherawy wrote: > On Sat, Aug 19, 2017 at 12:46 PM, Scott Kitterman > > wrote: > > On Saturday, August 12, 2017 09:58:30 PM Salz, Rich wrote: > > > At the IETF meeting last month there was strong consensus to have MUST > > > > NOT > > > > > for both generate and verify using SHA-1. The discussion on the list > > > had > > > one major participant opposed, who removed their objection once they > > > understood there were two separate documents. > > > > > > Therefore, we are entering a one-week WG last call. > > > > > > (Seth, please start preparing your shepherd writeup :) > > > > > > > > > On 8/12/17, 5:55 PM, "IETF Secretariat" > > > > > wrote: > > > The IETF WG state of draft-ietf-dcrup-dkim-usage has been changed to > > > > "In > > > > > WG Last Call" from "WG Document" by Rich Salz: > > > https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ > > > > We're within a few hours of the week being up and the rate of additional > > commentary has fallen to nil, so I took a crack at updating based on the > > last > > call comments. I'm attaching an rfcdiff of what I would propose as a > > post-LC > > -04, but won't upload it until I get some direction. > > Hard to tell since the colors showing what's changed aren't rendering for > me, but it looks like it's going in the right direction. > > Only a couple of minor things with this version: > > - Section 4.1 gives no guidance to verifiers about what to do with smaller > keys. It only says it should be able to verify signatures generated with > > >= 1024-bit keys. Do we want to say SHOULD NOT accept smaller keys? > > Otherwise, I can accept a 512-bit key and be compliant. I realize it also > says the thing about local policy, so we're covered as-is, but I'm > surprised we're not sending a stronger message on this point like we did > everything else. > > - Section 6 shouldn't change the Reference column for rsa-sha1 since the > place it's actually defined isn't changing. We're only changing the Status > column of that entry. As for John's question about what the value should > be, Section 7 of RFC6376 stipulates that it has to be either "active" or > "historic", so that's our answer there. > > Late last week I met with Seth, who's getting his process feet wet by > shepherding this one, and we went through the process. He should be > submitting his writeup and/or contacting Scott either offline or via the > list to mention anything outstanding. Once he submits his final writeup we > can send it along to Alexey. Thanks. Updated again. Revised diff from -03 attached. I'll upload this soonish unless someone else has any more feedback. Scott K --nextPart1686695.yve1oFq2ya Content-Disposition: attachment; filename="draft-ietf-dcrup-dkim-usage-from--03.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-ietf-dcrup-dkim-usage-from--03.diff.html" Diff: draft-ietf-dcrup-dkim-usage-03.txt - draft-ietf-dcrup-dkim-usage.txt
 draft-ietf-dcrup-dkim-usage-03.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) July 31, 2017 Updates: 6376 (if approved) August 21, 2017
Intended status: Standards Track Intended status: Standards Track
Expires: February 1, 2018 Expires: February 22, 2018
Cryptographic Algorithm and Key Usage Update to DKIM Cryptographic Algorithm and Key Usage Update to DKIM
draft-ietf-dcrup-dkim-usage-03 draft-ietf-dcrup-dkim-usage-04
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 February 1, 2018. This Internet-Draft will expire on February 22, 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. The rsa-sha256 Signing Algorithm . . . . . . . . . . . . 3 4.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4.3. Other Algorithms . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
5. The DKIM-Signature Header Field . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Key Management and Representation . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 4
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 4
9.1. Normative References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
9.2. Informative References . . . . . . . . . . . . . . . . . 6
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
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.
2. Introduction 2. Introduction
skipping to change at page 3, line 8 skipping to change at page 2, line 50
[VULNOTE], the operational community has recognized that shorter keys [VULNOTE], the operational community has recognized that shorter keys
compromise the effectiveness of DKIM. While 1024 bit signatures are compromise the effectiveness of DKIM. While 1024 bit signatures are
common, stronger signatures are not. Widely used DNS configuration common, stronger signatures are not. Widely used DNS configuration
software places a practical limit on key sizes, because the software software places a practical limit on key sizes, because the software
only handles a single 256 octet string in a TXT record, and RSA keys only handles a single 256 octet string in a TXT record, and RSA keys
significantly longer than 1024 bits don't fit in 256 octets. significantly longer than 1024 bits don't fit in 256 octets.
Due to the recognized weakness of the sha1 hash algorithm, see Due to the recognized weakness of the sha1 hash algorithm, see
[RFC6194], and the wide availability of the sha256 hash algorithm (it [RFC6194], and the wide availability of the sha256 hash algorithm (it
has been a required part of DKIM [RFC6376] since it was originally has been a required part of DKIM [RFC6376] since it was originally
standardized in 2007, the sha1 hash algorithm is removed from the standardized in 2007, the sha1 hash algorithm MUST NOT be used. This
protocol. This is being done now to allow the operational community is being done now to allow the operational community time to fully
time to fully shift to sha256 in advance of any sha1 related crisis. shift to sha256 in advance of any sha1 related crisis.
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 replaces [RFC6376] Section 3.3 in its entirety. This section updates [RFC6376] Section 3.3.
Generally, DKIM supports multiple digital signature algorithms. One
algorithm, rsa-sha256, is currenlty defined. Signers MUST implement
and sign using rsa-sha256. Verifiers MUST implement and verify using
rsa-sha256.
4.1. The rsa-sha256 Signing Algorithm
The rsa-sha256 Signing Algorithm computes a message hash as described DKIM supports multiple digital signature algorithms. Two algorithms
in [RFC6376], Section 3.7 using SHA-256 [FIPS-180-3-2008] as the are defined by this specification at this time: rsa-sha1 and rsa-
hash-alg. That hash is then signed by the Signer using the RSA sha256. Signers MUST sign using rsa-sha256. Verifiers MUST verify
algorithm (defined in PKCS#1 version 1.5 [RFC8017]) as the crypt-alg using rsa-sha256. rsa-sha1 MUST NOT be used for signing or
and the Signer's private key. The hash MUST NOT be truncated or verifying.
converted into any form other than the native binary form before
being signed. The signing algorithm SHOULD use a public exponent of
65537.
4.2. Key Sizes 4.1. Key Sizes
Selecting appropriate key sizes is a trade-off between cost, Selecting appropriate key sizes is a trade-off between cost,
performance, and risk. Since short RSA keys more easily succumb to performance, and risk. Since short RSA keys more easily succumb to
off-line attacks, Signers MUST use RSA keys of at least 1024 bits for off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
all keys. Verifiers MUST be able to validate signatures with keys all keys. Signers SHOULD use RSA keys of at least 2048 bits.
ranging from 1024 bits to 4096 bits, and they MAY be able to validate Verifiers MUST be able to validate signatures with keys ranging from
signatures with larger keys. Verifier policies can use the length of 1024 bits to 4096 bits, and they MAY be able to validate signatures
the signing key as one metric for determining whether a signature is with larger keys. Verifier policies can use the length of the
acceptable. signing key as one metric for determining whether a signature is
acceptable. Verifiers MUST NOT consider signatures using RSA keys of
Factors that should influence the key size choice include the less than 1024 bits as valid signatures.
following:
o The practical constraint that large (e.g., 4096-bit) keys might
not fit within a 512-byte DNS UDP response packet
o The security constraint that keys smaller than 2048 bits may be
subject to off-line attacks
o Larger keys impose higher CPU costs to verify and sign email
o Keys can be replaced on a regular basis; thus, their lifetime can
be relatively short
o The security goals of DKIM [RFC6376] are modest compared to
typical goals of other systems that employ digital signatures
See [RFC3766] for further discussion on selecting key sizes.
4.3. Other Algorithms
The rsa-sha1 was formerly used by DKIM [RFC6376]. Signers MUST NOT
sign with rsa-sha1 and verifiers MUST NOT verify using rsa-sha1.
Other algorithms will be defined in the future. Verifiers MUST
ignore any signatures using algorithms that they do not implement.
5. The DKIM-Signature Header Field
This section updates the a= tag in [RFC6376] Section 3.5.
The text description of the tag is now:
a= The algorithm used to generate the signature (plain-text;
REQUIRED). Verifiers MUST support "rsa-sha256"; Signers MUST
sign using "rsa-sha256". See [RFC6376] Section 3.3 (as updated
by this document) for a description of the algorithms.
The following ABNF element is updated:
ABNF:
sig-a-tag-h = "sha256" / x-sig-a-tag-h
6. Key Management and Representation
This section updates the h= tag in [RFC6376] Section 3.6.1.
The following ABNF element is updated:
ABNF:
key-h-tag-alg = "sha256" / x-key-h-tag-alg
7. 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 the removal of rsa-sha1 from DKIM. resolved due to the removal of rsa-sha1 from DKIM.
8. 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
Algorithms" as follows: Algorithms" as follows:
+------+-----------------+----------+ +------+-----------+----------+
| TYPE | REFERENCE | STATUS | | TYPE | REFERENCE | STATUS |
+------+-----------------+----------+ +------+-----------+----------+
| sha1 | (this document) | obsolete | | sha1 | [RFC6376] | historic |
+------+-----------------+----------+ +------+-----------+----------+
Table 1: DKIM Hash Algorithms Changed Value Table 1: DKIM Hash Algorithms Changed Value
9. References 7. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<http://www.rfc-editor.org/info/rfc3766>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76, "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>. <http://www.rfc-editor.org/info/rfc6376>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<http://www.rfc-editor.org/info/rfc8017>. <http://www.rfc-editor.org/info/rfc8017>.
9.2. Informative References 7.2. Informative References
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<http://www.rfc-editor.org/info/rfc6194>. <http://www.rfc-editor.org/info/rfc6194>.
[VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys [VULNOTE] US-CERT, "Vulnerability Note VU#268267, DomainKeys
Identified Mail (DKIM) Verifiers may inappropriately Identified Mail (DKIM) Verifiers may inappropriately
convey message trust", October 2012. convey message trust", October 2012.
9.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 his DCRUP work that was the source for much of
 End of changes. 18 change blocks. 
112 lines changed or deleted 41 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/
--nextPart1686695.yve1oFq2ya-- From nobody Mon Aug 21 14:47:10 2017 Return-Path: X-Original-To: dcrup@ietf.org Delivered-To: dcrup@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FC71329E8; Mon, 21 Aug 2017 14:47:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dcrup@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150335202252.6835.7335675674015721003@ietfa.amsl.com> Date: Mon, 21 Aug 2017 14:47:02 -0700 Archived-At: Subject: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-04.txt X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 21:47:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DKIM Crypto Update WG of the IETF. Title : Cryptographic Algorithm and Key Usage Update to DKIM Author : Scott Kitterman Filename : draft-ietf-dcrup-dkim-usage-04.txt Pages : 5 Date : 2017-08-21 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 21 14:50:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9CE132AC6 for ; Mon, 21 Aug 2017 14:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 8BZOgym_oftw for ; Mon, 21 Aug 2017 14:49:58 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034CA126CB6 for ; Mon, 21 Aug 2017 14:49:58 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9BC78C40144 for ; Mon, 21 Aug 2017 16:49:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1503352196; bh=3LDsqPErqhk7EIrOvrzadKIzMeqLuYecNQOpUy4LpJI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=haM4mKsbI94SJiHLpEe0o18Rkx3buLWtfDcyzUgg5CeugKycN2vnP9s2FtT9VEeXM xHo0Ab+xXm2ikCA73WszK4yOtGAdHu13IlTGij2kvLL0vmgUQakx3SEJ87flTstexf oSryC2puLZDHVD1Kxdz5kproFCa/S80E/wZ7SfuY= From: Scott Kitterman To: dcrup@ietf.org Date: Mon, 21 Aug 2017 17:49:55 -0400 Message-ID: <3138270.YpZQQM3Y9b@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <150335202252.6835.7335675674015721003@ietfa.amsl.com> References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-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: Mon, 21 Aug 2017 21:50:00 -0000 On Monday, August 21, 2017 02:47:02 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the DKIM Crypto Update WG of the > IETF. > > Title : Cryptographic Algorithm and Key Usage Update to > DKIM Author : Scott Kitterman > Filename : draft-ietf-dcrup-dkim-usage-04.txt > Pages : 5 > Date : 2017-08-21 > > 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-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-04 This is the same as the last diff I posted, except for one small change in Security Considerations where I tweaked the wording slightly to match the rest of the document now that we are merely saying don't use rsa-sha1 vice completely expunging it from the protocol. Hopefully, this means we're done. Scott K From nobody Mon Aug 21 15:25:04 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FCD1329E8 for ; Mon, 21 Aug 2017 15:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0Vi28yeudmF for ; Mon, 21 Aug 2017 15:24:59 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A83312008A for ; Mon, 21 Aug 2017 15:24:59 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id a77so89485583qkb.0 for ; Mon, 21 Aug 2017 15:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=noW2lMhr59war06gOFNfV61o6qktDl828QRdXQiiROM=; b=ASdjig6bDylUliASrnBRuREN0L/OkMcfFN7KUVXLvxSaU1EvYlinRn585xSaiyb7Yj kiMFYOsuRA+CmkYvY7HUVV28tidTqe4KuUVtKUjsQBO1NJM0AEmYfmHhcYoizVKQoONM u2G2UJ2CnqLJdzgNuCUUn2g5/kSKf4EQpfeJkks8lPgSUI2XW8TUHNhTpth99cwZhOUU TS9AuQu2p0F2o+2VQtHcf+e2WRmZOt6DiBM1iZxdr/tHb5FgYG3RnTJfcCUIQYYY4GFa XB9LEzC1QW4Y+W7tVJL4OxTEmY8dHcGQy0L27xSsSTQOUPQrbprcTIx5awSUZBHn6LMm BwMw== 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=noW2lMhr59war06gOFNfV61o6qktDl828QRdXQiiROM=; b=e5LtTOlkfIPFEgsUqkua5XLtg8gmgSNDBPQWUqW+LQy49Xa/Pv7KD0vlKRdf+xd18q lBOlhdqlGyy/9mDESbnddsI8EBSMNoI9UMRZxu1YvVBtVqjRTWOsbgqw2zRQSbsJKnhh ktyob52HYPWac94pJsLO+Kyn/Lz3e+HMT1luYoMnGdRxJa9FQ+JZUd+9mQ4JrNC08Qf/ h2985Pnxi7jh7qgsYwR+Mp+8EWYjMvx4Nb5Zw+VJc/cpzXS6xViNzlNSiTLYjEpcavex FutH75azk0QKKs3Qy1ALBqGnAfNfPv9rCcGbNWBiWXTqpYRMx2n1J8Uc08kCejZJBkR+ DCvA== X-Gm-Message-State: AHYfb5iz7ASKVxRUKQyE6cgGqHJlqaqumC0eGuLZPK+XklYZt+O4vWZ1 0qOf15vvx8eBZ85Gdo5ETQK6IZXPi5t+qZ2WbQ== X-Received: by 10.55.34.73 with SMTP id i70mr23687381qki.313.1503354297958; Mon, 21 Aug 2017 15:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.50 with HTTP; Mon, 21 Aug 2017 15:24:37 -0700 (PDT) In-Reply-To: <3138270.YpZQQM3Y9b@kitterma-e6430> References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <3138270.YpZQQM3Y9b@kitterma-e6430> From: Seth Blank Date: Mon, 21 Aug 2017 15:24:37 -0700 Message-ID: To: dcrup@ietf.org Cc: Scott Kitterman Content-Type: multipart/alternative; boundary="001a11490b36e6d10405574af21a" Archived-At: Subject: Re: [Dcrup] I-D Action: 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: Mon, 21 Aug 2017 22:25:02 -0000 --001a11490b36e6d10405574af21a Content-Type: text/plain; charset="UTF-8" Scott, I'm shepherding this document, and have two questions to complete the writeup on -04: 1) Does this document conform to BCP 78 and 79? There is no listed IPR in the datatracker. 2) The nits ( https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt) show a downreference to rfc8017, and some warnings/comments around RFC boilerplate. Are you OK submitting with these warnings? Once I have the answers to these questions, I'll complete the writeup. Thanks, Seth On Mon, Aug 21, 2017 at 2:49 PM, Scott Kitterman wrote: > On Monday, August 21, 2017 02:47:02 PM internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the DKIM Crypto Update WG of > the > > IETF. > > > > Title : Cryptographic Algorithm and Key Usage Update to > > DKIM Author : Scott Kitterman > > Filename : draft-ietf-dcrup-dkim-usage-04.txt > > Pages : 5 > > Date : 2017-08-21 > > > > 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-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dcrup-dkim-usage-04 > > This is the same as the last diff I posted, except for one small change in > Security Considerations where I tweaked the wording slightly to match the > rest > of the document now that we are merely saying don't use rsa-sha1 vice > completely expunging it from the protocol. > > Hopefully, this means we're done. > > Scott K > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a11490b36e6d10405574af21a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Scott,

I'm shepherding this documen= t, and have two questions to complete the writeup on -04:

1) Does this document conform to BCP 78 and 79? There is no listed = IPR in the datatracker.

2) The nits (https://www.ietf.org/tools/idnits?url=3Dhttp= s://www.ietf.org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt) show a = downreference to rfc8017, and some warnings/comments around RFC boilerplate= . Are you OK submitting with these warnings?

Once = I have the answers to these questions, I'll complete the writeup.
=

Thanks,

Seth

On Mon, Aug 21, 2017 at= 2:49 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On Monday, August 21, 201= 7 02:47:02 PM internet-drafts@i= etf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the DKIM Crypto Update WG of= the
> IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Cryptographic Algorithm and Key Usage Update to
> DKIM Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Scott Kitterman
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-= ietf-dcrup-dkim-usage-04.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : 2017-08-21
>
> Abstract:
>=C2=A0 =C2=A0 The cryptographic algorithm and key size requirements inc= luded when
>=C2=A0 =C2=A0 DKIM was designed in the last decade are functionally obs= olete and in
>=C2=A0 =C2=A0 need of immediate revision.=C2=A0 This document updates D= KIM requirements
>=C2=A0 =C2=A0 to those minimaly suitable for operation with currently s= pecified
>=C2=A0 =C2=A0 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/draf= t-ietf-dcrup-dkim-usage-04
> https://datatracker.ietf.or= g/doc/html/draft-ietf-dcrup-dkim-usage-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?= url2=3Ddraft-ietf-dcrup-dkim-usage-04

This is the same as the last diff I posted, except for one small cha= nge in
Security Considerations where I tweaked the wording slightly to match the r= est
of the document now that we are merely saying don't use rsa-sha1 vice completely expunging it from the protocol.

Hopefully, this means we're done.

Scott K

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



--
=

3D"logo

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols

seth@valim= ail.com
+1-415-894-2724
=
--001a11490b36e6d10405574af21a-- From nobody Mon Aug 21 15:44: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 395A2132AC6 for ; Mon, 21 Aug 2017 15:44:38 -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 Vz-2Nk_iqyNK for ; Mon, 21 Aug 2017 15:44:36 -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 3AD3C132AC0 for ; Mon, 21 Aug 2017 15:44:36 -0700 (PDT) Received: from android-df929938bd25e485.home.kitterman.com (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3C8D0C40499; Mon, 21 Aug 2017 17:44:34 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1503355474; bh=ofTFP/rQoPaeLodJHu28GjPlNTsIm21UeHORLInyPPI=; h=Date:In-Reply-To:References:Subject:To:From:From; b=z0m79tYhq+icKT1ahGY3/M7qDhAXNEPwK8thZY9R9Pv7jcPTE3KK/Z1vrIlH7BOye rkWj/EgQHXgZqyPs+02sEN37HDX8cwEaknPey18YEzN9veiFiw77CO0rWTMvCyw2Rv QSXmOE0zc0sU3lRRFd6DNxlK4g6noFs9ITqg/DlA= Date: Mon, 21 Aug 2017 22:40:28 +0000 In-Reply-To: References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <3138270.YpZQQM3Y9b@kitterma-e6430> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: dcrup@ietf.org From: Scott Kitterman Message-ID: Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-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: Mon, 21 Aug 2017 22:44:38 -0000 On August 21, 2017 6:24:37 PM EDT, Seth Blank wrote: >Scott, > >I'm shepherding this document, and have two questions to complete the >writeup on -04: > >1) Does this document conform to BCP 78 and 79? There is no listed IPR >in >the datatracker=2E To the best of my knowledge, yes=2E >2) The nits ( >https://www=2Eietf=2Eorg/tools/idnits?url=3Dhttps://www=2Eietf=2Eorg/arch= ive/id/draft-ietf-dcrup-dkim-usage-04=2Etxt) >show a downreference to rfc8017, and some warnings/comments around RFC >boilerplate=2E Are you OK submitting with these warnings? Yes=2E >Once I have the answers to these questions, I'll complete the writeup=2E > >Thanks, > >Seth Thanks, Scott K >On Mon, Aug 21, 2017 at 2:49 PM, Scott Kitterman >wrote: > >> On Monday, August 21, 2017 02:47:02 PM internet-drafts@ietf=2Eorg >wrote: >> > A New Internet-Draft is available from the on-line Internet-Drafts >> > directories=2E This draft is a work item of the DKIM Crypto Update WG >of >> the >> > IETF=2E >> > >> > Title : Cryptographic Algorithm and Key Usage >Update to >> > DKIM Author : Scott Kitterman >> > Filename : draft-ietf-dcrup-dkim-usage-04=2Etxt >> > Pages : 5 >> > Date : 2017-08-21 >> > >> > 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=2E This document updates DKIM >requirements >> > to those minimaly suitable for operation with currently >specified >> > algorithms=2E >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker=2Eietf=2Eorg/doc/draft-ietf-dcrup-dkim-usage/ >> > >> > There are also htmlized versions available at: >> > https://tools=2Eietf=2Eorg/html/draft-ietf-dcrup-dkim-usage-04 >> > >https://datatracker=2Eietf=2Eorg/doc/html/draft-ietf-dcrup-dkim-usage-04 >> > >> > A diff from the previous version is available at: >> > https://www=2Eietf=2Eorg/rfcdiff?url2=3Ddraft-ietf-dcrup-dkim-usage-0= 4 >> >> This is the same as the last diff I posted, except for one small >change in >> Security Considerations where I tweaked the wording slightly to match >the >> rest >> of the document now that we are merely saying don't use rsa-sha1 vice >> completely expunging it from the protocol=2E >> >> Hopefully, this means we're done=2E >> >> Scott K >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/dcrup >> From nobody Mon Aug 21 19:55:33 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EA8132AFA for ; Mon, 21 Aug 2017 19:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 CuPkfeRbx7eL for ; Mon, 21 Aug 2017 19:55:30 -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 C6D31132398 for ; Mon, 21 Aug 2017 19:55:29 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id d15so20939436qta.0 for ; Mon, 21 Aug 2017 19:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GZAwIJh94iA/xSg385r6/TF132ZNvazY8KZ+mf/dQjc=; b=PntD1yEMR/Lor8/kcl+v38EB3bTUk5BF8iHJGPziQTxHEN76CYG2FBG6Bq3akLxqdi YRaXgwewSp1D0oo4vZ36MsYmafWjhCKi/tnMjmKkAzw1rbUM3DDokrXXW729a9zxyrnn 4iKboR+qfeLWUHK1865fLq5khW51YjWvZjl5pzI+Qo0v8it0IoSKDevjh6epBFBcR8ow y3+Qts74fpdW0XA9UarhyaBzugaw3sp21vnzi7onDf+r5+s2SJHHFKdTRDfz3HYI/Olt PO1MJDi7oNclECrwJRfXHOssxx+4rJ4LHeiVrfXsujYr8EUp20KtjPI0advW9sstOtmV 8dAQ== 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=GZAwIJh94iA/xSg385r6/TF132ZNvazY8KZ+mf/dQjc=; b=BimOPz+nMYLKxau+rFocLgG21ujMTyIYL6WlD3Qb4aItfR1Qdx2iIivSmPJ3G2Npb9 KbGxfkBR1kaYFodhVarfE7L5wUjuglfwbE0P5LgdsXQuRExhIKFIdbcg0DYeLipPvS3L i2LLhybfetXEsfUmXiQ3hwDK0jay2laCaHSIdQTghiTUTJKerFzXNIT3kLvpgdiyXUxf 3wLXe6KuETVh1bN7qoQf503/AOcwaYL0TAtq5jft+iUojvpQ5LoevVgmEoybBdNpvo8k KBPu0croJxKUq6I/XYFLD0O5BeDyNPofRXfEvyjD7aSeMSEKhQbG2l3eZem+UyrBk3QI 0S8A== X-Gm-Message-State: AHYfb5gXFNcwlaPQ2TCwOD5ASVrYSq2GLEtBBczJXubrUb/JAp4ITkaF murX9MSDj8ibt0g0bg/iES6fh5k++w== X-Received: by 10.200.48.37 with SMTP id f34mr11838583qte.308.1503370528805; Mon, 21 Aug 2017 19:55:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Mon, 21 Aug 2017 19:55:28 -0700 (PDT) In-Reply-To: References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <3138270.YpZQQM3Y9b@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 21 Aug 2017 19:55:28 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a11377fc055da2d05574ebac2" Archived-At: Subject: Re: [Dcrup] I-D Action: 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: Tue, 22 Aug 2017 02:55:32 -0000 --001a11377fc055da2d05574ebac2 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman wrote: > >2) The nits ( > >https://www.ietf.org/tools/idnits?url=https://www.ietf. > org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt) > >show a downreference to rfc8017, and some warnings/comments around RFC > >boilerplate. Are you OK submitting with these warnings? > > Yes. > The nit about the content of Section 7.3 is legitimate. We should either delete it now (my preference since it doesn't add anything), or change it to something like: --BEGIN-- 7.3 Discussion Record [[RFC EDITOR: Please remove this section before publication.]] The content of this draft was discussed on the DCRUP working group mailing list (mailto:dcrup@ietf.org), and the history of that discussion can be found in its archive. --END-- The nit about RFC2119 boilerplate is clearly wrong, and as long as Seth's writeup mentions the downref, I think we're covered. -MSK --001a11377fc055da2d05574ebac2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
>2) The nits (
>https://www.ietf.org/tools/idnits?url=3Dhtt= ps://www.ietf.org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt)
>show a downreference to rfc8017, and some warnings/comments around RFC<= br> >boilerplate. Are you OK submitting with these warnings?

Yes.

--001a11377fc055da2d05574ebac2-- From nobody Mon Aug 21 21:20: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 05AD913233D for ; Mon, 21 Aug 2017 21:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CH2HaCaufjse for ; Mon, 21 Aug 2017 21:20: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 CA5201321B7 for ; Mon, 21 Aug 2017 21:20:42 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3E537C403DC for ; Mon, 21 Aug 2017 23:20:41 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1503375641; bh=Wj7butSjpCjdpmSDu2hRHFSiTUNSZn9aGBoMl6qQzD0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z6VLmmo903UH8tUR1lbgTLxZfG37eJ4KFJZ0Q4fcjZzph1oa0hCwmKtYBAZPdM6gg Bp48bpF3zRbUb7xoLk5gcp+3jNJUCYkWLYVzBVha6NUmL+bwHoeXelCqRlCVjnrmH7 YBy0optw7FN+n0PU5SqpwEP0VUTDscY81U4vQkiM= From: Scott Kitterman To: dcrup@ietf.org Date: Tue, 22 Aug 2017 00:20:40 -0400 Message-ID: <1974257.qbt99DRA5K@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-125-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-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: Tue, 22 Aug 2017 04:20:45 -0000 On Monday, August 21, 2017 07:55:28 PM Murray S. Kucherawy wrote: > On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman > > wrote: > > >2) The nits ( > > >https://www.ietf.org/tools/idnits?url=https://www.ietf. > > > > org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt) > > > > >show a downreference to rfc8017, and some warnings/comments around RFC > > >boilerplate. Are you OK submitting with these warnings? > > > > Yes. > > The nit about the content of Section 7.3 is legitimate. We should either > delete it now (my preference since it doesn't add anything), or change it > to something like: > > --BEGIN-- > 7.3 Discussion Record > > [[RFC EDITOR: Please remove this section before publication.]] > > The content of this draft was discussed on the DCRUP working group mailing > list (mailto:dcrup@ietf.org), and the history of that discussion can be > found in its archive. > > --END-- That's automatically added due to the discussion venue note (section 1). When that's deleted per the existing note to the RFC Editor, 7.3 goes away automagically when passed through xml2rfc again. I don't think we need to do anything. > The nit about RFC2119 boilerplate is clearly wrong, and as long as Seth's > writeup mentions the downref, I think we're covered. It's probably worth mentioning that RFC 3447 is an existing downref in RFC 6376 that this draft merely updates to used the newer RFC since 3447 is obsolete. Also, Seth wrote me privately to mention a typo (inclosed parens in the introduction). I've fixed that in my personal git repo and will upload that with whatever comes next. Scott K From nobody Mon Aug 21 22:25:45 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51281321A2 for ; Mon, 21 Aug 2017 22:25:44 -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 v-QuVuDgINuz for ; Mon, 21 Aug 2017 22:25:42 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C3F13236E for ; Mon, 21 Aug 2017 22:25:42 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id k126so9117522qkb.5 for ; Mon, 21 Aug 2017 22:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kQDIRlPeAGj3YhGI7AqQ9JxohUt90vR04i4TRVVgYTs=; b=Nr8EIbEplFEn8Glp4LGoG8nT7lKTj339wZEQqZRNBe2/uYDwOa9a+MOq0I3bEE5/N/ l5FgSQ45rMJOCxW/fO1P75ieeAtCQAewOioyhPkXUnS1c2Xoe8fK/TD1ABSso9NAbEUO DDNwXjlWYma5a7V4yw5KCenXWxlidhDj7WoDGMuXrL95zplJrPOr8WhJOwxzEdYULII8 czGOksKjbZLye8+YOgPvxqa8cS6br/Mi7xWGnjg2FPc2sictQSkOXUGfVGtMZJ6dVMme c6TIKv/7gaP+Iwgzz/tLPh/5g/qu8W3cpEdE8XitGu0oWOKmXgsaxixj8WJexMmfkNLW C7rQ== 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=kQDIRlPeAGj3YhGI7AqQ9JxohUt90vR04i4TRVVgYTs=; b=Us4VkysBjtdYXs3Q2Mxt+r7FdfPWdgTbQt3/6wb3Sc2rUZvWYQuKerefpEMXs41ux9 TyuJRCi2XMVFSgzaOaXxnm0dtXVDUGein8Rz3bHdJBlCLVZ1SBnLt809Qsj33rlGJp1v THAXIq1abINeenTI+S22gyQCU8GSn26CnWFPGyGXxymfFNYUT973dqkzBiM9A9dmmIN7 3S2Z0/5yLW1HayfqtRrv8vt/6JZIyINGN2gB+fzlWt/qSN7NsRoueIpCxHJEfjhplShH UAKkDL5s1GRif8SSkHDsZ15eZwVtvJdyGy/XF8iwEj5KolV70uT6UpCZ/5U1SHKvlYQk YmFg== X-Gm-Message-State: AHYfb5i4NF9kv7Eo8fVuLNMpDSM6GvZ45BU91UzsnCOyF8bBdkhj9YnJ NBmwWQ7VraLruWXrW3Yg4GWBqlDvkiIp X-Received: by 10.55.118.71 with SMTP id r68mr25307584qkc.234.1503379541357; Mon, 21 Aug 2017 22:25:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Mon, 21 Aug 2017 22:25:40 -0700 (PDT) In-Reply-To: <1974257.qbt99DRA5K@kitterma-e6430> References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <1974257.qbt99DRA5K@kitterma-e6430> From: "Murray S. Kucherawy" Date: Mon, 21 Aug 2017 22:25:40 -0700 Message-ID: To: Scott Kitterman Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c05f7e6867a7f055750d3f7" Archived-At: Subject: Re: [Dcrup] I-D Action: 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: Tue, 22 Aug 2017 05:25:45 -0000 --94eb2c05f7e6867a7f055750d3f7 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 21, 2017 at 9:20 PM, Scott Kitterman wrote: > On Monday, August 21, 2017 07:55:28 PM Murray S. Kucherawy wrote: > > On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman > > > > wrote: > > > >2) The nits ( > > > >https://www.ietf.org/tools/idnits?url=https://www.ietf. > > > > > > org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt) > > > > > > >show a downreference to rfc8017, and some warnings/comments around RFC > > > >boilerplate. Are you OK submitting with these warnings? > > > > > > Yes. > > > > The nit about the content of Section 7.3 is legitimate. We should either > > delete it now (my preference since it doesn't add anything), or change it > > to something like: > > > > --BEGIN-- > > 7.3 Discussion Record > > > > [[RFC EDITOR: Please remove this section before publication.]] > > > > The content of this draft was discussed on the DCRUP working group > mailing > > list (mailto:dcrup@ietf.org), and the history of that discussion can be > > found in its archive. > > > > --END-- > > That's automatically added due to the discussion venue note (section 1). > When > that's deleted per the existing note to the RFC Editor, 7.3 goes away > automagically when passed through xml2rfc again. I don't think we need to > do > anything. > Huh, OK. I haven't seen that added automatically before. > The nit about RFC2119 boilerplate is clearly wrong, and as long as Seth's > > writeup mentions the downref, I think we're covered. > > It's probably worth mentioning that RFC 3447 is an existing downref in RFC > 6376 that this draft merely updates to used the newer RFC since 3447 is > obsolete. > Yeah, I'd also suggest that Seth mention that in the writeup, but the real issue is that the RFC8xxx is a downref that's not already present in the downref registry. Alexey just needs to add it, and in any case needs to call it out in the IETF-wide Last Call according to procedure. Also, Seth wrote me privately to mention a typo (inclosed parens in the > introduction). I've fixed that in my personal git repo and will upload > that > with whatever comes next. > You can save any typos for the next revision, I think. It doesn't need to be sparkling just yet; we still have IETF Last Call to go through. -MSK --94eb2c05f7e6867a7f055750d3f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 21, 2017 at 9:20 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
On Mon= day, August 21, 2017 07:55:28 PM Murray S. Kucherawy wrote:
> On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > >2) The nits (
> > >https://www.ietf.org/tools/idnits?url=3Dhttps://www.ietf.
> >
> > org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt)
> >
> > >show a downreference to rfc8017, and some warnings/comments a= round RFC
> > >boilerplate. Are you OK submitting with these warnings?
> >
> > Yes.
>
> The nit about the content of Section 7.3 is legitimate.=C2=A0 We shoul= d either
> delete it now (my preference since it doesn't add anything), or ch= ange it
> to something like:
>
> --BEGIN--
> 7.3 Discussion Record
>
> [[RFC EDITOR: Please remove this section before publication.]]
>
> The content of this draft was discussed on the DCRUP working group mai= ling
> list (mailto:dcrup@ietf.org), an= d the history of that discussion can be
> found in its archive.
>
> --END--

That's automatically added due to the discussion venue note (sec= tion 1).=C2=A0 When
that's deleted per the existing note to the RFC Editor, 7.3 goes away automagically when passed through xml2rfc again.=C2=A0 I don't think we= need to do
anything.

Huh, OK.=C2=A0 I haven't = seen that added automatically before.

> The nit about RFC2119 boilerplate is clearly wrong, a= nd as long as Seth's
> writeup mentions the downref, I think we're covered.

It's probably worth mentioning that RFC 3447 is an existing down= ref in RFC
6376 that this draft merely updates to used the newer RFC since 3447 is
obsolete.

Yeah, I'd also suggest th= at Seth mention that in the writeup, but the real issue is that the RFC8xxx= is a downref that's not already present in the downref registry.=C2=A0= Alexey just needs to add it, and in any case needs to call it out in the I= ETF-wide Last Call according to procedure.

Also, Seth wrote me privately to mention a typo (inclosed parens in the
introduction).=C2=A0 I've fixed that in my personal git repo and will u= pload that
with whatever comes next.

You can save = any typos for the next revision, I think.=C2=A0 It doesn't need to be s= parkling just yet; we still have IETF Last Call to go through.
-MSK
--94eb2c05f7e6867a7f055750d3f7-- From nobody Tue Aug 22 10:24:02 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC5A1320D9 for ; Tue, 22 Aug 2017 10:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9hz_dqVeoi2 for ; Tue, 22 Aug 2017 10:23:56 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 864E3132026 for ; Tue, 22 Aug 2017 10:23:56 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id k126so17529224qkb.5 for ; Tue, 22 Aug 2017 10:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jsM5/UXgNF3RPgf9Zq3N1lMXkMdYQ0+OwcQ6Hogp6dg=; b=IwDfBVSxhUalSTbUZhbmc/U9Uj+hNVrjXX9LEcU/ZSL7Hhiapczx+deUTSXUiCDRKG O8StItL2c7bjolW4FL/ttu8WT8z+L7G/4NRvoxWQQT+cBxwrDMTqlaNeg+nODhKG0Tt1 MmXqLthX3Avu6NXUTHiAoFwS5X4QJssDCot0XRZDttuuxH3QNy2QDWkgger0RK2xSEp/ ZYTSFxZVZJunvETv1Bm2BqKjHxMJjghN5sZJ8ecQ4ZWbzuK0ga6ZyMSp9SkLltNr3YLg /73K7eowSDPiGuSHALRJL+3BTlYGhHh3Ysp+Y3LjcDnqgseDqxa25t5OicjZaBp19AGR XNTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jsM5/UXgNF3RPgf9Zq3N1lMXkMdYQ0+OwcQ6Hogp6dg=; b=TMEhTmMs3C5MUhhk5yaSh23baAeQVZYgBohhiO/guYJUB5mbVBpRhQOAX4YKiCKp9Y 5ryU3Nhp47mWEWZOh5JJ/u5jUUnsUC6+An/R4M9z7FrWKJHjm/U2E4sbJAgs4G+oJtMA D0pSBN0hx1WGSVCx4z4IJck3/ESmneVNkO1Nh7s/E29ou9oQjeTZUOalsIONPwbGuUIL nlrQeaC8YXmScl99/nxrov2IsyHesflttfDMQY67dGpm2SIhiwUe4IbK6l39meElfUyU F2eCCMlKptIB5AxVyUAVoWFu037PK69E64LmXjez1NX2WgMdE5vHhvpfBTZDmnhL8Nec sjWQ== X-Gm-Message-State: AHYfb5jSnsgSrPlg2AaXd8S4xlrlaLzdtxGlCkVN9+OLIiUSRmDsyJlh Y7j7C0TViZYbhK+CULI4tk04ThtbnaZ2Gsh35Q== X-Received: by 10.55.214.156 with SMTP id p28mr2045953qkl.144.1503422635497; Tue, 22 Aug 2017 10:23:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.42.50 with HTTP; Tue, 22 Aug 2017 10:23:35 -0700 (PDT) In-Reply-To: References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <1974257.qbt99DRA5K@kitterma-e6430> From: Seth Blank Date: Tue, 22 Aug 2017 10:23:35 -0700 Message-ID: To: dcrup@ietf.org, dcrup-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary="001a1147a46422f83d05575adca3" Archived-At: Subject: Re: [Dcrup] I-D Action: 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: Tue, 22 Aug 2017 17:24:00 -0000 --001a1147a46422f83d05575adca3 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 21, 2017 at 10:25 PM, Murray S. Kucherawy wrote: > On Mon, Aug 21, 2017 at 9:20 PM, Scott Kitterman > wrote: > >> On Monday, August 21, 2017 07:55:28 PM Murray S. Kucherawy wrote: >> > On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman >> > >> > wrote: >> > > >2) The nits ( >> > > >https://www.ietf.org/tools/idnits?url=https://www.ietf. >> > > >> > > org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt) >> > > >> > > >show a downreference to rfc8017, and some warnings/comments around >> RFC >> > > >boilerplate. Are you OK submitting with these warnings? >> > > >> > > Yes. >> > >> > The nit about the content of Section 7.3 is legitimate. We should >> either >> > delete it now (my preference since it doesn't add anything), or change >> it >> > to something like: >> > >> > --BEGIN-- >> > 7.3 Discussion Record >> > >> > [[RFC EDITOR: Please remove this section before publication.]] >> > >> > The content of this draft was discussed on the DCRUP working group >> mailing >> > list (mailto:dcrup@ietf.org), and the history of that discussion can be >> > found in its archive. >> > >> > --END-- >> >> That's automatically added due to the discussion venue note (section 1). >> When >> that's deleted per the existing note to the RFC Editor, 7.3 goes away >> automagically when passed through xml2rfc again. I don't think we need >> to do >> anything. >> > > Huh, OK. I haven't seen that added automatically before. > > > The nit about RFC2119 boilerplate is clearly wrong, and as long as Seth's >> > writeup mentions the downref, I think we're covered. >> >> It's probably worth mentioning that RFC 3447 is an existing downref in RFC >> 6376 that this draft merely updates to used the newer RFC since 3447 is >> obsolete. >> > > Yeah, I'd also suggest that Seth mention that in the writeup, but the real > issue is that the RFC8xxx is a downref that's not already present in the > downref registry. Alexey just needs to add it, and in any case needs to > call it out in the IETF-wide Last Call according to procedure. > I've updated the write up to cover this. I believe the write up is now complete. Can the chairs confirm? > > Also, Seth wrote me privately to mention a typo (inclosed parens in the >> introduction). I've fixed that in my personal git repo and will upload >> that >> with whatever comes next. >> > > You can save any typos for the next revision, I think. It doesn't need to > be sparkling just yet; we still have IETF Last Call to go through. > > -MSK > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > > -- [image: logo for sig file.png] Bringing Trust to Email Seth Blank | Head of Product for Open Source and Protocols seth@valimail.com +1-415-894-2724 <415-894-2724> --001a1147a46422f83d05575adca3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 21, 2017 at 10:25 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
<= div dir=3D"ltr">On Mon, Aug 21, 2017 at 9:20 PM, Sco= tt Kitterman <sklist@kitterman.com> wrote:
On Monday, August 21,= 2017 07:55:28 PM Murray S. Kucherawy wrote:
> On Mon, Aug 21, 2017 at 3:40 PM, Scott Kitterman <sklist@kitterman.com>
>
> wrote:
> > >2) The nits (
> > >https://www.ietf.org/tools/id<= wbr>nits?url=3Dhttps://www.ietf.
> >
> > org/archive/id/draft-ietf-dcrup-dkim-usage-04.txt)
> >
> > >show a downreference to rfc8017, and some warnings/comments a= round RFC
> > >boilerplate. Are you OK submitting with these warnings?
> >
> > Yes.
>
> The nit about the content of Section 7.3 is legitimate.=C2=A0 We shoul= d either
> delete it now (my preference since it doesn't add anything), or ch= ange it
> to something like:
>
> --BEGIN--
> 7.3 Discussion Record
>
> [[RFC EDITOR: Please remove this section before publication.]]
>
> The content of this draft was discussed on the DCRUP working group mai= ling
> list (mailto:dcrup= @ietf.org), and the history of that discussion can be
> found in its archive.
>
> --END--

That's automatically added due to the discussion venue note (sec= tion 1).=C2=A0 When
that's deleted per the existing note to the RFC Editor, 7.3 goes away automagically when passed through xml2rfc again.=C2=A0 I don't think we= need to do
anything.

Huh, OK.=C2=A0 I haven= 't seen that added automatically before.

> The nit about RFC2119 boilerplate is clearly wrong, and as long = as Seth's
> writeup mentions the downref, I think we're covered.

It's probably worth mentioning that RFC 3447 is an existing down= ref in RFC
6376 that this draft merely updates to used the newer RFC since 3447 is
obsolete.

Yeah, I'd also sug= gest that Seth mention that in the writeup, but the real issue is that the = RFC8xxx is a downref that's not already present in the downref registry= .=C2=A0 Alexey just needs to add it, and in any case needs to call it out i= n the IETF-wide Last Call according to procedure.

I've updated the write up to cover this.= I believe the write up is now complete. Can the chairs confirm?
<= div>=C2=A0


-M= SK

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




--

3D"logo

Seth Blank | Head of Product = for Open Source and Pr= otocols

seth@valimail.com
+1-415-894-2724
--001a1147a46422f83d05575adca3-- From nobody Tue Aug 22 10:48: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 23C54132A0F for ; Tue, 22 Aug 2017 10:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 KFhde0uXttgb for ; Tue, 22 Aug 2017 10:48:48 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE21132A06 for ; Tue, 22 Aug 2017 10:48:48 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7MHlbxw017542; Tue, 22 Aug 2017 18:48:46 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=0TgcXsZ6y60rS69Tl4HZk5bPK1+HHcWHtXjY8MZPHRc=; b=GsThiEHyxgwq9yjdC7e/EGyjMnv4qDzSvAlXMehGMCyD+WBmbqFzV4MD8fBOR1tNC5oA /QaTRUY+fiKbsb8OywQIF/IbehyTLwO66JldcOZBeJVWXfU+cl3IKaG62A0UNJpj4bx/ 5dtVjZ2kn+y654gKXYDShYFOXYWRWO6x6fghqmue8Fj1B1z+uOHzA59Szcg8RxbthY1o 9d3SimRGx699TrQE/I1whyrIr2lOUX5BIHBKBiXki5k37UJKNDHFmhSr8AqIC/hn1kD+ gXf6fWCM0kv2sRxMhKfSWEZWflvkKXBtENA0UdE05Zkri9+v/Ti62lqmusYcEktY7xRg 6A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2ceadccnxd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 18:48:45 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7MHkDNs001231; Tue, 22 Aug 2017 13:48:45 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cegnu4bvk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Aug 2017 13:48:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 22 Aug 2017 13:48:44 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 22 Aug 2017 13:48:44 -0400 From: "Salz, Rich" To: Seth Blank , "dcrup@ietf.org" , "dcrup-chairs@tools.ietf.org" Thread-Topic: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-04.txt Thread-Index: AQHTGscN6Y+LSn9DSkyPPK0Vo0gXraKPnFmAgAAJsoCAAARuAIAARz8AgAAXzgCAABIpAIAAyJWA///D+QA= Date: Tue, 22 Aug 2017 17:48:44 +0000 Message-ID: <194F6804-4686-461B-A46D-1E3F8F268111@akamai.com> References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <1974257.qbt99DRA5K@kitterma-e6430> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.162] Content-Type: multipart/alternative; boundary="_000_194F68044686461BA46D1E3F8F268111akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-22_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708220273 Archived-At: Subject: Re: [Dcrup] I-D Action: 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: Tue, 22 Aug 2017 17:48:50 -0000 --_000_194F68044686461BA46D1E3F8F268111akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCsOYICBJJ3ZlIHVwZGF0ZWQgdGhlIHdyaXRlIHVwIHRvIGNvdmVyIHRoaXMuIEkgYmVsaWV2 ZSB0aGUgd3JpdGUgdXAgaXMgbm93IGNvbXBsZXRlLiBDYW4gdGhlIGNoYWlycyBjb25maXJtPw0K DQpUaGUgd3JpdGV1cCBsb29rcyBnb29kIHRvIG1lOyBsZXTigJlzIHNoaXAgaXQg4pi6DQo= --_000_194F68044686461BA46D1E3F8F268111akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <22ACE570CC432147AF1B9A9A583D8A91@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206 MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bhbi5nbWFp bC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnNwYW4uZ21haWwtaG9lbnpiDQoJe21zby1z dHlsZS1uYW1lOmdtYWlsLWhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjE2NTgxNDY4OTU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjUyNzA3NDUxMiA2NzY5ODY5OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkkndmUgdXBkYXRlZCB0aGUgd3JpdGUgdXAg dG8gY292ZXIgdGhpcy4gSSBiZWxpZXZlIHRoZSB3cml0ZSB1cCBpcyBub3cgY29tcGxldGUuIENh biB0aGUgY2hhaXJzIGNvbmZpcm0/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg d3JpdGV1cCBsb29rcyBnb29kIHRvIG1lOyBsZXTigJlzIHNoaXAgaXQgPHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OldpbmdkaW5ncyI+DQpKPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_194F68044686461BA46D1E3F8F268111akamaicom_-- From nobody Tue Aug 22 12:42: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 05B501326ED for ; Tue, 22 Aug 2017 12:42:35 -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 90xvGjPJYG-4 for ; Tue, 22 Aug 2017 12:42:33 -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 6C3791321EC for ; Tue, 22 Aug 2017 12:42:33 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id o63so37780541qkb.3 for ; Tue, 22 Aug 2017 12:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eVDMowDUCxVSz8VP51hzrXuBrG9RJshVfDmoxyW7XOM=; b=YCg36+FkrEzNvSRNZhd92u7EvV56WCzXLEfn4t+mGLHBEBkgbY+TSStKikadaTtNSF JvRsM6Zc+uMHwsMwZ1gn1QoKHbnVvnnB7sJmakIbjZi5eorxZo9iLLDKyhojxA6+aA1r FZZvgeZKn1lxP7VgxKSfiCX5LHcDmNxpM6r4kZ3bBAU2walAapjDbWdM5gPr3VXdbfo0 b2z+53FAq6PbH0WWKVDkJmHVevifaeNEYaExBbC29lsADX/u7GGsKrBagZzkEJazRasH ok4uijzGhcCW0Hi/qgIz4j07e1RAvQIagJypG3uz+TusE3JNXyWxz2QNRLU0uAMYtImf b8vg== 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=eVDMowDUCxVSz8VP51hzrXuBrG9RJshVfDmoxyW7XOM=; b=DKX1rLtxbX8S4Gz0PQZ7ay5Zcfzd3MPtrx+XZIZotbiyMMYnupJujbCCLgejHL2C/I gOIosW8ebJe0Q7uHqfHtLNzYLv/jvvZyJoxFXQzUaAoaYnuMZP3yB5H+Ko7pcGQrLpoQ awdAr2HOYCM2pioXJgXDHf8lUGFoSjG/lSNaXgKzabsI+VLqA7z01X7s2d7qgo3QJtzP A39GXPs1Kd9M++tSZKQv8Qof5+jwzmpTBR5QntPHvW4WZ4+CiR2cybHEJ5pOd0DdIUWI gDpmZaqlSsg3oPHe7+HOJubdyNKWVIpXSA3qg5g7eLmKLDwcSip8bBt24TuqLihuKoPv NY7A== X-Gm-Message-State: AHYfb5ih1V8FQuMYztK/ws9GzG7Fwm4q8N92PND8LOiZwBpwnkBNxUml kaVzyut+GaVwkWXjaVam+djTTZYq4g== X-Received: by 10.233.237.145 with SMTP id c139mr373361qkg.328.1503430952266; Tue, 22 Aug 2017 12:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Tue, 22 Aug 2017 12:42:31 -0700 (PDT) In-Reply-To: <194F6804-4686-461B-A46D-1E3F8F268111@akamai.com> References: <150335202252.6835.7335675674015721003@ietfa.amsl.com> <1974257.qbt99DRA5K@kitterma-e6430> <194F6804-4686-461B-A46D-1E3F8F268111@akamai.com> From: "Murray S. Kucherawy" Date: Tue, 22 Aug 2017 12:42:31 -0700 Message-ID: To: "Salz, Rich" Cc: Seth Blank , "dcrup@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0970d8dab1f005575ccb64" Archived-At: Subject: Re: [Dcrup] I-D Action: 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: Tue, 22 Aug 2017 19:42:35 -0000 --94eb2c0970d8dab1f005575ccb64 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2017 at 10:48 AM, Salz, Rich wrote: > =C3=98 I've updated the write up to cover this. I believe the write up = is > now complete. Can the chairs confirm? > > The writeup looks good to me; let=E2=80=99s ship it J > > It's away. -MSK --94eb2c0970d8dab1f005575ccb64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 22, 2017 at 10:48 AM, Salz, Rich <rsalz@akamai= .com> wrote:

=C2=A0=C3=98=C2=A0 I've updated the write up to cover this. I believe= the write up is now complete. Can the chairs confirm?

The writeup looks good to me; let=E2=80=99s ship it = J



It's away.

-MSK
--94eb2c0970d8dab1f005575ccb64-- From nobody Wed Aug 30 11:25:42 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE71132803 for ; Wed, 30 Aug 2017 11:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=SkI9uovO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AgxGn/eE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gTRVFROhd9c for ; Wed, 30 Aug 2017 11:25:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2758B1326EA for ; Wed, 30 Aug 2017 11:25:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 17F5421C38 for ; Wed, 30 Aug 2017 14:25:35 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 30 Aug 2017 14:25:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=9wP/6v9HgrU3JUrz+ycaBLjZb7Wakv74nMiHq13W1tc=; b=SkI9uovO rEHC2pCbStt7LWHFNpvplMuslarfOitp7+LS5t0+v3Cc4p60PhGmyYOSDxFzLtXW EtEWwfbf//vdv4L/sKWpdAsS6zmaAviXEKBm7CULKH16m3v8ovlsjVfp4LdmBuAb b4po5TtogTZ5XbgRZ6yvUWuKTbvdKbQ1eJiRWfO3AS287n2hfVagE6EG5wgmzD7a tD0RllSZS53UXESSUxTPvnTeyGlAPB1TW1cNstQLvl/eX8vNXGzVU8tkRo4Gqo+4 a2rB5XSdCEYBcE1IWDOXLRpIjn7EZJf6HVWtCRgDRG1C07Az75qaf2WebBEPLVAy vHHBwvaDFAKzoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=9wP/6v9HgrU3JUrz+ycaBLjZb7Wak v74nMiHq13W1tc=; b=AgxGn/eEblGoBoVC9rpdThgy4eWxtHhqrmo9Z0m9YkwyH ZrMkWKMUQDmZzwNncBGGK2tbrpt2r1tlu+rta5GP5YCPJLzyiuxD6HFlhQX9rUck QChNR9DmE4+/V2/nciWrIaY2iN7H4RbnNGbi8MUCBzJjvZShRhWejDuD6fZXyJ1t WPIg97AkEJHiSc8xUopsDwlW1kGwDNzcIMMx9r/OEQZkxcQtBz5CULEmWC0xmD1z mjaN4hvstoQ4ZW1gR6Fgn9Bzg7k6+QjRAT0k7HAmlwhLSwD3Fnpj6tnLJ04v+krh erNNUS8SdE3lTtcnAyk5dbsalrqml9LJ05qBq8KPQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E254B9E2AC; Wed, 30 Aug 2017 14:25:34 -0400 (EDT) Message-Id: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> From: Alexey Melnikov To: 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-13b5a8c9 Date: Wed, 30 Aug 2017 19:25:34 +0100 Archived-At: Subject: [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, 30 Aug 2017 18:25:40 -0000 Hi, The document looks good enough for the IETF LC, so I've requested it. I have one small comment, which you should address (or at least discuss) during/after IETF LC: It would be good to say that Section 4.1 replaces Section 3.3.3 from RFC 6376. (I think 3.3.2 and 3.3.4 still remain relevant and are unaffected by this draft). Thank you, Alexey From nobody Wed Aug 30 11:30:05 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3C132936 for ; Wed, 30 Aug 2017 11: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 6XsK9-VY20qz for ; Wed, 30 Aug 2017 11:29:54 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07FA13292F for ; Wed, 30 Aug 2017 11:29:53 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id l65so31590399qkc.0 for ; Wed, 30 Aug 2017 11:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/taaYjpEcFEE2H5zesL4bTi5b0IYUi2uFSPGHDKOyyQ=; b=FxX6GuO7Vggi9RycDHN3iLXlkBdECJHhr1PN57irDkfKhs0bT7Uy1HYd1hdYfTr9q5 1ecxVWSol+ELm+OnFD6lz5F5ocP4EPPUpvoV6zOY/wUjg6Ng5nQB+9ALer0s9m9DB9Dr omdhcyJiNz3YLwdW16WPpt8GO2aC+CWZW1x/1Ii7s+iDpnHALHSGo1eOui/SerWhYFfO x/wTCWLLG9QVUEMYk/G/sFFVXdSF7jM7H+gG4KUyYc8oKDk1toSbgQN8wTo7O9LiQ0wk B1vMl7H6jmUEagNRayprlsCTwdRTa6ojri64IIa3afQnX3Mmuilfb14vfpY/zKwSS+94 cEzA== 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=/taaYjpEcFEE2H5zesL4bTi5b0IYUi2uFSPGHDKOyyQ=; b=YA15dquZkqBppAz5N+KJk5s2swq6ZwIJMDAwVU5ADdQuRS2+kkAFYZSDGRoRgs2qzN 0FrY8OGHj3LNAwiC1F4ilFwJFfJaNv76Jd7EjfCHNTEfPZZ6GZWvIEB7GiaHwkrS3jQJ 2WlvvLlhT0vrrMcvysT4V0dtJ/7bkiTtxof/4AGiZXD/44ZaYDSoVbxltKzm5pQdD9/H xGbDEmx1e8CpBmXGelWMklwfeKJ+HihT1GQ3EDDsr4eUFvqi6mt8jI9442QbZcxE5ADZ BxiNld4PKloNxkx5yW/QmSgrAt24AqFj5Zu1vi66KNbOYvGxrLHi2duhQ/rg7YzUR9MC C4xg== X-Gm-Message-State: AHPjjUgW8DoIinRF36SrVgFQNMKTEHJ5yyMVjcc1OeM0eaSbA6HPziyE enlAOsti1+abGARGJeWU5cNa8JG5tDpT X-Received: by 10.55.154.3 with SMTP id c3mr248002qke.241.1504117792854; Wed, 30 Aug 2017 11:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Wed, 30 Aug 2017 11:29:52 -0700 (PDT) In-Reply-To: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Wed, 30 Aug 2017 11:29:52 -0700 Message-ID: To: Alexey Melnikov Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="94eb2c053408be57bb0557fcb637" 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, 30 Aug 2017 18:29:58 -0000 --94eb2c053408be57bb0557fcb637 Content-Type: text/plain; charset="UTF-8" The first line in Section 4 already says this updates 3.3 of RFC6376. You think we need to be more specific? On Wed, Aug 30, 2017 at 11:25 AM, Alexey Melnikov wrote: > Hi, > The document looks good enough for the IETF LC, so I've requested it. > > I have one small comment, which you should address (or at least discuss) > during/after IETF LC: > > It would be good to say that Section 4.1 replaces Section 3.3.3 from RFC > 6376. (I think 3.3.2 and 3.3.4 still remain relevant and are unaffected > by this draft). > > Thank you, > Alexey > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup > --94eb2c053408be57bb0557fcb637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The first line in Section 4 already says this updates 3.3 = of RFC6376.=C2=A0 You think we need to be more specific?

On Wed, Aug 30, 2017 at 11= :25 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:=
Hi,
The document looks good enough for the IETF LC, so I've requested it.
I have one small comment, which you should address (or at least discuss) during/after IETF LC:

It would be good to say that Section 4.1 replaces Section 3.3.3 from RFC 6376. (I think 3.3.2 and 3.3.4 still remain relevant and are unaffected
by this draft).

Thank you,
Alexey

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

--94eb2c053408be57bb0557fcb637-- From nobody Wed Aug 30 11:33:10 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778DA13234B for ; Wed, 30 Aug 2017 11:33:09 -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=P6bJ4ln/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lHEYBRBL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b5jXUiyceco for ; Wed, 30 Aug 2017 11:33:07 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3D351326EA for ; Wed, 30 Aug 2017 11:33:07 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D2FDF20CCE; Wed, 30 Aug 2017 14:33:05 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Wed, 30 Aug 2017 14:33:05 -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=8fT6zt6jzHApL2KYIDcS383xXyRdz Lazm12qmR6xI5Y=; b=P6bJ4ln/TpNTDZXZuYb7X2m0p3ve1Od/wRObbk8+/gCOB JnjMYDi8gLbv2mIrmDBL9GBugSRhEeRATBYZNJDMra0hfebixLAD5rpbY2q8JdaU fkBMPHsm4YY9MoM4RFWStm+CCHOtWpZk7/RQsTVdY/Nru4q0Q6w+PtZ1yx/i6c5b 939pCDnEpgOMOQYQpvsVpwUddwordbmCKu0JHVtNRy9fOPKuwiEko6PLb9dF309S gBl8uEd0UgU/MEQ49jtZcvTJbAtyfvoeQy93ZALvJp/iWO5tMJgW7FdLZn/6+UpG fPVbK6sR16qAtryr8JOjhC8vTJKqAA/arCX2ijUOQ== 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=8fT6zt 6jzHApL2KYIDcS383xXyRdzLazm12qmR6xI5Y=; b=lHEYBRBLL2ULTunw756S1A IoJvUJYLPBOxCyHXIgbR5NonXS/pvvU0hKHYMtYeWKWVXmo1h8xULZc5wRUkaX4Y JtpneoseY5lt6hYc0ksSZ9TN+MFYMXXJlsOEf4kyFYq7sAGULU8KsHHG4DdI5Qv/ YlBbwMoqwQis1lNWsnSfZXXNCnSWTt0HOrZUHCXMOEmM2SOqoaapuRSp9fnryWUo jbvXNnSi91/PaL4XKY8v8TQJ9YMugn3D6kMO9YLzZRE/6MEn/+8DcWQGeijEB2Wu jv7eCywnQAmynrCALkMwE1MXc/IC/OvMCYRURce6uFdPPsuO+2MCkHyH78caiRFw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B4FD79E2AC; Wed, 30 Aug 2017 14:33:05 -0400 (EDT) Message-Id: <1504117985.498428.1090164600.651D13E7@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="_----------=_15041179854984281" X-Mailer: MessagingEngine.com Webmail Interface - ajax-13b5a8c9 In-Reply-To: References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> Date: Wed, 30 Aug 2017 19:33:05 +0100 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, 30 Aug 2017 18:33:09 -0000 This is a multi-part message in MIME format. --_----------=_15041179854984281 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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. > > On Wed, Aug 30, 2017 at 11:25 AM, Alexey Melnikov > wrote:>> Hi, >> The document looks good enough for the IETF LC, so I've requested it.>> >> I have one small comment, which you should address (or at least >> discuss)>> during/after IETF LC: >> >> It would be good to say that Section 4.1 replaces Section 3.3.3 >> from RFC>> 6376. (I think 3.3.2 and 3.3.4 still remain relevant and are >> unaffected>> by this draft). >> >> Thank you, >> Alexey >> >> _______________________________________________ >> Dcrup mailing list >> Dcrup@ietf.org >> https://www.ietf.org/mailman/listinfo/dcrup --_----------=_15041179854984281 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
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.


On Wed, Aug 30, 2017 at 11:25 AM, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
Hi,
The document looks good enough for the IETF LC, so I've requested it.

I have one small comment, which you should address (or at least discuss)
during/after IETF LC:

It would be good to say that Section 4.1 replaces Section 3.3.3 from RFC
6376. (I think 3.3.2 and 3.3.4 still remain relevant and are unaffected
by this draft).

Thank you,
Alexey

_______________________________________________
Dcrup mailing list

--_----------=_15041179854984281-- From nobody Wed Aug 30 11:34:12 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 8571D1201F8; Wed, 30 Aug 2017 11:34:10 -0700 (PDT) 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.59.0 Auto-Submitted: auto-generated Precedence: bulk CC: dcrup@ietf.org, seth@sethblank.com, dcrup-chairs@ietf.org, alexey.melnikov@isode.com, draft-ietf-dcrup-dkim-usage@ietf.org, Seth Blank Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150411805046.21503.17592531322027521150.idtracker@ietfa.amsl.com> Date: Wed, 30 Aug 2017 11:34:10 -0700 Archived-At: Subject: [Dcrup] Last Call: (Cryptographic Algorithm and Key Usage Update to DKIM) to Proposed Standard X-BeenThere: dcrup@ietf.org X-Mailman-Version: 2.1.22 List-Id: DKIM Crypto Update List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 18:34:11 -0000 The IESG has received a request from the DKIM Crypto Update WG (dcrup) to consider the following document: - 'Cryptographic Algorithm and Key Usage Update to DKIM' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) From nobody Wed Aug 30 11:53: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 3537313243E for ; Wed, 30 Aug 2017 11:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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=DTvjKk8T; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=D4KGO1Xk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4FPUCpt8a3h for ; Wed, 30 Aug 2017 11:53:15 -0700 (PDT) Received: from pop3.winserver.com (news.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7D1321CB for ; Wed, 30 Aug 2017 11:53:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=583; t=1504119190; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=sJkwFRY2WTWjZJCuseEhyHh17IQ=; b=DTvjKk8TBXK5SwWaKfUZX4kioVm/MjYw4Yp8jaLL8136WKYG1v+e+88NHxpBYu KkHKL3nRA+UEvqjwNb+IJWMWx6KXZyxNAhI0ohDUS7rRhvRstQuoH5VaVQTCFX7z 7tf0VFAY7wlBTlrhaeFUfg0cgCjQscthoZJZIoCz5Z6aU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Wed, 30 Aug 2017 14:53:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 4183032454.75665.2572; Wed, 30 Aug 2017 14:53:09 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=583; t=1504119188; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UN+bpOx 0hxuwtA3jAX7K9FnRpr1s6RTPViOEq/KvyLA=; b=D4KGO1Xkufo2Nn8QXkY6mEX 99l0s8J0wMyLlNy2fJO17gFxNubt8DPbFCxc3YrGuYReEA6D2jTzJINuoV1pcBNY 6vi2WsOWYo7+Dx72fVrWavxz+GgSgLHGP0nn86L4qEWvDmQEtaSDTOJ1yXLjHUlC UPsVKpM9SUiPY7OqbbWc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dcrup@ietf.org; Wed, 30 Aug 2017 14:53:08 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1067005531.9.28764; Wed, 30 Aug 2017 14:53:07 -0400 Message-ID: <59A70995.5020509@isdg.net> Date: Wed, 30 Aug 2017 14:53:09 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dcrup@ietf.org References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> In-Reply-To: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Wed, 30 Aug 2017 18:53:18 -0000 On 8/30/2017 2:25 PM, Alexey Melnikov wrote: > Hi, > The document looks good enough for the IETF LC, so I've requested it. > > I have one small comment, which you should address (or at least discuss) > during/after IETF LC: > > It would be good to say that Section 4.1 replaces Section 3.3.3 from RFC > 6376. (I think 3.3.2 and 3.3.4 still remain relevant and are unaffected > by this draft). > I'm reading (how I want to interpret it) the draft guidelines behind this document as an update to to the STD methods deployed, not as an replacement. Thanks -- HLS From nobody Wed Aug 30 17:11: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 627FB132969 for ; Wed, 30 Aug 2017 17:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ux6B60YPz3rs for ; Wed, 30 Aug 2017 17:11:32 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5B3132332 for ; Wed, 30 Aug 2017 17:11:32 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id v20so5261952qtg.3 for ; Wed, 30 Aug 2017 17:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BuCKjbBkyyZHCo1W0qHSTHDv44wtL4OPKe30evZCUlY=; b=ZakpBT+eG288STMQQuzpJZ1yoJEFGFAMGYC/BtLSEHIsNm2fAjDutT2Qht9cKKbeds L5Cwqc3ykyO/OcOsNp/DRARewebaQ64csAIFUK3YZGorJE7Xp3aFOlbaPB7XuvsDbwGx j9LXB5/UtKQtxoM1rOYIY1ssfOwGXkytYIcMYzRFIoaPAyhHgHquHmQXJCNoLkVxg52N BE3nMew8GKawsGg953RPfVjjVNcyK4whNwx8lZjzDvPjMm/ZufOq7Qt3hh3qTVDoQyl6 2yfr9fTAd3AHIk9onzoc81hL5O3911JqGyJQamf+ifoeJaWmKBDEqx0FFCMZmxaytZ0x Zv5g== 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=BuCKjbBkyyZHCo1W0qHSTHDv44wtL4OPKe30evZCUlY=; b=XyeNaoyfISXWGUEf99br0ZGGCiUCdJYDgyM9qLKnApGyRsm2jYSh0HRWCtL2Nbxt3Y yPuFT2hVPAmglrZCJ676Dt7I/PFC28dLc83poLgXB/me02G5qS1zLIuHYOczr+RC22X2 9v8RD2BALLINvnoy4t714jGPZW+6pihi/WS0BmbmBDNlA8hC7HQ5RmFksg0q7eC6gtlB lVSyJYHYGpp4yWlqEKZqgs7EIrOhuQ/nTP4UeDLd0oBEVaWAicFc2qhC4DpwhLl1Wet4 yR5qC5kAJYM2NKCQnFaFhxwKsAmeqM7ZgijInGNndsRQFpoWqIdS6Tft2h7577V3gYpJ 6jKQ== X-Gm-Message-State: AHYfb5iO3D7W5k/GEmbFAcZvr2CXiXRbIUr9M4jFqp+QUyTnKIp3lzu+ Uja7ArxJ0Oqjar8ZpSlPgT+Gma3jtg== X-Received: by 10.237.63.189 with SMTP id s58mr5180476qth.84.1504138291541; Wed, 30 Aug 2017 17:11:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.57.34 with HTTP; Wed, 30 Aug 2017 17:11:31 -0700 (PDT) In-Reply-To: <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> From: "Murray S. Kucherawy" Date: Wed, 30 Aug 2017 17:11:31 -0700 Message-ID: To: Alexey Melnikov Cc: dcrup@ietf.org Content-Type: multipart/alternative; boundary="001a114722048f7b300558017cd4" 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, 31 Aug 2017 00:11:34 -0000 --001a114722048f7b300558017cd4 Content-Type: text/plain; charset="UTF-8" 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. If it's better to say this updates a specific subsection, then that's also reasonable. I just thought what we have is sufficient. -MSK --001a114722048f7b300558017cd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 30, 2017 at 11:33 AM, Alexey Melnikov <a= amelnikov@fastmail.fm> wrote:
<= div class=3D"gmail_quote">
On Wed, Aug 30, 2017, at 07:29 PM, Murray S. Kuc= herawy wrote:
The first line in Section 4 alre= ady says this updates 3.3 of RFC6376.=C2=A0 You think we need to be more sp= ecific?

As I mentioned: I think sections 3.3.2 and 3.3.4 are still rele= vant. If this document is replacing 3.3 and its subsections, some of this i= s 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= 9;re saying "replaces".=C2=A0 I don't see those as the same t= hing.=C2=A0 What this document says is to my mind treated as an overlay, no= t a replacement; read RFC6376, then read this for current advice, then act.=

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

-MSK
--001a114722048f7b300558017cd4-- From nobody Wed Aug 30 17:22: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 E665D132418 for ; Wed, 30 Aug 2017 17:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pakttDDEKjcH for ; Wed, 30 Aug 2017 17:22:34 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBC813218C for ; Wed, 30 Aug 2017 17:22:33 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id k77so63947350oib.2 for ; Wed, 30 Aug 2017 17:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MAnbi+AvFIycWHTsaFqShMr9DnL+eRwLY0HrB56IiPg=; b=O+DAYlvuTMMsT+YkoAXhltgLi2dEIEwYr2dJ9GefQeQ8xmaZlfHTge8vdolU2on9vJ jpiqlqSraxve466j6f0K9yQLDdjUEWyfHMco70q5yzzaq8zFlPMHzbUzdnJQu21Ymxby +o6blHzDp5BGszRk/fjq4AwcTOT7y8qaLho9yn1e1aM3lRX/HYX3r5q1Q1sszx16mDig vc10ZYsCgQ6QJPQaFYavJzxEJTjGW9VLfaZuzj5wWoivG+kiecUcqvOV+sai/6Nq9sMm QTZ5+XC5oCONczsDr7rtVX4r2DuctniKcbeXvO91QH9KvRtdq6SJmOr3FqOWpBAbtLEH KOdg== 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=MAnbi+AvFIycWHTsaFqShMr9DnL+eRwLY0HrB56IiPg=; b=cGn+buG0L3dmOKjYDqOqzSjdmhaPaXGwshoxnMntaTZfbjPu+ZhorTvtxytoFfBINf 0Nlo7JJktdyNPkk2Hl93iwxNBIstVojb0xzr1fDtBK3F/Td5bpiVi+zhe0OWDhde5KYz sGFzhJ3bLaPYAknJSiKn/1GLRo6bBnHzuYU4MhgxLce9saWrmr9DXdckspLPRnmfw6CL yMvP4mEYpu1kuLPNnX2H0hUEsLHDNCcsnjbFPrM94uH6XlYJNThbCBN/74uxaNBMSADE w408yChR74I3E2DF/ZG/ttzSK0kjTet4e5qEnp6IakcPRh+DuPnMZaIorPbKvpcBU14h FBkg== X-Gm-Message-State: AHYfb5jAg4XTswk8bF2b3b6UuLdvl0tm9kUhU57fgELGHNFJR+TGjJDU Fb+q8dBkr9jaYpiUG0+9BJVdwLDsaw== X-Received: by 10.202.170.20 with SMTP id t20mr3149141oie.38.1504138953309; Wed, 30 Aug 2017 17:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.163 with HTTP; Wed, 30 Aug 2017 17:22:32 -0700 (PDT) In-Reply-To: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> From: Martin Thomson Date: Thu, 31 Aug 2017 10:22:32 +1000 Message-ID: To: Alexey Melnikov Cc: dcrup@ietf.org Content-Type: text/plain; charset="UTF-8" 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, 31 Aug 2017 00:22:36 -0000 Minor editorial notes to add. The last paragraph of the introduction has a parenthetical that is never closed (I think that the ")" belongs after "2007") Though the RFC editor might catch this...when referring to SHA-1 or SHA-256 (the algorithms, rather than the specific tags that are used in DKIM), I would prefer to see the names capitalized with the hyphen. I think that most instances of "sha1" and "sha256" could be altered. You have one instance of "SHA-1". Otherwise, this looks great. On Thu, Aug 31, 2017 at 4:25 AM, Alexey Melnikov wrote: > Hi, > The document looks good enough for the IETF LC, so I've requested it. > > I have one small comment, which you should address (or at least discuss) > during/after IETF LC: > > It would be good to say that Section 4.1 replaces Section 3.3.3 from RFC > 6376. (I think 3.3.2 and 3.3.4 still remain relevant and are unaffected > by this draft). > > Thank you, > Alexey > > _______________________________________________ > Dcrup mailing list > Dcrup@ietf.org > https://www.ietf.org/mailman/listinfo/dcrup From nobody Thu Aug 31 03:58:10 2017 Return-Path: X-Original-To: dcrup@ietfa.amsl.com Delivered-To: dcrup@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6951D132D54 for ; Thu, 31 Aug 2017 03:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 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, 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=eH+kRuxW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SDHR+Ksf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ruLvUdVmtiK for ; Thu, 31 Aug 2017 03:58:06 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B238B132D4F for ; Thu, 31 Aug 2017 03:58:06 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0FE6020BA7; Thu, 31 Aug 2017 06:58:06 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Thu, 31 Aug 2017 06:58:06 -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=DNSJSTLiuMB4S0wfY5iKst+9tBEdH yPUmbD/cBt75BE=; b=eH+kRuxWei/32jkGF/KLhwQvNhDq0c3u61gRdxSbi9rdQ 7Cm1T7SNWmZv4Fz4k3LWD6phua/orCiKmfVTCl88N2q1dzD+cD00zAzxhIHODkZu +fNjHJ2o95NuWIijR+vY4DQP3JllfJ0zaypjZP2HwG997ENPquSoVZuoAhYK+R0Q 0P4TgiQzUtNtfqR6KEAdV/tO3wAZkWevd2GT5oQgLp5j0qAQeB2zN3L7ruMjZNMx 2Ausa1Y0aUej2Q0HjYlp4m0Fr7kkNompWsQhj9QwdV1YPSK9FyivT6GufJrO+Jqh Ubs2FYtHwgt1+z8ZkK+ifqkdc6OwEWXLmeZjBlGjw== 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=DNSJST LiuMB4S0wfY5iKst+9tBEdHyPUmbD/cBt75BE=; b=SDHR+KsfzgAWohWpFHSZkX ZBI9VS6aBPUAj+3qXtE4/Ym+YbUX3uACSiQX0F/dC+yzzD9kFl4Vu0TzP+l6OGSZ gp0ffoWYR1bMN8FI6dsQrTnsoHjF7ON9VXNmEY+PGD83J+FuHPlMtiO1iDyxKSDy GaPwtYvUzcvbHHJDrndNxrYwDxh7Qdr017syFHFGHMz+NE8KadbWP0saw8D2F8uv WvcXc65LGwIH/Yi6GXW3SL7ku1W8lpXYFmrNEvVOZ4rj3tfRPSBh7C5Z87HO+HwK GYFcjvWIxHgsTUHWJIC5Ii2+FI8U5j/H/VJq/AMAoMhY66jgvYVUHGqyEwUpHWbA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E14079E2B5; Thu, 31 Aug 2017 06:58:05 -0400 (EDT) Message-Id: <1504177085.2153024.1090910512.3EA32E07@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="_----------=_150417708521530241" X-Mailer: MessagingEngine.com Webmail Interface - ajax-13b5a8c9 References: <1504117534.496823.1090155768.0E7DA2E2@webmail.messagingengine.com> <1504117985.498428.1090164600.651D13E7@webmail.messagingengine.com> Date: Thu, 31 Aug 2017 11:58:05 +0100 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, 31 Aug 2017 10:58:08 -0000 This is a multi-part message in MIME format. --_----------=_150417708521530241 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" 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. --_----------=_150417708521530241 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
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.
--_----------=_150417708521530241--